Summary: | Window height bigger than screen height | ||
---|---|---|---|
Product: | [Applications] okteta | Reporter: | Alexander Wilms <f.alexander.wilms> |
Component: | general | Assignee: | Friedrich W. H. Kossebau <kossebau> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | adam.m.fontenot+kde, damjan.rems, paulmcquad |
Priority: | NOR | ||
Version: | 0.26.15 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Alexander Wilms
2024-05-12 13:30:24 UTC
I can confirm the same. Platform: KDE Neon. All KDE 6 updates. As curiosity. Okteta is showing this components: KDE Frameworks : 5.115.0 Qt 5.15.10 (build 5.15.10) by TheR On my system, Okteta's About dialog shows the following: KDE Frameworks Version 5.115.0 Qt Version 5.15.13 (built against 5.15.13) The wayland windowing system Okteta now remembers the window size when opening files via Dolphin and doesn't exceed the screen size. On the 2560x1440 screen, it opens with the dimensions 861 x 1390 when launched from Kickoff. The about dialog shows the following: Okteta version 0.26.15 KDE Frameworks version 5.116.0 Qt version 5.15.14 (built against 5.15.14) I see this issue on Qt6 + Wayland, can anyone confirm? Okteta 0.26.15 Operating System: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.9.10-arch1-1 (64-bit) Graphics Platform: Wayland I built and tried the KF6 branch: https://invent.kde.org/utilities/okteta/-/commits/work/kossebau/kf6?ref_type=heads In this case the height of the window is limited to the height of the screen, but it still doesn't remember its size after closing under Wayland. Not yet got to research the issue (as myself still not on Wayland). From what I have heard elsewhere there might be two different issues when it comes to wayland: * Qt does not properly save & restore the state of QDockWidgets there, even more broken on Qt5 * Wayland window managers might not be too cooperative when a windows tries to restore/set the window size by itself (?) Okteta code itself tries to rely on the abstraction API Qt & KF libraries provide over X11, Wayland (and other windowing systems/platforms). So Okteta should not do anything wrong here, also might only try to work-around things where possible (ideally avoided though and issues fixed with the actual culprits). Someone trying to investigate this bug(s) might try with doing a simple dummy app with some QDockWidgets to reproduce the issues and perhaps find some work-around. Because at least with Qt5 any Qt-side fixes might not be something to expect to arrive soonish now to FLOSS users. Situation is really unfortunate, I am sorry for your experiences. My rough plans hopefully will have me get to complete the current blocker porting-from-QtScript in autumn and then move Okteta finally to Qt6, perhaps even get rid of using QDockWidget (some local sketch exists). For now, until I get to research things, can you help with some information: what happens with the QDockWidgets/tool views on reopening? I.e. * are those you closed shown again? * are they in the same location (left/right/stacked) (In reply to Friedrich W. H. Kossebau from comment #6) > For now, until I get to research things, can you help with some information: > > what happens with the QDockWidgets/tool views on reopening? I.e. > * are those you closed shown again? > * are they in the same location (left/right/stacked) On your KF6 under Wayland, the tool widgets are remembered in their open / closed state, and the location is preserved as well. When multiple tool widgets are placed under a tabbed parent, the active tab is remembered as well. *** This bug has been marked as a duplicate of bug 462703 *** |