Open haarp opened 1 year ago
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
.
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.
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.
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 1xdotool key foo
works like mode 4xdotool getmouselocation click/key foo
works like mode 3 in supported applicationsSo 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 🥲
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 seeSENDEVENT NOTES
section inxdotool
manpage.Describe alternatives you've considered
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 ofSEND_KEY
ing previous/next, one may instead usexdotool 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 :)