Re: Multiple monitors, VirtualScreens and/or Xrandr

Hi all,

Episode IV:

* Functions f.*zoom operate on current monitor;

* New functions operating across all monitors (like old f.*zoom function 
did):

f.xbottomzoom + alias f.xhbzoom
f.xfullscreenzoom
f.xfullzoom
f.xhorizoom + alias f.xhzoom
f.xleftzoom + alias f.xvlzoom
f.xrightzoom + alias f.xvrzoom
f.xtopzoom + alias f.xhtzoom
f.xzoom

Remaining things:

* little progress: finish the inventory of Scr->root* uses (43% -> 63% 
done) to know if they need to be switched to layout mechanism or not.

https://github.com/maxatome/ctwm-mirror/tree/xrandr

++

Max.


On 22.01.2018 22:45, Max wrote:
> Hi all,
>
> Episode III:
>
> * Correction of very old bug when using BorderSize>0 and no 3D 
> borders: 
> https://github.com/maxatome/ctwm-mirror/commit/ec40a4b9f07b21f90562b7731efceb3a6fecdf6d
>   As I note in commit message, I think the bw parameter of 
> MoveOutline() should always be 0 (at least for BorderSize>0 and no 3D 
> borders);
>
> * XRandr support can be disabled at compile time use USE_XRANDR15=OFF 
> (default to ON);
>
> * fill "right|left|top|bottom", pack "right|left|top|bottom" and jump* 
> functions now detect inter-monitors edges;
>
> Remaining things:
>
> * rename current *zoom functions (which operate across several 
> monitors) to <prefix>*zoom, <prefix> to be defined, some ideas? :)
>
> * modify *zoom functions to operate on current monitor only;
>
> * untouched: finish the inventory of Scr->root* uses (43% done) to 
> know if they need to be switched to layout mechanism or not.
>
> https://github.com/maxatome/ctwm-mirror/tree/xrandr
>
> ++
>
> Max.
>
> On 04.01.2018 12:49, Max wrote:
>> 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.
>