On Mon, Jan 09, 2023 at 06:27:31AM +0100 I heard the voice of
Per Backman, and lo! it spake thus:
>
> Now I compiled the 20221228 beta without EWMH support, and the
> problem seems to be gone, [...]
OK, I've done a little playing around, and I can reproduce some odd
shuffling around with stalonetray in an otherwise empty xnest. The
symtoms I get are that I start it, a small gray window pops up in the
upper left. When I restart, it moves to about its height down on the
left margin. Restart again, it flops to its width in on the top
margin. And repeated restarts just flip it back and forth between
those positions.
The oddness appears to have come in with r644 with the RLayout
changes. So that's why it's not showing up in 4.0.3.
OK, a bunch more investigation, and here's the source. In
add_window.c:1465, we adjust the positioning of any window so it's
inside the BorderedLayout (as opposed to the pre-RLayout code, which
just make sure it was inside the full screen size; you could argue
about which behavior is a bug, really...). So when stalonetray is
started, it's 24x24+0+0, and that's just fine. But on the restart,
the strut exists, so we move the stalonetray window down to +0+24 so
it's "on-screen". Next restart, the left side is reserved
(stalonestray switched itself from going sideways to going down when
it was no longer "at the top"), so it gets shoved over to +24+0 (and
considers itself going sideways). And back and forth.
So... hm. I guess windows should be constrained by OTHER windows'
struts, but not their own? That sounds insanely tricky to manage;
certainly can't be handled by simply overriding BorderedLayout. Maybe
it's wrong to be abusing BorderedLayout for struts anyway, since it's
presumably more for user-level constraining. And let's not even think
about the weird ordering considerations of when windows or messages
show up...
stalonetray doesn't pay attention to _NET_SUPPORTED, so just taking
the STRUTS out of our claimed support doesn't help that case; we'd
have to explicitly ignore the message.
I think maybe we just don't really handle struts usefully, and we
SHOULD ignore them? Possibly forever, considering the
underspecification... Olaf?
Extra details from investigation that you don't need to follow, but I
already typed out, so:
The oddness appears to have come in with r644 with the RLayout
changes. And it can be hidden away by just commenting out the
Scr->BorderedLayout = RLayoutCopyCropped(.....
line in EwmhRecalculateStrut. With that done, it stays in the upper
left all the time.
Now, what goes on here? Let's comment that out, start up, and fire up
the stalonetray. Then using xprop, we can see
% env DISPLAY=:1 xprop -name stalonetray _NET_WM_STRUT_PARTIAL
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 0, 23, 0, 0
and it stays just the same on restarts. So that's claiming 24 pixels
at the top, from y=0 to 23. OK.
So what if we bring the BorderedLayout recalculation back? Well, it
starts up the same. Then we restart ctwm:
% env DISPLAY=:1 xprop -name stalonetray _NET_WM_STRUT_PARTIAL
_NET_WM_STRUT_PARTIAL(CARDINAL) = 24, 0, 0, 0, 24, 47, 0, 0, 0, 0, 0, 0
Now it's claiming 24 pixels at the left, from x=24 to 47. Restart a
few more times:
% env DISPLAY=:1 xprop -name stalonetray _NET_WM_STRUT_PARTIAL
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 24, 47, 0, 0
24 pixels at the top, from y=24 to 47.
% env DISPLAY=:1 xprop -name stalonetray _NET_WM_STRUT_PARTIAL
_NET_WM_STRUT_PARTIAL(CARDINAL) = 24, 0, 0, 0, 24, 47, 0, 0, 0, 0, 0, 0
% env DISPLAY=:1 xprop -name stalonetray _NET_WM_STRUT_PARTIAL
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 24, 47, 0, 0
and it just keeps flipping back and forth. We don't mess with that,
it's doing it itself. Reading its code and playing with its tracing,
it seems to be doing that solely based on the position of the window,
so... [loop back around to add_window stuff above]
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
