Der aktive Knopf in der Leiste sieht jetzt aktiv aus - #16
Merged
Merged
Conversation
Martin, 2026-09-28: "wird nicht übernommen" -- zwei Bilder, auf denen verschiedene Seiten vorne lagen (Karte, dann Rotoren) und in der Leiste trotzdem immer dasselbe Kürzel hell wirkte. Der Zustand stimmte: genau der aktive Knopf war checked. Nur SAH man ihm nichts an. Für QToolButton gab es im App-Stylesheet überhaupt keine Regel, und ein flacher Knopf (autoRaise) zeichnet im dunklen Thema gedrückt fast wie nicht gedrückt. Jetzt trägt der aktive Knopf die Akzentfarbe, einen etwas helleren Grund und einen Balken am linken Rand -- wie die Leiste in Longpath. Der Prüfstand dazu setzt ausdrücklich dasselbe Stylesheet wie main.cpp. Ohne diese Zeile prüfte er den nackten Standardstil, der einen gedrückten Knopf von sich aus zeichnet: grün, und das Programm trotzdem falsch. Gemessen wird der Akzent am linken Rand, nicht "irgendwie anders" -- ein reiner Pixelvergleich war in der Gegenprobe auch ohne Regel bei 99 %. Gegenprobe jetzt: ohne Regel 0 % statt 67 %, Test rot. Mit CP_LEISTE_BILD=<pfad> legt der Prüfstand ein Bild der Leiste ab. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Meldungen von Martin, 2026-09-28. "ich habe den rotor-zeiger geändert, aber in der karte war dieser auf null grad." Ohne Draht zum Rotor meldet RotctldClient::azimuthDeg() 0, und stateChanged feuert auch bei jedem erfolglosen Anlauf der Verbindungsprüfung. Jeder dieser Takte schob die 0 in die Karte -- über die Richtung hinweg, die man gerade von Hand gestellt hatte. Der Zeiger blieb auf 31, der Lichtkegel sprang auf 0. Die Richtung kommt jetzt vom Bedienfeld, nicht vom Client: es zeigt, was der Steckplatz verfolgt, ob gemessen oder von Hand gestellt -- dieselbe Regel, nach der auch die Nadel gezeichnet wird. Prüfstand mit beiden Rotoren (31/39), vorher rot: "Zeiger: 31 -- Karte: 0". "im chat gibt es keine optionen - diese sollten dafür dienen, dass ich zb die gruppe wechseln kann." Das Menü gab es längst, samt Chatraum (50, 144/432, Mikrowelle, EME, Kurzwelle und "dem Band folgen") -- nur keinen Knopf, der es öffnet: PanelHeaderBar zeigt den ⚙ erst nach setOptionsAffordanceEnabled(true), und beim Chat fehlte diese Zeile. Der neue Prüfstand geht den Weg zum Menü für jedes Panel, das Optionen hat (Chat, Log, Karte) -- ein Menü, das man prüfen, aber nicht anklicken kann, ist keines. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Martin, 2026-09-28: "schön wäre, wenn wir vielleicht icons dazu
hätten". Aus drei Blättern (A: nur Symbol, 38 px; B: Symbol über
Kürzel, 44 px; C: Symbol und Name, 150 px) hat er C gewählt.
Neun gezeichnete Symbole statt Bilddateien: Log = Zeilen, Rotoren =
Kompass mit Nadel, Karte = Rundsicht mit Kegel, Nächstes Ziel =
Peilung auf einen Punkt, Rate = Balken, Check = Lupe, Bandmap =
Skala, Skeds = Uhr, Chat = Sprechblase. Gezeichnet, weil die Farbe
dem Zustand folgt -- als Dateien wären es achtzehn, die bei der
nächsten Palette wieder nicht passen. Im QIcon stecken beide
Fassungen (Off/On), den Wechsel macht Qt beim Ankreuzen selbst.
Der Name wird beim Zeichnen gekürzt, nicht beim Anlegen: die Breite
steht erst fest, wenn der Knopf sie hat. Zu knapp gerechnet kürzt Qt
selbst noch einmal nach, und zwar in der Mitte ("KARTE ...ERBIN") --
deshalb gehen Symbol, Randbalken, beide Polster und der Abstand
ausdrücklich ab.
Prüfstand: alle neun Knöpfe tragen ein Symbol, das auch wirklich
gezeichnet ist (durchsichtige Fläche wäre nicht null), den Namen und
den vollen Namen als Tooltip.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Martin, 2026-09-28: "die widgets sollte man aber auch wieder per drag and drop rausziehen können, in dem fall nach rechts." Hinein ging es längst durch Ziehen am Panelkopf, hinaus nur per Rechtsklick auf das Leistensymbol -- und den findet man nicht von selbst. Jetzt: Leistenknopf packen, nach rechts ziehen, loslassen. Das Panel liegt dort, wo der Zeiger war, mit der Größe, die es vor dem Hineinlegen hatte. Zwei Dinge, die dabei zu beachten waren. Der Knopf darf beim Ziehen NICHT umschalten: QToolButton kreuzt beim Loslassen an, deshalb geht ein erkannter Zug gar nicht erst an die Basisklasse. Und innerhalb des Bereichs losgelassen heißt "doch nicht" -- sonst risse ein Rutscher beim Umschalten das Panel heraus. Der Prüfstand fährt beides: im Bereich losgelassen bleibt es drin, nach rechts gezogen liegt es auf der Fläche. Ein breites Panel ganz rechts wird dabei auf die Fläche zurückgeschoben, sonst hinge die Hälfte draußen; das steht so in der Erwartung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Funde aus der Live-Prüfung des Herausziehens. Erstens wurde die Zugposition nur EINMAL gemerkt, beim Überschreiten der Losreißschwelle -- also dicht neben dem Knopf, mitten im Seitenbereich. Das Herausziehen galt damit als "doch nicht", und es passierte gar nichts. Jetzt zählt jede Bewegung. Zweitens weist trySetGeometry() ein gesperrtes Panel ab, und Martins Panels sind gesperrt: Skeds kam zwar aus der Leiste, legte sich aber an seinen alten Platz statt dorthin, wo losgelassen wurde. Wer ein Panel eigenhändig herauszieht, verschiebt es absichtlich -- das Schloss schützt vor Versehen, ein Zug quer über den Schirm ist keines. Es bleibt gesperrt, nur dieser eine Handgriff geht durch. Dazu die Klemme auf die Fläche: die besorgt der Layout-Manager sonst selbst, bei einem gesperrten Panel aber nicht -- ein breites Panel ganz rechts abgelegt hinge sonst zur Hälfte draußen. Prüfstand erweitert: gesperrt hineingelegt, herausgezogen, Lage und Schloss geprüft; dazu die Rotorreihe, die ihr eigenes Layoutgesetz hat. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Martin, 2026-09-28: "ich kann nichts herausziehen." Der Leistenknopf ging (das habe ich mit echten Mausereignissen nachgeprüft), gezogen wird aber am PANELKOPF -- spiegelbildlich zum Hineinziehen, und genau das war nicht verdrahtet. Jetzt entscheidet derselbe Griff beide Richtungen: liegt das Panel im Seitenbereich, holt der Zug es heraus, sonst legt er es hinein. Während des Zugs verschiebt sich im Bereich nichts mehr -- dort sitzt das Panel in einem QStackedWidget und füllt ihn aus, Verschieben gäbe nur Gezitter. Die eigentliche Lehre steckt in den Prüfständen: der alte rief dragPanelOutOfSideArea() selbst auf und bewies damit nur die halbe Strecke. Die beiden neuen drücken, bewegen und lassen los -- einmal am Leistenknopf, einmal am Panelkopf. Gegenprobe: ohne die Weiterleitung ist der Kopfzug rot. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Martin, 2026-09-28: "was im chat mich betrifft soll in magenta
gekennzeichnet werden."
Entscheidend ist, was als "betrifft mich" gilt: mein Rufzeichen als
eigenes Wort, irgendwo in der Zeile -- ON4KST schreibt die Anrede
mitten in den Text ("OE5SOS de DL1ABC ..."), ein Empfängerfeld gibt
es nicht. Ein Rufzeichen, das meines als Anfang enthält (OE5SOSX),
schlägt NICHT an, sonst leuchtete die halbe Liste und die Farbe sagte
nichts mehr. Schrägstriche zählen als Teil des Rufzeichens
(OE5SOS/P bleibt ein Treffer, DL1ABC/OE5SOS auch).
Die Zeile steht ganz in Magenta, auch wenn die Station schon
gearbeitet ist: wer mich anspricht, ist wichtiger als die Frage, ob
er schon im Log steht.
Der Ton kommt aus StyleKit (fester Farbton 310°, Sättigung und
Helligkeit vom Text des jeweiligen Themas), damit er in jeder Palette
sticht, ohne zu blenden. Rot wäre hier falsch -- das bleibt der
Warnung.
Das Rufzeichen kommt aus den Einstellungen und wird in
refreshMapWidget() mitgezogen; wer es ändert, hat sofort die richtige
Hervorhebung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beides fand die CI, nicht ich -- macOS war bei beiden grün. **Linux, SegFault in test_seitenbereich.** Der Rückruf beim Herausziehen lief mitten im mouseReleaseEvent des Leistenknopfes. onDragOut nimmt das Panel aus dem Bereich, dabei baut rebuildRail() die Knöpfe neu -- auch den, dessen Handler gerade läuft, und Qt arbeitet danach auf einem toten Objekt weiter. Unter macOS ging das zufällig gut. Der Rückruf läuft jetzt verzögert. Derselbe Fehler wie beim Bandmenü und beim ersten Leisten-Klick: niemals ein Widget aus seinem eigenen Handler heraus löschen. **Windows, Eingabezeile verrutscht.** Nach dem Wiedereinschalten der laufenden Nummer fing das Rufzeichenfeld bei 70 an, seine Spalte bei 185. Die leere Zelle der QSO-Nummer wurde beim Abschalten nur nicht mehr angepasst, aber nie versteckt -- und beim Wiedereinschalten deshalb auch nie wieder gezeigt. Jetzt folgt ihre Sichtbarkeit der Spalte. Dazu zieht setRunningNumberVisible() die Zeile am Ende ausdrücklich nach: setViewMode() baut sie neu, fitColumnsToViewport() ändert danach die Breiten, dazwischen passt sie niemand an. Neuer Prüfstand für den Rückweg (aus und wieder AN), der den Fehler mit genau den Zahlen der Windows-CI reproduziert hat. Gegenprobe: ohne die Sichtbarkeitskorrektur 179 statt 185, Test rot. Ein zusätzlich probiertes verzögertes Nachziehen erwies sich in der Gegenprobe als überflüssig und ist wieder draußen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der macOS-Lauf war rot, wo Linux und Windows grün wurden: in den DXLog-Vollspalten fing das Rufzeichenfeld 6 px vor seiner Spalte an (179 statt 185). Denselben 6-px-Versatz hatte der CI-Mac schon einmal, damals an anderer Stelle -- ein Zeichen, dass die Ursache tiefer liegt als die jeweilige Zelle. Sie liegt in der Methode: die Eingabezeile bekam SPALTENBREITEN und rechnete daraus ihre Positionen nach. Ränder, Gitterlinien und Rundungen summieren sich, und Qt 6.8.3 kommt dabei auf etwas anderes als 6.11.1. Eine Nachrechnung, die der Wahrheit nur nahekommt, driftet auf jeder neuen Qt-Fassung wieder woanders hin. Jetzt bekommen die drei Zellen vor dem Rufzeichen die ABSTÄNDE der Spaltenpositionen, die die Tabelle selbst meldet. Die Flucht stimmt damit per Konstruktion, und versteckte Spalten (Abstand 0) wie eine umsortierte Reihenfolge fallen von allein richtig heraus. Lokal alle vier Fälle deckungsgleich: Kompakt 185/185, Vollspalten 185/185, ohne laufende Nummer 130/130, wieder eingeschaltet 185/185. 107/107. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Martin, 2026-09-28: "wird nicht übernommen" — zwei Bilder, auf denen verschiedene Seiten vorne lagen (Karte, dann Rotoren) und in der Leiste trotzdem immer dasselbe Kürzel hell wirkte.
Der Zustand stimmte, genau der aktive Knopf war
checked. Nur sah man ihm nichts an: fürQToolButtongab es im App-Stylesheet gar keine Regel, und ein flacher Knopf zeichnet im dunklen Thema gedrückt fast wie nicht gedrückt.Jetzt: Akzentfarbe, etwas hellerer Grund, Balken am linken Rand — wie die Leiste in Longpath.
Was der Prüfstand anders macht
Er setzt ausdrücklich dasselbe Stylesheet wie
main.cpp. Ohne diese Zeile prüfte man den nackten Standardstil, der einen gedrückten Knopf von sich aus zeichnet — grün, und das Programm trotzdem falsch. Gemessen wird der Akzent am linken Rand, nicht "irgendwie anders": ein reiner Pixelvergleich war in der Gegenprobe auch ohne Regel bei 99 %.Gegenprobe: ohne Regel 0 % statt 67 %, Test rot. 107/107 grün.
🤖 Generated with Claude Code