XTEST versus XSendEvent
Joseph Krahn
SendEvents for security reasons. Now, the XTEST extension is common,
which some admins might not want it enabled. Therefore, xdotool should
not deoend on XTEST, and revert to just using SendEvents.
When XTEST is present, it may be more reliable than SendEvents, and
xdotool should support routing all events through XTEST. OTOH, there
may be times when XTEST is present, but not preferred (e.g. due to
extra XSyncs) and there should also be an option to prefer
XSendEvents.
Also for improved `type' command performance, it may be useful to have
a config file that defines keystrokes to produce a desired character.
This would allow for Compose key sequences, for example, and reduce
the need for keyboard mapping events. The syntax for the key sequence
can be the `key' command.
Joe Krahn
Henning Bekel
> In the old days, XSendEvent worked well. Now, most applications block
> SendEvents for security reasons. Now, the XTEST extension is common,
> which some admins might not want it enabled. Therefore, xdotool should
> not deoend on XTEST, and revert to just using SendEvents.
>
> When XTEST is present, it may be more reliable than SendEvents, and
> xdotool should support routing all events through XTEST. OTOH, there
> may be times when XTEST is present, but not preferred (e.g. due to
> extra XSyncs) and there should also be an option to prefer
> XSendEvents.
Not sure what you want. It sounds like you're contradicting yourself
in your first paragraph. If I understand you correctly, you're
suggesting that XTest should always be used by default if it's
available.
Xdotool currently allows the user to control which method is used. If
a command that sends events is used with an explicit --window target
(or if there's a current window on the stack), then XSendEvent is
used, otherwise, XTest is used.
This is straightforward and technically consistent, since XSendEvent()
always needs a target window to send the event to, while the XTest
functions always just simulate events (which will end up being
delivered to the the focused window).
In my opinion there is no need to
- Add or remove support for either method based on arbitrary
assumptions about which method is more likely to be available on a
given system. All systems are different.
- Take away choice from the user for no obvious reason, and try to
make smart guesses on what should happen based on the availability
of XTest, just because it MAY work better. Some of my scripts rely
on the current behaviour, and explicitly use XSendEvent.
Let's face it, the whole event handling of X is broken as it is, and
there is no truly sane way of sending events programatically. Xdotool
is fine as it is, giving the user choice and the means to deal with
both shortcomings of XSendEvent and XTest.
I personally haven't had a problem with using XSendEvent. In some
cases, it's the better choice over XTest, namely when you want to
invoke xdotool to send a modifier and key from a keybinding involving
another modifier, e.g. binding 'xdotool key alt+j' to win+x. Using
XSendEvent, xdotool can just encode the modifier in the event it sends
instead of having to jump through burning loops in order to keep the
keyboard state consistent by pressing and releasing modifiers prior to
faking the actual keypress... which may still fail and leave the
keyboard in an inconsistent state...
In conclusion, I don't see a need to change the current implementation
and I think it would make xdotool less useful to do so.
Regards,
Henning
Jordan Sissel
> In the old days, XSendEvent worked well. Now, most applications block
> SendEvents for security reasons. Now, the XTEST extension is common,
> which some admins might not want it enabled. Therefore, xdotool should
> not deoend on XTEST, and revert to just using SendEvents.
Regarding XSendEvent being ignored, you can trick applications into
accepting all synthetic events by using LD_PRELOAD to override
XNextEvent and set the 'send_event' member to false - applications
will be none-the-wiser. I posted an example of this, here:
http://www.semicomplete.com/blog/geekery/xsendevent-xdotool-and-ld_preload.html
>
> When XTEST is present, it may be more reliable than SendEvents, and
> xdotool should support routing all events through XTEST. OTOH, there
> may be times when XTEST is present, but not preferred (e.g. due to
> extra XSyncs) and there should also be an option to prefer
> XSendEvents.
In some cases XTEST is better than XSendEvent, and vice versa. You can
force XTEST by setting '--window 0' (which it is by default, unless
you've done a search prior in the command line.) For example, I use
this to activate google-chrome and focus the url bar:
xdotool search --title -- '- Google Chrome' windowactivate key
--window 0 --clearmodifiers ctrl+l
The '--window 0' makes the 'key' command use XTEST instead of
XSendEvent. See the "SENDEVENT NOTES" in the xdotool manpage.
>
> Also for improved `type' command performance, it may be useful to have
> a config file that defines keystrokes to produce a desired character.
> This would allow for Compose key sequences, for example, and reduce
> the need for keyboard mapping events. The syntax for the key sequence
> can be the `key' command.
Yeah, I was proposing this a few days ago on the mailing list. It's on
the TODO list.
-Jordan
Joseph Krahn
that already use XTest.
First, the presence of XTest should not be mandatory. It is an
extension, whereas XSendEvent is standard for all X servers.
Currently, xdotool will fail when XTest is absent, even if the given
command will never use XTest functions.
Second, it should be possible to use XSendEvent even when XTest is
available. In looking at the latest code with the window STACK, I now
realize that this is already possible. You can just use
'getwindowfocus' and then the type command will target that window
with XSendEvent.
Instead, I think it may be useful to automatically use XSendEvent to
the focus window when XTest is absent. If you don't want automatic
reversion to XSendEvent, the code should at least be updated to only
fail when XTest functions would be called.
Thanks,
Joe Krahn
Jordan Sissel
> OK, my description was not very good. I am mainly thinking of commands
> that already use XTest.
>
> First, the presence of XTest should not be mandatory. It is an
> extension, whereas XSendEvent is standard for all X servers.
> Currently, xdotool will fail when XTest is absent, even if the given
> command will never use XTest functions.
Ahh, I see what you're asking for. If XTestQueryExtension fails, we
should use XSendEvent to the active window? Sounds like a reasonable
feature and should be easy enough to implement.
-Jordan
