Bug 97084 – gnome-panel 2.10 incorrectly restores panels order if both are placed on bottom

• Product: Gentoo Linux
• Status: RESOLVED TEST-REQUEST

[Description Wiktor Wandachowicz 2005-06-25 19:17:53 UTC]

From gnome 2.6 I used to place both default panels (the one with gnome menu, and
the second one with task list) on the bottom of my screen. I like them to be
positioned as such:

+----+-----------------------------------------------------+-----------+
|desk|  [application buttons]                              |desk-switch|
+----+-----------------------------------------------------+-----------+
|MENU|Applications|Places|Environment| Nautilus|Shell      |date/time  |
+----+-----------------------------------------------------+-----------+

To do so, one just needs to drag the panel with gnome menu from the top (where
it is located by default) to the bottom of the screen.

However, from version 2.10 on a clean profile (like after adding a new user)
I can't get such configuration permanent anymore. I can arrange panels using
mouse, but after logging out and logging back, panels replace each other:

+----+-----------------------------------------------------+-----------+
|MENU|Applications|Places|Environment| Nautilus|Shell      |date/time  |
+----+-----------------------------------------------------+-----------+
|desk|  [application buttons]                              |desk-switch|
+----+-----------------------------------------------------+-----------+


I noticed that misbehaviour after I reinstalled Gentoo with Gnome 2.10.
It's interesting to notice that after I only upgraded Gnome on my main computer,
old settings still worked (i.e. no replacing occurs). But when there are no
settings at all, I can drag panels so they look the way I want, but after
re-logging they always replace each other.

Reproducible: Always
Steps to Reproduce:
1. emerge =gnome-2.10
2. make sure that there are no gnome-related settings in your home directory
(create a new user or move .gconf, .gconfd, .gnome, .gnome2, .gnome2_private,
.local dirs to some BACKUP dir)
3. log in
4. drag a top panel (with gnome menu) to the bottom of the screen
5. log out
6. log in
Actual Results:  
Panel positions are incorrectly saved and/or restored, so they replace each other.

Expected Results:  
Panels should save and/or restore their positions and order properly, so if I
put them both on the bottom, all should look the same after I log out and log in
back.

I'm not exactly sure if this problem happens in Gnome 2.10 only, or if Gnome 2.8
has had the same issue. I remark once again, that after I upgraded Gnome (thus
migrating my settings) I haven't noticed this. The problem occurs only on a
clean profile (new user --> no settings yet).

From all my observations this probably is a general upstream bug.

[Comment 1 John N. Laliberte (RETIRED) 2005-07-15 19:43:55 UTC]

does this happen in 2.10.2 ?

[Comment 2 Ivan Yosifov 2005-07-23 09:14:34 UTC]

In my case the panels were restored one on top of the other.
I had to move away one to see the other.

Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r0,
2.6.12-gentoo-r6 i686)
=================================================================
System uname: 2.6.12-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5, 2.4.1-r1
sys-apps/sandbox:    1.2.11
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -mtune=pentium4 -fomit-frame-pointer
-momit-leaf-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c
/etc/env.d"
CXXFLAGS="-O2 -march=pentium4 -mtune=pentium4 -fomit-frame-pointer
-momit-leaf-frame-pointer -pipe -fvisibility-inlines-hidden"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.ITDNet.net/gentoo"
LANG="en_US.utf8"
LC_ALL="en_US.utf8"
LINGUAS="en"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X acl alsa apache2 avi bash-completion berkdb bitmap-fonts bonobo cdr
crypt cups curl directfb doc dvd dvdr eds emboss encode flac foomaticdb gd gdbm
gif gnome gpm gstreamer gtk gtk2 guile hal imagemagick imlib ipv6 ithreads java
jpeg junit kde kdeenablefinal ldap libg++ libwww mad mikmod mmap mmx motif
mozilla mp3 mpeg mysql ncurses nls nptl nvidia ogg oggvorbis opengl pam pdflib
perl pic plotutils png postgres pthreads python qt quicktime readline sdl
session sharedmem spell sse sse2 ssl svga symlink tcltk tcpd tetex threads tiff
truetype truetype-fonts type1-fonts unicode usb vorbis win32codecs xml xml2 xmms
xv zlib linguas_en userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LDFLAGS

[Comment 3 Wiktor Wandachowicz 2005-08-02 05:29:51 UTC]

Recently I've spotted the same problem in Ubuntu 5.04, on a new account.
Since they use the same Gnome version, this confirms further my observations.

However, I don't really want to emerge newer, ~arch'ed Gnome, just to see that
the problem persists and it still doesn't work the way it did once. So, for me
there's still a regression bug with Gnome panels position saving/restoring.

