Closed guiambros closed 5 months ago
Thanks for identifying the source. I'll give it a look either in the morning or, if I can't fit it, during the next few days.
I have had people report one-pixel gaps, but I hadn't made it an exceptionally high priority because, before unexpected stuff came up and put QuickTile on the back burner for a while, I'd been planning to finally get around to the deep architectural changes needed for #10, which would involve a complete rewrite the positioning system to more of a grid system where every pixel is assigned to some cell and this kind of bug can't crop up.
(After I finished the plans to rework the config file handling to fix #13. When I had to put QuickTile on the back burner, I had mostly completed a "just press the key combo you want to assign" GUI for mapping hotkeys to action commands to make up for switching to something less friendly to manual editing but more suitable for hierarchical data, like JSON. I think most of what remains is regression testing to make sure I'm properly mapping between what the GUI captures and what the keybinding layer expects.)
Replicated using this quick-and-dirty HiDPI simulation and I don't see any problems with the change for low or high DPIs on my end. (Thanks to this page that I just discovered now.)
#!/bin/sh
cd -- "$(dirname -- "$(readlink -f -- "$0")")" || exit 1
Xephyr -screen 3840/508x2160/286 :1 &
sleep 1
export DISPLAY=:1
kwin_x11 &
gvim &
gvim &
gvim &
./quicktile.sh -b
Either you can make a PR or I can make the change myself.
In the former case, please edit docs/authors/index.rst
and run docs/update_authors.sh
to add an entry for yourself with something like "Diagnosed and fixed HiDPI layout bug".
In the latter case, please let me know whether Gui Ambros is your preferred way to be cited in that list.
Thanks @ssokolow! If you can make the change it'd be great (just so I don't have to go through my employer OSS contributing process). Yes, name is fine, but honestly no need to worry with credit. Just glad to have found QuickTile. Thank you!
Will do. It may take me a day or two more though. I've been taking advantage of favourable weather to get some home maintenance done in preparation for summer.
Change pushed. Sorry for the extra delay.
Tested and confirmed working. Thank you so much!
When tiling 3 windows side-by-side on a wide screen monitor, there's a perceptible small gap between the edges of adjacent windows.
On 5120 px wide monitor, the gap is 6px between left and center windows, and 1px between center and right window.
Specifically: the left window will be 0.333 5120 = 1704 px wide, while the center window will be 5120 0.667 - 1704 = 1711 px wide. See image.
This is caused by
round()
on make_winsplit_positions() andGravityLayout
class using only 3 decimal places . This shouldn't be a problem in lower resolutions, but as the screen size increases, the gap becomes more noticeable.Adjusting to 10 decimal places in this line and this line fixes the problem.
I'd be glad to send a PR if helpful; just wanted to check if it won't break anything else.
Debug log -- Before:
Debug log -- After:
To be 100% precise, there's still a some residual rounding error that results in a tiny 1px gap, where the right window starts at 3413, but 2 x 1706 = 3412, so the border of the windows don't overlap. Depending on the window manager and translucency of the theme used, you may see a 1px wide shade of the desktop background between the center and right window:
But it's really imperceptible, and fixing would require a lot of additional changes on how the split is calculated depending on the col_number, so I'd say it's not worth it.