On Wed 11 Jan 2023 at 19:22:56 -0600, Matthew D. Fuller wrote: > 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...
> I think maybe we just don't really handle struts usefully, and we > SHOULD ignore them? Possibly forever, considering the > underspecification... Olaf? It seemed so simple at the time :) I just had an idea for a potential strategy. Struts are, as I understand it, meant to keep other windows away from something like a toolbar or menu bar which is stuck to the side of the screen. In other words, the window setting the struts is located inside the area it indicates. So maybe, when calculating the effective size of the combined struts, we can ignore the struts of windows that aren't actually located (or fully located, or don't overlap, or somesuch) in their strut area. Could that be an effective strategy? Maybe not, maybe this affects strutting windows only after they are put in the wrong place. Another idea: windows that set struts get to ignore all struts (including their own). The idea is that generally, only one window per side of the screen would set struts anyway. A window that sets struts conveniently has the EWMH_HAS_STRUT flag. Then at the mentioned location in add_window.c, ctwm could use Scr->Layout instead of Scr->BorderedLayout for these windows. > Matthew Fuller (MF4839) | fulle...@over-yonder.net -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFH falu.nl@rhialto
signature.asc
Description: PGP signature
