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.
