Hopefully, you are not talking about workspaces, which almost everyone I know 
> On 07/17/2021 9:44 AM Rhialto <rhia...@falu.nl> wrote:
> 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

Reply via email to