[Kde-accessibility] dasher

[JP Schnapper-Casteras]

Dear Mr.Tapsell, kde-accessibility,

     Sorry for the major delay in responding, I've been playing catchup
for a while and my laptop broke last week (thankfully, it's back and
fixed now).

     First of all, great work on Dasher in general, I just discovered
it a bit ago.

     Yes, it would be great to look at it for and make it work with
KDE.  Also, regarding the possible expansions that we all regard as
"big projects," what do you think about involving other schools (e.g.,
Stanford, where I am), to help with parts of this?  Are you
collaborating with any other schools at this point?  It seems like the
sort of changes previously discussed on this list would both be very
interesting [senior] projects and be very useful for the respective
projects.

     Is the source code available for download now what we should be
looking at / playing with?  (Jeff, did you see the source code was
available for download now?)

Thanks.

Best,

--JP Schnapper-Casteras






--- Jeff Roush <jeff@mousetool.com> wrote:
> 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
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-accessibility


=====
-
Cell: 206-849-9032
LARS: http://trace.wisc.edu/linux
FDAWG: http://www.speechinfo.org/fdawg

__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute