GNOME Bugzilla – Bug 137128
Gedit forgets unmaximized window size
Last modified: 2013-06-20 19:46:37 UTC
Gedit forgets its unmaximized size if the window is closed after the window has been maximized. Steps to reproduce: 1. Open Gedit modify window to prefered size 2. Maximize the window 3. Quit the program 4. Restart the program and switch back to unmaximised state The window should remember its size in unmaximised state on next startup of the program even if it was closed in the maximised state. Wonderful app, by the way. :)
Your are right, but implementing this feature in the current code base requires an ammount of work I'm not sure it is worth doing. I'm not going to implement it, but I'm willing to accept patches.
If you or anyone intends to implement it, it could be safe to read this Evolution's bug #243962 in order to know how to implement it correctly.
I see this problem when I exit gedit in both unmaximized or maximized state.
Can't we store the current size of the window on the window maximize event? Everytime the window is maximized, the latest dimension gets saved. we can retrieve this stored dimension when we open Gedit next time.. Please correct me if i'm wrong.
Created attachment 160626 [details] [review] Save window position and fix saving the size of an unmaximixed window
We intentionally do not save the position, the window manager should make its choice depending on which other windows are already on the screen, which is the current monitor in a multihead setup etc.
Unfortunately this is not done and some applications do save their position. For example devhelp does this, their keys are in /apps/devhelp/state/main/window and they are x_position and y_position. Non-extensive list of other applications that save their position: Banshee, Rhythmbox, XChat, Glade.
they are all apps that usually have just a single window (except for devhelp, but usually you do not have two devhelp windows open either) with a text editor it is different I have gedit windows open on different workspaces and they are all placed at different positions
Created attachment 160651 [details] [review] Updated to remove position logic
Created attachment 160654 [details] [review] Removed unused function
Review of attachment 160654 [details] [review]: One minor comment. ::: gedit/gedit-window.c @@ +222,3 @@ +{ +save_window_state (GtkWidget *widget) +static gboolean you can just use window->priv->...
Created attachment 160655 [details] [review] Use variable instead of casting
Review of attachment 160655 [details] [review]: It is late and I just glanced over the patch, but I still don't understand why we need a timer to poll the size instead of using the appropriate signal when the size changes
Created attachment 161193 [details] [review] Don't use a timer I used a timer like other implementations I believe they did this in-case saving the size was slow which would affect resizing the window. The attached patch does not use a timer.
Created attachment 161194 [details] [review] Fix warning
Review of attachment 161194 [details] [review]: Some questions inline. ::: gedit/gedit-window.c @@ +371,3 @@ } + if (GTK_WIDGET_CLASS (gedit_window_parent_class)->window_state_event) is this check really needed? @@ +393,1 @@ + if (GTK_WIDGET_CLASS (gedit_window_parent_class)->configure_event) Same as above.
Created attachment 161229 [details] [review] Dont check if configure_event is set The check for state_event is needed as it currently is not set.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
What is the version which is fixed? In Mint 15 I still see this problem (although Mint 15 uses pretty old version of gedit - 2.30.4 - for unknown reason)
2.31.2 Mint 15 has 2.30.4 installed by default, but you can install 3.6.4 by going into synaptic and choosing an alternative version.
Thanks. I do not see the problem in 3.6.4 anymore.