Re: Multiple monitors, VirtualScreens and/or Xrandr

Hi all,

Episode II:

* bottomzoom = hbzoom, horizoom = hzoom, leftzoom = vlzoom, rightzoom = 
vrzoom, topzoom = htzoom, zoom (vertical zoom) → OK

* fullscreenzoom, fullzoom → changed too. In fact, I do not see any 
reason to zoom a window with parts not visible...

* fill "right|left|top|bottom" as well as pack "right|left|top|bottom" → OK

* mouse-3 window placement → OK

* identity window (f.identity) → correctly clipped

Remaining things:

* monitor*zoom functions

* inter-monitor edge detection for fill, pack (add 
"monitor{right,left,top,bottom}" params?) & movepack functions

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

Regards,

Max.


Le 31.12.2017 à 20:29, Max a écrit :
> Hi all,
>
> As promised a long time ago :), I made a POC of xrandr use:
> https://github.com/maxatome/ctwm-mirror/tree/xrandr
>
> As a remainder, the goal is to allow ctwm to work correctly in 
> "xinerama" mode with multiple monitors using different sizes.
>
> Implementation details & status:
> - use of a RLayout concept: RLayout is composed of a list of areas 
> (RAreaList), each area (RArea) representing a monitor. A Rlayout 
> includes a 2 caches of vertical & horizontal list of areas, these 
> areas allow to know the vertical & horizontal limits of the screen;
> - constrained move of window is fully handled (EWMH interaction not 
> tested), when using DontMoveOff with or without 
> MoveOffResistance/Border{Left,Right,Top,Bottom};
> - menus are correctly constrained too.
>
> I would be happy if someone can test on its side.
>
> Things that will be added in order of importance (from my point of view):
> 1. the following functions should take into account the new layout 
> mechanism:
> + bottomzoom = hbzoom
> + horizoom = hzoom
> + leftzoom = vlzoom
> + rightzoom = vrzoom
> + topzoom = htzoom
> + zoom (vertical zoom)
>
> 2. new "zoom" functions to operate on the current monitor only, 
> instead of the WHOLE screen (perhaps should they be named differently? 
> I just prefixed their names with "monitor"). Read them as "monitorxxx" 
> function works as "xxx" function, but operates on the current monitor 
> ("current monitor" = monitor which holds the largest area of a window):
> + monitorfullscreenzoom
> + monitorfullzoom
> + monitorhorizoom = monitorhzoom
> + monitorleftzoom = monitorvlzoom
> + monitorrightzoom = monitorvrzoom
> + monitortopzoom = monitorhtzoom
> + monitorzoom
>
> 3. fill "right|left|top|bottom" should take into account the new 
> layout mechanism + the limit between 2 monitors;
>
> 4. movepack should take into account the limit between 2 monitors (new 
> layout already OK).
>
> Then I propose to get rid of the variable "VirtualScreens" and all 
> related code. It will OVER-simplify the code without loosing any 
> feature, as I think it does work as is...
>
> Best regards,
>
> Max.
>
> On 24.06.2017 17:11, Rhialto wrote:
>> On Tue 13 Jun 2017 at 04:25:23 -0500, Matthew D. Fuller wrote:
>>> My gut says that _doing_ the right thing probably isn't that hard; the
>>> tricky thing will be doing it in all the right places.  I don't know
>>> much about the whole vscreen/xinerama/etc implementation, but from
>>> what I've seen I think it's probably pretty hard on the "quick&dirty"
>>> side of things.
>>>
>>> A lot of things probably only appear to work by accident due to the
>>> rather simple model when the rule is "everything's a giant rectangle".
>>> Change that model, and I'll bet we'll find all _sorts_ of bizarre
>>> schrodinbugs coming out of the woodwork...   should be great fun   :)
>>
>> Well we'll just HAVE to try it out! :-)
>>
>> -Olaf.
>>