Bug 1203823 - Cannot independently size message preview vs message list in separate windows
Summary: Cannot independently size message preview vs message list in separate windows
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 21
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Milan Crha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-19 18:18 UTC by Alex Williamson
Modified: 2015-04-07 06:25 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-07 06:25:51 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 746763 0 None None None Never

Description Alex Williamson 2015-03-19 18:18:35 UTC
Description of problem:
Often when catching up on a mailing list or reviewing patches filtered into a folder I'll open a second evolution window (Shift+Ctrl+W) so that I can monitor my inbox.  My demands for each window are very different, for instance if I'm reviewing patches I like to vertically maximize the window and adjust the divider between preview and message list (using classic view w/ message preview), I might also like to turn off the sidebar since I'm focused on a single folder.  Unfortunately every one of these operations is mirrored on the other window that I've opened to track my inbox.  Often I can't even see the message list because a small divider in my vertically maximized window equates to covering everything in my smaller inbox window.  Viewing or not viewing the sidebar is also intended only for the window in which I make that selection.

Long story short, when multiple windows are in use, modifications to the view should affect only the window in which the change was made.  Each window should be independently adjustable for task specific purposes.

Version-Release number of selected component (if applicable):
evolution-3.12.11-1.fc21.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Open a second Evolution window
2. Attempt to adjust the view in one window independent of the other
3.

Actual results:
Inexplicable mirror behavior between the two windows

Expected results:
Independent view selection and geometry manipulation within the windows

Additional info:
This is a really frustrating deficiency of Evolution

Comment 1 Milan Crha 2015-03-24 14:24:37 UTC
Thanks for a bug report. Evolution saves the last window position, size and its inner arrangements to be able to restore the window layout the next start. It's hard to know which one should be restored, when you've multiple windows opened. Would it be the first opened, the last opened, the last where you made a change? The changes are saved separately, independently from the others (like window position and size is saved on those changes only, the inner layout is also independent from the windows size and position (in some extent)).

Opening only the message itself in a separate window (by double-clicking the message or pressing enter in the message list) is a different thing, that window doesn't have anything common with the main Mail window, it shows only the message content. Wouldn't that work for you better?

Comment 2 Alex Williamson 2015-03-24 15:05:08 UTC
(In reply to Milan Crha from comment #1)
> Opening only the message itself in a separate window (by double-clicking the
> message or pressing enter in the message list) is a different thing, that
> window doesn't have anything common with the main Mail window, it shows only
> the message content. Wouldn't that work for you better?

That's not the workflow I desire, no.  Then I end up with a bunch of separate message windows when I could be working in one.  I don't really want to open and close a new message window just to skim a reply.  Imposing a second rate user experience on the first instance of the application so that the second instance might have a marginal improvement sounds like a poor design model.  If the restore code can't track that I have two separate windows, what good is it?  Why is the second window tracked at all?  It seems like the obvious solutions are either to track windows separately via some sort of cookie so they can each be restored properly, or focus only on restoring the primary, ie. first opened, window on restore.  Having both windows mirror internal geometry changes certainly is not a behavior that any user would expect, or probably desire.

Comment 3 Milan Crha 2015-03-25 07:36:09 UTC
Right, I was also thinking of some window indexing (the 'cookie' in your text), to have something like "the main window (window0)", "window1", "window2" and so on, but then I realized that saving a state for those "n" windows separately might partly work. The fun begins when you close windows in other than the reverse order, that is, open a new window, then you have window0 and window1, then close window0. What should happen now? Will window1 become window0, or the next newly created window will get the first free index? As you can see, this breaks both options, storing window layout separately, the same as storing only layout of the first window (the close of window0 makes the window1 "the first window").

I know I might do this overcomplicated, it's just that such change would cause another unexpected behaviour. Maybe less irritating than the current state, but still.

In any case, this is not Fedora specific. The change should be done upstream first, then it'll get into Fedora with regular updates (once it's done). The upstream for evolution is https://bugzilla.gnome.org . I didn't search for any of it, but maybe the bug is already filled there.

Comment 4 Alex Williamson 2015-03-25 17:54:54 UTC
Created gnome bz https://bugzilla.gnome.org/show_bug.cgi?id=746763

If I were coding it, I'd probably have a shared window index that gets incremented each time a window is opened.  If a previous index window is closed... so what.  You can then always assume that the primary window, if you choose to only restore one, is the lowest remaining index.  If you choose to restore them all, then you simply iterate through the (potentially sparse) list creating new windows for the restored session.

If you were to restore only a single window, it's a reasonable and documentable choice to select the oldest window as the restore candidate.  Heuristics to select the last window used sound troublesome and arbitrary from a user perspective.  But of course restoring them all eliminates that question.

TBH, as a user, restoring geometry on restart is not even something I would necessarily expect.  It's a nice feature, but it shouldn't induce bugs like this.  I wouldn't complain if the code dropped any notion of saving window geometry for restore any time multiple windows were in play.

Comment 5 Milan Crha 2015-04-07 06:25:51 UTC
You are right.

Let's close this in a favour of the upstream bug (to avoid bugzilla work duplicity). Thanks for filling it there.


Note You need to log in before you can comment on or make changes to this bug.