After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 84744 - Some applets don't preserve order on drawers
Some applets don't preserve order on drawers
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: panel
2.0.x
Other All
: High major
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 76925 85421 86289 86660 87352 87685 87721 88737 90598 98740 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-06-10 14:50 UTC by Jan Mynarik
Modified: 2015-03-24 13:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Don't touch applet position on drawers (371 bytes, patch)
2002-10-03 13:36 UTC, Frederic Crozat
none Details | Review

Description Jan Mynarik 2002-06-10 14:50:43 UTC
Panel version 2.0.0.

I have two corner panels at the bottom of the screen. Both are horizontal,
one in the left corner and second in the right one.

I set the applets this way (from left):
left panel: gnome menu, terminal, workspace switcher, lock button
right panel: keyboard switcher (gkb), clock

After logout (using checkbox to save settings) applets are reordered:
left panel: gnome menu, workspace switcher, terminal, lock button
right panel: clock, keyboard switcher

Tried many times, always same result.
Comment 1 Jan Mynarik 2002-06-11 09:34:25 UTC
.... after logout and new login ... :-))

Comment 2 Luis Villa 2002-06-11 22:05:00 UTC
I could swear this was a dup but I can't find it.
Comment 3 Arvind S N 2002-06-13 03:43:02 UTC
luis:bug #76925
Comment 4 Jan Mynarik 2002-06-18 10:34:30 UTC
It's maybe duplicate but it's definitely not fixed (tested also with
panel 2.0.1).
Comment 5 Jeremy Nickurak 2002-06-25 06:31:59 UTC
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
Comment 6 Heath Harrelson 2002-07-02 05:14:47 UTC
*** Bug 86289 has been marked as a duplicate of this bug. ***
Comment 7 Heath Harrelson 2002-07-02 05:15:02 UTC
*** Bug 86660 has been marked as a duplicate of this bug. ***
Comment 8 Heath Harrelson 2002-07-02 05:25:52 UTC
*** Bug 85421 has been marked as a duplicate of this bug. ***
Comment 9 Heath Harrelson 2002-07-06 04:06:25 UTC
*** Bug 87352 has been marked as a duplicate of this bug. ***
Comment 10 Mark McLoughlin 2002-07-09 05:48:39 UTC
Okay, both myself and Arvind have spent some time trying to fix this.
The problem is thus:

1) Applets can be loaded in a different order from which they are saved
2) the PanelWidget corner, sliding and floatin panels starts off
small, i.e. not big enough to hold the applets it is going to contain.
3) When you add an applet at a certain co-ordinate, room is not made
for the applet to be placed at that co-ordinate, just appended to the end.

We need to either add support to create the PanelWidget at a certain
size before loading applets or expand the PanelWidget when each applet
is added to be big enough to place the applet at the correct co-ordinate.

I tried the former and it didn't turn out very well. The later seems
more sensible, but its not easy to do.
Comment 11 Heath Harrelson 2002-07-09 09:05:10 UTC
*** Bug 87721 has been marked as a duplicate of this bug. ***
Comment 12 Heath Harrelson 2002-07-09 09:05:51 UTC
*** Bug 87685 has been marked as a duplicate of this bug. ***
Comment 13 Jeremy Nickurak 2002-07-13 18:31:29 UTC
Personally, both those solutions would seem to me to violate the
principals of a dynamicly sizable panel. For such panels, it really
doesn't seem to make sense to store a pixel position at all. Rather,
an order would be more appropriate, wouldn't it? What happens if an
applet's width changes between executions of the panel? (ie, with a
new version, or a different set of input data...)

I'll also throw in that in addition to corner, sliding and floating
panels, drawers need to be taken into consideration in the same category.
Comment 14 Jeremy Nickurak 2002-07-23 20:10:49 UTC
*** Bug 76925 has been marked as a duplicate of this bug. ***
Comment 15 Havoc Pennington 2002-07-24 05:19:09 UTC
Marking this higher in severity. The reason is for one thing all the
duplicates, but also because this bug makes it impossible to set up a
reasonable default panel configuration with applets on it - they end
up in random order, despite the positions set in the schemas file.

GNOME's standard default isn't too affected because there aren't many
applets and some of them are fixed in place by nature.

But if you have a configuration with more applets it's just a disaster.

