GNOME Bugzilla – Bug 90133
Session is not restored correctly
Last modified: 2009-08-15 18:40:50 UTC
I set up my windows like this: 1. gnome-terminal in desktop 1, nearly full-screen 2. gedit in desktop 2, with a certain geometry tied to some graphic elements on my background image (so that I could easily see whether it was being restored correctly). 3. eog in desktop 3, again with a certain geometry tied to the background image. I logged out saving the session, and logged back in. 1. The gnome-terminal was in desktop 1 with the correct geometry. 2. gedit appeared in desktop 1, with incorrect geometry. 3. eog did appear in desktop 3, with incorrect geometry. Both EOG and GEdit save their session info correctly with unique roles for their windows. This case works correctly on sawfish, btw. Below are the attached eog/gedit/metacity session files.
Created attachment 10343 [details] Metacity session file
Created attachment 10344 [details] EOG session file
Created attachment 10345 [details] GEdit session file
*** Bug 84989 has been marked as a duplicate of this bug. ***
*** Bug 84986 has been marked as a duplicate of this bug. ***
When a file is opened in gedit (say sample.c) and do save session, logout and login back, then for the opened file window (sample.c), a message with _NET_ACTIVE_WINDOW set is send. This makes gedit to be raised and activated. Since in metacity after login by default first workspace is activated, it forces gedit to be put on the first workspace whenever any file is opened in gedit. It is reversed in sawfish, the workspace where gedit present is activated rather than the gedit window. sawfish raises the workspace where gedit is present whereas metacity raises gedit in the current active workspace. do we need NET_ACTIVE_WINDOW really? sorry i don't know the requirements of gedit
That explains gedit, but what about eog?
when i open eog and do save session, logout and login back, eog process is started (ps -ef|grep eog lists eog) but not displayed in metacity, sawfish and without any window manager also (eog's problem!)
OK, so gtk_window_present() is being called in bonobo_mdi_set_active_view(), which is called from the GEdit session code. Paolo, can we remove the call to gtk_window_present()? IMO it is better to decouple setting the active view from bringing the window to the front - if you were to pick an MDI document from a menu, say, you could call gtk_window_present() in that code explicitly. [BTW, the WM spec does not specify what should be done if you send the _NET_ACTIVE_WINDOW message and the window is in another desktop; it says that you can either move the window to the current desktop, or you can change desktops altogether. This should be specified better.] EOG seems to work correctly for me, however. After re-starting your session, can you please check that the eog process is running? If so, could you please run "xwininfo -root -children" to search for the eog window? If it is there, is it mapped and what is its geometry?
OK, I committed the gtk_window_present() bit. There may be some problems with restoring the windows' geometries as gedit likes to save a default geometry by itself, so I'll look into that. I still cannot reproduce the EOG problem. Could you please test the things I posted above?
Created attachment 10543 [details] [review] Patch with another fix for gedit
All the GEdit bits are committed now. It still doesn't get restored correctly with Metacity. If I run a gedit instance with two open windows (open two files, drag one of the notebook tabs outside of the window) and then save/restore my session, then: - Both windows appear in their correct desktops. - One window has the correct geometry. - The other window has its correct position, but incorrect size. EOG still gets restored just fine. JeyaSudha, it would be useful if you could please post the details about EOG that I mentioned above. Havoc, I noticed that Metacity saves window sizes as the difference between their actual size and the minimum size. Is this right? Sawfish stores the actual size - I'm not claiming that it does the right thing, but it does restore my session correctly :)
The idea of how metacity saves is that e.g. if you have an 80x24 terminal, save session, change your terminal font, then restore session, you still get an 80x24 terminal, instead of say a 73x19 terminal.
Created attachment 10550 [details] xwininfo -root -children details
After restarting the session, eog process is started but window is not displayed.
Could you please put the following patch in eog/shell and then attach with a debugger to the eog process after your session restarts? Please go line by line in the session_load() function to see what is going on. It would be useful to know if it is doing the session load at all.
Created attachment 10586 [details] [review] Patch for debugging
Eog is not restored only when it doesn't have any open files. The code also says the same. Only when there is any uri of the opened file then it is calling eog_window_new otherwise not I just tried the following. In the function load_uri_with_role, checked the value of uri before calling eog_window_open and commented out two lines in session_save if (!uri) continue; It seems to work fine.
Wow, thanks, JeyaSudha! The EOG bit is in CVS now.
What is the min_width*min_height for gedit? In metacity initially when the gedit window is created the value is 267*94 but later the value gets changed to 267*176. Hence while restoring the session it uses min_height as 94 whereas while save session it uses min_height as 176. Hence difference in height of 82 occurs while restoring.
Yeah correct JeyaSudha, there is a change in the "min_height" for gedit and the Issue may be due to this. I could see similar issues with other applications also (gnome-perfmeter, Aisle Riot game etc). For these applications also there is a change in "min_height X min_width" and while restoring the session they are unable to get back to original size. I have marked the issue generally comes for application that uses "configure_event" . But I don't see the applications doing anything wrong that changes the min_height or min_width. The issue is not reproduciable when I use sawfish (does not mean the bug is in metacity :). But I don't have any clue as to where the fix should go, in the Application or in metacity. The issue comes (for example for gedit ) because 1.the min_height changes from 94 to 176. 2.metacity gets two requests for Updating WM_NORMAL_HINTS. 3.Though the min_height changes from 94 to 176 the base_height is maintained at 94 only. and during restoring this value (94) is used which make the height of gedit to shrink by 82 (176-94). Hope I am clear !!
Are you saying that gedit ends up with a min_height 176 and base_height 94, in the WM_NORMAL_HINTS, or that gedit has min_height/base_height both 176 but metacity does not notice the change to the base height?
yeah, gedit ends up with min_height/base_height both 176, but for metacity the base_height remains as 94. Which is causing a shrink of 82 in the height while restoring the session.
Havoc, I have a question. Could you please clarify it. When we get the XGetWMNormalHints of gedit for the first time it gives the value of min_height as 94. After that, gedit sends a property notify event and the value min_height changes to 176. Is min_height not a constant value for an application. Can it be changed? If it shouldn't change then it might be the application problem. If min_height can be changed then is it right to Create all application windows of the display then Apply saved session properties for each window in a loop rather than Create a single application window and apply its saved session properties Go for the next window Since by the time when all the application windows are created, the change in the properties would have finished and we can get constant min_height value. I may be wrong sorry, i just want to clarify it.
min_height can be changed. gedit probably _shouldn't_ be changing it immediately upon mapping the window though, as it will flicker a bit.
If min_height can be changed then I guess the window manager should not use this value for calculation while restoring a session. As it can change during the course of an application execution which may lead to wrong calcualtions.
Gedit tries to change the min_height from 94 to 176 when it tries to open its saved file subwindows. When it doesn't have any opened files, then there is no change in geometry. Since this min_height can change at different points for different reasons in varied applications, for the safer side :( could we go about saving the exact width and height at the cost of restoring original geometry in the case of changing the font?!
You guys are missing the point, I think. We need to know: - what are the base/min size of gedit when gedit is saved? (look with "xprop", don't assume metacity gets it right) - what are they when gedit is restored? (also look with xprop) - if they are different, why? - if metacity gets a different value from xprop, why?
When gedit is opened newly then the min size is 267*94. Then it opens a new empty file (Untilted 1 - gedit) when the min size changes to 267*176. Now do save session. During session save the value taken for min size is 267*176 and it saves the empty file (Untitled 1) also. During restore session metacity first draws empty gedit without any opened file when the value taken for min size is 267*94. Metacity then applies the saved session properties i.e geometry also for gedit. Soon after, it restores the opened empty file (Untitled 1) when the min size changes to 267*176. Actually if metacity tries to apply the saved session properties after restoring all opened files, then there wouldn't been any problem. If we close the empty file (Untitled 1) then the min size again changes to 267*94. Now do save session. The value taken for min size is 267*94. During restoring session gedit restores properly with 267*94 since there is no opened file. Gist: Gedit restores properly without any opened files. When it has any opened files then gedit is drawn min size is 267*94 metacity applies its saved geometry properties gedit opens the saved already opened files min size gets changed to 267*176 now any save session uses 267*176
I propose the right fix here is for gedit to open the file before mapping its windows, or for gedit to not change min size when it opens a file.
*** Bug 91970 has been marked as a duplicate of this bug. ***
Could it be moved to gedit ?!
Moved to gedit
gedit is not changing the min_size specifically. I think the problem is with using the gtk_window_set_default_size(). gtk_window_set_default_size() does not obey the geometry hints and may be this is the problem. Replacing all gtk_window_set_default_size() with gtk_widget_set_size_request() solves the Issue , but it makes the window non shrinkable . Attching a patch which sets the base size after calling gtk_window_set_default_size() and fix the issue ( without making the window non shrinkable).
Created attachment 11109 [details] [review] Proposed patch for gedit
There's no way that patch is the right thing to do. Something else is wrong, either in GTK or gedit or metacity.
Satyajit, hp: FWIW, the PATCH keyword should be added if a patch is attached to a bug and removed if the patch is inappropriate.
Agreed. This is just a hack ( may be a bad one) to fix the thing in gedit. Cause I don't find gedit doing anything specifically to change the min_height and min_width ( or rather geometry). While going through the debug messages (metacity) I find metacity gets two different sets of min_size from gedit. Here are the debug messages. 1.Window manager: Window has _NET_WM_PID 4088 GEOMETRY: Updating WM_NORMAL_HINTS for 0x1600003 GEOMETRY: Window 0x1600003 sets min size 267 x 94 GEOMETRY: Window 0x1600003 sets gravity 1 2.Window manager: Property notify on 0x1600003 (Untitled 1) for WM_NORMAL_HINTS GEOMETRY: Updating WM_NORMAL_HINTS for 0x1600003 (Untitled 1) GEOMETRY: Window 0x1600003 (Untitled 1) sets min size 267 x 176 GEOMETRY: Window 0x1600003 (Untitled 1) sets gravity 1 Trying to find out the place or call in gedit which generates a PropertyNotify event with atom WM_NORMAL_HINTS. ( Any help on this)
To Add more to this bug ( not related to gedit at all) as I had mentioned earlier gperfmeter ( gnome-perfmeter) also has similar issue where the size is not getting restored properly after the saving the session. But there I could find a gtk_window_set_geometry_hints() getting called after a gtk_widget_show ( after the widget is mapped). I just reversed the order ( that is gtk_widget_show() after setting the geometry) and it fixes the issue (which I guess is correct). But in gedit I don't find any place where any geometry related events are getting called except the above one.
When gedit starts there are two things that gets mapped 1.The window (gtk_widget_show (GTK_WIDGET(mdi->priv->active_window)); which sets the min_size to 267*94 . 2.The view that gets created.( bonobo_mdi_child_create_view ()) which sets the min_size to 267*176 When I click on File->Close the view gets removed and the min_size is set to 267*94 again and things work fine. Now As I understand if there is one mapping we will have one min_size only and it will solve the issue. Does that mean the active window should get mapped at the end ( after the view is crteated and added) which will send only one min_size.
I verified with sun's beta2 build9 cvs dated 17th sept on solaris. EOG is not fully session aware. If I open any *.png file before logout I do get EOG. If I just EOG without any opened file in it, I don't get EOG after login.
I've tried this on sun's beta2 build10 - dated 24th sept from CVS. Gnome-terminal and Eog do not restart after logging out and logging back in again. Gedit starts no problem and in the correct workspace. I also found that Eog would start if there was a file open before logging out.
yes, If EOG is opened with any file, then it will be restored after session logout and login. Otherwise(If EOG is just invoked with-out any opened file in it) session logout and login will not bring back EOG. As of now, EOG is session aware only with the file opened in it.
I think this is fixed for gedit. Can someone confirm, and possibly give a hint where the bug should be moved to if it is?
Yogi: Shane: ?
paolo: I verified this on linux cvs head dated 16th dec 2002. This bug is still exists. (i.c, gedit comes with incorrect/decreased geometry on every logout /login). And EOG is still not session aware without any opened doc in the application.
I verified with 30th Dec2002 cvs build on linux, EOG is session aware. I do get EOG after logout and login without any file opened in it. this bug can be moved to verified.
What about gedit? Could someone give a look at this bug?
I verified this bug on community head build dated 23-06-2003. Gedit works fine and is fully session aware. this can be closed.
So, closed then.