[Kde-accessibility] Re: How to set focus to another application?

[Gunnar Schmi Dt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Shaheed,

On Monday 29 September 2003 20:22, shaheed wrote:
> On Monday 29 Sep 2003 1:06 pm, Lubos Lunak wrote:
> >  So, if this is the common case, you already know the answer. If it's
> > not, then please describe it, as there may be different solutions
> > depending on what exactly you want to do.
>
> I am writing a visual keyboard ("viki")  for KDE[1]. Viki is expected to be
> a complete KDE application. When Viki starts and so has focus, the user
> point's'clicks to select a "target" application window such as KWord. The
> user then gets to click on KPushButtons which mimic the real keyboard keys
> but actually deliver events to the target application using XTest's
> XTestFakeKeyEvent().
> [...]

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.)

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.

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.)

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)?

Gunnar Schmi Dt

P.S.:
You might want to join the kdeaccessibility mailing list. It does not have 
much traffic and it is in any case related to your application.
- -- 
Co-maintainer of the KDE Accessibility Project
Maintainer of the kdeaccessibility package
http://accessibility.kde.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/fYvisxZ93p+gHn4RAkvwAJ9m3OyH3u9moCwqRFEH62QOvvqojgCcD8SG
aNdGXMCSRJwxMo/pX0zjGD8=
=IfsM
-----END PGP SIGNATURE-----