gtk3_port branch does not handle desktop geometry change (adding/removing/rotating monitors).

[fidergo-stephane-gourichon]

With regular branch, one can change desktop geometry at any time (add/remove/change-orientation-of-relative-position-of monitors using xrandr, xfce4-display-settings or anything similar) and quicktile always correctly handle new desktop geometry and monitor positions immediately.

On branch gtk3_port, quicktile operates as if the desktop geometry and monitor relative positions were never changed since it started. Stopping and restarting quicktile works around the problem.

Observed on Xubuntu 19.10, xfce 4.14.

[ssokolow]

It's a known regression. I had to defer hooking into monitor-change and property-change events in order to get something out by New Years.

(The lack of property-change event hooking is why my own Kubuntu 16.04 LTS desktop requires me to restart QuickTile on every login because it starts before Plasma has reserved space for the panels.)

I plan to come back and fix this once I've finished doing a similar but even more necessary un-breaking on my ITAD Importer userscript. (I intend to have that done some time between January 7th and January 14th.)

[kbsali]

Confirmed on ubuntu-mate 19.10 :)

[ssokolow]

Actually, to be fair to the problem, I held back the resolution changing because I'm not in a position to test it at the moment and I was worried about bugs from listening for monitor resolution changes but not panel reservation changes.

Hooking into the events for changing the set of available monitors would only be about five or six new lines, but if I don't also do the more complex task of listening for changes to _NET_WM_STRUT_PARTIAL reservations, it could result in horrendous breakages if QuickTile re-queries everything before the panels have updated their reservations.

(Think "A 1280px-wide panel reservation on an 800px-wide screen, sticking out into the middle of the screen next to it.")

The old QuickTile re-queried all that information every time you triggered a keybinding and my main reason for changing that is that, to finally fix #10, I want to go in a direction more like a tiling window manager, where everything is based on a tiling grid and windows that have been snapped into it automatically adjust to resolution changes without you having to press a key.

[ssokolow]

A little more clarification:

It's not the knowing how to listen for property change events that's the problem. I've done that before.

The problem is that I need to re-architect the internals so the code for listening to incoming X events is part of the core rather than part of the key-binding module and then plumb X11 events into the Glib event loop so both the keybinder and the WM interaction code can subscribe to them... which isn't difficult either, it's just time-consuming so I want to get ITAD Importer back on its feet first.

[ssokolow]

For now, I've decided to resolve this by going back to the old approach of re-querying the desktop's shape on every command.

It was just one added winman.update_geometry_cache(), so it shouldn't complicate things when it comes time to do it the way it's meant to be done later.

[ssokolow]

Oh, please do try the current HEAD of the gtk3_port branch and let me know if you encounter any problems.

I've had so many problems over the years with window managers scrambling up my windows in response to resolution changes or monitor addition/removal that I've used nVidia's MetaModes option to lock the desktop resolution at 4480x1080 and, likewise, I leave my desktop session open for weeks or months at a time, so I can't easily check whether it's fixed the "QuickTile loads before the panels reserve space" problem until I've further enhanced the functional test runner.

[fidergo-stephane-gourichon]

Now using it once (bash quicktile.sh --daemonize). Appears to fix this bug. No negative impact observed after 2 minutes. :-)
Will report in case of problem.

If correct, what I will do is rebase or merge my debian package branch on it, rebuild a package and let it just work from that on.

Thanks!

[ssokolow]

If correct, what I will do is rebase or merge my debian package branch on it, rebuild a package and let it just work from that on.

Please, wait until I've pushed the branch to master. That'll be coming as soon as I've fixed these issues.

(#12 and #107 are listed as open because they'll be auto-closed on the push to master so it's just #108 and #45 left to fix.)

[kbsali]

@fidergo-stephane-gourichon I'd be interested in getting your branch rebased! :)

[ssokolow]

OK. The 0.4.0 release candidate is now in the gtk3_port branch. I need to get some sleep, but, after that, I'll decide what the order of operations will be for getting #106 merged in.