With 4.0.2 out, the top thing on my todo list is getting Max's XRANDR
support together and integrated. I've been working on that in my
sadly sparse spare moments since, and I think it's in good shape.
I've got it in a branch I think is pretty much ready to land. So, CFT
time; it's in <lp:~fullermd/ctwm/randr>
(https://code.launchpad.net/~fullermd/ctwm/randr). Big thanks to Max
for writing it, and also for helping me understand my way through it
during the process.
If you were already running Max's code, this should be functionally
very similar. I did some minor (hopefully-)non-functional code
preening and a bunch of commenting. There are 3 intended visible
changes:
1) The cmake option is renamed from USE_XRANDR15 to just USE_XRANDR.
It does still require libXrandr 1.5 currently (thought there are
some comments in the code pointing a way to possibly supporting
lower versions, if we really turn out to need it for a meaningful
number of people. I feel like that's be a high bar; it'd just be
adding already almost obsolete code, that a fairly short passage of
time would thoroughly kill).
2) The startup code now checks a little more carefully as to what the
server supports, and falls back to old-style screen info lookup.
Just because you have the RANDR libs doesn't necessarily mean your
server supports it, after all. e.g., Xnest doesn't, and how can
you test without Xnest? So we'll now work as well as we did
pre-RANDR, even if you have RANDR missing or turned off in your
server.
3) I pulled the f.* aliases for the new x*zoom functions. Generally,
I think function aliases are a net loss, adding more confusion than
they fix. e.g., I know I've seen snippets of people's rc files
containing stuff like
"Reload twmrc" f.twmrc
"Restart ctwm" f.restart
even though they're the exact same thing. We still do have the
support for the historical ones, since it's a moderate bit of
compat trouble to remove them on people, and having already written
the support, the cost of keeping it is low. But I'd prefer not to
add any new ones, absent a really good reason.
If people feel strongly otherwise, we can revisit this easily
enough.
I've done a reasonable bit of testing, including a little with 2
monitors, and I'm typing this on a system running it, so it's at least
a good imitation of stable. Give it a whirl!
Here's one fun side effect (not really a bug, at least not in
randr) that I found. f.fullscreenzoom is our function to
basically make the client window take up the whole screen, with no
decorations. It does this by blowing up the window size to (full
screen + size of our borders/titlebar), and positioning the window
just slightly offscreen so the titlebar/etc isn't visible. Well,
now that it will fill up one of our monitors, we can now see the
border peeking out the side into the next monitor! And presumably
(haven't tried) if we stack 'em vertically, the titlebar could
poke into the bottom of the next window up. I guess it's time to
implement that function a little less hackily...
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