I suspect the problem is that you need to "freeze" things, load all
the applets, then place them on the panel in order; or alternatively,
load applets one at a time but save their original position and sort
according to it. George had this working in GNOME 1.x, I'm sure he can
explain how it used to work.
Comment 16 anneetbertrand 2002-07-26 13:21:19 UTC
Still present in gnome-panel-2.0.2-4mdk : in my corner panel in the
middle bottom of my desktop all buttons and applets keep their
location, but not the modemlights_applet and the logout button which
always alternate their positions.The modemlights_applet is the last
applet to appear, at the topr right of the panel, which is the place I
choose for the logout button..
Comment 17 Mark McLoughlin 2002-07-29 05:30:54 UTC
*** Bug 88737 has been marked as a duplicate of this bug. ***
Comment 18 Mark McLoughlin 2002-08-06 02:09:49 UTC
2002-08-06  Mark McLoughlin  <mark@skynet.ie>

        Fixes #84744, applets not loading in the correct order,
        by loading all types of applets in the idle handler, in
        the same order as they should appear on the panels.

        * applet.c:
        (panel_applet_load_idle_handler): handle loading all types
        of applets.
        (panel_applet_load_from_unique_id): queue all applets for
        the idle handler.
        (panel_applet_compare): impl.
        (panel_applet_load_applets_from_gconf): sort the queued
        applets and run the idle handler over them.

Comment 19 Jan Mynarik 2002-08-08 15:56:04 UTC
Works for me and my problem. Using panel 2.0.5.
As the reported of this bug I've set it VERIFIED.
Comment 20 Jeremy Nickurak 2002-08-18 20:17:54 UTC
Correction: this fix does not appear to be complete, or perhaps has
some unwanted side effects.

In one particular drawer panel of mine, I can repeatedly restart
gnome-panel, and find my launchers to be in a different order every time.

gnome-panel 2.0.6
Comment 21 Luis Villa 2002-08-19 20:56:58 UTC
Jeremy: any more details? Reproduction instructions? This now works
fine on all my panels and it was definitely broken before.
Comment 22 Jeremy Nickurak 2002-08-23 21:05:26 UTC
In my case, all I have to do is add a drawer to a panel, and place a
series of launchers in that drawer.

Trigger: open a drawer; 'killall gnome-panel'
Expected: gnome-panel restarts (as defined in
gnome-session-properties),  with all launchers in the same order.
Actual result: launchers are in a different order every time.

Note that I have not been able to duplicate this behavior in corner,
menu, or floating panels, only in drawer panels.
Comment 23 Havoc Pennington 2002-08-23 21:09:17 UTC
See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72288
Comment 24 Mark McLoughlin 2002-09-09 05:42:49 UTC
Okay, because I'm only hearing drawers being mentioned I'm assuming
this is a dup of #90598 and was fixed by

2002-08-14  Mark McLoughlin  <mark@skynet.ie>

        * applet.c: (panel_applet_save_position): don't
        save the position backwards if it isn't a packed
        panel. The saved position only has the effect of
        ordering the applets on packed panels, not actually
        specifying the position. Fixes #90598.


Re-open if not

*** This bug has been marked as a duplicate of 90598 ***
Comment 25 Jeremy Nickurak 2002-09-12 04:55:04 UTC
Re-opening, although I'm still not 100% positive.

1) I'm running gnome-panel 2.0.9. How would I confirm if a
"2002-08-14" bug fix would be in this particular version?
2) I'm seeing a shuffling effect, not a reversal: It appears that the
left most launcher in my right-gravitating drawer gets moved to an
apparantly random position on the drawer.

I am however unable to duplicate with a floating panel.
Comment 26 Mark McLoughlin 2002-09-16 01:20:03 UTC
Jeremy: the fix is in 2.0.9 ..

So I can reproduce this could you attach before and after screenshots
and the output of 'gconftool-2 -R /apps/panel' to this bug ? Thanks.
Comment 27 Jeremy Nickurak 2002-09-16 07:15:04 UTC
http://rifetech.com/~atrus/panel/

Three stages, seperated by gnome-panel restarts.
Comment 28 Mark McLoughlin 2002-09-19 23:54:26 UTC
How marvellous - the last launcher on a drawer full of launchers seems
to swap around :/

Easy to reproduce.

1) Create a drawer with two launchers. Note the order of launchers
2) Restart the panel, the order will be swapped
3) Restart again, and they will be swapped again.
Comment 29 Mark McLoughlin 2002-09-24 21:28:47 UTC
*** Bug 90598 has been marked as a duplicate of this bug. ***
Comment 30 Frederic Crozat 2002-10-03 13:36:05 UTC
Created attachment 11380 [details] [review]
Don't touch applet position on drawers
Comment 31 Frederic Crozat 2002-10-03 13:38:08 UTC
The attached patch fully fixes the problem as in bug #90598

I'm not seing any regression in applet position load anymore..

Mark, can you review this patch ? 

Thanks.
Comment 32 Mark McLoughlin 2002-10-03 22:56:42 UTC
Ah very good. Nice one Frederic. Please commit to gnome-2-0 and HEAD
with a ChangeLog.
Comment 33 Frederic Crozat 2002-10-04 15:55:27 UTC
Committed on both branches
Comment 34 Vincent Untz 2002-11-18 16:21:24 UTC
*** Bug 98740 has been marked as a duplicate of this bug. ***