Le 01.04.2018 à 01:11, Stefan Monnier a écrit :
Check the code, removing VirtualScreens handling would over-simplify
the code.
I hope it would only simplify it, rather than over-simplify it ;-)
Did'nt know the oversimplify verb :) good catch! Anyway, you understood me.
The way VirtualScreens currently tries to work is almost the same as having
2 (or more) X11 screens (:0, :1, ...) In a Xinerama (XRandR now)
environment, it is a bit weird, no?
It kind of gives the best of both worlds: with :0, :1, :2 (or
even with :0.0, :0.1, :0.2), you can't move an existing application
from one screen to the other.
Not being able to move between screens is why I said "almost".
Perhaps what we want to do is a compound of:
- ability for a window to be in several workspaces (as it is already
possible), but at different positions (add a functions family to
zoom/move on current workspace only + reset position);
- possibility to tag windows (a window could have one or several tags)
and have commands to operates on these tags (move, iconify, workspace
occupation)
?
This way you could compose each workspace as you want, without being
constrained by screens sizes and this VirtualScreens layer. What do you
think about that?
++
Max.
