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.
