[Kde-accessibility] dasher

[Jeff Roush]

On Friday 30 August 2002 12:50, Bill Haneman wrote:
> 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.

The copy I downloaded (1.68) is a research prototype that let you save text to 
a file, but had no other way to communicate with other programs.  But when I 
(just now) went back to their site, I saw that they're going to release new 
versions soon, and I bet that'll be added.

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

Yep.  That would definitely be the easiest way to do it.  I was just wondering 
if there might be times when you'd want to construct full sentences and 
phrases before sending them to other applications.  I might be 
overengineering here, but it seems like it might be handy for editing.

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

Although to really be able to edit code well, you might want Dasher to know 
where you've moved the cursor to, so it can adjust its predictive models to 
the context.  

But it looks like the Dasher team are already thinking about editing.  From 
the Dasher FAQ:

Q. How would you use Dasher to <b>edit</b> text?
A. This is a whole extra project to work on. For the moment Dasher is mainly 
intended to be a system for writing something in one shot. In version 2.* 
there is the option to select a piece of text you've written (by highlighting 
it from right to left) and then write a replacement. But we have fancier 
ideas we would like to try eventually.
(end Dasher FAQ quote)

> > 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" :-)

Hey, that is cool.  I'm an ex-Windows programmer, and am still learning my way 
around X; that is definitely a better way to do it.  

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

I'll have to take a look at GOK.  I've been meaning to explore the GNOME 
accessibility API anyway.  Thanks for pointing me to it :-)

Jeff