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. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl -- are condemned to reinvent it. Poorly.
signature.asc
Description: PGP signature
