On Thu 16 Mar 2017 at 14:21:53 -0500, Matthew D. Fuller wrote: > 3) We could use them as a "change priority" sort of statement, so when > we see _ABOVE we shift it up from where it otherwise was, etc. > This leads to things that contradict the spec; e.g., a window was > at -3, we define _ABOVE -> "+= 2"; now the window is _ABOVE, but is > _not_ stacked above "normal" windows since it's still at an > effective -1.
So, to rephrase as what I understand you mean: we add the user's preference (from config file and later +/- changes) plus the EWMH level (basically treating both as an offset off default), and use the sum as the final layer. I think I'm most in favour of this one. It feels the most symmetric. > There's the further complication that we do (and should) also set > _ABOVE/_BELOW in the property on the window to signal to the > app[4] where it is. We currently do that via essentially "(pri > ... > So we have to come up with extra magic to be able to tell the > difference between "has _ABOVE set because at some point the app > asked to be _ABOVE" and "has _ABOVE set because config/user action > set OTP to something positive and so we set it to inform the app" > (and similarly for _BELOW). Ugh. Gremlins. [5] I suppose we could solve that by setting yet another property on the window: a ctwm-specific one that reflects the layer where the window eventually winds up. When later restoring after a restart, we just need to look there. (Like there aren't enough properties already...) We have similar problems, potentially, with other window details too. For instance "borderless" or "titlebar-less" can be set from various sources (EWMH, mwm hints, config file), and we need to reach some resolution there too. (We do, of course, in some way, but maybe it needs to be looked over to be more consistent with the rest of ctwm.) Fortunately, most of those attributes don't usually change over the lifetime of a window (except definitely fullscreen, I just realise). But because these are binary, we have fewer final values to choose from :-). And we can just reflect the end-result in the EWMH property on the window. I think there is documentation saying that a window manager is in no way obliged to obey the program's request. Actually, that would be the solution of the _ABOVE/_BELOW problem too. We set the property how we think it makes sense, and the application has no standing to complain if that doesn't seem to be what it wanted. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl -- are condemned to reinvent it. Poorly.
signature.asc
Description: PGP signature
