On Thu 15 Jul 2021 at 22:05:48 -0500, Matthew D. Fuller wrote: > - Then over time we can start unwinding ->vs and the various > Scr->*root things as we have to deal with them, since they could > only ever be in one known state.
I would propose to do this more thoroughly, when we get to that point. Remove variables and struct members related to virtual screens, and fix up all code that breaks because of it. That should get the majority of the work done. I suspect that after that, there will be some less obvious cases of "strange code" or "weird design" that are still there. Those we can improve as they get identified. > So, who wants to speak up in favor of VirtualScreens? Or against > working up a release? Down with virtualscreens! Long live a release! :) What could get a similar treatment are WindowBox and "-w [win-id]". Both play nasty games with coordinates and *Root windows. In theory, a WindowBox is a nice way to group windows. I played with it in the past, but there are too may weirdnesses there. -w [win-id] is sort of nice for debugging ctwm and/or configurations. Things like f.hypermove speak to the imagination. It is also somewhat reminicent of the thing from MSWindows 3.x where you'd have an application like an IDE which has one big master window, and subwindows inside that for editing or debugging or whatnot. I've forgotten what it's called. It would be great if programs like The GIMP which have a similar feature could use the user's preferred window manager for that. But it'll never happen, I fear: too late. -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
