Ein langer Tab, etwa der Druck-Tab mit aufgeklapptem Basemap-Bereich, schob den unteren Rand des QGIS-Fensters über den Bildschirm hinaus, statt einen Scrollbalken zu zeigen. Ursache: Qt verlangt für ein Dock mindestens die Höhe seines höchsten Tabs. BaseDockWidget.setWidget packt jetzt jeden Tab eines QTabWidget in einen QScrollArea (widgetResizable, ohne Rahmen). Das gilt auch für Plan41 und Verfahrensgebiet, die ihre Tabs in _init_tabs_with_services() selbst aufbauen; deren Code muss sich nicht ändern. Issue: #104
Wie geprüft
Zuerst die Tests, die den Fehler zeigen (5 neue Tests in tests/test_base_dockwidget.py, vor der Korrektur rot).
python scripts/run_tests.py sn_basis --baseline: GRÜN 464/464, unverändert gegenüber Baseline.
sn_plan41: unverändert gegenüber Baseline. sn_verfahrensgebiet: dieselben 3 „NEU ROT“ und 8 „neu grün“ wie schon vor dieser Änderung (verfahrensgebiet_alkis_komplett, verfahrensgebiet_shape_komplett); sie betreffen keinen geänderten Code, die Baseline von Verfahrensgebiet ist gegenüber unstable verschoben.
QGIS-Test (manuell, 05.10.2026, Daniel): die fünf Prüfschritte aus der Übergabenotiz durchgespielt, alles wie erwartet – senkrechter Scrollbalken statt verlängertem Fenster, Tab-Leiste und aktiver Tab unverändert, kein zusätzlicher Rahmen, waagerechter Scrollbalken bei schmalem Dock, Schließen und Öffnen ohne Fehler.
Änderungen an Verträgen
BaseDockWidget.setWidget überschreibt QDockWidget.setWidget. Neue Funktion base_dockwidget.tabs_mit_scrollbereich(tab_widget).
dock.widget().widget(i) liefert jetzt den Scroll-Bereich, die Tab-Instanz ist ….widget(i).widget(). Eine Suche in allen Fachplugins hat keine Stelle gefunden, die darauf angewiesen ist; closeEvent packt den Scroll-Bereich selbst aus.
qt_wrapper: neu QScrollArea, QFrame, FrameNoFrame (Qt6, Qt5, Mock). Das Mock-Dock und das Mock-Tab-Widget haben die nötigen Methoden bekommen.
Dokumentiert in schnittstellen.md Abschnitt 2 (Projektwissen-Branch docs/104-dock-scrollbereich).
Herkunft der Lösung: Wie gewünscht habe ich zuerst „VLN Karte“ 2.0 (qgis-plugin) und „VLN Karten“ 0.5 (vln_karten) im Profil QGIS4/dev durchgesehen. Keines der beiden hat eine eigene Lösung (kein QScrollArea), ihr Dock-Inhalt ist nur kurz genug. Die Lösung hier ist das übliche Qt-Muster.
Entscheidungen (mit Daniel abgestimmt):
Zentral in BaseDockWidget statt einer Hilfsfunktion, die jedes Fachplugin aufrufen müsste: ein PR statt drei.
Fix beginnt auf unstable, weil es den langen Basemap-Bereich nur dort gibt.
Im QGIS-Test geprüft (05.10.2026, alles wie erwartet):
Plan41- und Verfahrensgebiet-Dock öffnen, im Druck-Tab den Basemap-Bereich aufklappen. Bei kleinem oder halbhohem QGIS-Fenster erscheint ein senkrechter Scrollbalken, und der untere Fensterrand bleibt sichtbar.
Tab-Leiste und Tab-Titel bleiben gleich; es ist derselbe Tab aktiv wie vorher.
Ist das Fenster hoch genug, sieht der Tab aus wie bisher (kein zusätzlicher Rahmen, Inhalt oben ausgerichtet).
Dock schmal ziehen: Wenn nötig erscheint ein waagerechter Scrollbalken, und nichts wird abgeschnitten.
Dock schließen und wieder öffnen: keine Fehlermeldung, die Toolbar-Action wird zurückgesetzt (cleanup() der Tabs läuft).
## Was
Ein langer Tab, etwa der Druck-Tab mit aufgeklapptem Basemap-Bereich, schob den unteren Rand des QGIS-Fensters über den Bildschirm hinaus, statt einen Scrollbalken zu zeigen. Ursache: Qt verlangt für ein Dock mindestens die Höhe seines höchsten Tabs. `BaseDockWidget.setWidget` packt jetzt jeden Tab eines `QTabWidget` in einen `QScrollArea` (`widgetResizable`, ohne Rahmen). Das gilt auch für Plan41 und Verfahrensgebiet, die ihre Tabs in `_init_tabs_with_services()` selbst aufbauen; deren Code muss sich nicht ändern. Issue: #104
## Wie geprüft
- Zuerst die Tests, die den Fehler zeigen (5 neue Tests in `tests/test_base_dockwidget.py`, vor der Korrektur rot).
- `python scripts/run_tests.py sn_basis --baseline`: GRÜN 464/464, unverändert gegenüber Baseline.
- `sn_plan41`: unverändert gegenüber Baseline. `sn_verfahrensgebiet`: dieselben 3 „NEU ROT“ und 8 „neu grün“ wie schon vor dieser Änderung (`verfahrensgebiet_alkis_komplett`, `verfahrensgebiet_shape_komplett`); sie betreffen keinen geänderten Code, die Baseline von Verfahrensgebiet ist gegenüber `unstable` verschoben.
- QGIS-Test (manuell, 05.10.2026, Daniel): die fünf Prüfschritte aus der Übergabenotiz durchgespielt, alles wie erwartet – senkrechter Scrollbalken statt verlängertem Fenster, Tab-Leiste und aktiver Tab unverändert, kein zusätzlicher Rahmen, waagerechter Scrollbalken bei schmalem Dock, Schließen und Öffnen ohne Fehler.
## Änderungen an Verträgen
- `BaseDockWidget.setWidget` überschreibt `QDockWidget.setWidget`. Neue Funktion `base_dockwidget.tabs_mit_scrollbereich(tab_widget)`.
- `dock.widget().widget(i)` liefert jetzt den Scroll-Bereich, die Tab-Instanz ist `….widget(i).widget()`. Eine Suche in allen Fachplugins hat keine Stelle gefunden, die darauf angewiesen ist; `closeEvent` packt den Scroll-Bereich selbst aus.
- `qt_wrapper`: neu `QScrollArea`, `QFrame`, `FrameNoFrame` (Qt6, Qt5, Mock). Das Mock-Dock und das Mock-Tab-Widget haben die nötigen Methoden bekommen.
- Dokumentiert in `schnittstellen.md` Abschnitt 2 (Projektwissen-Branch `docs/104-dock-scrollbereich`).
## Übergabenotiz
**Stand:** fertig, QGIS-Test bestanden. Branch `bugfix/104-dock-scrollbereich` (1 Commit), Doku auf `Projektwissen:docs/104-dock-scrollbereich`.
**Herkunft der Lösung:** Wie gewünscht habe ich zuerst „VLN Karte“ 2.0 (`qgis-plugin`) und „VLN Karten“ 0.5 (`vln_karten`) im Profil QGIS4/dev durchgesehen. Keines der beiden hat eine eigene Lösung (kein `QScrollArea`), ihr Dock-Inhalt ist nur kurz genug. Die Lösung hier ist das übliche Qt-Muster.
**Entscheidungen (mit Daniel abgestimmt):**
- Zentral in `BaseDockWidget` statt einer Hilfsfunktion, die jedes Fachplugin aufrufen müsste: ein PR statt drei.
- Fix beginnt auf `unstable`, weil es den langen Basemap-Bereich nur dort gibt.
**Im QGIS-Test geprüft (05.10.2026, alles wie erwartet):**
1. Plan41- und Verfahrensgebiet-Dock öffnen, im Druck-Tab den Basemap-Bereich aufklappen. Bei kleinem oder halbhohem QGIS-Fenster erscheint ein senkrechter Scrollbalken, und der untere Fensterrand bleibt sichtbar.
2. Tab-Leiste und Tab-Titel bleiben gleich; es ist derselbe Tab aktiv wie vorher.
3. Ist das Fenster hoch genug, sieht der Tab aus wie bisher (kein zusätzlicher Rahmen, Inhalt oben ausgerichtet).
4. Dock schmal ziehen: Wenn nötig erscheint ein waagerechter Scrollbalken, und nichts wird abgeschnitten.
5. Dock schließen und wieder öffnen: keine Fehlermeldung, die Toolbar-Action wird zurückgesetzt (`cleanup()` der Tabs läuft).
## Checkliste
- [x] Nur Änderungen zum Issue
- [x] Keine direkten Qt/QGIS-Importe, keine Debug-`print`
- [x] `changelog.txt` ergänzt
- [x] Wissensbasis nachgezogen (schnittstellen, fallstricke, modulkarte, STATUS, Testkatalog)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Ein langer Tab (Druck-Tab mit aufgeklapptem Basemap-Bereich) schob den
unteren Rand des QGIS-Fensters aus dem Bildschirm, weil Qt für das Dock
die Höhe des höchsten Tabs verlangt. BaseDockWidget.setWidget packt jetzt
jeden Tab eines QTabWidget in einen QScrollArea; das wirkt auch für
Fachplugins, die ihre Tabs selbst aufbauen. QScrollArea/QFrame im
qt_wrapper ergänzt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Daniel
merged commit 3e1431642b into unstable2026-10-05 19:57:13 +00:00
Daniel
deleted branch bugfix/104-dock-scrollbereich2026-10-05 19:57:13 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Was
Ein langer Tab, etwa der Druck-Tab mit aufgeklapptem Basemap-Bereich, schob den unteren Rand des QGIS-Fensters über den Bildschirm hinaus, statt einen Scrollbalken zu zeigen. Ursache: Qt verlangt für ein Dock mindestens die Höhe seines höchsten Tabs.
BaseDockWidget.setWidgetpackt jetzt jeden Tab einesQTabWidgetin einenQScrollArea(widgetResizable, ohne Rahmen). Das gilt auch für Plan41 und Verfahrensgebiet, die ihre Tabs in_init_tabs_with_services()selbst aufbauen; deren Code muss sich nicht ändern. Issue: #104Wie geprüft
tests/test_base_dockwidget.py, vor der Korrektur rot).python scripts/run_tests.py sn_basis --baseline: GRÜN 464/464, unverändert gegenüber Baseline.sn_plan41: unverändert gegenüber Baseline.sn_verfahrensgebiet: dieselben 3 „NEU ROT“ und 8 „neu grün“ wie schon vor dieser Änderung (verfahrensgebiet_alkis_komplett,verfahrensgebiet_shape_komplett); sie betreffen keinen geänderten Code, die Baseline von Verfahrensgebiet ist gegenüberunstableverschoben.Änderungen an Verträgen
BaseDockWidget.setWidgetüberschreibtQDockWidget.setWidget. Neue Funktionbase_dockwidget.tabs_mit_scrollbereich(tab_widget).dock.widget().widget(i)liefert jetzt den Scroll-Bereich, die Tab-Instanz ist….widget(i).widget(). Eine Suche in allen Fachplugins hat keine Stelle gefunden, die darauf angewiesen ist;closeEventpackt den Scroll-Bereich selbst aus.qt_wrapper: neuQScrollArea,QFrame,FrameNoFrame(Qt6, Qt5, Mock). Das Mock-Dock und das Mock-Tab-Widget haben die nötigen Methoden bekommen.schnittstellen.mdAbschnitt 2 (Projektwissen-Branchdocs/104-dock-scrollbereich).Übergabenotiz
Stand: fertig, QGIS-Test bestanden. Branch
bugfix/104-dock-scrollbereich(1 Commit), Doku aufProjektwissen:docs/104-dock-scrollbereich.Herkunft der Lösung: Wie gewünscht habe ich zuerst „VLN Karte“ 2.0 (
qgis-plugin) und „VLN Karten“ 0.5 (vln_karten) im Profil QGIS4/dev durchgesehen. Keines der beiden hat eine eigene Lösung (keinQScrollArea), ihr Dock-Inhalt ist nur kurz genug. Die Lösung hier ist das übliche Qt-Muster.Entscheidungen (mit Daniel abgestimmt):
BaseDockWidgetstatt einer Hilfsfunktion, die jedes Fachplugin aufrufen müsste: ein PR statt drei.unstable, weil es den langen Basemap-Bereich nur dort gibt.Im QGIS-Test geprüft (05.10.2026, alles wie erwartet):
cleanup()der Tabs läuft).Checkliste
printchangelog.txtergänzt🤖 Generated with Claude Code