Works with stumpwm but window is gone when I kill and start stalonetray

[benjamin-asdf]

Hello, thanks for this nice software.
Is there some way to force a re-render or something? When I kill stalonetray and start it again, with stumpwm it doesn't decide to make a new window.
When I restart stumpwm it appears again.

Turns out somebody wrote a systray module for stumpwm that I am using now. I think both are great options for stumpwm users.

[kolbusa]

Hi @benjamin-asdf,

Can you please generate log files with --log-level trace for good and bad cases? Also, it would be interesting to take a look at the xwininfo -tree -all -id <window-id> output for the stalonetray window when it is visible and not. The <window-id> can be found by running xwininfo -tree -root | grep stalonetray.

[jkroonza]

Suspected same problem on evilwm (1.3.1) and stalonetray (0.8.4). Window will go away whenever I switch desktops, and often requires numerous kill+starts to render something sensible. It's a tad frustrating.

X11 error: BadWindow (invalid Window parameter) (request: X_ConfigureWindow, resource 0xc)
X11 error: BadWindow (invalid Window parameter) (request: X_MapWindow, resource 0x8)
X11 error: BadWindow (invalid Window parameter) (request: X_ConfigureWindow, resource 0xc)
X11 error: BadWindow (invalid Window parameter) (request: X_MapWindow, resource 0x8)
X11 error: BadWindow (invalid Window parameter) (request: X_GetProperty, resource 0x14)
X11 error 3 detected at xembed.c:518:xembed_retrive_data
X11 error: BadWindow (invalid Window parameter) (request: X_ChangeWindowAttributes, resource 0x2)
X11 error 3 detected at xutils.c:260:x11_get_window_size
X11 error: BadWindow (invalid Window parameter) (request: X_GetWindowAttributes, resource 0x3)
X11 error 3 detected at debug.c:156:print_icon_data
X11 error: BadWindow (invalid Window parameter) (request: X_ChangeWindowAttributes, resource 0x2)
X11 error: BadWindow (invalid Window parameter) (request: X_UnmapWindow, resource 0xa)
X11 error: BadWindow (invalid Window parameter) (request: X_ReparentWindow, resource 0x7)
X11 error: BadWindow (invalid Window parameter) (request: X_ConfigureWindow, resource 0xc)
X11 error: BadWindow (invalid Window parameter) (request: X_MapWindow, resource 0x8)
X11 error 3 detected at xutils.c:115:x11_get_server_timestamp

This seems to relate more to Xorg/X11 rather than the window manager.

With --log-level trace, output: stalonetray.log
xwininfo prior to ctrl+alt+right then back left: stalonetray_visible.txt
xwininfo after: stalonetray_not_visible.txt

xwininfo only difference is:

--- stalonetray_visible.txt	2022-11-09 09:36:45.496250134 +0200
+++ stalonetray_not_visible.txt	2022-11-09 09:36:51.796252201 +0200
@@ -35,7 +35,7 @@
   Window Gravity State: SouthWestGravity
   Backing Store State: WhenMapped
   Save Under State: no
-  Map State: IsViewable
+  Map State: IsUnviewable
   Override Redirect State: no
   Corners:  +1+1063  -1871+1063  -1871-1  +1-1
   -geometry 3x1+1-1

Currently my desktop details as per xrandr:

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384

Usually I've got two additional physicals to the right of that thus 5760 x 1080 in total. I want to retain stalonetray bottom-left at all times.

Current stalonetray config: stalonetrayrc.txt

Unsetting no_shrink true and kludges makes no difference. kludges force_icons_size does help with hexchat not sporadically having a massively oversized icon.

[kolbusa]

Hi Jaco. Thanks for the detailed logs! I'm completely out of bandwidth, so debugging this will take time...

Is there a log which also has the X11 errors so that I could correlate? This looks like one of the icons disappeared or WM sent a configure notify and stalonetray geometry handing code got confused. This code needs rewrite. I am not sure why the stalonetray window gets unmapped, though. I'll try installing evilwm and checking if I can reproduce this. Does this issue happen with just a single screen?

Does setting window_type to dock or desktop help?

[jkroonza]

