+++ This bug was initially created as a clone of Bug #778150 +++

(See https://bugzilla.gnome.org/show_bug.cgi?id=778150#c2 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).