1. Introducing GOK...

1.1. project goals/what is GOK?

GOK aims to enable users to control their computer without having to rely on a standard keyboard or mouse. Many individuals have limited voluntary movements and must control the computer using alternative input methods. These input methods may be controlled by actions such as blowing and sipping to activate a pneumatic switch, an eye blink and/or directed gaze with an eye tracking system, head movement, muscle contractions or limb movements.

Using innovative dynamic keyboard strategies, and leveraging Gnome 2's built-in accessibility framework, the GOK will make control more efficient for these users, and enable use of the Gnome 2 desktop for some users who otherwise would have no access to Gnome. With the right hardware support and the GOK these individuals will have full access to applications that support the AT SPI, and therefore, full access to the functionality these applications provide.

For more information on how to build, install, or get involved with the GOK project, please visit http://www.gok.ca/, or contact: David Bolter, University of Toronto

This text is copied from: http://developer.gnome.org/projects/gap/AT/GOK/index.html

1.2. Mailing list

There is a Mailing List devoted to GOK on GNOME's servers. You can subscribe to it at the following page: http://mail.gnome.org/mailman/listinfo/gok-list

2. current issues/projects/topics

2.1. Zero-conf GOK

Currently the biggest headache for GOK installers, distros, users, and testers is configuration. This is largely due to the inherent problems when a 'meta app' like GOK tries to use a pointing device without being the foreground application. (Applications and toolkits typically claim 'ownership' over the core pointer, and pointer grabs can interfere with GOK). GOK deals with this problem by using the XInput extension and trying to ensure that the device being used to operate GOK is not connected to the system core pointer. Unfortunately, the default configuration for all modern systems is for the various mouse-like devices to be multiplexed into the core pointer, since this is usually what the end user wants and needs. De-coupling a head pointer, trackball, or switch device from the core pointer is technically difficult, poorly supported, and otherwise problematic.

The XEvie x server extension was developed to solve a similar issue having to do with the need to snoop on the keyboard and pointer devices without interfering with the normal operation of applications. (The old XTrap extension allowed something similar, but fell out of use and only recently seems to be making a comeback).

Now that XEvie is a standard part of modern xservers (for instance the XOrg server) we propose to have GOK use XEvie (via at-spi-registryd, which currently uses XEvie for its own event notifications when available) to receive core pointer events. In this way we believe we can avoid the classic pointer grab/corepointer issues and make GOK 'just work' with the default XOrg configuration.

2.2. GOK Refactor

GOK's codebase could stand to be refactored; over its history it shows the signs of many separate hands and coding styles. This can make it unpleasant to maintain; also, with the benefit of experience with GOK over the past 5 years, some good places to modularize the code are now apparent. It would be nice, also, to move some of GOK's codebase to a different language - for instance python. This would allow GOK to use an application-specific scripting approach such as that used by Orca, to make it even more effective for end users.

2.3. Keyboard editor revitalization

One of GOK's strengths is its ability to use customized XML-based keyboards, whose buttons can be configured to do all sorts of things (mimic physical keys, launch applications, branch to other keyboards, etc.). GOK's source code base includes a keyboard editor applications, but it has gone unmaintained for a long time. It would make a suitable project for one person to get it running again, so that end-users and/or clinicians/friends could easily craft new GOK keyboards without having to write XML directly.

2.4. XML format documentation

Related to the keyboard editor discussion, it would be nice to document the XML format GOK uses for its keyboards. I seem to recall an effort to write an XML schema for this, but...

2.5. GOK facelift?

GOK's default button style isn't for everyone. And the straight row/column layout, while great for directed scanning (up/down, left/right), doesn't mimic the physical keyboard as well as some would like. It wouldn't be too hard to provide alternate color schemes for GOK (less "garish" to quote one review), or even to provide alternate rendering frontends.

2.6. Accessibility::Selector support for GOK

The Accessibility::Selector interface is designed for agents that offer a set of choices, so that various kinds of clients can help the user indicate their selection. In its current incarnation GOK presents these choices itself as a set of 'buttons', but it could just as well pass them to a voice recognition engine or over a wire to some alternative device such as a mobile phone or remote control. Implementing Accessibility::Selector in GOK would facilitate this.