Customizable focus behavior

[haarp]

Is your feature request related to a problem? Please describe

Hey, Touchegg currently has fixed focus behavior. Actions such as SEND_KEYS will always focus and raise the window under the mouse cursor before sending the action. This is not always desireable. e.g. I might want to switch the tab in my browser window containing documentation without taking focus away from my text editor.

It would be nice if Touchegg was configurable in this regard.

Describe the solution you'd like

Add option that controls how/if focus is handled. The following modes may be considered:

1) Focus the window under the cursor before executing action (current method) 2) Do not react if window under cursor isn't already focused 3) Do not focus the window under the cursor, but send action to window under cursor 4) Do not focus the window under cursor and send action to focused window (application selector also should compare against focused window instead of the one under cursor in this mode)

Additional context

It's not always possible to actually send keys to unfocused windows. That's probably the reason SEND_KEYS behaves the way it currently does. XSendEvent is the call in question, and it sometimes needs hacks to work. In my experience however, all windows except browsers (Firefox) work without the hack. Also see SENDEVENT NOTES section in xdotool manpage.

Describe alternatives you've considered

• If the Send Event thing is too hacky/unreliable to be worth implementing, then limiting the option to the first 2 modes would be enough :)
• RUN_COMMAND doesn't change focus and can be used to work around this somewhat. Depending on the WM, only mouse1 inside a window actually focuses it. So e.g. instead of SEND_KEYing previous/next, one may instead use xdotool click 8/xdotool click 9. This is limited to very few actions tho, i.e. those that have mouse buttons bound to them.

Thanks a lot! Touchegg rocks :)

[JoseExposito]

RUN_COMMAND doesn't change focus and can be used to work around this somewhat. Depending on the WM, only mouse1 inside a window actually focuses it. So e.g. instead of SEND_KEYing previous/next, one may instead use xdotool click 8/xdotool click 9. This is limited to very few actions tho, i.e. those that have mouse buttons bound to them.

I was going to suggest to use RUN_COMMAND + xdotool key/click ... to workaround this issue. Wouldn't that work for you?

Having in mind that most users won't take advantage of an extra configuration option, I think that this would add an extra layer of complexity to the config and GUI that is not worth it if it can be emulated with xdtool.

[haarp]

Hey,

Wouldn't that work for you?

Well, as I wrote, in case of xdotool click this works like mode 3, but involves maybe 2-4 relevant buttons.

xdotool key will send to the application with keyboard focus, which would be inconsistent. It could be somewhat used as a substitute for mode 4, if one knows exactly what they're getting themselves into.

What I'm mainly looking for myself is mode 3. Even knowing of the SENDEVENT challenges, many applications work with it.

[JoseExposito]

What I'm mainly looking for myself is mode 3. Even knowing of the SENDEVENT challenges, many applications work with it.

As you mentioned, it is difficult to make this mode reliable, and adding it would result in new bug reports :smiling_face_with_tear:

In general, I try to keep the configuration options as minimum as possible because I need to test all the possible combinations before each release and my time is limited.

However, for ad-hoc use cases like this one, you can always build a small tool/script that works for you and invoke it with RUN_COMMAND.

[haarp]

Ok, I played with it some more.

• xdotool click n works like mode 3, assuming the WM doesn't focus on buttons >1, otherwise it's mode 1
• xdotool key foo works like mode 4
• xdotool getmouselocation click/key foo works like mode 3 in supported applications

So what to do about applications that don't work with the latter? You don't want them to get focused unexpectedly -> Fallback to mode 2 for these apps:

sh -c 'eval $(xdotool getmouselocation --shell); [ $(xdotool getactivewindow) = $WINDOW ] && xdotool key foo'

X11 is such a mess 🥲