GNOME Bugzilla – Bug 76925
launchers and applets reloading in the wrong position
Last modified: 2015-03-24 13:00:31 UTC
start with a blank panel at the top (the one with the foobar, clock, etc) and add the system monitor and workspace switcher. then create some launcher icons (i have some for mozilla, gnome-terminal, etc). now, move the system monitor and workspace switcher as far right on the bar as they will go, and push the launchers just up against those from the left. log out, save your settings and log back in. your launchers are now by the clock instead of being to the left of the task switcher and system monitor. they should be where you left them.
I think this probably has to do with the 'right_stick' property. If a launcher to the left of an applet has this set it will get loaded before the applet and will end up to the right of the applet.
*** Bug 78531 has been marked as a duplicate of this bug. ***
Highly visible; marking 2.0.0.
This is also a problem without mixing applets and launchers. I have panels that only contain applets. After a logout(with save-session) and relogin, that also start in the wrong position. This is really annoying, I can't put my mail-check applet where I see it ;-).
I fixed this in CVS by changing the meaning of the 'right_stick' property. If right_stick == TRUE, then the applets position as saved in gconf will be relative to the right hand side of the panel. This will break peoples applet setup the first time they use this fix - if they have pre-saved applets with the right_stick property as TRUE.
I have a corner panel filled with drawers, launchers, a menu button, and a log-out button. Each corner panel is filled with only launchers. (the idea is to have a more powerful equivelent of a "quick launch" toolbar, and it works quite well). On the corner panel, the positions of all objects appear to be mixed up on logout/login, as does the positions of the launchers in the individual drawers. Gnome panel 2.0.1 (reposted from #84744) Could this be a special case that hasn't been fixed for this bug, or perhaps is #84744 not a duplicate of this as suggested there?
*** This bug has been marked as a duplicate of 84744 ***