I am seeing the same issue in interactive mode. I tried portix's suggestion which didn't change this problem.
For a bit I thought the problem came from calculating a keycode from the keysym string in the config file: if two keys are mapped to "Escape" the X11 function still only can give one key code. I worked around this by doing the reverse logic: I scanned through every keycode available on the display and tried matching the keysym against the string in the keycode. This should allow mulitple keys to be bound to the "Escape" key string. This had no effect, though, so I removed that code again.
I tried implementing localization and initializing an X input context (XIC), but this had no effect.
I have another small tool which does register the CapsLock mapped to escape as an actual escape key. The only remaining difference is that the other tool has it's own window, iocane catches events on the root window.
I'll continue to look into this, but I don't see a solution to be likely as iocane will never have it's own input window.
On another note, I've updated the man page, and cleaned up the recent changes. Iocane can even run scripts with an iocane shebang:
#!/usr/bin/iocane
move 0 0
sleep 1 0
button 1
move 40 40
cursor 65
...
@Trilby: I execute iocane in interactive mode with Mod_I in dwm. By "recently", I mean that I only remapped caps to escape a few weeks ago. I just updated iocane to the latest version in AUR and my problem is resolved, though iocane doesn't respond to the remapped-caps_lock-now-escape; I have to hit the genuine escape key to close it.
]]>It seems I was making some substantial changes on the code up on github, but unlike most of my packages this is not a -git PKGBUILD, so the aur package is still at the last "stable" version.
For the purposes of the present issue, I'm still testing with the current stable version and cannot (yet) replicate this problem. But I'll also update the aur package soon which has substantial design and code changes - so further troubleshooting may be best targeted at that after I post it to the aur.
EDIT: I just packaged the updated code as ver 0.4 now in the AUR. Note that the existing man page is no longer completely reliable, but my general versioning scheme is that anything less than 1.0 is not considered complete usually due to missing documentation. The bump to this thread is good reason for me to finally finish the man page and get a proper 1.0 release of this ready. Expect that to come within a week. The main difference in functionality is that the interactive mode is no longer the default. Along with this, I've done away with many functionally overlaping "modes" like script mode. 0.4 runs by default in a script-like mode that reads from stdin. Use `iocane -i` for the interactive (previously default) mode.
]]>Hi Trilby. I have my Caps Lock key remapped to Escape in ~/.xinitrc:
xmodmap -e "clear lock" #disable caps_lock xmodmap -e "keycode 0x42 = Escape" #caps_lock is now escape
Recently, I noticed that executing iocane reverts Caps Lock to its old behavior. Could you have a look at what is causing this?
Have you tried to remap caps with setxkbmap? For me setxkbmap is more reliable than xmodmap. To map caps_lock to escape you can simply execute
setxkbmap -option caps:escape
How do you execute iocane? Do you use it interactively, or do you execute a script or command-line command movement?
You say this happened recently, does that mean you just noticed it, or did it used to work as intended but recently changed? If the latter, how recent? The code hasn't changed in quite a long time, so if it was recent, it'd be due to the interaction with whatever was updated at the time of the change in behavior.
]]>xmodmap -e "clear lock" #disable caps_lock
xmodmap -e "keycode 0x42 = Escape" #caps_lock is now escape
Recently, I noticed that executing iocane reverts Caps Lock to its old behavior. Could you have a look at what is causing this?
]]>If xdotool does better than iocan with gtk3, then there is definitely room to improve iocane. If xdotool also fails some of the time with gtk3 then there may also be a gtk3 issue (phew!).
I'll test out some of these ideas tonight, and can hope for at least some progress on this issue by Saturday morning (US EST).
]]>Mousekeys doesn't have any of its own actual code - it is basically just a configuration for xbindkeys to bind certain keys to actions.
The center keypad button is mapped to "action = PointerButton()". But I grepped through the entire source tree of xbindkeys and every one of it's dependencies (through evdev) to find where this action is defined. I couldn't find it anywhere.
Does anyone know where xbindkeys's actions are defined?
]]>EDIT: I just installed gtkpod (the first gtk3 program I could find) and confirmed this is a problem. I'll start investigating.
EDIT2: I have been browsing the source code of gtk3 .... that is a miserable tangle of nonsense. I also made a very simple gtk3 "hello world" type program (which is larger than my window manager ... why the hell do people like these toolkits?). I have further confirmed that gtk3 programs do not properly receive events sent via XSendEvent. I have no leads yet on how to solve this.
]]>I did just put up a version 0.2 which introduced notable changes. There is now a (limited) man page which describes the various commands that iocane recongizes. Note that the "offset" command is now gone, but has been replaced by "move" which now moves the selected number of pixels. The behavior of the previous move command - to go to specific coordinates - is now acheived by just passing two coordinates with no command.
A colon-separated list of commands can be passed on the command line, or iocane can be run in script mode by passing a single "-" as the first parameter. In script mode iocane will read either from its stdin or from a script file provided as the second parameter.
I have also made it so iocane can respond to any arbitrary mouse button numbers, but these are simply passed on to the X server, so the response depends on the server being able to handle them.
I have also experimented with simulating "drag-like" events, but there doesn't seem to be any practical way of accomplishing this. I can simulate mouse-down and mouse-up events separately, but these are completely useless and tend to be either treated like regular clicks, or just ignored entirely.
Lastly, the keybindings are now all controlled from a rc file (e.g. ~/.iocanerc). A sample rc file with a good set of keybindings is packaged with v0.2.
]]>