Unable to use some chars in hotkeys

[pixelastic]

The following code :
:c_:$>::$this->
:c_:$ù::log(
(Replace $> with $this-> and $ù with log( )

Displays the following error in shell when I try to execute the shortcuts
Warning, could not look up key: <
Warning, could not look up key: Ù

I should note that I am using Ubuntu 10.04 with an azerty keyboard. I guess my Ubuntu is still in en_US but there may be parts of fr_FR somewhere as I bought it from Dell France, if that can help you.

Also, it seems that most of the "exotic" chars on my keyboard (I mean, anything apart from [a-zA-Z0-9]) triggers some kind of look up error in the shell.

[TobiasKappe]

Hey there,

Short answer: unfortunately, there will be no solution for both this issue and issue #33 on a short term.

Long answer: we're in a bit of a pickle with regard to how to work around this issue. Currently, we capture keyboard output by interfacing with the C-level XLib API. The upside of this approach is that we can capture input for indeed any application - be it written in Qt, GTK or even plain old Motif. It also allows for very direct access into the graphical server's primitives, such as which keys are being held down.

The downside, however, is that we only which keys are pressed, not what they mean. Currently, the key-to-meaning mapping is done statically for QWERTY-like keyboards only. Scaling this approach to multiple keyboard layouts would mean two things. First, we have to detect which keyboard is set by the user. This is not all that hard, it would probably involve reading a configuration file somewhere. Bear in mind that it may become more complicated if the user can have a different keyboard layout per window (as some distributions allow).

The second reason this is not feasible is that we would have to ship a key-to-meaning mapping for every conceivable keyboard - or at least a decent subset of them - with IronAHK. As it IA is meant to be used to produce stand-alone executables, we can not put them in some common folder and be done with it. Every executable would have to carry these mappings.

A better approach would be to abandon the X-interaction code and go for something younger, newer. By this I mean the at-spi accessiblity interface. At-spi is actually meant to facilitate users with some kind of physical impairment (such as blindness or paralysis) to still use a computer. We can, however, 'abuse' it to listen in to windows and even send fake key presses to them. One downside of this approach is that it limits us to listening/manipulating windows that are available to at-spi. To the best of my knowledge, these programs currently include those written using Qt and GTK - still a majority of the graphical programs.

A minor caveat is that the user would have to have enabled at-spi to be launched upon login. This could be worked around by automatically enabling/launching at-spi when a script is started.

The reason that we cannot switch to this approach on a short term is a bitter one. Currently, the most widely version of at-spi is one that uses CORBA and Bonobo for inter-process interaction. As you might be aware, Bonobo is due to be abandoned in Gnome 3. Additionally, CORBA is a major pain in the back to implement (properly) and C bindings for at-spi are somewhat lacking to bind to, next to introducing another dependency.

There is, however, some hope: Gnome 3 will ship with at-spi2, a shiny new version which uses D-Bus for inter-program communication. D-Bus is very easy for our C#-implementation to talk over. On the other hand, it will take some time before Gnome 3 has fully penetrated into the market, and maybe even longer for us to write a proper implementation of the key-listening and key-sending code over at-spi2.

So that's how it is, we basically have to wait for at-spi2 to come along and hope that it fully satisfies our needs. My apologies for the late reply and the lack of solution at the moment. Should you have a better idea, we would be very eager to hear from you. Any contributions to the code are, naturally, always welcome.

--Tobias

[pixelastic]

Thanks a lot for you answer. I indeed thought something about non-qwerty keyboards was interfering with my scripts, and you proved me right.

That may be a silling question, but can't I rewrite my scripts to use the expected keys instead of the one displayed on my keyboard. I mean, if when I press a A, ironAHK understands a Q, can't I rewrite my scripts to use Q everytime I mean A ?
This means, manually doing the key pressed => key signification translation myself while writing my script.

If such a workaround is possible, is there an easy way for me to get which key is transmitted to ironAHK on each key press ?

[TobiasKappe]

Sure you could work around it. You could probably wager a good guess at the translations from the current source code. But I would strongly advise against doing that, mainly because it is bad practice (you're compensating incomplete code with bad code). Also, if ever we manage to properly implement this your script will break horribly (or we'll have to write more glue code...)

[madewokherd]

I don't think at-spi2 will solve this problem. The events we can get from it (http://git.gnome.org/browse/at-spi2-core/tree/idl/device.didl) do not appear to have any more information than an X keyboard event, i.e. they tell us nothing about what the key means.