GNOME Bugzilla – Bug 323175
Capplets do not remember their window size
Last modified: 2010-11-16 15:44:40 UTC
Run gnome-background-properties, resize the window the way you like it. change your wallpaper or whatever, close the window. Open it again, and its size will be reset to that annoyingly tiny size. You need to scale it up again each time. It is not so great when you have a huge amount of wallpapers in there.
I'd like to see this happen. How does this behavior relate to other capplets, such as the theme manager? If they also have this problem, this bug should probably be noted for all the capplets it applies too. If there are no objections to having this feature, I'll see if I can make a patch.
They only remember their size when their "mother" window was not closed (speaking of the theme manager for example. If I click details, size it, close it, click details again, it will keep its size. But if I close the entire thing, the size will be reset). Also, the window positions are not remembered at all.
Created attachment 56826 [details] [review] Save and restore window size This patch store the size of the window in gconf and restore it when it's started. The key used to do this is: /apps/gnome-background/ui/width (and height). The app already use /desktop/background/ but I think more convenient to use the /apps/gnome-background to store this kind of things. What do you think? I it's ok, I will create the schema for it.
I believe gnome-background would make sense, but I'm just a user :) but yes, I am more inclined to look into /apps/ first instead of looking into /desktop/ so this might be a good idea.
This is an application setting, not a desktop setting, so it should definitely reside in /apps/. One thing to consider is that it would be nice to be able to patch the other appropriate capplets with this functionality (such as the theme manager), so it would be good to consider that they all save their state information in a consistant way.
Ah, I was hoping someone would say this :) so far I've been filing bugs on various parts of the desktop for this same issue. Actually, are there any apps that MUST NOT remember their dimensions? I think this can work with pretty much anything, and I was surprised when I arrived in gnome 2.6 and lots of applications did not have that "functionality".
I would much prefer something like "/apps/control-center/<capplet>/<direction>" as the keys for the settings. For gnome-background-properties, this could be, for example, "/apps/control-center/background/{width,height}" and would get rid of the extra "/ui/" tree bit. This also would be a good precedent for other and future capplets to use. Alternatively, we could also use an ini-style file in ~/.gnome2/ or somewhere.
Created attachment 56875 [details] [review] Save and restore window size v2 Updated patch with schema file and using /apps/control-center/background/{height, width }
Sorry to bug you again, but is the patch going into gnome 2.14 after all?
Sorry, no. It will not be in 2.14.0. Perhaps in 2.14.1, but I have not had time to look at this any further due to more important issues to solve. I will try to look at it again soon. We really need a standard common way of doing this for all of the capplets, not just copying the code into every capplet.
I have to bug you guys again (it's almost the birthday of that bug ;) if it could get into 2.18. Is gconf-editor part of this? It does not remember its properties either. Neither does the GTK File Chooser. If having a big infrastructure for saving this globally would require so much time, why not use the (less elegant) technique of just copy-pasting that code into the applets, if it works for now? Just add a reminder to beautify it sometime.
I don't really like having the same code cut-and-pasted. It also adds a new file, with new strings. The background schemas are in libgnome already. I don't think we should have a bunch of separate schemas files for each capplet, just to set up descriptions for keys to store the width/height of the windows. I would prefer that the code that peaks at the allocation to save state, either just peaked into the allocation when calling gconf_set_int rather than copying the allocation's address out, or that _get_allocation or one of the _get_size methods, were used.
The schema file in libgnome (desktop_gnome_background.schemas.in) is for the settings of the current background selected. There are another for the capplet? (I can find it).
No. There are no settings specific to the capplet itself. However, if we really need schemas to store the window size and position, then we should have one schema file for all of control-center, not one for each capplet therein.
I think this probably ought to go in one of the libraries in capplets/common, (or a new library if an appropriate one doesn't exist). I'm going to move this bug to the 'general' component to indicate we need a solution for all capplets.
Updating title too.
If the new "all in one window" control center is to take over the menus in GNOME 2.18, it needs to remember its attributes such as size and position. Otherwise, a lot of folks will likely be horrified to resize up/down the window each time they open it up. Go! Go! Go!
*** Bug 439534 has been marked as a duplicate of this bug. ***
*** Bug 452073 has been marked as a duplicate of this bug. ***
Can't a dialog calculate it's optimal size automatically based on it's contents? Remembering size (and position) may not be necessary and may not be what users want.
This bug is half a decade old. Here are the components in control center, as of today, that typically display lots of elements and that can't easily calculate their optimal size on their own. These are the components that should remember their size: - appearance - startup programs - keyboard shortcuts - screensaver - network connections (network manager) - printers (if part of gnome) - gnome-volume-control - gnome-nettool Could this be looked into for GNOME 3.0? What is needed for this to happen?
This is actually a bug for each individual panel, not a throw-it-all bug. When you've tested the new control-center, feel free to file bugs for panels that don't work as you expect.