Bug 517403 - pane sizes not correctly restored on Evolution startup
Summary: pane sizes not correctly restored on Evolution startup
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 15
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-13 18:49 UTC by Adam Williamson
Modified: 2011-06-06 07:28 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-06 07:15:37 UTC


Attachments (Terms of Use)
how I set Evo to look every time I start it up (250.45 KB, image/png)
2009-08-13 18:50 UTC, Adam Williamson
no flags Details
how evo looks when I first start it up (202.61 KB, image/png)
2009-08-13 18:51 UTC, Adam Williamson
no flags Details
How Evo panes look before quitting (477.45 KB, image/png)
2009-08-28 12:32 UTC, Gavin Simpson
no flags Details
How Evo panes look upon restart (457.95 KB, image/png)
2009-08-28 12:34 UTC, Gavin Simpson
no flags Details


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 608203 None None None Never

Description Adam Williamson 2009-08-13 18:49:44 UTC
In Rawhide, when starting Evolution, the pane sizes are not correctly restored. It always starts up with an unusably narrow left pane (seems to be sized to the width of the widest of the Mail / Contacts / Calendars / Tasks / Memos buttons at the bottom of the pane), and the top-right pane is slightly less tall than I set it. Each time I start Evo, I have to make the left pane a lot wider and the top-right pane somewhat taller.

Will attach screenshots.

Comment 1 Adam Williamson 2009-08-13 18:50:30 UTC
Created attachment 357358 [details]
how I set Evo to look every time I start it up

Comment 2 Adam Williamson 2009-08-13 18:51:10 UTC
Created attachment 357359 [details]
how evo looks when I first start it up

Comment 3 Matthew Barnes 2009-08-13 23:15:08 UTC
You might try using Configuration Editor to see whether Evolution is stomping on the GConf key for this or just ignoring it at startup.  My guess is something's stomping on it.

/apps/evolution/shell/view_defaults/folder_bar_width

