search

bbidulock / icewm

A window manager designed for speed, usability, and consistency
Other
571 stars 97 forks source link

Window focus (or positioning) seems confused for some dialogs/transients #720

Closed bananaliker closed 1 year ago

bananaliker commented 1 year ago

I've noticed this after coming back to icewm recently, I don't recall having these issues a year or so ago. I've noticed it in 3.3.3 on both Arch and Gentoo.

Some dialog windows are behaving quite oddly. The dialog will appear like normal, as in any other WM, but it seems to be "misplaced" when I go to actually click within it. For example, hovering over or click a button or dropdown menu within the dialog window doesn't register, but clicking a few (10px, 20px?) pixels below it will, like it's expecting to be somewhere different. This seems to be remedied if I manually move the window before trying to interact with it.

Examples of where I've seen this happen: Krita dialogs, ie. new file and save file windows pcmanfm-qt dialogs, ie. empty trash. Noticed it mostly while using kvantum as my qt style, notably the issue seemed to possibly go away when using the "Windows" style. For reference with the above, Krita seems to use "Fusion" by default, at least on my system. Gamepad configuration in Wine's control panel ie. "wine control" in terminal then the gamepad config section.

Let me know if any additional info is required.

gijsbers commented 1 year ago

Sofar not reproducible for me. I start krita with QT_STYLE_OVERRIDE=kvantum krita. Then I can new and save fine. If I do QT_STYLE_OVERRIDE=kvantum pcmanfm-qt and empty the trash, the mouse hover is immediately sensitive, but the mouse click needs to be repeated two more times before it acts. Don't know how to start the wine Gamepad. So aim for concretely reproducable scenario's. Assume I'm unfamiliar with your OS, desktop environment and applications. If you want, you can test previous versions to see when the change happened.

bananaliker commented 1 year ago

Well, I have a backup install with Debian Bullseye and I can confirm that the issue doesn't occur there (icewm version 2.1.2-1 according to https://packages.debian.org/search?searchon=names&keywords=icewm)

For the wine gamepad, you only need to type "wine control" in terminal and in the menu that appears there should be a game controllers menu.

Assume I'm unfamiliar with your OS, desktop environment and

As I said, Arch is where I'm having the issue right now. Debian is where I'm not. I use icewm started through xinit with no display manager on either, and just a few programs in my startup script (xset, lxqt-policykit-agent, redshift, feh, opensnitch-ui and fcitx). Settings are pretty default, I can share my prefoverrides if needed (I did try messing with dialog relevant options to see if any would fix it, they didn't).

And I accidentally closed this issue by clicking wrong button lol, reopening.

gijsbers commented 1 year ago

wine control verified. Clicking on the buttons doesn't work. Keys do. After moving or resizing button click works. Initiating a move with Alt+Button1 moves it top-left 2 pixels.

Which theme? That they don't respond to mouse clicks is a new phenomenon.

bananaliker commented 1 year ago

I've tried it both with the default theme and with a couple of custom themes and haven't found one that makes a difference.

bananaliker commented 1 year ago

To add to that, I just tested a bunch of different themes, and it seems like the height of the titlebar affects how "offset" the dialog window and its contents actually are. ie, a theme with a 30px title will be offset more than a theme with a 20px title.

gijsbers commented 1 year ago

This fixes both pcmanfm-qt and wine control for me.

bananaliker commented 1 year ago

Seems to fix Krita dialogs as well. Great work, thanks!