Re: Using Choosers for and OSK

["Peter Parente" <parente gmail com>]

> 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 .

This is how we use Perks and choosers in LSR. But you're not bound to
this structure. Consider:

1) A Perk that just displays a GUI dialog itself, neglecting the
chooser convenience altogether.
2) A Perk that also implements chooser. (May not be entirely possible
today, but we could enable it.)

Each approach has its ups and downs. For instance, a Perk that shows a
gtk dialog directly is bound to use gtk on all platforms whereas if
the GUI code exists in a separate chooser module, the appropriate one
could be loaded for the current platform without a change to the Perk.
But this separation of responsibility into two modules makes
communication between the two more difficult than the design which
combines them.

> 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.

I'm not sure what to recommend here. You might spend ages implementing
basic GUI functionality using low-level cairo commands just to get eye
candy. On the other hand, you'll wind up being just another OSK if you
use a grid of gtk widgets. Tough choice, and no clear path leading
from one to the other down the line.

> 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.

One possibility. See above for others.

> 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?

There are trade-offs either way. We actually use a mix of both in the
standard LSR choosers. Most of the time, LSR is reading its own
dialogs by responding to AT-SPI events. In some cases, though, the
choosers send specific signals to the Perks indicating something more
specific needs to be spoken, Brailled, magnified, etc. For instance,
as you re-order the Perks in the Perk chooser, LSR makes announcements
such as "moved gaim perk above basic speech perk, below none"
indicating the new position of the Perk in the list. It would be quite
complex to make such a domain specific report using AT-SPI events
alone. So, instead, we signal a Perk from the chooser to make an
intelligent announcement about what's actually happening in this list.

> 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.

Still don't have a recommendation for you. :) I think this is one you
need to answer for yourself based on what you want the initial version
of Jambu to be.