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 544700 - [PATCH] Treat expandable applets as fully expanded when finding free spot
[PATCH] Treat expandable applets as fully expanded when finding free spot
Status: RESOLVED OBSOLETE
Product: gnome-panel
Classification: Other
Component: panel
2.22.x
Other Linux
: Normal minor
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-07-25 14:43 UTC by Michael Terry
Modified: 2020-11-06 20:20 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Attachments
Proposed patch (2.34 KB, patch)
2008-07-25 14:44 UTC, Michael Terry
none Details | Review

Description Michael Terry 2008-07-25 14:43:50 UTC
The algorithm for finding a free spot when you right click on a menu item and say "Add this launcher to panel" starts at the left and works its way right until it finds a free pixel that isn't absolutely claimed by an applet already.

This breaks down when you have an expandable applet near the left.  If you organize your panel with the Window List on the very left, and you "Add this launcher to panel" for any launcher, it squished the Window List down to just the drag handle.

I'm attaching a patch that treats the Window List (or any expandable applet) as expanded as much as it can be so that new applets will go to it's right.  It leaves one pixel free so that the expandable applet does allow its space to be taken.

Expandable applets are not treated as expanded for the purposes of a 'free move' like when you are moving applets with your mouse.  In that case, you still want the user to see the effect on the expandable applets.

This patch should only affect the 'auto placement' algorithm.  This patch is against gnome-panel 2.22.1, but it's small, and I assume it applies cleanly against SVN.
Comment 1 Michael Terry 2008-07-25 14:44:12 UTC
Created attachment 115252 [details] [review]
Proposed patch
Comment 2 Michael Terry 2008-07-25 14:48:46 UTC
Oh, and the patch is copyright Canonical, Ltd.
Comment 3 Vincent Untz 2008-08-04 03:24:53 UTC
Thanks for the patch. I didn't have time to test it, but how does it work if (assuming the standard layout) I click in the middle of the bottom panel to add an applet. Does it add the applet in the middle or at the right of the panel?

I'd think that fully expanded would be wrong too -- we want to leave some space, not all space. But maybe your patch already does that?
Comment 4 Michael Terry 2008-08-04 18:32:12 UTC
With this patch, if you click in the middle of the bottom panel, it will still use that location.  This patch only modifies the "find a free pixel and I don't care where it is" algorithm.

It's not _quite_ fully expanded.  It's fully expanded minus one pixel (which gives the panel applet the hook -- it consumes what space it needs after it is created).
Comment 5 Michael Terry 2009-07-23 15:15:18 UTC
Just a friendly poke about this patch.  I confirmed the bug in 2.27, and the patch still applies cleanly to master.

It's easy to test:
 1) Have your normal 'Applications/Places/System' on top left
 2) Add a 'Window List' applet (or any expandable applet) to the top and slide it so it abuts the main menu.  Make sure it's snug and there are no pixels in between.
 3) Go to any application in the main menu (e.g. Accessories/Calculator), right click it, and say 'Add this launcher to Panel'.
 4) Note how your window list got squished.
Comment 6 Martin Pitt 2010-07-16 11:04:29 UTC
I can easily reproduce this using the steps in comment 5. The patch still applies cleanly to 2.30.2.
Comment 7 André Klapper 2020-11-06 20:20:53 UTC
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.