Re: accessebility suggestion for Ubuntu 6.06 LiveCD

[Bill Haneman <Bill Haneman Sun COM>]

On Mon, 2006-07-24 at 13:42, Henrik Nilsen Omma wrote:
> Bill Haneman wrote:
> > On Mon, 2006-07-24 at 12:41, Henrik Nilsen Omma wrote:
> >   
> >>  Our plan is to go ahead with the new 
> >> technology and deal with the problems as they arise.
> >>     
> >
> > If by this you mean that you will ship SOK in preference to GOK in
> > Ubuntu, I think you are making a mistake.
> >   
> 
> SOK will be installed by default and GOK will be an installable option.
> 
> I still haven't seen a complete use case with a description of the users 
> needs and an example of where it fails (like specific applications where 
> a problem occurs and the hardware used).

I'll try to follow up in later emails.  There were tons of problems
logged but they were all closed as NOTABUG if I recall correctly.

> Have you tried SOK yet? And specifically you should try running it next 
> to GOK to experience the difference.
> 
> SOK has a few limitations, but also a range of advantages over GOK:
> 
> * More flexible layout - the layout files are quite easy to modify in 
> Inkscape so you can have a range of different layouts. Switching between 
> them is easy.

By default GOK gets the physical keyboard's layout from the xserver and
displays that.  However GOK also has alternate physical layouts that you
can use.  They are XML files and straightforward to customize by editing
the XML.  There was a keyboard editor included with GOK but it has been
unmaintained for some time - however I don't think it would be hard to 

> * Scalable - Just grab the corner and change it to the size you want so 
> you can optimise your screen usage.

You can scale GOK's keyboards this way as well, if you turn off the
"dock" and "fill" options (via either the GOK prefs dialog or via GOK's
own configuration keyboard).

> * Less general clutter. Extra keys (like function keys) appear on a 
> separate keyboard level so they do not take up valuable screen space. 
> The window does not keep changing shape as you navigate the desktop or 
> the keyboard itself. No scary warning boxes.
Making GOK's function keys appear in a separate keyboard would not be
difficult, nor would making GOK's window a fixed size.  However a fixed
size window will limit the options you can present to a user when using
GOK's more advanced features.  If you're using GOK as a more simple
keyboard replacement this is trivial to do.

The "scary warning boxes" are very necessary if the system is
mis-configured.  However they can easily be suppressed/turned off.

> * Works with tablet PCs - because it just uses the core pointer from X. 
> I predict that these devices will increasingly be used as assistive 
> technology.

GOK can use tablet PCs as well, with proper configuration.

> * Non-latin input is more feasible because it has full unicode support 
> (which I guess GOK has as well right?) and the more flexible layout 
> allows you to have 50, 100 or even 200 hundred keys on the screen. Using 
> multiple levels you can acomodate thousands of symbols.

GOK was designed from the outset for non-latin input, full unicode
support, and hundreds of keys in multiple levels.  See for instance the
demo Chinese branching keyboard which functions as an 'input method'...
so this is an area where GOK is ahead.

> * Much simpler codebase, written in python. This makes it easier to fix 
> bugs and add new features. A much smaller install size, which is good 
> for Live CDs.

There have been discussions regarding moving much of GOK to python.  We
invited you to help us when the SOK project was first announced :-(

> * We are adding a flexible macro and script system that lets you attach 
> a simple text-entry macro or a more complicated python script to any key.

Please see above.  I think it's a terrible shame that we seem to be
duplicating effort if not downright competing in this
already-under-resourced space :-(

> * Looks nicer :) You can customize it in an SVG editor with the colours 
> and layout you like.

You can customize GOK's color scheme fully.  And making it look "nicer"
would merely be a matter of changing the implementation of GokButton's
"paint" method.

> * Finally it just runs more smoothly IMO, most likely because of the 
> Cairo rendering.

???  Because GOK uses GTK+ for its rendering it uses Cairo too.

> In my opinion sticking with old technology for too long is a mistake 
> because you loose out on opportunities to innovate.

You seem to have made decisions about "old technology" without
understanding it very well, or taking the designers/developers up on
their previous offers of more information :-(

> We haven't make any attempt get this into Gnome 2.16 as I could see that 
> there would be strong opposition, but I think we can make a good case 
> for Gnome 2.18.

Absolutely not.

- Bill

> - Henrik
> 
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list