Inaccurate window positioning with terminal

[ldmdev]

Hello, I'm using quicktile with Xubuntu 14.04, when I try to move any terminal window for first time I get an inaccurate position leaving a small amount of space between screen edges and window border (as you maybe can see in the attached screenshot). When I move again the same window, the problem disappear. No issues with other applications. Thank you so much for any feedback!

[ssokolow]

I'm not sure why moving it would fix it, but here's what I think is happening:

Windows can specify that their sizes must be in increments of their monospace font's character size (If you manually resize a terminal window, you should notice that it happens in steps).

The desktop expects a position relative to the top-left corner of the window and QuickTile's code for translating positions relative to other corners isn't currently smart enough to recognize that the window may refuse to take the exact size that was requested.

(QuickTile has a bit of a history of problems with windows that refuse to do exactly as they're told and I've been meaning to do a major rewrite to fix it for years.)

[diwu1989]

There's a similar type of bug in the mac app Spectacle when certain apps specify constraints on its geometry or resize themselves. There's not much that Spectacle does for those applications, I think the reasoning being that those apps are out of Spectacle's control and it's a best effort resize.

My opinion is I don't feel this is a bug in quicktile because the resize behavior is out of its control.

[ssokolow]

There is, however, a definite bug in QuickTile that's related: #20

[ssokolow]

OK, with #20 now solved, I've confirmed that QuickTile currently makes no attempt to read and work around sizing hints such as the size_inc hint that terminals generally set, so fixing that is my next goal and it'll probably resolve this issue.

[rvega]

I'm suffering this issue as well on gnome and gnome-terminal. BTW, thanks for quicktile! :)

[ssokolow]

Unfortunately, at the moment, I've had to redirect my efforts (when I can fit them in) to the task of porting to Python 3 and GTK+ 3.x.

(It's not the most straightforward task because QuickTile, by its very nature, relies heavily on the APIs which changed the most between GTK+ 2.x and 3.x... including some APIs that GDK 3.x tried to shove off on the X11 libraries in a way that's not exactly clear for non-C/C++ languages.)

I did actually attempt to get started on handling window-sizing hints properly shortly after saying that back in 2017, but I underestimated the severity of the changes necessary in the approach I picked and stuck on some bugs that were difficult to track down because it was a massive snarl of rectangle calculations with no tests.

When I try again after the GTK+ 3.x port is finished, I'll be taking what I learned from that experience and trying again with a much greater focus on architecting it to be a lot of little bits of math, each with its own unit test.

[ldmdev]

I'm still using QuickTile, so, however, thank you for your work!

[ssokolow]

The GTK 3 port is almost finished (and already has quite a pile of the unit tests I said I'd write). It's already usable if you want to try it and see how upgrading to libwnck 3.x changes things (if at all).

https://github.com/ssokolow/quicktile/tree/gtk3_port

(Just don't use the pip3 URL install method. The URL given is for the master branch which still contains the GTK+ 2.x version at the moment.)

The main things keeping it from being merged into master are:

• Need to finish writing the new Sphinx-based docs to remove the dependency on ePyDoc.
• Need to fix regressions #107 and #108
• Want to write a few functional tests

[ssokolow]

For the record, I'm starting to triage bugs to get caught back up on things (COVID driving society crazy wasn't good for me) and I've confirmed the continued presence of some kind of tiling bug on the first interaction with an xterm window in current QuickTile HEAD.

(Initially on my Kubuntu 20.04, xterm snaps to a shape that's very much not what was requested and can't be explained by a simple rounding to multiples of the character cell size either.)

I'll probably make a point release before addressing this to get the HiDPI support released before I focus on completing the integration test harness I want to rely on to prevent fixes to things like this from regressing.

[ssokolow]

Ugh. And now, when I went back to diagnose the problem I experienced with --debug, it heisenbugged itself away including when I rolled back to the revision where I encountered the problem before, and I'm left wondering if I just accidentally left some of my testing settings for the new margin support active.

I have no choice but to close this since the only part that isn't "as expected, given the limitations of the current design" is the "When I move again the same window, the problem disappear" and I can't reproduce it.

I'll tag it as "needs more info" while closing it. Feel free to reopen if you're still experiencing the problem and can point me at a distro and DE version to try spinning up in a VM.