Aspect ratio sometimes gets hosed after moving around

redhog / InfiniteGlass

Window manager with infinite desktop, infinite zoom and infinite window resolution

https://redhog.github.io/InfiniteGlass/

GNU General Public License v3.0

36 stars 6 forks source link

Aspect ratio sometimes gets hosed after moving around #34

Closed redhog closed 4 years ago

redhog commented 4 years ago

Split out from https://github.com/redhog/InfiniteGlass/issues/23

Moving around sometimes mess with the aspect ratio of the windows:

Normal:

redhog commented 4 years ago

That is indeed a funny bug... Did you zoom in and out far, or what did you do to trigger this? It is a bit of an issue that sizes are stored as width,height, not with,aspectratio, so they are subject to rounding errors, and compound rounding errors... Not sure this is the case here though...

redhog commented 4 years ago

Yes, I did zoom in and out. I did a test with only moving around after you mentioned it and it eventually comes up again. The test is simple: open Audacity, move around, open xterm, move around, open another xterm, move around, etc. until it breaks the aspect ratio.

redhog commented 4 years ago

Fixed here: https://github.com/redhog/InfiniteGlass/commit/cc570ae05b42b0c00a182ab29c618b76edddb602

IanTrudel commented 4 years ago

Seems to be fixed. One thing that is annoying when I use the WINKEY is that changing focus on xterm grab the input and subsequent WIN+ARROWS are swallowed by the xterm. Nothing should be able to grab the input while using WINKEY. And, I'm still enjoying the edge highlight very much. :D

redhog commented 4 years ago

Yeah, I've seen the WINKEY swallowing by other apps too, esp Chrome. I really have no idea how those apps can override a XGrabKey on the root window. There are still parts of the X protocol that I'm a bit unsure of - and this stuff isn't that well documented :(

IanTrudel commented 4 years ago

https://bugs.freedesktop.org/show_bug.cgi?id=39545

Seems like a bug but the question is... How other WMs do it?

redhog commented 4 years ago

Oh... maybe thats's it? If so, there is very little I could do I think? But not sure this is actually it... What I do is:

XGrabKey(WINDOWS) User presses WINDOWS. XGrabKeyboard() User presses and releases a bunch of stuff, I use it all User releases WINDOWS XUngrabKeyboard()

This logic is implemented in glass-input/glass_input/grabbed.py and input.json...

IanTrudel commented 4 years ago

Would it be possible to somehow disable all windows (or just their input) when WINKEY is pressed? Then you go through the list again to reenable when the key is released.

redhog commented 4 years ago

Hm, isn't that what XGrabKeyboard is supposed to do?!

IanTrudel commented 4 years ago

Hm, isn't that what XGrabKeyboard is supposed to do?!

Yes. o_O

Or, could you check if WINKEY is already pressed when another window grab the input? If it's pressed, have it skip the grab, otherwise grab it as usual.