How to set focus to another application?

[shaheed]

Hi Gunnar,

First, its worth pointing out that this is still in the "I don't know if this 
is possible" phase (because I haven't yet been able to work out how to 
associate the KeyCode I need to generate for each key). Assuming I get past 
this showstopper...

> That sounds interesting. You might know that we currently don't have an
> on-screen keyboard as part of the kdeaccessibility module. (Of course there
> is Klaviatura in kdenonbeta, but Klaviatura is more a proof-of-concept
> application that demonstrates the use of the QAccessible interfaces. In
> order to do so, Klaviatura depends on a patched Qt.)

Yes, I am aware of the possible application to accessibility interfaces, and I 
would be happy to see Viki used for this. However, since I (a) want to focus 
on my immediate needs, and (b) undestand that major changes in the Qt 
infrastructure for this is awaited, let me try to get the basic problem 
solved, then people can be free to rework additions as required.

FWIW, my immediate need is to be able to display a visual equivalent of 
whatever keyboard you are physically using, but generate kxkb-harmonised 
foreign language layouts (e.g. Bengali).

> I would like to add a few comments:
> 1) From your description I assume that you want to write a simple on-screen
> keyboard. As an extra functionality the keyboard should have the
> possibility to select an other application when it is started and has the
> focus. While this is not a bad idea, I would prefer that the application
> prevents gaining focus in the first place.

Following suggestions from Lubos and base on not being able to make 
setActiveWindow() work, this is indeed the way I am going at the moment. 
However, I am not fully convinced that this is the right way as it makes it 
tricky for the user to do other things with Viki (e.g. change option 
settings)...I think it would be better for it to behave like a full KDE 
application.

> 2) KDE has a feature called "Sticky Keys". This feature is used in order to
> allow key combinations to be pressed sequentially rather than
> simultaneously. (For example you first press "Control" and after that "S"
> in order to save a file.) You might want to rely on this feature in order
> to support key combinations. (Maybe you can offer the user to enable that
> feature when your keyboard starts.)

Interesting - thanks for the hint. This was a problem I had not yet solved :-)

> 3) If (once your keyboard has the basic functionality) you want to add
> extra functionality it might be worth to support other input methods as
> well. (Think of people that can neither handle a keyboard nor a mouse).
>
> 4) In addition to point 3 you might want to provide special "keys" for the
> actions that are possible at the current state of the current application.
> In order to do so, it is best to wait for Qt4.0 and KDE 4.0 as they will
> export their GUI information via the AT-SPI protocol (which is also used by
> GNOME).
>
> Points 3 and 4 are really high-end features. It is OK if you simply drop
> them. If you do not understand what they are about you might risk a look on
> the GNOME On-screen Keyboard (GOK) which is available at http://www.gok.ca/
>
> Is the code of your application available for download somewhere (so that
> others can get an impression about the look-and-feel of your application)?

If you want a look at the current state of the experiment, feel free to grab:

http://www.aozw65.dsl.pipex.com/viki.tgz

Just configure and make it in the usual way. Once it is running, you'll see a 
single toolbar item - click on it, and the cursor will change to a cross-
hair.

Point to another window, and (a) the pointer will move to (10, 10) in the 
selected window, (b) focus should be set to the new window and (c) a key 
event delivered. The code in Xkb::selectTarget() and Xkb::keyEvent() are the 
important ones.

Just as soon as I get the keycode mapping working, I'll stick it in CVS under 
kdenonbeta.

Thanks, Shaheed