Window positions/sizes not pixel perfect when screen resolution is not cleanly divisible by 3

[oikonny]

Hello,

i noticed that windows which habe been resized to be 2/3 of the horizontal screen resolution and aligned to the left edge of the screen are one pixel to short and windows with a size of 1/3 on the right edge are positioned one pixel over to the left, both of them leaving a nasty one pixel line the its right. This happens when the horizontal screen resolution is not cleanly divisible by 3 like 1024 or 1366.
I tried fixing it on my own, but i don't have much experience with python and i saw, that you save the windows sizes as percentages and not absolute pixels, which underminded my attempt to "just add a +1 to the relevant spots".
I noticed this issue in version 0.2.2 and it still exists in version 0.3.0. I use this project on all my xfce4 desktops for years and it would be perfect if this could be fixed.

[ssokolow]

That's been mentioned over the years and I'm aware of it. I've been trying to find time to work on QuickTile lately and, once I clear out more pressing problems (eg. issue #87), I plan to rework how QuickTile works internally so this bug becomes impossible.

(Currently, QuickTile calculates dimensions from scratch each time you trigger it. My plan is to have it calculate a grid all at once and then remember that grid and slot windows into it as needed.)

[allanlaal]

(Currently, QuickTile calculates dimensions from scratch each time you trigger it. My plan is to have it calculate a grid all at once and then remember that grid and slot windows into it as needed.)

would that take account new monitors added/disconnected?

[ssokolow]

To be perfectly honest, I don't really think about hotplug because every WM I've used has been so broken about resolution-changing that my solution was to lock the desktop resolution in xorg.conf so that applications which want to fullscreen can't scramble up my windows before I can find the "Fullscreen" checkbox and uncheck it.

The plan was just to keep being monitor-agnostic for all commands which don't switch windows between them and rely on the host WM for the rest.

[allanlaal]

I personally use xrandr commands (mapped to shortcut keys) every time I connect a combination of monitors rather than ~/.config/monitors.xml or xorg.conf, because some of the screens are HiDPI and others need to be scaled and there is no way for my laptop to know which way a monitor is rotated anyway

[ssokolow]

I'd probably do likewise, but keyboard shortcuts can't really help when the situation is "I never hotplug, but every two-bit game that uses resolution-changing to fullscreen will permanently move all my windows into the same monitor unless I lock the desktop resolution".

That's a destructive/irreversible operation unless I were to remember to hit some kind of "take snapshot of window positions" key before doing so... and that would still turn off two monitors that could be perfectly useful while I'm gaming for status display, reference material, etc.

(And, since I mostly play games which don't grab the pointer, it's even more useful to keep the other monitors on.)

[allanlaal]

this might warrant a separate ticket, but since its heavily related to what we are discussing here, I'll post it here for now:

I really like that the amount of columns is now configurable (before it was hardcoded to 3 like #90 refers to), but this does not address having lots of different monitors with different widths: some can handle only 3 columns, whilst most of my monitors can handle 4 columns - as a workaround I've started using 6 columns (which means column#1 is useless). maybe it would be better to have a minimum width per column and have QuickTile precalculate how many columns per monitor to use?

As an aside: it would be great to configure vertical rows too. Currently its hardcoded to 2, but that discriminates against vertical monitors

then again having more than 3 cols and more than 2 rows necessitates the need for a new method of tiling shortcuts: having 6 cols in 2 rows, it is impossible to position a 1/6 wide window in col#2 from the right nor the left

[ssokolow]

this might warrant a separate ticket, but since its heavily related to what we are discussing here, I'll post it here for now:

I really like that the amount of columns is now configurable (before it was hardcoded to 3 like #90 refers to), but this does not address having lots of different monitors with different widths: some can handle only 3 columns, whilst most of my monitors can handle 4 columns - as a workaround I've started using 6 columns (which means column#1 is useless). maybe it would be better to have a minimum width per column and have QuickTile precalculate how many columns per monitor to use?

Actually, as of a month or two ago, I finally have monitors of different sizes (in a "1280x1024, 1920x1080 ,1280x1024" horizontal arrangement) so that is on my radar... I just have so much else that's more urgent that I haven't had time to work on QuickTile.

Originally, I'd been deferring it as a shortcoming to be addressed "Once I've fixed #10, #13, and #24".

As an aside: it would be great to configure vertical rows too. Currently its hardcoded to 2, but that discriminates against vertical monitors

then again having more than 3 cols and more than 2 rows necessitates the need for a new method of tiling shortcuts: having 6 cols in 2 rows, it is impossible to position a 1/6 wide window in col#2 from the right nor the left

That's #53 which, again, is blocked on #13 and friends. (Yes, it's been sitting there for two years, but that's because, until recently, I didn't have time for QuickTile, period.)

At the moment, all my hobby-programming time is taken up working on reviving some other creaky old codebases which need to be moved to new hosting because of a hosting company price bump.

[ssokolow]

Just a status update on "creaky codebases". I've been actively working on QuickTile since the last couple of weeks of December and I'm getting close to releasing the GTK 3 port.

As a bonus, it's growing a nice set of automated tests, which is what I need to feel confident in refactoring to fix this and other bugs.