search

jordansissel / xdotool

fake keyboard/mouse input, window management, and more
Other
3.21k stars 318 forks source link

"behave_screen_edge" doesn't work with maximized borderless/undecorated GTK3 or QT5 windows, in Openbox or Fluxbox, at least #325

Open dannielsoares opened 3 years ago

dannielsoares commented 3 years ago

Additionally, with whatever is Google Chrome's toolkit. The terminal where it's running won't show any message as it fails, it just keeps running as if nothing had happened.

I haven't tested it yet on other window managers than Openbox and Fluxbox. It doesn't matter if the window is undecorated as the program starts or if it's switched off after. Toggling it back makes behave_screen_edge work normally.

It works normally with GTK2 maximized undecorated windows (geeqie), as well as those of whatever are the toolkits of xterm, xmessage, Dillo, Firefox (Debian's 78.8.0esr), and a "MS windows" window via WINE.

I was giving a try at using "behave_screen_edge" to bring Openbox menu for all windows in all desktops. Besides apparently requiring me to create a "devilspie" script to kill xdotool and restart it for every new window opened (otherwise it won't work on that window, when it's maximized -- perhaps that's an "issue" of its own, maybe even more likely to affect more people, to whop perhaps his workaround wouldn't be feasible, for some reason), it also fails with undecorated windows that are maximized.

The main thing is:

xdotool behave_screen_edge --quiesce 1000 --delay 600 top exec xdotool key XF86AudioPlay

Where the second/exec-ed xdotool can be replaced by something like "echo working | aosd_cat" for testing purposes. (It's what I have to bring the Openbox "all windows" menu, wouldn't have the same or any effect elsewhere)

NNBnh commented 2 years ago

This also happen on BerryWM...

wranai commented 2 years ago

Same on i3wm. Maybe these wms capture these events somehow and they never reach xdotool.

jordansissel commented 2 years ago

Hmm, I don't have any ideas yet as to what would cause this.

Some background on what might be going on: xdotool watches for existing and new windows and asks the X11 server to be notified any time time pointer (mouse) moves in any window. If there is movement, xdotool will check to see if pointer's current location (an x,y pixel location) is the edge/corner of the window.

Now, for a borderless window, I have a guess but it might be wrong. Xdotool only thinks of "left" as being the x=0 coordinate, right is x=max-1 where max is the width of the given window. It's possible xdotool isn't correctly identifying the boundaries of the window? Or maybe the window extends off of the visible screen edge and beyond where the mouse pointer can reach? I'm just guessing here and haven't seen this issue myself.

dannielsoares commented 2 years ago

Same on i3wm. Maybe these wms capture these events somehow and they never reach xdotool.

But the windows' toolkit is also a factor, not just the WMs. At least on Open & Fluxbox.

Makes me wonder if one of those xwininfo -like programs will show something different in otherwise "equivalent" windows drawn by different toolkits, like they secretly are one pixel larger or something. I'll see if I find something.

xwininfo seems to give essentially the same properties, at least with default "verbosity," whereas xprop will have certain differences between the windows, but none that matches the pattern. Or none that I could find so far.

dannielsoares commented 1 year ago

Somehow, it seems to be working as expected by now. I don't even know if I'm running a new version or what. Certainly not a version from github itself, whatever that's the stock package for Debian stable. Either some new tweak since then on xdotool or any other possibly related package must have made a difference. Or some random minor config difference on things like openbox' rc.xml, picom, I don't know.

Actually, on geeqie (now a GTK3 one) it "behaves" when the cursor touches the edge at the window are that's just the image, but not the menu part. But with Krita (QT window) there's no such distinction. It does nothing in "full screen" mode, but then I wouldn't even expect that.

Nevermind. It's really the same as before, it must be affected by the order in which different programs are started or restarted. Openbox itself and picom, the main suspects. I suspect that at times there will be a reserved row of pixels making a difference.