GNOME Bugzilla – Bug 650557
Gedit shouldn't save half-maximized window size
Last modified: 2020-11-24 09:59:05 UTC
If you half-maximize gedit's window (maximize vertically but not horizontally), then close it, it restarts half-maximized. If, then, you try to un-maximize it (by dragging it), the window stays at the same size. This is because gedit saves the window size, even if it's half-maximized. For information, the bug doesn't seem to exist when the window is fully maximized (both vertically and horizontally).
Actually, I've just noticed that Nautilus suffers from the same bug too. Does it mean that it's a general problem? Is it possible for an application to know that it has been half-maximized so that it can ignore the new size?
In gedit we check for GDK_WINDOW_STATE_MAXIMIZED, so if this is not the state of the window when it is half maximized we will indeed save the window. I guess that it is a bug in Gdk or we would need a new state.
You're right, I've just found GDK bug #315647.
(In reply to comment #2) > In gedit we check for GDK_WINDOW_STATE_MAXIMIZED, so if this is not the state > of the window when it is half maximized we will indeed save the window. I guess > that it is a bug in Gdk or we would need a new state. GDK_WINDOW_STATE_MAXIMIZED means that the window is maximized both vertically and horizontally - tiled (a.k.a half-maximized) windows on the other hand are only maximized vertically. In fact, the tiled state is currently not backed by any hint, we probably should change that and then add GDK_WINDOW_STATE_TILED in Gdk.
Something like in bug #671677, but for half-maximized windows, could work-around this bug.
there's now GDK_WINDOW_STATE_TILED
mmm, not sure what we can do with that though. for GDK_WINDOW_STATE_MAXIMIXED we can call maximize() to restore the state, for FULLSCREEN we can call fullscreen(), but for tiled we can store that state but how can we restore a tiled window? how do we know if it is tiled left or right?
(In reply to comment #7) > mmm, not sure what we can do with that though. > > for GDK_WINDOW_STATE_MAXIMIXED we can call maximize() to restore the state, for > FULLSCREEN we can call fullscreen(), but for tiled we can store that state but > how can we restore a tiled window? how do we know if it is tiled left or right? Well, that's probably naive, but maybe you could just read (and remember) the window position as well as the tiled state, and, if the window position was 0, re-tile to the left, and if it was >0, re-tile to the right.
GDK_WINDOW_STATE_TILED doesn't seem to have very good semantics also, it doesn't specify how the window is tiled. What if suddenly window managers start to allow tiling vertically instead of only horizontally? Maybe we should just store the previous (untiled) state of the window instead.
(In reply to comment #9) > GDK_WINDOW_STATE_TILED doesn't seem to have very good semantics also, it > doesn't specify how the window is tiled. What if suddenly window managers start > to allow tiling vertically instead of only horizontally? > > Maybe we should just store the previous (untiled) state of the window instead. If I undesrtand the problem correctly, you actually need to save two things: #1: the latest window state (normal, maximized, fullscreen or tiled), position and size (useful only for the "normal" state). #2: the latest window position and size in the "normal" state (not maximized, not fullscreen, not tiled). Then, when the application starts, it restores to #1, and when you restore the window (un-maximize it or un-tile it), it should restore to #2. So, using the GDK_WINDOW_STATE_TILED information, it is now possible to fix #2, but not #1. As of this bug, it was really about #2, not about #1, so it should be easily fixable now.
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.