[Kde-accessibility] dasher

[Bill Haneman]

On Fri, 2002-08-30 at 20:20, Jeff Roush wrote:
...

> The first modification would be to have Dasher generate keystrokes.

Doesn't it?  I downloaded it, but didn't read the sources yet.
 
> My experience trying to get KMouseTool to generate mouse events was that the X 
> Windows function XSendEvent was nearly useless (many applications ignore the 
> events it generates), and that you need to use the XTest X extension.  I 
> haven't looked at generating key events yet, though.

XTest isn't too bad really, especially if you are just generating
keystrokes; maybe a days' work.
 
> When I was using Dasher I made a number of mistakes, and often had to back up 
> to correct them; it occured to me that having the option to generate complete 
> sentences and phrases in Dasher before sending the characters in a batch to 
> the target application might make this easier.  This might become a non-issue 
> as the user got better and made fewer mistakes, though.  

Yes, or you could just synthesize BackSpace when in a text-entry
context.

A seeming limitation, for those who needed Dasher for text entry, would
be that Dasher is designed for free-form text, and might have a hard
time with things like "tab tab tab Ctrl-uparrow".  A little tweaking the
logic, maybe allowing a "navigation mode" that changed dasher's
heuristics and prediction tables, would be the ticket.

> One thing about generated events: they will go to the window with the focus.  
> If clicking on a window sets the focus to that window, then you don't want to 
> have to click on the Dasher window to make it send text to another window; 
> and it would be nice to not have to click on it to set any controls.   You 
> could still have a send-completed-sentence button on Dasher, but it would 
> have to either send Dasher into the background before sending the text, or 
> use mouse dwell times to let the user press the button without clicking on 
> it.  

You could also tweak the code so that Dasher rejects attempts by the
window manager to give it input focus; see recent changes to GOK (the
Gnome Onscreen Keyboard, LGPL in GNOME CVS) which do just that. 
Basically you register for the window manager WM_TAKE_FOCUS protocol,
then when the WM sends you the TAKE_FOCUS message you throw it away
instead of calling XSetFocus like a "normal" application "should" :-)

GOK has a dwell mode that works well with pointing devices, BTW.  It
works with KDE but with GNOME2 apps it can scavenge the application's UI
to present menu items, dialog buttons, etc. and also control navigation
and window manager functions.  There's no reason why Dasher couldn't do
the same with GNOME apps, and no reason why KDE apps couldn't expose
their UI "action" information via the same APIs that GNOME uses (other
than, perhaps, some resistance to linking KDE to GNOME libraries and
APIs ;-)

In any case the XTest stuff should be straightforward; for an example,
see /at-spi/registryd/deviceeventcontroller.c for examples, in GNOME CVS
module "at-spi":
http://cvs.gnome.org/bonsai/cvsblame.cgi?file=at-spi/registryd/deviceeventcontroller.c&rev=&root=/cvs/gnome

(BTW that module is some of the ugliest code in the module, my
apologies; the key synthesis is pretty easy, but the key interception
and snooping, in the same module, is a real nightmare).

best regards,

Bill