Bug 134537 - Gnome-panel update rearranges existing panel config in confusing manner
Gnome-panel update rearranges existing panel config in confusing manner
Product: Fedora
Classification: Fedora
Component: gnome-panel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mark McLoughlin
: 134609 (view as bug list)
Depends On:
Blocks: 131589
  Show dependency treegraph
Reported: 2004-10-04 10:56 EDT by Stephen Tweedie
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-12 14:12:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Screenshot showing rearranged panel (398.60 KB, image/png)
2004-10-04 10:58 EDT, Stephen Tweedie
no flags Details

  None (edit)
Description Stephen Tweedie 2004-10-04 10:56:36 EDT
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
 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):

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:
Comment 1 Stephen Tweedie 2004-10-04 10:58:37 EDT
Created attachment 104718 [details]
Screenshot showing rearranged panel
Comment 2 Bryan W Clark 2004-10-04 14:06:45 EDT
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:
Comment 3 Mark McLoughlin 2004-10-05 01:43:53 EDT
*** Bug 134609 has been marked as a duplicate of this bug. ***
Comment 4 Mark McLoughlin 2004-10-05 06:28:03 EDT
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

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.
Comment 6 Barry K. Nathan 2004-10-05 07:30:31 EDT
(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).
Comment 7 Mark McLoughlin 2004-10-05 07:46:35 EDT
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.
Comment 8 Havoc Pennington 2004-10-05 11:02:53 EDT
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.
Comment 9 Mark McLoughlin 2004-10-05 11:12:59 EDT
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
existing panels.
Comment 10 Mark McLoughlin 2004-10-12 14:12:41 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.