jordansissel / xdotool Goto Github PK
View Code? Open in Web Editor NEWfake keyboard/mouse input, window management, and more
License: Other
fake keyboard/mouse input, window management, and more
License: Other
There seems to be some problem when sending keys to another firefox window when the currently focused window is a firefox window belonging to the same firefox instance. For example, if I had a key binding configured in my window manager mapping some key to 'xdotool search SomePage key control+r', sometimes the event will be received by the currently focused firefox window instead of the one showing a page titled "SomePage". This doesn't follow a systematic pattern or at least I couldn't find one. It could be that firefox confuses the focused window with the one receiving the KeyPress event. Furthermore, I don't know if some behavior is considered standard in this case: should the application attribute the KeyPress event to the target window or to the focused window?
I'm using firefox 26, xdotool 2.20110530.1, dwm 6.0, and arch: Linux localhost 3.12.7-2-ARCH #1 SMP PREEMPT Sun Jan 12 14:02:09 CET 2014 i686 GNU/Linux
It would be incredibly helpful if mousemove distinguished percentages from plain numerical coordinates.
Many GUI layouts are proportional. For example. in GPick, if the Palette panel is visible, moving to the (98%, 50%) mark will always put you in the Palette. Or in Sakura, moving to the 0.5%, 1% mark will get you to the first tab (assuming multiple tabs are open))
Currently, xdotool mousemove 50% 50%
simply moves to 50,50. The change I'm suggesting would make xdotool mousemove 50% 50%
move to the centre of the current screen, and xdotool mousemove -w $WINDOW 50% 50%
move to the centre of the specified window.
I used commands like xdotool click --position 867 523 --window 79691777 1
to control a window in the background (flash in chrome), below all other windows.
This is used to work, but after the latest system update, the window is always focused and raised to foreground, which is very annoying.
Is there a way to prevent that focusing?
On xfce/debian
The 1st call to xdotool search
from within a graphical application returns a BadWindow
error:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 3 (X_GetWindowAttributes)
Resource id in failed request: 0x4e011ca
Serial number of failed request: 318
Current serial number in output stream: 319
The 2nd and subsequent calls don't return errors. If called directly from bash
, no errors are returned.
It's reproducible, suffice it to create a simple script with these lines:
#!/bin/bash
echo 'Attempt #1'
xdotool search --class puddletag
echo 'Attempt #2'
xdotool search --class puddletag
and then run it from bash
and a graphical app (I called the script from plugin Custom Commands
in quodlibet
, or from a .desktop
file as an external editor in geeqie
). puddletag
can be replaced with any other suitable app name. When called from bash
directly, these were the (correct) results
Attempt #1
65011714
65011732
Attempt #2
65011714
65011732
but when called from either quodlibet
or geeqie
, the first search
call failed and the second succeeded:
Attempt #1
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 3 (X_GetWindowAttributes)
Resource id in failed request: 0x4e011ca
Serial number of failed request: 318
Current serial number in output stream: 319
Attempt #2
65011714
65011732
This error was not tied neither to quodlibet
nor to geeqie
: when called from any graphical application, whether GTK+
or Qt
, xdotool search
always failed with the BadWindow
error on its first invocation.
I'm using:
xdotool
3.20130111.1-5
xserver-xorg
7.7+7ubuntu2
xfce
4.11
Xubuntu
14.10
I'm running i3 in Arch. Also documented here. Thanks for the great tool!
$ xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ bcm5974 id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ Sleep Button id=9 [slave keyboard (3)]
↳ Apple Inc. Apple Internal Keyboard / Trackpad id=10 [slave keyboard (3)]
$ xkbcomp -i 3 keymap.xkb :0
$ xdotool type "bla"
bla⏎
keymap.xkb is no longer active after running the commands above.
Hello,
My idea is to use xdotool to run indicator-synapse with a shortcut. But in Xubuntu 14.04 (Xfce 4.10) xdotool doesn't work correctly with the shortcut assigned. This is my little script:
xdotool mousemove 1050 5 click 1 mousemove restore
And when I select the shorcut it seems that goes to the assignated coordinates and returns to the original position but the click doesn't has effect, the indicator-synapse icon changes its color (this means that is clicked), anything else happens.
This happens in my desktop Xubuntu install and in a Virtualbox VM configured for reproduce the issue. Under Unity desktop runs perfect, no problem at all.
Please, could you suggest me a solution?
Thank you very much and very best regards.
I am not sure if this is an issue with gnome or xdotool, but I created a script which hides gnome-terminal when it is visible, and shows it when it is hidden. I use the following line to do this.
xdotool search --onlyvisible --class 'Terminal' windowunmap %@ || xdotool search --class 'Terminal' windowmap %@
The problem is that when I hide and then unhide the gnome-terminal window, a tiny extra window appears (of the same class and name). Only one extra window appears, no matter how often I hide/unhide gnome-terminal. The window contents is black. i can't do anything in there. It isn't a big problem, but it clutters the window list and doesn't seem to be the expected behaviour.
I also can't close the window.
I am running ubuntu 12.04 with gnome-shell. These are some of the details of my setup.
||/ Name Version Description
+++-==============-==============-============================================
ii gnome-shell 3.4.1-0ubuntu2 graphical shell for the GNOME desktop
ii xdotool 1:2.20110530.1 simulate X11 keyboard/mouse input
Linux dolfdesktop 3.2.0-34-generic-pae #53-Ubuntu SMP Thu Nov 15 11:11:12 UTC 2012 i686 i686 i386 GNU/Linux
Cheers,
Dolf.
I am unable to send braces {} and brackets [] using type:
Calling
xdotool type --window 73400333 'a[]b{}'
inside an xterm, gives "ab" in another xterm with the above id.
xdotool type 'a[]b{}'
yields "aeib.p" in the very same window.
I want to select all windows on the current desktop which are NOT named 'Gnome-Pie'
Since extended regexps aren't supported (eg 'xdotool search --desktop 1 '(?!Gnome.Pie)' just gives an error about 'failed to compile regex').. I considered that the most sensible way to make this kind of matching a possibility,
would be to have a --subtract option.
This would store the old windowstack, and once the search results are in, set the final windowstack to contain only the windows which are in the old stack and not in the new one..
(Originally reported as issue 72 on code.google.com)
$ xdotool search --onlyvisible Chrome get_desktop_viewport %1
Defaulting to search window name, class, and classname
Expected 2 items for _NET_DESKTOP_VIEWPORT, got 12
-452067296 32767
$ xprop -root | grep _NET_DESKTOP_VIEWPORT
_NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
Some of the newer shells (unity, some KDE plasma set ups) can place the menu bar for all programs at one place on the screen like the Mac does.
If you do a movewindow --relative with y=0 or y=y (e.g. movewindow --relative -- -100 0) you will observe that the window moves down slightly by the height of the menu bar.
I left the same issue on the google code tracker because I didn't know which was active.
I came across this post that windowclose patch was integrated, but the command still isn't available--at least in my version of xdotool.
$ xdotool -v
xdotool version 3.20130505.1
While fixing bugs found with Clang static analyzer, I encountered the cmd_behave_screen_edge
function.
Issues that make me avoid fixing this code:
printf
debugging printsThe actual issue was a "Dead assignment" warning, in cmd_behave_screen_edge.c:295. Variable trigger
is set to False
every time the loop is executed.
Another question: why is need_new_context = True
written on line 294? context_execute
does not seem to free tmpcontext. Perhaps the tmpcontext = calloc(..)
part should be moved outside the while loop and the copy be made unconditional? I don't know... I am not using this option and I am not going to fix it either.
Hi, maybe it's just that I don't understand something, but this seems to be quite broken.
Here is a script:
echo KP_Enter
xdotool key KP_Enter
echo "
"
echo KP_0
xdotool key KP_0
echo "
"
echo KP_1
xdotool key KP_1
echo "
"
echo KP_2
xdotool key KP_2
echo "
"
echo KP_3
xdotool key KP_3
echo "
"
echo KP_4
xdotool key KP_4
echo "
"
echo KP_5
xdotool key KP_5
echo "
"
echo KP_6
xdotool key KP_6
echo "
"
echo KP_7
xdotool key KP_7
echo "
"
echo KP_8
xdotool key KP_8
echo "
"
echo KP_9
xdotool key KP_9
echo "
"
echo KP_Insert
xdotool key KP_Insert
echo "
"
echo KP_Delete
xdotool key KP_Delete
echo "
"
echo KP_Add
xdotool key KP_Add
echo "
"
echo KP_Subtract
xdotool key KP_Subtract
echo "
"
echo KP_Divide
xdotool key KP_Divide
echo "
"
echo KP_Multiply
xdotool key KP_Multiply
echo "
"
echo KP_Home
xdotool key KP_Home
echo "
"
echo KP_Up
xdotool key KP_Up
echo "
"
echo KP_Prior
xdotool key KP_Prior
echo "
"
echo KP_Left
xdotool key KP_Left
echo "
"
echo KP_Tab
xdotool key KP_Tab
echo "
"
echo KP_Right
xdotool key KP_Right
echo "
"
echo KP_End
xdotool key KP_End
echo "
"
echo KP_Down
xdotool key KP_Down
echo "
"
echo KP_Next
xdotool key KP_Next
If I run the script with Num Lock on, this is what happens:
[root@archie ~]# sh /tmp/test_xdotool.sh
KP_Enter
KP_0
^[[2$
KP_1
^[[8$
KP_2
^[[b
KP_3
^[[6$
KP_4
^[[d
KP_5
KP_6
^[[c
KP_7
^[[7$
KP_8
^[[a
KP_9
^[[5$
KP_Insert
0
KP_Delete
.
KP_Add
+
KP_Subtract
-
KP_Divide
/
KP_Multiply
*
KP_Home
7
KP_Up
8
KP_Prior
9
KP_Left
4
KP_Tab
KP_Right
6
KP_End
1
KP_Down
2
KP_Next
3[root@archie ~]#
[root@archie ~]# 0.+-/*78946123
If I run the script with Num Lock off, this is what happens:
[root@archie ~]# sh /tmp/test_xdotool.sh
KP_Enter
KP_0
^[Op
KP_1
^[Oq
KP_2
^[Or
KP_3
^[Os
KP_4
^[Ot
KP_5
^[Ou
KP_6
^[Ov
KP_7
^[Ow
KP_8
^[Ox
KP_9
^[Oy
KP_Insert
^[[2~
KP_Delete
^[[3~
KP_Add
+
KP_Subtract
-
KP_Divide
/
KP_Multiply
*
KP_Home
^[[7~
KP_Up
^[[A
KP_Prior
^[[5~
KP_Left
^[[D
KP_Tab
KP_Right
^[[C
KP_End
^[[8~
KP_Down
^[[B
KP_Next
^[[6~[root@archie ~]#
(i-search)`': ^[[3~+-/*
Hey. I'm no X11 guru, so this is possibly an issue with Xtightvnc. Is it?
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bd7e8f in _xdo_populate_charcode_map (xdo=0x61ba80) at xdo.c:1304
$1 = (XkbDescPtr) 0x0
$2 = 8
(gdb) where
#0 0x00007ffff7bd7e8f in _xdo_populate_charcode_map (xdo=0x61ba80) at xdo.c:1304
#1 xdo_new_with_opened_display (xdpy=, display=, close_display_when_freed=close_display_when_freed@entry=1) at xdo.c:133
#2 0x00007ffff7bd80a1 in xdo_new (display_name=, display_name@entry=0x0) at xdo.c:95
#3 0x000000000040319e in args_main (argc=argc@entry=4, argv=argv@entry=0x7fffffffe668) at xdotool.c:493
#4 0x0000000000403724 in xdotool_main (argc=4, argv=0x7fffffffe668) at xdotool.c:316
So we got an unhandled NULL coming from XkbGetMap() :-(
Xvnc version TightVNC-1.3.9
Linux xxxx 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
xdotool/libxd built minutes ago from HEAD.
--onlyvisible
limits to the current desktop, and --maxdepth
can't guarantee elimination of only non-visible windows.
Hi, I want to run a command xdotool key enter
, but I get error like this:
(symbol) No such key name 'enter'. Ignoring it.
So. I would like to know whether there is an "enter" key?
https://github.com/soliton4/nodeMirror/releases/tag/0.1.18
a x11 terminal forwarded to the web ;)
xdo_get_active_modifiers()
returns a pointer to a struct instead of returning the values in arguments like all similar functions in the library does.
By changing this there would be no need for the xdo_active_mods_t
struct either.
Using xdotool to insert charackters like äöü is really slow.
Inserting a
$ time xdotool type "a"; time xdotool type "ä"
a
real 0m0.014s
user 0m0.001s
sys 0m0.002s
ä
real 0m0.072s
user 0m0.002s
sys 0m0.002s
A more extreme example of inserting 10 characters at a time:
$ time xdotool type "aaaaaaaaaa"; time xdotool type "ääääääääääää"
aaaaaaaaaa
real 0m0.281s
user 0m0.003s
sys 0m0.002s
ääääääääää
real 0m2.060s
user 0m0.003s
sys 0m0.006s
It does not take much cpu though as the user and sys time are really low. At least not the xdotool process. It also does freeze X for that time: no screen updates besides mouse movements are rendered.
Using "time xdotool key adiaeresis" can also used to produce the same effects.
I pulled an older version and it worked as intended.
What happens with older versions:
$ xdotool getwindowfocus key --clearmodifiers ctrl+v ctrl+v Return
^V
xev reports:
$ xdotool key --window 0x2e00001 --clearmodifiers ctrl+v
KeyPress event, serial 198, synthetic YES, window 0x2e00001,
root 0x0, subw 0x0, time 0, (1,1), root:(1,1),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 198, synthetic YES, window 0x2e00001,
root 0x0, subw 0x0, time 0, (1,1), root:(1,1),
state 0x4, keycode 55 (keysym 0x76, v), same_screen YES,
XLookupString gives 1 bytes: (16) ""
XmbLookupString gives 1 bytes: (16) ""
XFilterEvent returns: False
KeyRelease event, serial 198, synthetic YES, window 0x2e00001,
root 0x6b66b540, subw 0x0, time 0, (1,1), root:(1,1),
state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 198, synthetic YES, window 0x2e00001,
root 0x6b66b540, subw 0x0, time 0, (1,1), root:(1,1),
state 0x0, keycode 55 (keysym 0x76, v), same_screen YES,
XLookupString gives 1 bytes: (76) "v"
XFilterEvent returns: False
Newer versions:
$ /usr/bin/xdotool getwindowfocus key --clearmodifiers ctrl+v ctrl+v Return
vv
xev reports:
$ /usr/bin/xdotool key --window 0x2e00001 --clearmodifiers ctrl+v
KeyPress event, serial 198, synthetic YES, window 0x2e00001,
root 0xae8de07, subw 0x0, time 0, (1,1), root:(1,1),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 198, synthetic YES, window 0x2e00001,
root 0xae8de07, subw 0x0, time 0, (1,1), root:(1,1),
state 0x0, keycode 55 (keysym 0x76, v), same_screen YES,
XLookupString gives 1 bytes: (76) "v"
XmbLookupString gives 1 bytes: (76) "v"
XFilterEvent returns: False
KeyRelease event, serial 198, synthetic YES, window 0x2e00001,
root 0xa6dccf4, subw 0x0, time 0, (1,1), root:(1,1),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 198, synthetic YES, window 0x2e00001,
root 0xa6dccf4, subw 0x0, time 0, (1,1), root:(1,1),
state 0x0, keycode 55 (keysym 0x76, v), same_screen YES,
XLookupString gives 1 bytes: (76) "v"
XFilterEvent returns: False
The last version that exhibits the correct behaviour seems to be edbbb7a.
Other functions dealing with screens in libxdo uses only the integer index of screens while xdo_get_window_location
returns X11's Screen
structure, and only if the caller wants it. This breaks the convention used otherwise in the library.
There should be git tags for previous releases, so people can do stuff like
git log v2.20110530.1..HEAD
to see what they're getting by switching to using a git checkout.
I already figured out that v2.20110530.1
corresponds to 15835e3 but didn't look at older releases.
(Originally reported as issue 71 on code.google.com)
If I run xdotool selectwindow
and click on the currently focussed urxvt window, it returns 83892796
. However xdotool getwindowfocus
and xdotool getactivewindow
both return 81788939
, as does xdotool search --class urxvt
.
If I suffix these commands with getwindowname
then the first one returns a blank line and the others all return 0:6:pac - "adam@pacific"
.
This is on openSUSE 12.2 with the latest version from github. If I use the 20110530 release, it's the same except that xdotool selectwindow
also returns the following:
findclient: 83892797
findclient: 83892796
xdotool crashes with a segmentation fault if the display is not reachable.
How to reproduce
unset DISPLAY
xdotool getmouselocation
I frequently find myself wanting to have search
look over the stack instead of the full window list.
Here's an example:
xdotool search --class google-chrome \
search --stack --name github \
set_desktop_for_window %@ 2
I ZIP'd the latest code, and modified the makefile:
DEFAULT_LIBS=-L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -lX11 -lXtst -lXinerama
since Xtst is under /usr/lib
/usr/lib/libXtst.so.6
/usr/lib/libXtst.so.6.1.0
/usr/lib64/libXtst.so.6
/usr/lib64/libXtst.so.6.1.0
I tried to compile, but get:
pod2man -c "" -r "" xdotool.pod > xdotool.1
sh version.sh --header > xdo_version.h
cc -pipe -O2 -pedantic -Wall -W -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wdisabled-optimization -Wno-missing-field-initializers -g -std=c99 -I/usr/X11R6/include -I/usr/local/include -fPIC -c xdo.c
cc -pipe -O2 -pedantic -Wall -W -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wdisabled-optimization -Wno-missing-field-initializers -g -std=c99 -I/usr/X11R6/include -I/usr/local/include -fPIC -c xdo_search.c
cc -shared -Wl,-soname=libxdo.so.2 xdo.o xdo_search.o -o libxdo.so -lrt -L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -lX11 -lXtst -lXinerama
/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/libX11.so when searching for -lX11
/usr/bin/ld: cannot find -lXtst
collect2: ld returned 1 exit status
make: *** [libxdo.so] Error 1
Any suggestions?
Thanks.
Lester
P.S.:
I also could not compile on Ubuntu 12.04:
pod2man -c "" -r "" xdotool.pod > xdotool.1
sh version.sh --header > xdo_version.h
cc -pipe -O2 -pedantic -Wall -W -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wdisabled-optimization -Wno-missing-field-initializers -g -std=c99 -I/usr/X11R6/include -I/usr/local/include -fPIC -c xdo.c
xdo.c:29:34: fatal error: X11/extensions/XTest.h: No such file or directory
compilation terminated.
make: *** [xdo.o] Error 1
If I'm not missing something, the last released version (xdotool-2.20110530.1) is ancient (from 2011). Is a new release planned and what's stopping it?
Could you add an option to dump the translation table that had been keysym_charmap[]
in xdo_util.h
in an easily machine-readable format?
One of my tools used to rely on downloading it from this repo, but now that the method has changed, my work-around using the old version (from before bbf0e70) will probably become out of sync soon.
Best regards, M.K.
input: xdotool search --pid <program_pid>
output Can't consume 1 args; are only 0 available. This is a bug.
version: xdotool version 2.20110530.1
system: Arch Linux (3.6.8-1-ARCH)
I wanted to use xdotool in a shell-script to wait for X applications to be visible. Therefore I issued a command like this:
xdotool search --onlyvisible --sync --pid 1234
The output was this: Can't consume 1 args; are only 0 available. This is a bug.
I narrowed down the issue to the --pid option, which causes the aforementioned error message.
I have tried to run the tests, but it fails:
Running test_basic.rb
Warning: Tried to connect to session manager, Could not open network socket
Setting up keymap on new server as us
Warning: you should require 'minitest/autorun' instead.
Warning: or add 'gem "minitest"' before 'require "minitest/autorun"'
From:
/usr/lib/ruby/2.1.0/test/unit.rb:1:in `<top (required)>'
test_basic.rb:4:in `<main>'
MiniTest::Unit::TestCase is now Minitest::Test. From /usr/lib/ruby/2.1.0/test/unit/testcase.rb:8:in `<module:Unit>'
/usr/lib/ruby/2.1.0/test/unit.rb:676:in `<class:Runner>': undefined method `_run_suite' for class `Test::Unit::Runner' (NameError)
from /usr/lib/ruby/2.1.0/test/unit.rb:261:in `<module:Unit>'
from /usr/lib/ruby/2.1.0/test/unit.rb:15:in `<module:Test>'
from /usr/lib/ruby/2.1.0/test/unit.rb:7:in `<top (required)>'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from test_basic.rb:4:in `<main>'
make[3]: *** [do-test] Error 1
make[3]: Leaving directory `/home/daniel/Vcs/xdotool/t'
% ruby --version
ruby 2.1.2p95 (2014-05-08) [x86_64-linux-gnu]
What am I missing?
Is my Ruby stack too new? (MiniTest::Unit::TestCase is now Minitest::Test
)
Executing
xdotool search --onlyvisible . behave %@ focus getactivewindow getwindowname
and then focusing a window causes the program to crash:
Defaulting to search window name, class, and classname
*** Error in `xdotool': double free or corruption (out): 0x00007ffd8f26d8a0 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x7198e)[0x7f82fc55f98e]
/usr/lib/libc.so.6(+0x76dee)[0x7f82fc564dee]
/usr/lib/libc.so.6(+0x775cb)[0x7f82fc5655cb]
xdotool[0x402c9a]
xdotool[0x406b85]
xdotool[0x40310b]
xdotool[0x407ed4]
xdotool[0x40310b]
xdotool[0x4033c7]
xdotool[0x4038f4]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7f82fc50e800]
xdotool[0x402b01]
======= Memory map: ========
00400000-0040f000 r-xp 00000000 08:03 275112 /usr/bin/xdotool
0060e000-0060f000 r--p 0000e000 08:03 275112 /usr/bin/xdotool
0060f000-00611000 rw-p 0000f000 08:03 275112 /usr/bin/xdotool
00cdb000-00d5e000 rw-p 00000000 00:00 0 [heap]
7f82fb05f000-7f82fb075000 r-xp 00000000 08:03 269331 /usr/lib/libgcc_s.so.1
7f82fb075000-7f82fb274000 ---p 00016000 08:03 269331 /usr/lib/libgcc_s.so.1
7f82fb274000-7f82fb275000 rw-p 00015000 08:03 269331 /usr/lib/libgcc_s.so.1
7f82fb275000-7f82fb27a000 r-xp 00000000 08:03 269292 /usr/lib/libXdmcp.so.6.0.0
7f82fb27a000-7f82fb479000 ---p 00005000 08:03 269292 /usr/lib/libXdmcp.so.6.0.0
7f82fb479000-7f82fb47a000 r--p 00004000 08:03 269292 /usr/lib/libXdmcp.so.6.0.0
7f82fb47a000-7f82fb47b000 rw-p 00005000 08:03 269292 /usr/lib/libXdmcp.so.6.0.0
7f82fb47b000-7f82fb47d000 r-xp 00000000 08:03 269286 /usr/lib/libXau.so.6.0.0
7f82fb47d000-7f82fb67d000 ---p 00002000 08:03 269286 /usr/lib/libXau.so.6.0.0
7f82fb67d000-7f82fb67e000 r--p 00002000 08:03 269286 /usr/lib/libXau.so.6.0.0
7f82fb67e000-7f82fb67f000 rw-p 00003000 08:03 269286 /usr/lib/libXau.so.6.0.0
7f82fb67f000-7f82fb68e000 r-xp 00000000 08:03 272554 /usr/lib/libXi.so.6.1.0
7f82fb68e000-7f82fb88e000 ---p 0000f000 08:03 272554 /usr/lib/libXi.so.6.1.0
7f82fb88e000-7f82fb88f000 r--p 0000f000 08:03 272554 /usr/lib/libXi.so.6.1.0
7f82fb88f000-7f82fb890000 rw-p 00010000 08:03 272554 /usr/lib/libXi.so.6.1.0
7f82fb890000-7f82fb8a1000 r-xp 00000000 08:03 269295 /usr/lib/libXext.so.6.4.0
7f82fb8a1000-7f82fbaa0000 ---p 00011000 08:03 269295 /usr/lib/libXext.so.6.4.0
7f82fbaa0000-7f82fbaa1000 r--p 00010000 08:03 269295 /usr/lib/libXext.so.6.4.0
7f82fbaa1000-7f82fbaa2000 rw-p 00011000 08:03 269295 /usr/lib/libXext.so.6.4.0
7f82fbaa2000-7f82fbaa4000 r-xp 00000000 08:03 268241 /usr/lib/libdl-2.21.so
7f82fbaa4000-7f82fbca4000 ---p 00002000 08:03 268241 /usr/lib/libdl-2.21.so
7f82fbca4000-7f82fbca5000 r--p 00002000 08:03 268241 /usr/lib/libdl-2.21.so
7f82fbca5000-7f82fbca6000 rw-p 00003000 08:03 268241 /usr/lib/libdl-2.21.so
7f82fbca6000-7f82fbcc7000 r-xp 00000000 08:03 270129 /usr/lib/libxcb.so.1.1.0
7f82fbcc7000-7f82fbec6000 ---p 00021000 08:03 270129 /usr/lib/libxcb.so.1.1.0
7f82fbec6000-7f82fbec7000 r--p 00020000 08:03 270129 /usr/lib/libxcb.so.1.1.0
7f82fbec7000-7f82fbec8000 rw-p 00021000 08:03 270129 /usr/lib/libxcb.so.1.1.0
7f82fbec8000-7f82fbee0000 r-xp 00000000 08:03 268232 /usr/lib/libpthread-2.21.so
7f82fbee0000-7f82fc0df000 ---p 00018000 08:03 268232 /usr/lib/libpthread-2.21.so
7f82fc0df000-7f82fc0e0000 r--p 00017000 08:03 268232 /usr/lib/libpthread-2.21.so
7f82fc0e0000-7f82fc0e1000 rw-p 00018000 08:03 268232 /usr/lib/libpthread-2.21.so
7f82fc0e1000-7f82fc0e5000 rw-p 00000000 00:00 0
7f82fc0e5000-7f82fc0e7000 r-xp 00000000 08:03 272557 /usr/lib/libXinerama.so.1.0.0
7f82fc0e7000-7f82fc2e6000 ---p 00002000 08:03 272557 /usr/lib/libXinerama.so.1.0.0
7f82fc2e6000-7f82fc2e7000 r--p 00001000 08:03 272557 /usr/lib/libXinerama.so.1.0.0
7f82fc2e7000-7f82fc2e8000 rw-p 00002000 08:03 272557 /usr/lib/libXinerama.so.1.0.0
7f82fc2e8000-7f82fc2ed000 r-xp 00000000 08:03 272566 /usr/lib/libXtst.so.6.1.0
7f82fc2ed000-7f82fc4ec000 ---p 00005000 08:03 272566 /usr/lib/libXtst.so.6.1.0
7f82fc4ec000-7f82fc4ed000 r--p 00004000 08:03 272566 /usr/lib/libXtst.so.6.1.0
7f82fc4ed000-7f82fc4ee000 rw-p 00005000 08:03 272566 /usr/lib/libXtst.so.6.1.0
7f82fc4ee000-7f82fc687000 r-xp 00000000 08:03 268212 /usr/lib/libc-2.21.so
7f82fc687000-7f82fc887000 ---p 00199000 08:03 268212 /usr/lib/libc-2.21.so
7f82fc887000-7f82fc88b000 r--p 00199000 08:03 268212 /usr/lib/libc-2.21.so
7f82fc88b000-7f82fc88d000 rw-p 0019d000 08:03 268212 /usr/lib/libc-2.21.so
7f82fc88d000-7f82fc891000 rw-p 00000000 00:00 0
7f82fc891000-7f82fc9cc000 r-xp 00000000 08:03 263643 /usr/lib/libX11.so.6.3.0
7f82fc9cc000-7f82fcbcb000 ---p 0013b000 08:03 263643 /usr/lib/libX11.so.6.3.0
7f82fcbcb000-7f82fcbcd000 r--p 0013a000 08:03 263643 /usr/lib/libX11.so.6.3.0
7f82fcbcd000-7f82fcbd2000 rw-p 0013c000 08:03 263643 /usr/lib/libX11.so.6.3.0
7f82fcbd2000-7f82fcbd3000 rw-p 00000000 00:00 0
7f82fcbd3000-7f82fcbda000 r-xp 00000000 08:03 268233 /usr/lib/librt-2.21.so
7f82fcbda000-7f82fcdd9000 ---p 00007000 08:03 268233 /usr/lib/librt-2.21.so
7f82fcdd9000-7f82fcdda000 r--p 00006000 08:03 268233 /usr/lib/librt-2.21.so
7f82fcdda000-7f82fcddb000 rw-p 00007000 08:03 268233 /usr/lib/librt-2.21.so
7f82fcddb000-7f82fcede000 r-xp 00000000 08:03 268258 /usr/lib/libm-2.21.so
7f82fcede000-7f82fd0de000 ---p 00103000 08:03 268258 /usr/lib/libm-2.21.so
7f82fd0de000-7f82fd0df000 r--p 00103000 08:03 268258 /usr/lib/libm-2.21.so
7f82fd0df000-7f82fd0e0000 rw-p 00104000 08:03 268258 /usr/lib/libm-2.21.so
7f82fd0e0000-7f82fd0eb000 r-xp 00000000 08:03 275114 /usr/lib/libxdo.so.2
7f82fd0eb000-7f82fd2ea000 ---p 0000b000 08:03 275114 /usr/lib/libxdo.so.2
7f82fd2ea000-7f82fd2eb000 r--p 0000a000 08:03 275114 /usr/lib/libxdo.so.2
7f82fd2eb000-7f82fd2ec000 rw-p 0000b000 08:03 275114 /usr/lib/libxdo.so.2
7f82fd2ec000-7f82fd30e000 r-xp 00000000 08:03 268254 /usr/lib/ld-2.21.so
7f82fd4d6000-7f82fd4de000 rw-p 00000000 00:00 0
7f82fd50c000-7f82fd50d000 rw-p 00000000 00:00 0
7f82fd50d000-7f82fd50e000 r--p 00021000 08:03 268254 /usr/lib/ld-2.21.so
7f82fd50e000-7f82fd50f000 rw-p 00022000 08:03 268254 /usr/lib/ld-2.21.so
7f82fd50f000-7f82fd510000 rw-p 00000000 00:00 0
7ffd8f24e000-7ffd8f26f000 rw-p 00000000 00:00 0 [stack]
7ffd8f308000-7ffd8f30a000 r--p 00000000 00:00 0 [vvar]
7ffd8f30a000-7ffd8f30c000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)
hi, im trying to use libxdo for a private project.
i'm doing two easy calls to xdo_new and xdo_move_mouse_relative. but when i tried to build my file using this command:
g++ LinuxTest.cpp -lXtst -lX11 -lxdo
but i'm getting:
LinuxTest.cpp:(.text+0x34): undefined reference to `xdo_new(char const*)'
LinuxTest.cpp:(.text+0x54): undefined reference to `xdo_move_mouse_relative(xdo const*, int, int)'
xdo.h is located at "/usr/local/include/" and libxdo.so is in "/usr/lib/"
It would be nice if the window stack could be used with the exec command, to pass the matched window id(s) on to other programs. Right now I have to do something like this:
windowid=$(xdotool search --sync --name whatever getwindowid)
wmctrl -ir $windowid ...
It would be nifty to be able to do it like this, though:
xdotool search --sync --name whatever exec --sync wmctrl -ir %1 ...
esp. if it then supported %@ for running the command once for each window in the stack.
When doing a type with the --file argument, some characters are replaced. In my test case, _ is replaced by ?, ' by / and + by -.
windowsize accepts percentages of the screen--it would be good if windowmove did too, so I could e.g. set up windows in the four quadrants easily.
Note that the formula should make placements of, for example, 33.33% or 50% width and similar X position work out to tile the screen with no overlap.
I think the correct formula is simply to round down and make no adjustment (the default)
The library function xdo_active_keys_to_keycode
is redundant and has a misleading name since it only returns the modifiers currently active, not any key that is being pressed.
wmctrl can list all visible windows across all desktops in one go, along with their window name, class, window id, pid, and desktop number:
$ wmctrl -lpx
0x01800003 -1 5733 xfdesktop.Xfdesktop pacific Desktop
0x04200003 -1 6104 gkrellm.Gkrellm pacific gkrellm
0x0520000b -1 6186 urxvt.URxvt pacific watchlogs-system
0x01600004 -1 5732 xfce4-panel.Xfce4-panel pacific xfce4-panel
0x05e00032 5 23702 skype.Skype pacific Skype
0x01200047 0 26835 emacs.Emacs pacific focus-emacs-frame
0x0500000b 1 4759 urxvt-256color.URxvt pacific adam@pacific
This is very convenient for scripting.
What steps will reproduce the problem?
Having this in .xbindkeysrc:
"sleep 0.1 && xdotool type --clearmodifiers --args 1 123123 && xdotool key --clearmodifiers Tab && xdotool type --clearmodifiers --args 1 123123"
m:0x40 + c:10
Mod4 + 1
(That's for filling 2 textboxes in a browser)
push win(mod4)+1
sometimes the mod4 key is "stuck"
that means pressing e.g. TAB acts like win+TAB
What version of the product are you using? On what operating system?
20110530.1-6
xubuntu 13.04
"xdotool sleep 0.2 type --clearmodifiers test123"
m:0x14 + c:49
Control+Mod2 + grave
I'm experiencing this issue too. I think the problem is that I hit the macro by first pressing control then a moment later pressing grave, and to release the key combination I let go of everything at once. So, the macro thinks it needs to put the modifier back into the "down" state, even though it has already been released.
To put it more succinctly, I suspect that the problem is that clearmodifiers doesn't keep track of changes to key state since the modifiers were saved.
On my 3 monitor system running openbox, getdisplaygeometry and getmouselocation always return data for screen 0, even when the active screen is not screen 0.
When using the "xdotool key", some characters show incorrectly.
Odiaeresis, Udiaeresis, Gbreve and Scedilla show up as ö, ü, ğ and ş instead of Ö, Ü, Ğ and Ş.
Not a big problem, it can be worked around by using "dead_diaeresis O", "dead_diaeresis U", "dead_breve G" and "dead_cedilla S", but I thought you'd like to know it.
When I do
xdotool type "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
I get
ABCDEFGHIJKLMNOP�RSTUV�XYZ
instead of
ABCDEFGHIJKLMNOPQRSTUVWXYZ
I have an azerty keyboard and I'm using xdotool
on a ubuntu 14.04 64bit.
When I switch my keymap to qwerty I get the expected result. (ABCDEFGHIJKLMNOPQRSTUVWXYZ
)
Let me know if you need more information about my machine / settings / ...
Thank you for this awesome tool ! :)
Hi,
I'm redirected from this ticket:
https://sourceforge.net/p/keepass/bugs/1123/
Is it the good place?
Regards,
Sylvain.
% xdotool type --clearmodifiers --delay 0 '////'
qqqq
My xmodmap -pke: https://paste.xinu.at/Nq9Jz/sh
$ xmodmap -pm
xmodmap: up to 4 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock ISO_Next_Group (0x42)
control Control_L (0x25), Control_R (0x69)
mod1 Alt_L (0x40), Alt_R (0x6c), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
; xdotool search --class xterm behave %@ focus getactivewindow
44040207
*** Error in `xdotool': double free or corruption (out): 0x00007fff40df9700 ***
zsh: abort xdotool search --class xterm behave %@ focus getactivewindow
*
I presume this happens because search
finds the same window that getactivewindow
finds.
As per my post from October 2012, the xdotool project is currently in a confusing state for newcomers where it's hard to find out what the authoritative location for code and issue tracking is. It would make a big difference if you took a few minutes to board up the broken windows, e.g.:
Thanks!
I am getting this error during make
./libxdo.so: undefined reference to `xkb_keysym_to_utf32'
Here is a full log.
Both libxkbcommon-dev and libxkbcommon-x11-dev are installed.
xdo_getwinprop
breaks the naming convention and should probably be named something like xdo_window_get_prop
, judging by the name of other functions. There are also other functions that probably should be renamed. The convention that probably would be simplest to conform to would be xdo_window_verb_[...]
for all functions that takes a Window
argument as the second argument and xdo_verb_[...]
for all other functions. A, imho, better convention would be xdo_verb_[things being acted on]_[...]
, so for example xdo_move_mouse
, xdo_type_window
(maybe rather xdo_enter_text_window
), xdo_set_prop_window
, and so on.
Hi,
if I start the program with ' xdotool - ' , the program does not execute the commands that I put in following lines. I'm missing something or this feature is broken?
Stefano
Hi!
I'm newbie at using xdotool and I was trying to do the following in my Centos 6.5, xdotool (xdotool-2.20110530.1-7.el6.x86_64), kernel 2.6.32, xorg-x11-server-Xorg-1.13.0-23.1.el6.centos.x86_64:
I opened a PuTTY terminal and execute an xterm to open a new terminal xterm &
Then I get the ID of this new terminal with xdotool search --name "myterminal"
Finally I execute xdotool key --window "ID" 2
to send a 2 to the terminal but nothing happens.
I checked also the ID of the terminal with xwinfo
I used it with windowfocus and windowsactivate, but I'd like to avoid it if possible. Also, is there any possibility of speeding the process, everytime that I send an keystroke, the execution of the command xdotool key 2
line is quite slow for my purposes.
I want to open as several terminals and then send them a chain of keystroke as fast as possible with some delay between keystrokes.
I also have another issue, having my little script xdotool
windowfocus $1
type "Hi, how are you"
key 7
It doesn't press number 7 after typing Hi, how are you
, it types Hi, how are youkey 7
. How can I solve it?
Thank you very much, sorry but I'm a newbie!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.