Google Summer of Code 06 - A Simplified Onscreen Keyboard
Chris Jones
cej105 at soton.ac.uk
Thu May 11 11:26:39 BST 2006
Using xlib in the program would make porting to other platforms
difficult. It may be worth using GTK as a layer of abstraction even
if the actual keyboard is rendered in cairo. It is possible to write
widgets in cairo to be used on top of GTK, as shown in this paper:
http://webcvs.freedesktop.org/*checkout*/cairo/papers/gtkcairo_guadec04/gtkcairo_guadec04.pdf?rev=1.1
After quickly diving into the GOK source I notice that it uses xlib
for the actual output of characters to other windows, I assume this is
because GTK does not provide the necessary abstraction for this
function.
Using GTK for everything we can would give us two advantages. Firstly
it would make porting easier, GTK might provide this function at a
later date. Alternative output code could be written for each
platform, this would be much easier than rewriting all the user event
handling code for every platform.
GTK is also a far easier API than xlib, also the Python bindings are
in wide use and well documented. I can't comment on the xlib bindings
if they exist.
Another thing I notice from the GOK source code, and I may be wrong,
but there seems to be no sharp abstraction between the AT-SPI code and
GOK's complex middle layer.
Since we already have the pyspi bindings it might be better to just
use them rather than create our own on top of GOK's AT-SPI handling
code.
Chris Jones
On 11/05/06, Reset Reboot <reset.reboot at gmail.com> wrote:
> El mié, 10-05-2006 a las 17:08 +0100, Henrik Nilsen Omma escribió:
> > I'm interested in brainstorming a bit more about the C/C++ core with a
> > python wrapper approach. If this is indeed workable (my knowledge of
> > python is limited, so I don't know how C extensions are handled), it
> > might also save some work because the AT-SPI code could then be fished
> > out from GOK.
> >
> > AFAICT, the parts of GOK that talk to AT-SPI work just fine, and the
> > problems are in the user interface, which we would in any case replace.
> >
>
> Well, the design proposed from Jack looks good, but I think that it is
> only useful if we reuse those parts of GOK that talk to AT-SPI. The
> "need for speed" it's not critical in this application, and Python
> responds well and fast to the keypresses (just take a look around some
> of the python games out there).
>
> If we take this approach we should make clear which parts will be our
> "core" and which ones will be implemented in Python. If we use a X
> library for Python, we could handle the keys and messages from the X
> server without reinventing the wheel and having that already implemented
> in C.
>
> Again, the Cairo option leaves us with a higher level API than X lib for
> drawing, it's mature in Python and allows to do more graphic work easily
> and it can be used apart from GTK, which allows to get
> desktop-independancy. Also, Cairo is very scalable so it could work from
> an XGL server to a small PDA with much less work. The only drawback it's
> that we should stick to X lib for key management, but I think that Cairo
> is more programmer friendly for graphics than X Lib.
>
> As you can see, with those libs and the work made from the folks of GOK
> (an adding to it), we have much of the Core C/C++ work made for us, so
> we could have much more time to think about the main app, in Python.
>
> > I also like the idea of not locking ourselves to the GOK keyboard file
> > format, but do a one-time conversion. That would also give us a chance
> > to automatically remove data we don't need, like the numeric keypad and
> > function keys. The reason we need to do this at all is that GOK has
> > literally hundreds of existing layouts.
>
> I'm with you in this one, we could switch away sooner or later from the
> GOK ideas and go in our own way of redefining what an onscreen keyboard
> we will do. Not only being desktop-independent, but doing something
> really useful for the impaired.
>
> > - Henrik
> >
> >
> --
> Reset Reboot
>
> Jabber y Google Talk: reset.reboot at jabberes.org
>
> http://www.libreyfacil.org
> http://resetreboot.blogspot.com
> http://resetblogo.blogspot.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBEYwKoLtZVaJEhFxQRAj93AJ9+MG5gbfEwgZ8Xq236ufFR4YPH6ACfSlcE
> FYkZs67BDE0wfoDXRCsLhZY=
> =qb4Y
> -----END PGP SIGNATURE-----
>
>
> --
> Ubuntu-accessibility mailing list
> Ubuntu-accessibility at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
>
>
>
More information about the Ubuntu-accessibility
mailing list