Describe the bug
Icon growth gravity doesn't seem to be honored when the tray is repositioned after a monitor change.
To Reproduce
I'm running stalonetray with --grow-gravity NE and --geometry +1590+0 (my screen is 1920px wide and I want the tray to be positioned before volume, battery level, clock, etc. and grow leftward.
When I add a new monitor, the tray is repositioned with icons going to the right.
Here's how it looks prior to adding a monitor:
And what it looks like afterwards:
The rightmost icon on the first image aligns perfectly with the leftmost icon on the second image.
I'm still running stalonetray with options on the command line so it might be related to options reloading, although sending SIGHUP doesn't trigger the problem. If I'm not mistaken, the logic for monitor repositioning is in xinerama.c (I'm using xrandr btw) and it looks like it is not using the growth gravity in xinerama_handle_event or xinerama_update_geometry, but only the position and the width/height, which would explain the new position.
I'm able to mitigate this issue by passing --monitor -1 to disable monitor repositioning, but I suspect I'm only able to do so because I'm adding monitors exclusively to the right, thus not messing with the absolute coordinates of the tray position.
Describe the bug
Icon growth gravity doesn't seem to be honored when the tray is repositioned after a monitor change.
To Reproduce
I'm running stalonetray with
--grow-gravity NEand--geometry +1590+0(my screen is 1920px wide and I want the tray to be positioned before volume, battery level, clock, etc. and grow leftward.When I add a new monitor, the tray is repositioned with icons going to the right.
Here's how it looks prior to adding a monitor:
And what it looks like afterwards:
The rightmost icon on the first image aligns perfectly with the leftmost icon on the second image.
I'm still running stalonetray with options on the command line so it might be related to options reloading, although sending SIGHUP doesn't trigger the problem. If I'm not mistaken, the logic for monitor repositioning is in
xinerama.c(I'm using xrandr btw) and it looks like it is not using the growth gravity inxinerama_handle_eventorxinerama_update_geometry, but only the position and the width/height, which would explain the new position.I'm able to mitigate this issue by passing
--monitor -1to disable monitor repositioning, but I suspect I'm only able to do so because I'm adding monitors exclusively to the right, thus not messing with the absolute coordinates of the tray position.