Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look into using xdo instead of xdotool #58

Open
anonymouse64 opened this issue Aug 31, 2021 · 2 comments
Open

Look into using xdo instead of xdotool #58

anonymouse64 opened this issue Aug 31, 2021 · 2 comments
Labels
bug Something isn't working enhancement New feature or request

Comments

@anonymouse64
Copy link
Contributor

xdotool is unmaintained and doesn't work with XWayland on Wayland as per @bboozzoo

Suggestion was to investigate xdo instead: https://github.com/baskerville/xdo

@anonymouse64 anonymouse64 added bug Something isn't working enhancement New feature or request labels Aug 31, 2021
@anonymouse64
Copy link
Contributor Author

FWIW this sort of loop seems to work most reliably:

xdo id -m -N "Antstream Arcade" # wait for the a client with the window opts to appear
# loop waiting for the id to no longer be inspectable, trying to close the window repeatedly
while xdo id -N "Antstream Arcade" > /dev/null; do 
    xdo close -N "Antstream Arcade"
done

We need to do this because there isn't really a command which blocks until the window is painted/mapped in xdo as it stands, at which point we then would grab a time measurement and close the window. xdo kill -m ... just kills the client immediately before anything is drawn or painted which skews the measurement to be smaller than it should be in reality, while xdo close ... simply submits a "close request" or some sort of thing which can be sent successfully so xdo returns exit code 0 but the application can be in a state where that close request does nothing and is effectively ignored. So we need to keep sending the close request until the window stops appearing in which case we know it showed up and was closed.

@bboozzoo mentioned there may be a better way if we patched xdo to have a call to xcb_get_geometry() that we could use (or maybe we could just do the call directly from etrace via cgo) but needs some investigation

@anonymouse64
Copy link
Contributor Author

The option mapping between xdotool (where etrace currently derives it's own options names from) and xdo is essentially as follows I think:

xdotool xdo
--classname -N
--name -a
--class ???

--class vs --classname in xdotool is a bit of a mystery to me still so it's unclear if -N is sufficient or not for both cases

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant