trayer position sometimes has extra offset compared with the geometry

[ST-Saint]

I am using the xmonad and I add stalonetrayer & in my startup hook.

I set geometry 1x1+1896+0 to make it stay at the top right corner. However, I noticed that sometimes the trayer panel would shift left with a slot, especially after a reboot.

If I just kill the stalonetrayer and restart it then it works fine.

I am wondering if it is a bug or expected behavior and how could I fix this?

Thanks.

Here is the wrong xprop.

WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 1776, 1895, 0, 0
_NET_WM_STRUT(CARDINAL) = 0, 0, 24, 0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_DESKTOP(ATOM) = undefined atom # 0xffffffff, undefined atom # 0xffffffff
_NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_TASKBAR
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x1, 0x0, 0x0, 0x0
STALONETRAY_TIMESTAMP(STALONETRAY_TIMESTAMP) = 0x73
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING
_NET_SYSTEM_TRAY_ORIENTATION(_NET_SYSTEM_TRAY_ORIENTATION) = 0x1
WM_COMMAND(STRING) = { "stalonetray" }
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 1752, 0
		user specified size: 120 by 24
		program specified minimum size: 120 by 24
		program specified maximum size: 120 by 24
		program specified resize increment: 24 by 24
		program specified base size: 0 by 0
		window gravity: NorthWest
WM_CLASS(STRING) = "stalonetray", "stalonetray"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		Initial state is Don't Care State.
WM_NAME(STRING) = "stalonetray"

And the expected xprop

WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 1800, 1919, 0, 0
_NET_WM_STRUT(CARDINAL) = 0, 0, 24, 0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_DESKTOP(ATOM) = undefined atom # 0xffffffff, undefined atom # 0xffffffff
_NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_TASKBAR
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x1, 0x0, 0x0, 0x0
STALONETRAY_TIMESTAMP(STALONETRAY_TIMESTAMP) = 0x73
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING
_NET_SYSTEM_TRAY_ORIENTATION(_NET_SYSTEM_TRAY_ORIENTATION) = 0x1
WM_COMMAND(STRING) = { "stalonetray" }
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 1848, 0
		user specified size: 120 by 24
		program specified minimum size: 120 by 24
		program specified maximum size: 120 by 24
		program specified resize increment: 24 by 24
		program specified base size: 0 by 0
		window gravity: NorthWest
WM_CLASS(STRING) = "stalonetray", "stalonetray"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		Initial state is Don't Care State.
WM_NAME(STRING) = "stalonetray"

[kolbusa]

Thanks for the report and apologies for a very long delay.

Not sure if this is still relevant, but in case it is, can you please attach log files (--log-level trace on the command line or log_level trace in the configuration file) for good and bad cases? I also wonder if enabling shrink-back mode (no_shrink false in the configuration file) would work around this bug.

[lucius-martius]

The bug only happens very sporadically and most sessions not at all.
I'm confident that when stalonetray is started with --no-shrink it doesn't happen.
Without --no-shrink, see the attached log for a case where the bug is reproduced:
stalonetray_trace.txt

Furthermore, after reading through the log it is clear that stalonetray wants to run xwininfo, which wasn't installed on my system. I guess it runs xprop as an alternative, which is installed. After installing xwininfo, however I wasn't able to reproduce the bug anymore now for several days/sessions and counting.

For the simplest fix, maybe xwininfo should be a hard dependency and documented in the readme file.

[kolbusa]

Huh. Thanks for the another log. I have xwininfo on my machine, and I still see some buggy behavior. I think the code that handles configure notifies from the X server is buggy. I need to find some time to look into this...

Regarding missing xwininfo: I can probably add some logic to switch between xwininfo and xprop. Which system you are on and which packages have xwininfo and xprop? Is one of them installed by default?

[lucius-martius]

Great to hear that you can reproduce the issue on your system now. Yesterday I also noticed the bug happening with xwininfo installed, so sorry for that misinformation.

I'm on Gentoo (running exwm as a window manager) and packages are x11-apps/xprop and x11-apps/xwininfo respectively.

Neither is installed by default, but a lot more packages (like the x11-misc/dunst transitively via x11-misc/xdg-utils) are pulling in xprop vs. xwininfo being completely optional.