Regression: panel launcher position are not stored after moving the launcher

[raveit65]

Expected behaviour

Panel launcher position should be stored after moving the launcher and a panel restart.

Actual behaviour

Panel launcher position are not stored after moving the launcher and a panel restart.

Steps to reproduce the behavior

1. add much panel launcher in a row to the panel like eg. this
2. move a launcher from the row to another position
3. Restart the panel with a killall mate-panel in terminal
4. Boom, the launcher isn't anymore at the new position

Sometimes it works better when moving the launcher to right direction, but not in all cases. And it is very hard to select the new position during moving. For me this is really a show stopper for a new major release, because moving a launcher will be done very often and it breaks the desktop appearance.

I could track down the issue to those commits Fix center- and right-sticking of expanding applets Add "center-stick" capability applets on the panel

Sadly simply reverting the commits is impossible, i had to revert some more unrelated commits to get this working :/ Constify some pointer references in locals Reduce scope of more code Avoid a redundant NULL check Reduce scope of variables

For better testing i created a branch with all those commits reverted. https://github.com/mate-desktop/mate-panel/commits/revert-launcher-progress_real/ You will see that moving a launcher works well again. Same like with stable 1.26 branch I know that reverting the unrelated commits isn't a solution and they have to add again. So best solution might be to find a fix for this buggy behavior.

MATE general version

master

Package version

master

Linux Distribution

all

Link to bugreport of your Distribution (requirement)

Thanks god that this isn't released!

[lukefromdc]

With a row of 8-10 launchers between the menu and window list left side of a bottom panel, on Debian Unstable I've never had trouble with launcher positions not being saved.

When I get home tonight will test a 2nd panel many launchers and nothing else on it. If they stay put we need to find out what is different between my case and where the problem appeas

[raveit65]

Here is a small video (862,1 KB) with 5 panel launcher in a row. See what happens. https://www.dropbox.com/scl/fi/k1fdbvadyev9vu2xvfvy4/panel_launcher-2024-01-28_17.44.08.mp4?rlkey=dm70h5ugzwgtp2g6wo63h90jw&dl=0 This is with collection menu enabled, but the issue still exists without collection menu. Edit: A smaller version (416,5 KB) https://www.dropbox.com/scl/fi/no6zhvc3pn4lgso64qjbq/panel_launcher-2024-01-28_17.44.08-small.mp4?rlkey=aft54fa15f978k73vpf4n4zsu&dl=0 I use a classic layout for the top panel. Classic menu, some launchers (default fedora panel layout), the newly added launchers, volume applet (default layout), tray-applet, clock-applet. Panel is compiled in-process.

[lukefromdc]

Just tested with a row of launchers on a top panel for testing. May have seen this issue once, then could not duplicate it (under wayland anyway) even under same conditions as the video. Will now try it in x11

[lukefromdc]

A little easier to invoke it under x11 (though sample size is small here), but was not consistant. Seems that it's when launchers are "spring loaded" against oneanother is when this is most likely to happen. The reason I've never seen this before then would be the fact that all of my normal launchers are part of a hand packed arrangement that avoids the "springy" condition entirely on the left side of the panel.

This part of the code (applet spacing) is not one I have much of an understanding of.

[raveit65]

@thesquash Huston we got a problem.