GNOME Bugzilla – Bug 32225
Wish panel applets had a 'save as default' option.
Last modified: 2020-11-07 12:15:14 UTC
Package: panel Severity: wishlist Version: Synopsis: Wish panel applets had a 'save as default' option. Class: change-request Distribution: Red Hat Linux release 6.2 (Zoot) System: Linux 2.2.16 i686 unknown C library: glibc-2.1.3-15 C compiler: egcs-2.91.66 glib: 1.2.8 GTK+: 1.2.8 ORBit: ORBit 0.5.3 gnome-libs: gnome-libs 1.2.8 libxml: 1.8.9 gnome-print: gnome-print-0.20 gnome-core: gnome-core 1.2.99cvs Description: This is my wish: Panel applets should have a 'save as default' button in their property dialog so that the user's settings can be saved between removing / re-adding an applet. The reason this can not be automatic is because of multiple applets, but at least with this option the user can have a 'useable default' to their liking. Addition should be simple: make an applet_property_box widget derived from gnome_property_box. Add the button, this makes changing applets to support it a one line change, and retains backward compatibility. For example the modemlights_applet already has this (check it's advanced properties, see button in lower right corner :). Sorry, too lazy to do it myself. ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-27 13:17 ------- This bug was previously known as bug 32225 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=32225 Originally filed under the gnome-core product and panel component. The original reporter (johne@bellatlantic.net) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, panel-maint@bugzilla.gnome.org.
Adding relevant keywords. You can filter on the phrase 'luis doing GNOME2 work' to catch all instances of this so that you can ignore them.
this would be a very handy feature, especially when you first setup your panels and add/remove applets.
*** Bug 89690 has been marked as a duplicate of this bug. ***
*** Bug 89311 has been marked as a duplicate of this bug. ***
*** Bug 73921 has been marked as a duplicate of this bug. ***
Right ... so this can be really annoying. For example if you have a workspace setup with more than a single row, every time you add a pager or start the panel with a new profile or whatever you're thrown back to a single row again ... So I've implemented a "Save Preferences As Default" feature and I'll attach the patch in a second. At the moment libpanel-applet just merges in a menu-item to the popup menu but really each individual applet should do that because an applet may not have any preferences and only the applet can know where to merge it into the menu ... So ... usability-maint: this sucks really. But should we put it in? If we do put it in, might it be better to have it as a button in the preferences dialog. Havoc, I cc-ed you because I'm sure you'll have some insight ... Maybe this is all just indicative of the fact that these settings aren't per applet settings at all and should be global settings. But how do we control the semantics of these settings if we make them global and a user has more than a single instance of the applet on the panel. Do we have a second preferences dialog for global preferences ?
Created attachment 13520 [details] [review] patch
Would it be OK if some things (such as number of workspaces) were just transparently global to all workspace applets. i.e. leave the UI exactly as it is now, but save that setting in a global spot, and have changing it update all the workspace applets. Another possibility is that if we resolve the bug http://bugzilla.gnome.org/show_bug.cgi?id=94716 there might be a Defaults button in the dialog, so then it would be pretty safe to just transparently save the last prefs that were modified as the defaults for new applets. i.e. if I have one applet, and I make another, it copies the existing one instead of starting from scratch. Also if I have an applet, delete it, put it back, then I get back the config I had. I do think the extra menu item is pretty bad, it's the kind of overcomplicated manual fix that most people won't figure out, and hackers will grow to love and whine hugely if you take it out. Also, I think given the ease of removing an applet, it would be better if applet state was *automatically* saved if you remove the applet and then put it back. That could really save your butt in a lot of cases (where I doubt you'll normally have remembered to manually "save as defaults") Well, just some ideas, I don't claim to have the perfect solution.
Hmm ... I'd like the saving to defaults to be done automatically too, but I fear we'd just be leading ourselves into the 1.4 scenario of "whichever instance of the app you closed last is the one who's preferences will be saved" - is that not what gconf is trying to prevent ? Consider a scenario that I go through quite often: * Have a gweather applet telling me what the weather is in Auckland at the moment ... * Oooh, I hear its cold at home ... add a gweather applet set to Dublin and snigger to meself for a few hours and then remove the applet again. So in that case the default location would be saved as Dublin, but Auckland makes more sense. Its still a lot better than the current default of Pittsburg alright ... Hmm, actually ... maybe those semantics aren't too bad. So long as we only save the defaults when the applet has been explicitly removed.
well, the 1.4 situation was that if you had 10 instances open with different settings, logged out, logged in, the 10 were restored with the same settings (matching a random one of the 10). This is slightly different, in that as long as the 10 are open, they will always get back their correct per-instance state, we're just talking about randomly picking one to copy for *new* instances, right. Which doesn't seem terrible. Thinking more about the number of workspaces thing, I don't think the pager is even supposed to be storing that, it should be reading it from metacity I thought... and for workspace layout, only the first applet to open should affect it... so there may just be a bug there.
It was workspace layout I was referring to. I think the problem there is that instead of being a global preference on how your desktop is set up, the layout is currently just seen as property of the visual representation of the workspaces in the pager ... but its clearly a global preference rather than a pager setting because you don't just navigate around workspaces with the pager - you do it by the keyboard too. (But sure I see your point about the contrast with the 1.4 problem. This clearly wouldn't be anywhere near as bad)
Right, basically having two pagers with different layouts is just broken; the layout is a global fact of life and you can't have two different ones. There's supposed to be a selection though that the pager has to own before it can set the layout - the libwnck code goes to a lot of trouble to be sure only one pager will set it, the first one to run. That code must be broken if running a second pager resets the layout. Anyway, I guess this is a tangent. ;-)
(Just to continue the tangent ... I wasn't referring to any problems with two pages at the one time, I was referring to the fact that the preference is save per-applet, rather than in a global /desktop/applications/window_manager or /apps/metacity or whatever)
Calum, Seth, Nils, Dave: no opinions here ?
Well, I haven't put a huge amount of thought into this, but I do think Havoc's "make any preference changes the new default" idea sounds better than what we've got now, and a lot better than having a "Set as Default" button in every applet's preferences dialog...
Mark, is this patch still valid/useful/whatever? I'm guessing from the description 'no'...
Comment on attachment 13520 [details] [review] patch Decision on functionality needs to be made; see Comment #9 and following remarks
The problem with this idea is it would store crap somewhere on the off-chance you would re-add an applet you have removed. The answer probably lies in designing more intelligent defaults and detection schemes in the applets themselves. Suggest this be closed off as trivial and stale.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use gnome-panel and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.