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 _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
