Using Choosers for and OSK

["Steve Lee" <steve fullmeasure co uk>]

Having explored LSR's code in more detail I'm beginning to feel I'm
getting to grips with it. I'd like comments and ideas on how the
following proposed design is in keeping with LSR's architecture. I'm
also undecided whether to use gtk for basic UI (which I admit is a
little off topic).

For simplicity lets say the requirements are for a simple grid of
button-like cells, each with some text, one of which is selected with
a visual highlight. <gesture1> cycles the selected cell causing the
new selection's text to be spoken, and <gesture2> activates the
current selected cell and speaks using some suitable phrase like
'Activate' + <button text>

> From my understanding of the chooser ABC / interface and the examples
the design pattern is as follows. A perk calls loadChooser() and the
chooser creates an UI. The UI responds to system events itself in
order to manage its own state / display and signals the Chooser as
required (e.g change of state).  The chooser in turn _signals() it's
partner perk with events that require more complex behaviour and
choosers avoid the TaskTools API (that's a design trade decision and
perhaps not a requirement). The perk can signal the chooser by calling
Update(). So we have a loose message-based coupling between the UI,
Chooser and perk .

In this case UI could be simple custom drawn using cairo say but then
the chooser will have to manage quite a lot including state. A widget
set such as gtk will save a lot of work. pygtk is the natural choice
as it's already used in LSR via glade for the monitors. For layout on
a grid OSK the TreeView and GenericRenderer look useful. However it
may not be flexible enough for advanced SVG graphics or other layouts.

So I think we want a perk that maps events/gestures to actions and
which asks the chooser to draw the OSK and perform actions via
Update(),  e.g SelectNextCell, ActivateSelectedCell. When the cell
changes the UI signals the chooser which then signals the perc which
then speaks the cell text after querying it from the chooser.

The obvious feature of this is that the interaction between perk and
chooser looks much like what happens between LSR and the a11y API and
so we're duplicating what has already be done. It would be better if
the chooser UI was accessible itself so it could be more directly
managed by the perk via TaskTools and all that signaling would be
replaced via LSRs normal mechanisms?

gtk is accessible on Linux but it's unlikely it's accessible on
Windows which I eventually want to port to. So I'm still undecided
whether to start with GTK or own draw with pycairo as above.

Any comments or ideas welcome?

--
Steve Lee
www.fullmeasure.co.uk
www.oatsoft.org
www.schoolforge.org.uk