Repository navigation
Contest-Panels aufs Raster; Rastersprung schließt sich selbst ab; Submodul auf CP #75 - #402
Merged
Merged
Conversation
…bmodul auf #75 Betreiber 2026-11-05, mit Bild: "hier funktioniert der raster nicht mit der anordnung der fenster" -- Karte, Log und Chat standen schief zum Panadapter. Ursache: Longpaths vier schwebende Fensterklassen rufen aus ihrem moveEvent/resizeEvent snapToGridAfterSettle() und meldeZug(); ein Panel des Contestprogramms zieht sich mit EIGENEM Mauscode (PanelContainerWidget::updateDrag -> move()) und wusste von beidem nichts. Jetzt haengt die Bruecke an jedes Panel einen Ereignisfilter (PanelRaster), der dieselben zwei Aufrufe macht, solange das Panel ein Fenster ist. Schiebt das Raster selbst (EigeneBewegung), ruft der Filter zusaetzlich trySetGeometry(), damit der PanelLayoutManager des Contestprogramms die GERASTERTE Lage speichert. Dabei gefunden, in WindowPlacement selbst: ein gelungener Rastersprung wurde erst im Nachlauf 180 ms spaeter als abgeschlossen vermerkt. Zog der Bediener vorher wieder (jeder Zug startet den Timer neu), fiel der Nachlauf aus, und der naechste Zug auf dieselben Rasterlinien galt als "das System haelt das Fenster fest" -- verworfen. Jetzt gilt der Versuch sofort als erledigt, wenn der Rahmen nach dem setGeometry auf dem Ziel sitzt. Das trifft Longpaths eigene Fenster genauso. WindowPlacementBruecke.h: die Bruecke darf `src` nicht auf dem Include-Pfad haben (das Contestprogramm hat Koepfe gleichen Namens, core/RigctldClient.h), darum ein Kopf ohne weitere Abhaengigkeiten. tst_contestfenster::einPanelRastetNachDemZugEin -- rot ohne Filter (101,127), rot ohne die WindowPlacement-Behebung (101,135), gruen mit beidem. Submodul auf Contestprogramm main nach #75: eingebettet bleibt dessen Menueleiste im Fenster, der Mac zeigt Longpaths (am Geraet gesehen: "Datei / Fenster / Hilfe" mit dem Log-Fenster vorn). Nicht live gesehen. Co-Authored-By: Claude Fable 5.1 <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
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.
Betreiber 2026-11-05, mit Bild: „hier funktioniert der raster nicht mit der anordnung der fenster" — Karte, Log und Chat standen schief zum Panadapter.
Ursache: Longpaths vier schwebende Fensterklassen rufen aus
moveEvent/resizeEventdas Raster (snapToGridAfterSettle) und den Zugmelder; ein Panel des Contestprogramms zieht sich mit eigenem Mauscode und rief nichts davon.Behebung
PanelRaster): dieselben Aufrufe, solange das Panel ein Fenster ist. Nach einem Schub des Rasters zusätzlichtrySetGeometry(), damit das Contestprogramm die gerasterte Lage speichert.WindowPlacementgefunden: ein gelungener Rastersprung galt erst im Nachlauf 180 ms später als abgeschlossen; zog man vorher wieder, fiel der Nachlauf aus und der nächste Zug auf dieselben Linien wurde als „System hält das Fenster fest" verworfen. Jetzt sofort abgeschlossen, wenn der Rahmen sitzt — gilt für alle Fenster.WindowPlacementBruecke.h: Kopf ohne Abhängigkeiten, weil die Brückesrcnicht auf dem Include-Pfad haben darf (gleichnamige Köpfe im Contestprogramm).Prüfung:
tst_contestfenster::einPanelRastetNachDemZugEin— rot ohne Filter (101,127), rot ohne die WindowPlacement-Behebung (101,135), grün mit beidem. Weitere Raster-/Platzierungs-Prüfstände grün (siehe Lauf). Live noch nicht gesehen.🤖 Generated with Claude Code