Bug 462703 - Starting window size
Summary: Starting window size
Status: RESOLVED FIXED
Alias: None
Product: okteta
Classification: Applications
Component: general (show other bugs)
Version: 0.26.9
Platform: Other Linux
: HI normal
Target Milestone: ---
Assignee: Friedrich W. H. Kossebau
URL:
Keywords:
: 167769 336936 480289 486919 490938 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-12-06 12:19 UTC by German P
Modified: 2024-09-06 12:48 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In: 0.26.17
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description German P 2022-12-06 12:19:24 UTC
When opening okteta the window is vertically very large (1108x2462) which exceeds my 1080p screen.
After resizing and restart the window size is not saved.
Okteta is the only application that shows this behaviour.

SOFTWARE/OS VERSIONS
Manjaro  - GNU/Linux 6.0.11
KDE Plasma Version: 5.26.4
KDE Frameworks Version: 5.100
Qt Version: 5.15.7
Comment 1 jackyzy823 2023-04-10 09:12:35 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) .
Comment 2 Friedrich W. H. Kossebau 2024-01-24 21:35:43 UTC
*** Bug 480289 has been marked as a duplicate of this bug. ***
Comment 3 Friedrich W. H. Kossebau 2024-01-24 21:44:11 UTC
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).
Comment 4 Friedrich W. H. Kossebau 2024-01-24 21:50:48 UTC
(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.
Comment 5 Paul McQuade 2024-07-28 18:34:43 UTC
*** Bug 490938 has been marked as a duplicate of this bug. ***
Comment 6 Paul McQuade 2024-07-28 18:37:11 UTC
*** Bug 336936 has been marked as a duplicate of this bug. ***
Comment 7 Paul McQuade 2024-07-28 18:45:27 UTC
*** Bug 486919 has been marked as a duplicate of this bug. ***
Comment 8 Paul McQuade 2024-07-28 19:05:53 UTC
*** Bug 167769 has been marked as a duplicate of this bug. ***
Comment 9 Friedrich W. H. Kossebau 2024-07-28 19:10:44 UTC
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.
Comment 10 Bug Janitor Service 2024-08-16 21:33:13 UTC
A possibly relevant merge request was started @ https://invent.kde.org/utilities/okteta/-/merge_requests/27
Comment 11 Adam Fontenot 2024-08-16 22:41:25 UTC
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.
Comment 12 Friedrich W. H. Kossebau 2024-09-06 12:48:43 UTC
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