Hi Francesco, Please see my answers/responses in-line, below.
> ... > I have added the "Improve efficiency of the GNOME desktop for > mouse-only users" to the above mentioned wiki page. In fact, GNOME is > lacking (or did I miss it?) an onscreen keyboard targeted > specifically at people that have no difficulty to move the > mouse/pointer (regardless of whether it is a standard mouse or some > adaptive hardware like a headpointer), but are not able to use a > hardware keyboard. > It may be that OnBoard fits this bill reasonably well. But I'm not familiar enough with the motivations behind OnBoard to say whether it is expressly targeting the population you describe. > For users that have difficulties to use the mouse button, there is > mousetweaks that should fill the gap. Unfortunately, I have not found > any keyboard on linux as efficient as the commercial product that I > am using on the other operating system: > > There is dasher that is reputed to have a good prediction engine; but > it seems to lack the possibilities to control the desktop. > > There is gok, which seems to be rather targeted at users that can not > efficiently use the pointer. It has word completion without word > prediction. The keyboard is not resizable,... > > Should dasher be enhanced, should the composer in gok be enhanced, or > should a new project aimed at the mouse only users be started from > scratch? I don't know. > I think the best place to start is for you to describe the feature(s) you like and use in the commercial product(s), and let that lead a discussion of how best to achieve those results. The more detailed you can be (both in the description of the feature(s), and in describing how they help you and aid efficiency/productivity), the better. > By the way, the GetInvolved page mentions porting gok to python. Why the port? > GOK uses a set of C language bindings to AT-SPI. In part as part of a move away from CORBA dependencies, we have introduced the pyatspi interface, Python bindings that can are designed in part to be layered on top of DBUS. This library is being shared by a number of tools, and if GOK were ported to Python, it could very easily move to pyatspi (in fact, it would be the natural thing to use). Also, Python being a higher-level language than C, numerous programming headaches go away (like memory management). Finally, per-application scripting is very easily accomplished in Python - Orca makes great use of this. There are a number of use cases in which per-application on-screen keyboard behavior would be very useful. > Cheap Head Mice? The adaptive Headpointers that I know of, use > special reference items weird by the user to track his movement. I > wonder whether a simple camera (webcam) working without a reference > item can be accurate enough to use it as headpointer. Does anybody > have any experience with "reference-less" headpointing? > > About writing drivers for headpointers: do you have any headpointers > in mind? Some headpointers (usually the more expensive models) > present themselves as a normal mouse to the computer and consequently > should work with the mouse driver shipped by the operating: this has > the advantage of not requiring a specific driver (and maybe the > disadvantage of not being customizable). > I believe Steve Lee already addressed this question. Let me add that the Inference folks at Cambridge (who brought Dasher to the world) are working on the OpenGazer project (see http://www.inference.phy.cam.ac.uk/opengazer/), which uses a "£50 Logitech QuickCam Pro 4000" to drive eye tracking (with somewhat limited resolution), which in turn can drive Dasher or some other on-screen keyboard. This is work I would very much like to see expanded and refined. > Another point I am wondering about: Am I right when I think that > there is a standard about making the computer accessible for users > that can only use the keyboard!? If it is true, maybe that a standard > for people that can only use the mouse (with and without buttons) > could also be useful. > There is a very fuzzy line between what apps do for accessibility in and of themselves, and what they do via the use of an assistive technology application. For a variety of reasons, on Windows & in GNOME & in KDE, we have drawn that line such that keyboard-only operation is handled by the apps themselves, while mouse-only is done via desktop AT. Of course, "keyboard-only" is only about "full use of keyboard-only". We bring in AT with things like StickyKeys, MouseKeys, etc. On Macintosh, "full use of keyboard-only" requires desktop AT (VoiceOver) to give you all of the functionality you have in Windows & GNOME & in KDE. Which goes to the point that the line is fuzzy in desktop computing. For essentially these historical and "current state of the art" reasons, I think it is best to solve full use by mouse only via add-on (though perhaps built-in to GNOME) AT which accomplishes that task, and utilizes the AT-SPI standard for driving apps where needed (e.g. with the AccessibleSelection, AccessibleAction, AccessibleValue, etc. interfaces). Regards, Peter Korn Accessibility Architect, Sun Microsystems, Inc. _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