Comment 4 Adam Williamson 2009-08-13 23:37:37 UTC
It seems to be ignoring it. It shows around 372 (varies 370-380 since obviously I don't drag it to the exact same place every time) when I quit with it set the way I like it. When I then re-launch it and the pane becomes narrow again, gconf-editor shows the value still at 370-380. If I quit evo with it in that state, it stores the narrow value, which is 100. So it seems to be ignoring the value, it's not that the value gets stomped some other way and Evo does the right thing.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 5 Gavin Simpson 2009-08-28 12:30:49 UTC
Not sure if this is the same bug or related, but I have my Evolution set-up to be in wide view (and I don't display the Mail/Calendar etc buttons). Evolution always sets the list of messages to be quite narrow and the message preview pane toe be very wide on start-up regardless of how I had the panes configured before quitting. Every time I start Evo now I have to resize the message list pane to be able to see the message fields I have displayed.

Note that I am not using the View > Current View > For_Wide_View but rather a custom one similar to the default that is used when not in wide layout.

I took a quick look in gconf-editor an noted that

/apps/evolution/mail/display/hpaned_size

Is changed if I resize the panes and quit (I too never get it exactly the same each time). But regardless, Evo starts up with a tiny message list pane and a wide message preview pane.

I've got a couple of screen shots that show the problem that I'll attach in a minute.

Note this is for Fedora 11, not RawHide (I'm not in a position to test this in RawHide just at the moment), and the same problem was in Evo in Fedora 9 (the last version I used on my home desktop with the large monitor).

Here are the versions of evo and associated programmes that I have installed:

$ yum list installed | grep evolution
evolution.x86_64                      2.26.3-1.fc11              installed      
evolution-bogofilter.x86_64           2.26.3-1.fc11              @updates       
evolution-data-server.x86_64          2.26.3-2.fc11              installed      
evolution-data-server-devel.x86_64    2.26.3-2.fc11              installed      
evolution-data-server-doc.noarch      2.26.3-2.fc11              installed      
evolution-help.noarch                 2.26.3-1.fc11              installed      
evolution-perl.x86_64                 2.26.3-1.fc11              installed      
evolution-sharp.x86_64                0.20.0-3.fc11              @updates       
gnome-do-plugins-evolution.x86_64     0.8.1-6.fc11               @updates       
gnome-python2-evolution.x86_64        2.26.0-3.fc11              @fedora

Let me know if there is anything else I can provide.

Comment 6 Gavin Simpson 2009-08-28 12:32:13 UTC
Created attachment 359053 [details]
How Evo panes look before quitting

Comment 7 Gavin Simpson 2009-08-28 12:34:13 UTC
Created attachment 359054 [details]
How Evo panes look upon restart

Note that the two attachments I just added are showing a HTML email with images etc. The described behaviour happen with normal plain text emails as well, so it is not a peculiarity of the message being shown.

Comment 8 Matthew Barnes 2009-08-28 14:13:40 UTC
I spent the past couple days on this issue and I believe I finally have it working correctly in the codebase that will ship in Fedora 13.  I had to write my own pane widget to get it to work right, and I'm not sure if my solution can be back ported to earlier Fedoras.  I'll at least try to explain the issues.

Basically we're doing everything wrong with panes.  We're packing them wrong, saving the divider position wrong and restoring the divider position wrong.

Packing them Wrong
------------------

Preview panes should remain a fixed size when resizing or maximizing a window.  You can see the bug in action just by resizing the main window.  The divider position remains fixed and the preview pane shrinks and expands with the window.  Instead the message list should shrink and expand with the window.

Same goes for the task and memo lists on the right side of the calendar view.  If you unmaximize the main window, push the divider in calendar view all the way to the right so the task and memo list are complete hidden, and then expand the window horizontally, the divider should stay locked to the right side of the window.  Instead the divider remains fixed on the screen and the task and memo lists are revealed again as you expand the window.

Saving the Divider Position Wrong
---------------------------------

In order for the bottom or right panel sizes to remain a fixed size, we need to track and remember the divider position as pixels from the bottom or right edge of the pane.  GtkPaned, however, tracks the position as pixels from the top or left edge of the pane.  And that's the value that gets saved to GConf, which is wrong for our needs.

Restoring the Divider Position Wrong
------------------------------------

This part took me the longest to figure out.  At startup, the above issues converge to cause the problem you're seeing.

Windows are not maximized until they're mapped on the screen.  During startup we create the main window and restore it to its previous -unmaximized- size and if it was maximized in the last session, we request that GTK+ maximize it again when it's mapped on the screen.

Prior to the window being maximized, however, we restore the position of the pane divider.  Now, because we save the position as pixels from the top or left edge of the pane, the value will be different depending on whether you exited Evolution with a maximized window or unmaximized window.

If you exited Evolution with an -unmaximized- window, you're fine.  The pane divider position will be restored correctly.  But if you exited Evolution with a -maximized- window, then we'll be restoring a pane divider position meant for a maximized window on a not-yet maximized window.  The position will likely exceed the size of the window, and so GTK+ will have to clamp it.

Once the window actually is maximized, because we're packing it wrong the divider will remain fixed at whatever position GTK+ clamped it to, while the bottom or right pane expands to the edge of the screen.  Just like in the examples above.

That is the story behind the Gavin's screenshots.

As for Adam's screenshots, try unmaximizing your Evolution window and widen the window enough that you can see your folders in the unmaximized window.  That should prevent a similar clamping behavior at startup prior to maximization.

Comment 9 Adam Williamson 2009-08-28 16:32:19 UTC
thanks for the explanation! now, what should we do with the bug, do you think?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 10 Gavin Simpson 2009-08-28 18:05:47 UTC
I'd like to add my thanks to those of Adam; very much appreciated and allows me to work around this bug :-)

As a work around for my situation I can just not maximise my window, but instead manually resize it to fill as much screen real estate as possible. This seems to solve the immediate frustration for me then until I get Fedora 13...

Cheers Matthew!

Comment 11 Matthew Barnes 2009-08-28 21:03:21 UTC
(In reply to comment #9)
> thanks for the explanation! now, what should we do with the bug, do you think?

Up to you.  We can leave it open until Evolution 2.29 hits post-F12 Rawhide, or we can close it now if you're satisfied with the temporary workaround.

Comment 12 Adam Williamson 2009-08-28 21:15:18 UTC
let's close it as DEFERRED, bit of a hack but closest I can think of.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 13 Adam Williamson 2010-01-26 00:45:58 UTC
it's post-f12 rawhide, so I'm re-opening this. Panel sizes are erratic on startup in 2.29.5 on current Rawhide.

Comment 14 Adam Williamson 2010-01-26 00:47:00 UTC
it's clearly different to f12-and-earlier behaviour, but still broken. there seems no rhyme or reason to the sizes any more, any pane can be any size on startup - i've had top right being huge and bottom right tiny, vice versa, left hand pane seems to be a different size every time I start...

Comment 15 Adam Williamson 2010-02-08 20:35:32 UTC
Actually, it's settled down somewhat now. Every time I start up, the left hand (vertical) separator is further to the left than I set it, and the right hand (horizontal) separator is much further down (so the folder list is narrower, the message list smaller bigger and the message preview window smaller than I wanted).

Comment 16 Bug Zapper 2010-03-15 12:46:03 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 17 Bug Zapper 2011-06-02 17:50:07 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 18 Adam Williamson 2011-06-04 04:29:35 UTC
haven't seen this lately, although i vaguely remember using some gconf hackery that 'fixed' it, so it may not be really fixed. let's close it, though.

Comment 19 Adam Williamson 2011-06-04 04:36:01 UTC
Hah, that's funny - I actually happen to have just reinstalled this system, and right after closing the bug, I had to close and re-open Evo, and found this bug's still valid! Unless you manually set the window_height and window_width values in gconf apps/evolution/shell/view_defaults to appropriate values, this still happens.

Comment 20 Milan Crha 2011-06-06 07:15:37 UTC
Do you have your evolution window maximized? Because that's usually the reason for "not saving" pane sizes. Maximizing the window is done "asynchronously", while recomputing what the pane size was the last run is done synchronously, with the old window size, usually smaller than the full screen size.

A workaround is to restore window size from the maximized state and make it as largest as possible, nearing the screen resolution. Then maximize it again. This is the same as playing with GConf as you noticed above, only one doesn't need to know the key name. The next start will be restored window size to the larger, and the pane position will be recomputed "properly".

There is an upstream bug [1] for this, thus I'm moving it there.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=608203

Comment 21 Adam Williamson 2011-06-06 07:28:26 UTC
Maximized, yup. So this is indeed that upstream bug.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers


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