Hi Kolbusa,

I know the feeling of bandwidth ... I completely understand. Don't have too many cycles myself at the moment, but if you can point me at where and why you think it's going wrong I could potentially spend a few cycles on this.

Unfortunately not. Yes, it happens with just a single screen. It felt slightly different with multiple screens but similar behaviour.

The GROW also seems to be backwards, after re-reading the manpage I understood I want east, as in new icons to be added to the right ... but it turns out if I set it to east then new icons gets added towards the left, or at least, the left edge of the containing "window" moves off-screen. This seems counter, setting it back to SW solved that and they now stack nicely towards the left again.

I've tried window_type dock, this would prevent the containing window from being available on all desktops, but at least it didn't completely disappear. Setting it to desktop seems to work as intended (stays available and bottom left of the screen). However, it's an early assumption as I've seen that sometimes just restarting stalonetray enough times fixes the problem described above. I did restart a handful of times now and it worked correctly on every try ... so who knows, maybe it's sufficient. Haven't tried this on multi-screen yet.

Thank you for your response.

[kolbusa]

Thanks!

To save me some time with configuration: do you do anything special wrt WM configuration to make stalonetray appear on all desktops?

The icon placement knobs are a mess, unfortunately. I myself have to reread the docs all the time to understand them. If you have any ideas how to change them -- suggestions are welcome.

To debug this I would start tracking map notifications and geometry changes. I think WM thinks that stalonetray misbehaves and unmaps it, but I'm not sure. WMs have bugs too, so it is sometimes hard to tell.

BTW, when the window 'goes away', does it go away on all the desktops?

[jkroonza]

To save me some time with configuration: do you do anything special wrt WM configuration to make stalonetray appear on all desktops?

evilwm is named such for a reason. There is really not much to configure. It's primary purpose is to not annoy me with bells and whistles. The only configuration is stuff passed from the CLI from .xinitrc, which I use thusly:

exec /usr/bin/evilwm -snap 10 -fg yellow -bg grey -term urxvtc

To further put this into perspective, almost all other stuff (stalonetray, xautolock, telegram, pipewire) are started before the WM itself from .xinitrc. It's barebones. It's simple to understand, and for me it "just works".

The icon placement knobs are a mess, unfortunately. I myself have to reread the docs all the time to understand them. If you have any ideas how to change them -- suggestions are welcome.

I'd have to dig into the code on how the underlying X11 principles work before I would be able to constructively contribute. From principle, I'd say:

1. Fix one corner of the containing window (since I want bottom-left, say SW@+0-0).
2. Grow in two directions, a primary and secondary, giving a "max dimension" in terms of either pixels or number of icons for the primary, and possibly the secondary - but what to do if the grid is overflown?

For example:

traybase = SW@+0-0
traygrow = E20N

Which says: keep the south-west corner fixed at +0-0.
Grow firstly in the Eastern direction, to a max of 20 icons, then grow north.

Now here comes your next trick question, should I have 21 icons, do you split that 20+1 or 11+10?

What about 41? 20+20+1 or 14+14+13?

So trayequalizesecondary = yes/no to choose between the two options may be sensible.

I believe that eliminates quite a few knobs overall. It does, however, not take icon sizes into consideration, but with kludges force_icons_size in my case I don't care. One could sort the icons by size as a first ordering system, and place largest ones first, and let them just consume the spaces for the primary direction in the secondary direction too ... I don't know, will have to think about this a bit more, but personally I just want all icons the same size.

To debug this I would start tracking map notifications and geometry changes. I think WM thinks that stalonetray misbehaves and unmaps it, but I'm not sure. WMs have bugs too, so it is sometimes hard to tell.

I meant: where in the stalonetray code should I go look at how all this works? The closest I've ever gotten to writing GUI code was with Qt3 and a fair amount of HTML. I don't think either one really counts :).

BTW, when the window 'goes away', does it go away on all the desktops?

Prior to setting window_type it would be impossible to say since it would go away immediately upon switching desktop the first time, so whether it goes away on the first switch, or was just never visible on other desktops and went away on the switch back is impossible to say definitively. Especially given that window_type dock only appeared on one desktop.