From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 Description of problem: Updating from rawhide-20040928 to rawhide-20041003, my existing panel got totally rearranged, and the resulting layout has icons and applets spread almost randomly over the desktop. The old panel was a standard one created with FC2, with only a couple of added applets. The existing panel was shrunk from 64 to 32 pixels; The desktop browser was split apart and rendered unusable: the multiple-desktop image was split apart from the current viewport window list; the window list was given about 100 pixels to work with. Applets were reorganised randomly: battery applet on bottom panel, audio on top; process monitor on bottom, date/time and notification area on top. I'll attach a screenshot. Version-Release number of selected component (if applicable): gnome-panel-2.8.0.1-2 How reproducible: Didn't try Steps to Reproduce: 1. Install FC2 2. Create account 3. Upgrade to rawhide Actual Results: Unusable panel config. Expected Results: Either leave existing accounts alone or create a sensible reorganisation. Additional info:
Created attachment 104718 [details] Screenshot showing rearranged panel
Mark, the new panel arrangement shouldn't have effected existing users, only configurations that haven't been initialized, correct? Here is what the intended layout is: http://people.redhat.com/bclark/screenshots/new_panel_layout.png An explanation of changes: http://www.redhat.com/archives/fedora-devel-list/2004-October/msg00077.html
*** Bug 134609 has been marked as a duplicate of this bug. ***
Okay, this is actually a difficult issue. I don't see an easy way out of it. What's going on here is the panel configuration consists of a large set of inter-related GConf keys. Lets think about just two of them for a minute - toplevel_id_list and object_id_list. The former contains the list of panels in the configuration and the latter contains the list of launchers, menu buttons, menu bars etc. (everything but bonobo applets). These GConf keys individually inherit their default values from defaults database. If you set one of the keys, it no longer matters what the default is, but the other one still inherits the default. So, looking at Stephen's screenshot, its obvious what happened. He added a new launcher to his panel at some point, setting object_id_list to contain all the default launchers and his new one. toplevel_id_list remained unset, inheriting the default. Now, when the panel package was updated the defaults changed, adding an extra panel to toplevel_id_list, removing the menu button from object_id_list and adding the menu bar to object_id_list. End result is that Stephen see's the new panel, but still sees the menu button when he should be seeing the menu bar. Two problems need addressing: 1) Is there any way we can make this particular change in defaults not break for people moving from FC2 to FC3? I don't have any bright ideas here 2) How to prevent this happening if we change the default panel configuration in future Probably the only thing we can do is that if you change anything in your panel configuration, we ensure that the whole lot is saved in the same database. Problem here is that locking down individual keys would no longer be able to work. The entire panel would have to be locked down if any individual key was locked.
(speaking as a user) Don't forget to also consider upgrades from stuff older than FC2 (e.g. RHEL3), if this panel change is ever going to reach RHEL at some point (whether that's RHEL 4 or RHEL 5).
Yeah, its not a problem with RHEL3 -> RHEL4 because in older version of the panel we copied the entire default panel configuration the first time the user logged in. We may need to go back to doing that again (we stopped doing it to avoid problems with lockdown and admins wanting to be able to change user's defaults) - but if we do, its not going to fix the immediate FC2->FC3 problem.
Mark, can you explain this, for some reason it's going over my head: > Problem here is that locking down individual keys would no > longer be able to work. The entire panel would have to be locked > down if any individual key was locked.
If you make it so that any change in the panel config requires you to write out the entire panel config, you need to be _able_ to write out the entire panel config in order to make _any_ change. e.g. if a user adds a launcher to the panel, we could write toplevel_id_list to avoid the kind of breakage we see now. But if toplevel_id_list is non-writable, you would have to disallow adding launchers. Right now, we allow people to lockdown toplevel_id_list to prevent people adding new panels while still adding new things to their existing panels.
Okay, so without a time machine I can't do anything about the FC2 -> FC3 problem, but in 2.8.1 I've made it so the id lists always get saved together which should prevent this happening again in future.