Re: accessebility suggestion for Ubuntu 6.06 LiveCD

[Henrik Nilsen Omma <henrik ubuntu com>]

Bill Haneman wrote:
>   
>
> Making GOK's function keys appear in a separate keyboard would not be
> difficult, nor would making GOK's window a fixed size.  
Cool, let's make it an easy-to select option.

> However a fixed
> size window will limit the options you can present to a user when using
> GOK's more advanced features. 
Not really, because you can show the extra layers on part of the fixed 
window or just make bigger buttons. Works nicely in SOK.
>  If you're using GOK as a more simple
> keyboard replacement this is trivial to do.
>   
Trivial is always cool. Let's do it this week.

> There have been discussions regarding moving much of GOK to python.  We
> invited you to help us when the SOK project was first announced :-(
>   
When the SOK project was announced it was too late. I had already 
decided to try a fresh start after trying to get changes implemented in 
GOK months back. Yes I did file bugs, but they all ended up in this kind 
of discussions too. I'm not sure porting GOK to python is a good use of 
resources.
>   
> 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 :-(
>   
It doesn't quite work that way. When I posted the SOK project as a 
Google Summer of Code project I had 12 applicants, which is quite good 
for an AT utility I think. Part of the attraction was making something 
new that would work well on tablets. I doubt that would have happened if 
the gist of the project was to make GOK work less poorly.

The innovation and excitement we are currently generating around 
accessibility in Ubuntu is drawing in a number of new developers and 
testers. By working well with upstreams, core developers and users we 
can make accessibility really mainstream and get some serious momentum 
going.


Yeah, I agree that competing is bad. I don't really want to write bad 
things about GOK (I've done too much of that already), but when you 
simply state that including SOK is 'a mistake' then I feel I at least 
need to list the strong points of SOK for those who may not be familiar 
with it.

> 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.
>   
But the user cannot change it herself without recompiling GOK. With SOK 
you just open the layout SVG file in Inkscape and paint it.
>   
> > * 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.
>   
But not directly which would be faster. I'm not sure what the exact 
technical reason is for why SOK feels more responsive but it does. Have 
you tried them side by side?
>   
> 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 :-(
>   
I tested GOK very thoroughly for my review and I do have some experience 
with on-screen keyboards. I reported the issues I found at that time. I 
felt that I had a good discussion with David at the time and still do. 
The problem is that things didn't actually improve. There are lots of 
"technical reasons" why things cannot be fixed. I don't really feel a 
need to understand that technology very well. If it cannot deliver a 
highly usable application then I want to try a different technology.

Chris and I have worked on SOK for about 3 months now and I think we 
have made huge leaps already. The code is still flexible and non-crufty 
so we can quite easily make changes as we get feedback.
>   
> > 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.
>   
So it seems we differ on this point. Ultimately the users will decide.

- Henrik