<html>
<head>
<base href="https://bugzilla.gnome.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Column resizing behaviour broken when un-maximising/maximising and causes problems with e.g. left/right window snapping, in vertical (3-column) view"
href="https://bugzilla.gnome.org/show_bug.cgi?id=778398">778398</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Column resizing behaviour broken when un-maximising/maximising and causes problems with e.g. left/right window snapping, in vertical (3-column) view
</td>
</tr>
<tr>
<th>Classification</th>
<td>Applications
</td>
</tr>
<tr>
<th>Product</th>
<td>evolution
</td>
</tr>
<tr>
<th>Version</th>
<td>3.22.x
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>minor
</td>
</tr>
<tr>
<th>Priority</th>
<td>Normal
</td>
</tr>
<tr>
<th>Component</th>
<td>general
</td>
</tr>
<tr>
<th>Assignee</th>
<td>evolution-shell-maintainers@gnome.bugs
</td>
</tr>
<tr>
<th>Reporter</th>
<td>gnome@nuclearsunshine.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>evolution-qa@gnome.bugs
</td>
</tr>
<tr>
<th>CC</th>
<td>mcrha@redhat.com, rob@robster.org.uk, wayland-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>GNOME version</th>
<td>---
</td>
</tr></table>
<p>
<div>
<pre>+++ This bug was initially created as a clone of <a class="bz_bug_link
bz_status_NEW "
title="NEW - [Wayland] Window resize change doesn't overwrite pending (and obsolete) resize change"
href="show_bug.cgi?id=778150">Bug #778150</a> +++
(See <a class="bz_bug_link
bz_status_NEW "
title="NEW - [Wayland] Window resize change doesn't overwrite pending (and obsolete) resize change"
href="show_bug.cgi?id=778150#c2">https://bugzilla.gnome.org/show_bug.cgi?id=778150#c2</a> for the background to
this).
When Evolution's window is resized, it resizes columns in a way that causes
problems:
* Shrinking the window width past a certain point (e.g. when un-maximising)
then enlarging it again (e.g. when re-maximising) results in completely
different column widths from before. This means every time this is done, the
user has to manually restore the column widths.
* The column-shrinking algorithm (and width-remembering behaviour) doesn't
result in usable column widths when the window shrinks past a certain point
(example: snapped to the left/right of a 1080p display), making this use-case a
huge pain, since the user has to also adjust the columns manually every time.
When shrinking the window width, Evolution adjusts column widths for the
narrow-width state non-optimally, then uses a non-symmetric algorithm to
re-calculate them again if the user widens (e.g. re-maximises) the window. If
the narrower width was 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 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.
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).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>