GNOME Bugzilla – Bug 778150
[Wayland] Window resize change doesn't overwrite pending (and obsolete) resize change
Last modified: 2018-05-02 18:02:30 UTC
Whichever component was displayed on closing Evolution (mailer, contacts etc.), on startup, Evolution widens the central column of that component (i.e. the one displayed on startup) to approx. 50% of the screen width. The column widths of the other components (i.e. whatever component wasn't last displayed on shutdown/first displayed) are unchanged, and correctly retain their user-set widths when the component is selected after startup. This means that on every startup, the central column of the first-displayed component has to be manually resized back to its previous width. This is a regression from 3.20.x, which correctly restored all widths of all components.
Thanks for a bug report. I cannot reproduce it, or I do not follow. Let's say that: a) open evolution in the Mail view b) make sure View->Preview->Vertical view is checked, the same as the preview itself. This makes the window layout divided into three columns, folder tree on the left, message list in the middle and the preview on the right. c) I change the width of the preview in the way that its left side is aligned at the end of the Search entry d) close evolution e) run evolution Once the UI is fully loaded the view looks the same as I closed it. It doesn't matter whether I had the window maximized or not. Could you try to run in one terminal this command: $ gsettings monitor org.gnome.evolution.mail then run evolution in the Mail view from another teminal: $ evolution -c mail and then reproduce the issue, please? You should notice on the first terminal that a hpaned-size value changes when you change the width of the preview panel.
Looking at the hpaned-size messages pointed me to what's actually going on - on launch, it shows the correct value (i.e. my preferred 3rd-column width) briefly, then a much smaller value almost immediately. What I've surmised is happening is that, when Evolution's window is in a maximised state and then closed, on next launch Evolution's window is temporarily unmaximised, before the window manager (GNOME Wayland) restores it to its previously maximised state. So Evolution re-calculates column widths for the un-maximised state, remembers them, then uses a non-symmetric algorithm to re-calculate them again when the window manager re-maximises the window. If the last-remembered unmaximised width is small enough, this results in the central column growing much wider than it was previously. The column width-sacrificing algorithm when in the 3-column layout seems to be: * message list (middle) column first, until it is zero-width, then * preview (right) column until it is approx. 50 px. wide, then * folder list (left) column until the window is at its minimum width (approx. 780 px.) The column growing algorithm is: * grow the message list (middle) column forever. So given a small-enough un-maximised width, Evolution shrinks the middle column to zero, then the right column as much as necessary, to fit the very brief unmaximised size, then grows the *only* the middle column as much as necessary to fill the maximised width afterwards, resulting in the middle column "stealing" much of the right column's width. When using a 3-column layout, especially with the "for wide view" 2-line middle column, I think it makes much more sense to grow the message pane than the middle column after a certain point, since that's potentially the largest and most variable content region. That could however conceivably be a divisive change. At a minimum, storing "maximised" widths separately would solve this problem (or delaying saving the column widths for a few seconds, giving the window time to be re-maximised). However, a "smarter" solution that doesn't assume user preferences would be to store two sets of column widths, a "narrow" and "wide" set, corresponding to the widths set by the user at the narrowest and widest window states that the user has adjusted columns, and then scale between these values for each column. So when the user sets the column widths, if the window is either the narrowest or widest it has been when the user has done that, then store the column widths. E.g.: * Window is maximised (i.e. widest, probably), and user adjusts columns: store column widths as "wide" set. Example: LHS=240, middle=480, RHS=1200 (i.e. window=1920) * User adjusts columns and window is narrower than it has ever been previously when they adjusted them: store column widths as "narrow" set. Example: LHS=240, mid=240, RHS=300 (i.e. window=780) At any given window width subsequently, calculate each column's width by scaling between its minimum/maximum widths proportionally as the window scales between/outside the minumum and maximum-seen window widths (and handling the case where the window is too narrow to do that). So: column_x_width = column_x_width_smallest + (column_x_width_largest - column_x_width_smallest) * (window_width_current - window_width_smallest)/(window_width_largest - window_width_smallest) E.g. for a window width of 1200 px and the above stored column widths would be: LHS: 240 + (240 - 240) * (1200 - 780) / (1920 - 780) = 240 Mid: 240 + (480 - 240) * (1200 - 780) / (1920 - 780) = ~328 px RHS: 300 + (1200 - 300) * (1200 - 780) / (1920 - 780) = ~632 px Total: 1200 px From the user's perspective, the LHS will stay the same width (which is probably what they want since they've set it that way both when the window has been the smallest and largest at which they've adjusted columns) and the RHS will flex faster than the middle column (again reflecting to a reasonable extent the user's implied preferences based on their manual column-sizing actions).
I meant to add, as a workaround I un-maximised the window, stretched it to the full display width, then adjusted the columns and re-maximised it, so that when temporarily un-maximised on startup it's not narrow enough to shrink the right-hand column/grow the middle column.
(In reply to Stephen from comment #3) > I meant to add, as a workaround I un-maximised the window, stretched it to > the full display width, then adjusted the columns and re-maximised it, so > that when temporarily un-maximised on startup it's not narrow enough to > shrink the right-hand column/grow the middle column. Right, that's the way to be done for now. Thanks for the offer, but I'm not going to implement it, it's too complicated to maintain. I thought that this scenario with too small umaximized window is already taken, I recall some related changes in a distant past, but it seems it's not fixed completely/again/yet.
Created attachment 345131 [details] gdb session I added some debugging and I did a gdb session as well and I can tell that this is broken due to gtk+ behaviour under Wayland, because it works properly under X.org. The session shows that the Wayland makes the window smaller and then larger again, even it had been told to be large enough before it is mapped. That easily breaks the Evolution code. That means that this should be fixed in gtk+.
Created attachment 345132 [details] evo debug patch (This is for a reference.) Below is what is printed and when: Evolution start under Wayland: > e_paned_set_hposition: 0x4700280: 0~>1306 > e_restore_window: w/h:897/795 maximized:1 at /org/gnome/evolution/shell/window/ > e_restore_window: going to maximize 897,795 ~> 1920,1080 of /org/gnome/evolution/shell/window/; resized at 1920,1080 > paned_size_allocate: 0x4700280: reports allocated:1632 for position:1306 > paned_notify_position_cb: 0x4700280: 1306~>1306, because alloc.width:1528 paned_pos:222 > paned_size_allocate: 0x4700280: reports allocated:1528 for position:1306 > paned_notify_position_cb: 0x4700280: 1306~>544, because alloc.width:557 paned_pos:13 > paned_size_allocate: 0x4700280: reports allocated:557 for position:544 > paned_notify_position_cb: 0x4700280: 544~>544, because alloc.width:1632 paned_pos:1088 > paned_size_allocate: 0x4700280: reports allocated:1632 for position:544 > paned_notify_position_cb: 0x4700280: 544~>544, because alloc.width:1580 paned_pos:1036 > paned_size_allocate: 0x4700280: reports allocated:1580 for position:544 Evolution start under X.org: > e_paned_set_hposition: 0xb06400: 0~>1264 > e_restore_window: w/h:897/795 maximized:1 at /org/gnome/evolution/shell/window/ > e_restore_window: going to maximize 897,795 ~> 1920,1080 of /org/gnome/evolution/shell/window/; resized at 1920,1080 > paned_size_allocate: 0xb06400: reports allocated:1580 for position:1264
Trying to summarize: When a window's size is changed before that window is mapped, the X.org backend properly discards (is it invoked at all) a window change notification with the old value, while the Wayland backend calls both notifications, which breaks Evolution code.
Can the Evolution column-scaling behaviour be split out into its own bug then (even if it's not going to be addressed at this point)? For instance tiling evolution side by side with another window is painful because of the current behaviour (user needs to manually adjust the columns twice).
(In reply to Stephen from comment #8) > Can the Evolution column-scaling behaviour be split out into its own bug > then (even if it's not going to be addressed at this point)? For instance > tiling evolution side by side with another window is painful because of the > current behaviour (user needs to manually adjust the columns twice). I do not know, if you think it'll worth it. I only know that I'll probably not have much time (and/or mood) to look on it.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/748.