So, relative to the backported stuff out in 4.0.3, we've got a small pile of minor bugfixes and improvements. We've got the slightly more visible _NET_FRAME_EXTENTS fix, that's visible in Firefox usage. And, most importantly, we've got the RandR changes giving sensible support for multiple monitors. It's been over 2.5 years since those landed in trunk, and I at least havve been exercising it pretty consistently for a while, without any big surprises in behavior. So, it's probably about time to let it work its way into a release.
The one outstanding thing I'd like to do something with before that is VirtualScreens. This was added by Claude post 3.6, right before Richard seized power, and made an attempt toward allowing manual config of multiple monitors. It certainly has a number of very odd quirks. The times I've experimented with using it for real I pretty quickly gave up under the weight of all the weirdness, and even using it for testing mostly winds up a bit eye-crossing. With the RandR code, with any remotely modern X server we now get actual monitor info from it, and the current code does a fair job of letting us do things like monitor-relative positioning etc. And on sufficiently old or weak X servers without new enough RandR, or environments where you want to lie about it (e.g., a single ultra-wide monitor you'd rather treat as two normal-wides), MonitorLayout allows manual specification. VirtualScreens does in theory give you the ability to show different workspaces on different VS's, which is a place the other code doesn't even try to go. But even that comes with a lot of limitations due to X (a window can only be displayed once, so showing the same WS on both sides, or windows occupying multiple WS's, won't work so hot). From the code side, the infrastructure supporting VirtualScreens adds a lot of weird complexity and indirection to a lot of window handling, Root stuff, etc. I regular wind up falling down a rabbit hole of VS stuff when looking at occupation or workspace switching or whatnot. >From the dev side, life would be easier if it could all go away. From the user side, it sure seems like it has too many weakness and quirks to be attractive even if it were the only way to attempt dealing with multiple monitors, and it won't be anymore. So, I propose that we deorbit it. I suggest a plan like: - In the upcoming release (4.1.0 presumptively), we deprecate it and complain when we see it in configs, but everything continues working the same. - In the next non-point release (4.2 or 5.0, or maybe 123.0 if we feel creative), remove handling of the config param, so we just always wind up with the code state we currently have for everyone who doesn't have it in their config (which should be everyone ;) - 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. So, who wants to speak up in favor of VirtualScreens? Or against working up a release? -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
