Re: Using Choosers for and OSK

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]