[Comment 4 Pacho Ramos 2005-10-04 10:42:51 UTC]

Have you tried using gnome-panel-2.10.2? Now, it is stable
Look at: http://packages.gentoo.org/ebuilds/?gnome-panel-2.10.2

[Comment 5 Wiktor Wandachowicz 2005-10-05 02:47:47 UTC]

Unfortunately, the problem remains.

1. I've created a new account, logged in and the initial panel locations were:
http://ics.p.lodz.pl/~wiktorw/gnome-problem/initial.png

2. Then I dragged the upper panel to the botom:
http://ics.p.lodz.pl/~wiktorw/gnome-problem/moved.png

3. Then I logged out, making sure that the settings will be saved.

4. After I logged in again, the panels were replaced:
http://ics.p.lodz.pl/~wiktorw/gnome-problem/re-login.png


The strange thing is that on my normal account, which was created quite a while
ago, I have the panels just as I would like them to be [see step 2.]
So, something is saved in the configuration in a way that gnome-panel restores
the locations correctly, even after upgrading it to the newer version.
However, the newer gnome-panel makes a mess on a new account wrt. dragging the
panels around.

This is a regression, and I suspect that Gnome developers may be unaware of this
fact, as they probably check if everything works on their EXISTING accounts. And
for the NEW accounts they prefer the panels to be on the top (menu) and the
bottom (takbar) of the screen...

[Comment 6 Wiktor Wandachowicz 2005-10-17 15:54:09 UTC]

Well, I have found a workaround finally.

I just searched the home directory for the string "_panel". It occurs in several
files, of which this one is important:

[1] ~/.gconf/apps/panel/general/%gconf.xml

Also the following two are the subject of suspicions:

[2] ~/.gconf/apps/panel/toplevels/top_panel_screen0/%gconf.xml
[3] ~/.gconf/apps/panel/toplevels/bottom_panel_screen0/%gconf.xml

The core problem comes from th fact that in the [1] file, there is a part near
the end which looks like this:

  <entry name="toplevel_id_list" mtime="1129586700" type="list" ltype="string">
    <li type="string">
      <stringvalue>bottom_panel_screen0</stringvalue>
    </li>
    <li type="string">
      <stringvalue>top_panel_screen0</stringvalue>
    </li>
  </entry>
  <entry name="profiles_migrated" mtime="1129586700" type="bool" value="true">
  </entry>
</gconf>

The first thing is to swap the original order of "bottom_panel_*" and "top_panel*":

    <li type="string">
      <stringvalue>bottom_panel_screen0</stringvalue>
    </li>
    <li type="string">
      <stringvalue>top_panel_screen0</stringvalue>
    </li>

into:

    <li type="string">
      <stringvalue>top_panel_screen0</stringvalue>
    </li>
    <li type="string">
      <stringvalue>bottom_panel_screen0</stringvalue>
    </li>

This from the programmatic point of view is the order in which the panels save
and restore their repsective positions. If the order is "bottom";"top", then the
bottom panel (task list) does it first then the top panel (gnome menu, etc). If
the order is reversed, then the top panel (menu) first occupies the desired part
of the screen, so the bottom panel (task list) must find its way above the menu.
Just changing this gives me the desired effect.

But there is also the vertical position issue.

The second thing is to locate the [2] and [3] files and check the "y" value for
the top and bottom panels, like:

[2] ~/.gconf/apps/panel/toplevels/top_panel_screen0/%gconf.xml
  <entry name="y" mtime="1129586786" schema="/schemas/apps/panel/toplevels/y"
    type="int" value="741">
  </entry>

[3] ~/.gconf/apps/panel/toplevels/bottom_panel_screen0/%gconf.xml
  <entry name="y" mtime="1129586786" schema="/schemas/apps/panel/toplevels/y"
    type="int" value="739">
  </entry>

(the actual values for "y" depend on the theme(s) used; for my original profile
the values were "742" and "740" respectively)

It looks like the values are stored correctly. I mean, the top panel / menu, is
placed LOWER (741) than the bottom panel / task list (739). After logging in
panels are restored CORRECTLY. But after logging out with saving the settings,
it turns out that the values are swapped (sic!). I don't understand that...
Luckily, those values don't affect the positions of the panels. Menu is still
below the task list.

At this point I can conclude that doing the first part (swapping the list
entries in [1]) solves my problem. But it looks like the position save/restore
code changed somehow from Gnome 2.8 to Gnome 2.10.

And that's the workaround I happily use right now :-)

The question if this should be reported upstream is still open.
And I don't know if this problem still applies to Gnome 2.12.
Is there anyone interested in testing that?
I'd be happy to know that this issue is already resolved!