On Sun, Jan 29, 2017 at 03:46:41PM +0100 I heard the voice of
Rhialto, and lo! it spake thus:
>
> It is probably the parsing of the config file, or applying it to the
> windows.
It seems to neither, or perhaps distantly related to the latter. The
config gets parsed right, and AddWindow() calls OtpAdd() which goes
down the chain and properly sets the OnTopPriority for the window just
fine.
The problem seems to come about because the process of a window
showing up is that we get a map request for it, so HandleMapRequest()
calls AddWindow(), which does all the above and sets everything right.
And then it overrides that priority with whatever EwmhGetPriority()
wants to give the window, which is pretty much always 0. So it's
actually fallout from the EWMH additions.
The quick hack is to yank EWMH's hands off the setting wholesale.
i.e.:
=== modified file 'event_handlers.c'
--- event_handlers.c 2017-02-19 13:39:34 +0000
+++ event_handlers.c 2017-02-19 14:33:52 +0000
@@ -1735,7 +1735,7 @@
/* add the new window to the EWMH client list */
EwmhAddClientWindow(Tmp_win);
EwmhSet_NET_CLIENT_LIST_STACKING();
- OtpSetPriority(Tmp_win, WinWin, EwmhGetPriority(Tmp_win),
Above);
+ //OtpSetPriority(Tmp_win, WinWin, EwmhGetPriority(Tmp_win),
Above);
EwmhSet_NET_WM_STATE(Tmp_win, EWMH_STATE_ALL);
#endif /* EWMH */
}
I'm not sure what the right answer is. It might be adding a flag to
completely skip doing EWMH-dependent stuff on windows that have an
explicit OTP already given. Or perhaps instead of _setting_ the
priority from EwmhGetPriority() bits, we should rather be using that
as an offset via an OtpChangePriority() call. Possibly with a little
rework/thinking of the EWMH priority bits to fit that role...
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
