Bug 1203823

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.