Red Hat Bugzilla – Bug 134537
Gnome-panel update rearranges existing panel config in confusing manner
Last modified: 2007-11-30 17:10:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
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
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):
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
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:
An explanation of changes:
*** 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
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
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
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
Right now, we allow people to lockdown toplevel_id_list to prevent
people adding new panels while still adding new things to their
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.