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.