Google Summer of Code 06 - A Simplified Onscreen Keyboard

[Michal Chruszcz]

I'm sorry I'm a bit late for the discussion, but my final exams are killing 
me.

It seems like on Wednesday 10 May 2006 19:48, Chris Jones typed:
> It should be quite easy  to make a wrapper around the GOK core using
> something like SWIG.  SWIG is a tool for wrapping up C/C++ classes so
> that a scripting language like python can use the code.

Yes, SWIG is a great tool for creating such bindings. After writing an 
interface definition file it automatically generates C code with embedded 
Python interpreter.

> There's a few niggles with GOK and I thought starting from a fresh
> codebase would mean we could avoid them.  Firstly its dependency on
> Sticky Keys, this is irritating if use use a keyboard with GOK as it
> pops up an annoying dialog box.  You might do this on a convertable
> tablet, or perhaps a teacher helping a student with a headmouse.  SOK
> should be designed so it can function both when sticky keys are on and
> off.
>
> GOK needs to disconnect the device that is controlling it from the
> system pointer.  It does this I assume, since it allows you to move
> the mouse using buttons from within GOK.  I don't think this is
> necessary for SOK use case though, since its not a feature we should
> implement if we want to keep SOK simple.
>
> GOK, for me at least is very sluggish.  Hopefully thats in the
> interface code which we would replace.
>
>
> If we were to use the GOK code base we would have to make quite a few
> changes to it, in my opinion.

I don't think reusing any of parts of GOK code is a good idea. In fact I 
believe this is going to bring on us many disadvantages of GOK, which we 
want to avoid. Especially since there are Python bindings to any of 
libraries we need to use and GOK already has got appriopriate code. This 
might look like duplicating the code, but as we want to make SOK _simple_ 
the code should be created with that in mind. This regards to sticky keys 
too, but as Chris already mentioned this is in the interface part of the 
code so we need to change it as well.

Summarizing I don't see any point in reusing GOK code. This *could* save 
some work, but it could not as well. At one point it might emerge that 
creating bindings to existing GOK code is tougher task than creating new 
code.
-- 
Michal Chruszcz -=- Seen at http://1lo.sanok.pl/~troll/gallery/
Meet Jacek: http://photoblog.be/jacek