Le 04/01/2018 à 09:20, Matthew D. Fuller a écrit :
On Sun, Dec 31, 2017 at 08:29:45PM +0100 I heard the voice of
Max, and lo! it spake thus:
[snip]
As a remainder, the goal is to allow ctwm to work correctly in
"xinerama" mode with multiple monitors using different sizes.
To clarify (as I assume I'm thinking right); that's the realm of
peaking XRandR to understand the layout of displays and the available
screen area, *not* the case of XRnR making dynamic changes to it
during runtime (that being a whole different keg of black powder).
Yes, you're right. Dynamic layout changes could be handled later. As
ctwm restart is fast, it can be used when the layout (monitor
add/remove) changes.
1. the following functions should take into account the new layout
mechanism:
+ bottomzoom = hbzoom
[...]
2. new "zoom" functions to operate on the current monitor only,
instead of the WHOLE screen
+ monitorfullscreenzoom
[...]
My immediate thought would be to go the other way; have the existing
functions fill out the current display, and have new functions to
expand across displays. e.g., if I've got mplayer on one display
running an important instructional video (and totally not a MST3k
back-episode or something) and I hit 'f' to full-screen it, I'd expect
it to fill out that display, not cover up the important work (and
totally not random flamefesting) I'm doing on the other display.
Possibly my expectations are skewed?
It can be done your way.
I wouldn't change too much the actual behavior that zooms over all
monitors, but I agree with your point of view. I can adapt very easily,
what name/prefix do you suggest to operate on several monitors instead
of current one?
A second thing is that, at a glance, it seems like you're currently
making XRandR a hard dependancy and replacing the old Xinerama bits
with it. We should ask and answer the question about what that does
to our support. A glance at the release history summary suggests you
probably wouldn't be requiring anything newer than RandR 1.3, and
further minor digging suggests that's X.org server 1.6 (early 2009)
and randr libraries of the same era. A little poking at the obvious
suspect for current-OS-with-old-packages suggests that keeps us in the
good graces of RHEL/CentOS 6, but perhaps not 5. We may also lose
whatever (if any) we still have of older proprietary unices or
non-X.org servers.
The only RandR function used is XRRGetMonitors() which needs RandR 1.5,
so 1.3 does not match.
I can make Xrandr_LIB completely optional, with the help of a new
USE_XRANDR15 parameter (as USE_EWMH does for EWMH.)
In case this parameter is not defined, the layout will reflect the
old-big-screen instead of the precise monitors one without any change
elsewhere. It's a very small change located in this function:
https://github.com/maxatome/ctwm-mirror/blob/xrandr/xrandr.c#L14 (+
handling of USE_XRANDR15 of course.)
That doesn't seem facially out of the question. That's a similar
vintage to things like standard-XCB and Xft2 and the like, which are
on my list to consider pushing toward. Just that it's a thing that we
do need to explicitly consider and intentionally decide.
It's up to you :)
Regards,
Max.
