On Wed, Feb 22, 2017 at 03:30:29AM -0600 I heard the voice of
Matthew D. Fuller, and lo! it spake thus:
>
> Because in looking over the various alterations due to EWMH states
> and zooming and all, it seemed like the easiest way to keep things
> in line.
I can probably explain that a bit better. Glancing back over my last
few mails, things get a little muddled up.
In the current state, we have the OTP stuff itself. Windows come into
being with a default priority set from the config file, falling back
to 0. They get relatively altered with f.changepriority, absolutely
altered with f.setpriority, and sometimes do the switching thing.
That all fits as far as I can see (modulo that digression of f.change
and switching) with the current code and data.
We also have the EWMH stuff. It has ideas about what the priority of
windows should be that takes no notice of whatever was initially set
or later altered by the OTP stuff, and any time it wants to alter
things (this thread coming up in the first place because one of those
times was "as soon as the window is setup"), it completely discards
anything OTP-proper has done and blats its own concept onto it.
There's also the zoom stuff which is tricksier, because it seems to
sometimes implicate just the OTP-proper bits, and sometimes some EWMH
stuff.
So, our problem is to harmonize it all. Some parts of that are easy.
There are bits of EWMH stuff (the _DESKTOP and _DOCK bits) that can be
though of as just additional info for the initial value, so can easily
slot in between "special stuff config tells us for this window" and
"fall back to 0". No sweeping changes needed there.
Other parts, though, like the _BELOW/_ABOVE states, and some of the
stuff around zooming, are a lot trickier, since they're things that
change at arbitrary times and for arbitrary reasons post-startup. And
to fit them in, they largely seem like they should be changed to be
more +/- alterations, rather than = override settings as they
currently are.
So in ruminating over implementing all that, ISTM that it's easier to
be sure of getting the right answer by making all those transient,
come-and-go effects happen by keeping them as a list of active
alterations to a long-term base, and then we can just add/remove from
that list and recalc when something changes (or may have changed,
since we generally find out about states rather than changes).
Keeping and adjusting only the final answer in the face of that sort
of fluidity strikes me as more error prone to write, and harder to be
sure of the correct and completeness of when reading.
(It's possible I'm hypersensitive on that last point from my
experience in the codebase the last year ;)
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
