| Summary: | Starting window size | ||
|---|---|---|---|
| Product: | [Applications] okteta | Reporter: | German P <germanp82> |
| Component: | general | Assignee: | Friedrich W. H. Kossebau <kossebau> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aapo.rantalainen, adam.m.fontenot+kde, bugs.kde.org, eamonnrea, f.alexander.wilms, jackyzy823, kraplax, paulmcquad, zawertun |
| Priority: | HI | ||
| Version: | 0.26.9 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/utilities/okteta/-/commit/109b029fc6f56fafe2c3cd5f07303945863f773a | Version Fixed In: | 0.26.17 |
| Sentry Crash Report: | |||
|
Description
German P
2022-12-06 12:19:24 UTC
I've experienced same bug here and https://bugs.kde.org/show_bug.cgi?id=336936. After some test , i found it worked under X11 with normal height , but failed in Wayland. Another problem is that in Wayland the window size is not remembered (in X11 windows size is remembered) . *** Bug 480289 has been marked as a duplicate of this bug. *** https://bugreports.qt.io/browse/QTBUG-120191might perhaps be related here, though only reported for Qt6. Myself had recently only shortly looked at the issue, but for now only resorted to update the existing hack (which seems to only work on X11 by what I saw meanwhile) -> https://invent.kde.org/utilities/okteta/-/commit/debc06113cfa8ec4c245c8924855201dbbee3a46 No leading ideas myself where things are broken when it comes to Wayland, also given that quite some things there seem to be developing, so not yet invested there myself. Hoping myself to solve this with a new generic approach to tool views started locally as part of the Qt6 port, sadly currently still stuck in the port away from QtScripts (no longer in Qt6). (In reply to Friedrich W. H. Kossebau from comment #3) > https://bugreports.qt.io/browse/QTBUG-120191might perhaps be related here, > though only reported for Qt6. Ah, seems that was for X11, my bad (had wrong memories and too quickly copied the url from my browser history). I might have thought of something else, will have to wait until I rediscover that. *** Bug 490938 has been marked as a duplicate of this bug. *** *** Bug 336936 has been marked as a duplicate of this bug. *** *** Bug 486919 has been marked as a duplicate of this bug. *** *** Bug 167769 has been marked as a duplicate of this bug. *** Dear Paul, thanks for trying to help. But please do not resolve all bugs as duplicate because of the same phenomenon. There might be different reasons in different context. Your help does not help me sadly. A possibly relevant merge request was started @ https://invent.kde.org/utilities/okteta/-/merge_requests/27 I managed to fix the starting size issue under Wayland, one-line patch here: https://invent.kde.org/utilities/okteta/-/merge_requests/27 The only remaining issue for me on KF6 + Wayland is that the ByteArrayColumnView doesn't respond to click events! I can scroll it just fine, and using the arrow keys to change the selected byte (along with shift to select multiple) works fine as well. Just click events. This works with `okteta -platform xcb`, so it's a Wayland specific issue. Git commit 109b029fc6f56fafe2c3cd5f07303945863f773a by Friedrich W. H. Kossebau. Committed on 06/09/2024 at 12:12. Pushed by kossebau into branch '0.26'. Fix initial too large window size Adding all the dock widgets next to each other on the right dock area at initialization results in an initial minimal size of the main window that is quite large vertically (e.g. > 2000 px). As KXmlGuiWindow::setupGUI() first tries to restore the size before trying to restore the positions of the dock widgets, any stored size will be minimally bounded by that large initial minimal size. As the stored size usually was smaller, due to users typically hiding or stacking dock widgets for some usable window size (similar also the default state set in OktetaMainWindow constructor), this effectively discards the stored size, also results in a vertical start size which does not fit on most typical consumer screens. On KWin/X11 this effect was shadowed a bit by (assumingly) the window manager trying to fit the window on start into the screen, at which stage the dock widgets positions had already been restored and thus the minimal size being typically small enough again to fit into the screen. Not adding the widgets to the dock area initially does not prevent them from being correctly restored later if the stored config asks for it. Because setting the main window as parent widget to the dock widget makes it known to the dock widget system. FIXED-IN: 0.26.17 M +6 -1 libs/kasten/gui/shell/shellwindow_p.cpp https://invent.kde.org/utilities/okteta/-/commit/109b029fc6f56fafe2c3cd5f07303945863f773a |