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):
Steps to Reproduce:
1. Open a second Evolution window
2. Attempt to adjust the view in one window independent of the other
Inexplicable mirror behavior between the two windows
Independent view selection and geometry manipulation within the windows
This is a really frustrating deficiency of Evolution
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?
(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.
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.
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.
You are right.
Let's close this in a favour of the upstream bug (to avoid bugzilla work duplicity). Thanks for filling it there.