Re: Multiple monitors, VirtualScreens and/or Xrandr

Hi all,

Take a look at https://github.com/maxatome/layout

I developed a POC (in perl) for all functions needed for the edges 
detection (moves and zooms).

They can easily be translated in C. I will do it once everyone will 
agree on them.

Tell me if it is not clear...

Best regards,

Max.


On 23.05.2017 20:05, Max wrote:
> Hello Olaf,
>
> Thanks, I will have a look at it.
>
> I think that handling dynamic resizing (aka monitor addition/removal) 
> can be done in a second time. Restarting ctwm is very fast.
>
> After all, it seems to me that the most difficult thing to do, is to 
> find the good edge detection algorithm, as we will abandon single 
> rectangle display in favor of multiple rectangles one... :)
>
> Best regards,
>
> Max.
>
> Le 20.05.2017 à 17:17, Rhialto a écrit :
>> On Sat 20 May 2017 at 12:01:52 +0200, Max wrote:
>>> As I want to add a third monitor, with a different resolution this 
>>> time, I
>>> am a bit annoyed... Note that it would be the same if I would 
>>> connect an
>>> external monitor to my laptop.
>> ...
>>> I tried to use VirtualScreens to declare my different size areas (2 
>>> in fact:
>>> the first one for the 2 monitors of the same size, the second for 
>>> the third
>>> monitor), but I did not succeed to use it correctly (even with last
>>> 4.0.0-beta.20170507.) Menus always open in first area when I click 
>>> on second
>>> (on root window or on frame button), moving window from one area to the
>>> second one works (using f.forcemove as DontMoveOff works as 
>>> expected), BUT
>>> both workspace managers (one in each area) display the window, 
>>> instead of
>>> only displaying the window in area owning it.
>>>
>>> So I have 2 questions:
>>> - do someone successfully use the VirtualScreens feature?
>> I *sort of* used it in testing, but never in real life. It used to be
>> somewhat broken, now it is less so. I imagine it may have remaining
>> weirdnesses. And it is only designed for monitors that are all
>> identical. A bit limited... since currenly I also use my laptop with an
>> additional external screen of different resolution. So I feel your
>> pain... (the idea is that each monitor has its own root window and shows
>> a different workspace. When windows are supposedly visible in both
>> workspaces, it cannot do that and it gets shown only in one. But
>> conceptually it is in both so maybe that explains why the
>> workspacemanager shows it like that.)
>>
>>> - do someone plan to integrate Xrandr extension?
>> I vaguely was planning to do that one time when I got around to it.
>> However I seem to have even less time currently than before, so it will
>> be a while... so if you want to look into it, please do.
>>
>> In particular I wanted to tackle the situation when the root window size
>> changes, which I believe sends a ConfigureNotify or something. Currently
>> all code assumes that the root window size can never change.
>>
>>> I understood how to request all monitors using Xrandr extension
>>> programmatically (I am not X Window programmer but quite experienced 
>>> C one.)
>>> But when I watched ctwm sources and found in screen.h the different 
>>> areas
>>> ctwm is able to handle (RealRoot, CaptiveRoot, XineramaRoot), I was 
>>> a bit
>>> confused...
>> Yes, these are confusing. Fortunately several of these are the same in
>> case the particular feature they are for is not in use. In fact I'd say
>> that these days, in typical use, they are all the same. (As a result of
>> this, there was code which used the wrong one for its context, but you'd
>> never notice normally). With Xrandr added, the Xinerama stuff can
>> probably be removed.
>>
>> The CaptiveRoot is for an ingeniously invented debug mode where ctwm
>> opens a normal window and runs in that, allowing subwindows to be
>> managed inside. Unfortunately this mode is difficult to get 100% right
>> and some bugs may remain even after I removed several. It is in this
>> mode I did most of the VirtualScreen testing.
>>
>>> If xrandr integration is not planned, I would like to have a look at 
>>> it to
>>> make DontMoveOff, f.pack and f.full* working. In this case, perhaps 
>>> someone
>>> can give me some pointers and/or pitfalls to avoid?
>> I'd say that in general you need to understand a bit about how X uses
>> messages related to window managers, such as its Inter Client
>> Communication Conventions Manual, in html for instance at
>> https://tronche.com/gui/x/icccm. Maybe it's not immediately necessary
>> for the job at hand but it might help to understand some of the other
>> code.
>>
>>> Max.
>> -Olaf.
>