GNOME Bugzilla – Bug 137473
Resetting of rightstick property of few panel applets
Last modified: 2020-11-06 20:26:39 UTC
Im running gnome built from CVS head, pretty simple, like the default applets,etc present nothing i have added. When i switch between resolutions of the screen, my Mixer applet and window list applet lost their rightstick property in Gconf, becoz of which the 2 applets gets relocated. Basically, the keys '/app/panel/profiles/default/applets/mixer/panel_right_stick' '/app/panel/profiles/default/applets/window_menu/panel_right_stick' are be disabled. Ill give the exact details. 0. Note the values of the keys i specified. It will be ON. 1. Have your Xserver run in 1024x768 resolution (Panel is running) 2. Type xrandr -s 640x480. This makes ur resolution 640x480. 3. do a pkill gnome-panel. This restarts your panel. 4. Type xrandr -s 1024x768. This makes ur resolution 1024x768. 5. Now note down the values of the two keys... its actually OFF. Which places them odd on the screen. 6. do a pkill gnome-panel. This restarts your panel. Now the two applets are placed at some odd positions. This is 100% reproducible.
*** Bug 152019 has been marked as a duplicate of this bug. ***
*** Bug 160549 has been marked as a duplicate of this bug. ***
*** Bug 338427 has been marked as a duplicate of this bug. ***
*** Bug 345157 has been marked as a duplicate of this bug. ***
Anything new wrt. this bug? I am seeing it even on the latest-greatest Fedora 10 (gnome-panel-2.24.1-3.fc10). It is quite annoying when for example some game or using an external VGA output for the beamer rearranges most of the applets in the panel. Maybe the gnome-panel should keep a per-resolution list of preferred applet positions? Does any of the developers read this bugzilla? This bug is even after 4+ years marked as "NEW" without any response from developers :-(
The problem is the panel is not able to understand if an object is to be positioned measuring from left or right. A workarround that works very well is the one I posted on launchpad (https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/36189/comments/26). The easiest fix (at least until a more elegant variant is found) would be to add a "stick right" option to the context menu of the panels.
Yes, this bug is extremely annoying. More so now that many of us have bought these cute, little netbooks that beg you to use an external monitor whenever you can. Why is this bug getting so little attention? It makes the GNOME desktop feel clumsy, breaks muscle memory and is generally annoying.
I don't think that a "stick right" option would fit. Applets that are in the center of the panel would then still suffer of this problem. Perhaps "proportional" placement instead of fixed placement is the only viable option. Does someone agree on this?
This bug is getting little attention because there's a few hundredthousand other ones too, plus limited manpower. Patches are always accepted.
I don't think "proportional" placement would provide a significant improvement. I, for example, have the panel almost full in the bigger resolution, so lowering the resolution definitely makes the panel overbooked. I don't mind (after all, with full-screen presentation on the beamer or with the full-screen game it does not matter). But I would like to have the exact arrangement of the applets restored when the display resolution is set back to the original values.
I am trying to figure out if there is a proper way of solving the problem. From your example it seems that the "proportional" placement should be referred to an ideally very huge screen, or otherwise, assuming that the applets don't have a size. When switching to a too low resolution, it would be a task of the renderer to find the best possible approximation on screen, but the data about the proportional position of the applets would not be changed by that. However, if you go to a lower resolution, you may move by hand some applets to gain space. That would destroy everything. However you may legitimately move an applet when on low resolution, and expect it to stay there when going back to the bigger one. So the system can't guess what you want to do. Keeping memory of different resolutions may seem better but will be a mess if you use virtual machines, because the "screen" is actually a window that may have tons of different sizes. I think that keeping a proportional placement which does not get changed when the render has to rearrange positions due to a too low resolution would be a good compromise between perfection (which includes here guessing what the user really wants to do) and nothing at all. How do other desktop environments (e.g. KDE) solve this problem? Do they solve it at all?
Is there documentation about the 'packed' gboolean on a panel widget? Based on the source code this is used when the panel doesn't have space for a widget? There seems to be inconsistencies with 'packed' panel widgets - inconsistencies that seem to affect the 'right_stick' property. Can someone familiar with this property comment?
The basic problem we are trying to solve is that "panel_right_stick" is unable to retain a TRUE value when the screen resolution is reduced. in 'applet.c': panel_applet_save_position() is where the "panel_right_stick" property is actually written. To determine the value of this property there is a function call to panel_is_applet_right_stick() in 'panel.c' panel_is_applet_right_stick() can only return TRUE if the function panel_widget_is_applet_stuck() in 'panel-widget.c' returns TRUE the problem is that panel_widget_is_applet_stuck() will by default return FALSE and is only able to return TRUE under certain circumstances. --------- Let's compare this to the 'locked' property which behaves very well... the 'locked' property is written a few lines later in 'applet.c' panel_applet_save_position()... To determine the value of this property there is a function call to panel_widget_get_applet_locked() in 'panel-widget.c' panel_widget_get_applet_locked() simply returns the value of the 'locked' member of an AppletData type struct (provided g_object_get_data() is successful) --------- Perhaps the "right_stick" property should be a member of the AppletData struct and default to FALSE... If Mark McLoughlin <mark@skynet.ie> is still around he would be the man to address this issue since every mention of these functions in the CHANGLOG are seemingly attributed to him. comments?
It should be noted that the struct type PanelAppletToLoad (defined in 'applet.c') has a 'right_stick' member as well as a 'locked' member. A proper fix for this bug seems as if it could case significant breakage. It seems as if the usage of the "panel_right_stick" property today is beyond the same scope as it was originally defined circa 2003. There is no UI method for setting a "Right Stick" in the same vein as the "Lock To Panel" A widget seemingly can only get the "right_stick" property set if the panel becomes too full (is this what "packed" means) Applets seemingly are unable to receive the "right_stick" value and get assigned a "position" large enough to keep them on the right side. ---- If you go through the steps originally described by Srinivasa Ragavan to reproduce this bug you might notice that "object"s receive the "panel_right_stick" value (even if they were originally on the left) and "applet"s will be assigned a position value that is relatively large. It is possible for "object"s (originally on the left) to become stuck on the right side. It is also the case that "applet"s that did have "panel_right_stick" set TRUE will lose that value and receive a large "position" value to compensate (which often results in them appearing more towards the middle). ---- To summarize an "object" and an "applet" will behave differently if you reproduce Srinivasa Ragavan's original procedure. comments?
bumping Gnome version to current stable.
This bug should be a duplicate of Bug 341441?!
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.