Re: [orca-list] Clarifying Script Association

[Joanmarie Diggs <joanmarie diggs gmail com>]

Hey Steve.

> I have a question with the new script structure put in place a while
> back.

FWIW, all the new script structure did was to move scripts that weren't
in their own folders so that we were consistent. That change happens to
be irrelevant here.

> For background, I just got Thunderbird upgraded by ArchLinux to
> version 3.1 and it is code named 'Lanikai'.  In the past, we always
> had to go into settings.py and update the strings which would
> associate a script with the application name.  Well here, Lanikai does
> not associate with Thunderbird because it isn't in settings.py; that's
> clear enough to me. 

Awesome.

> But I notice that it is associated with gecko.py
> because of an association through toolkig; make sense?

Yup, that's exactly what is going on.

> When does Orca know when to use the toolkit as a linkage instead of
> settings.py?

Orca does the following:

1. See if there's an exact match based on the script name. In other
words, you say the accessible app's name is Lanikai. Is there a script
called Lanikai found in Orca? If so, use it. We're done. If not,
however:

2. Is there a match in settings.py that points to a script in Orca with
some other name? If so, can the script with some other name be found? If
so to that, use it. We're done. If not, however:

3. What toolkit is being used? And is there a toolkit-specific script in
Orca that matches? If so, use that. We're done. If not, however:

4. We give up. We'll just create a new script based on the default
script and the Gtk+/Gail toolkit.

> Should we still update settings.py with 'Lanikai'?

Yup.

> My other question is there's a script settup for Thunderbird but I
> also see Gecko out there too. 

Yup, Gecko is the toolkit script. The script for any Gecko-based
application will need to be based on the Gecko script. If you look in
any of the Orca scripts for Gecko based apps, you'll see something like
this:

        class Script(Gecko.Script):
            """The script for Thunderbird."""

But in an application script for an app using Gtk+ you'll see:

        class Script(default.Script):
            """The script for Foo."""

Consider something as simple as giving focus to, and then moving around
in, a combo box.

* How do we get the name of the combo box?
* How do we know which item is selected?
* What sort of events do we see when a combo box gets focus?
* What sort of events do we see when a combo box is expanded or 
  collapsed?
* What accessible actions are present?
* What happens when we do an explicit grab focus on it?

The answers to all of the above are very important in terms of Orca
presenting the correct information to the user who just wants to access
a combo box. *And* those answers can be vastly different, depending on
which toolkit is being used. However, if you are attempting to access a
combo box in a Gecko-based app, the odds are excellent that the combo
box in your app will behave just like the combo boxes in Thunderbird and
the combo boxes in Yelp 2.0 and the combo boxes in Firefox and the combo
boxes in Instantbird. The odds, unfortunately, are equally excellent
that they will not behave like a Gtk+ combo box. It's due to this sort
of thing that:

1. If we can't find a match for the script at the app level, we fall
back on the toolkit script.

2. If we have made a script at the app level, it will be based on the
toolkit script.

But now consider performing email-specific tasks in the specific client
whose name should be Thunderbird: We need to handle things like:

* Announcing when an email address has be autocompleted in To/CC/BCC
* Presenting the spell check dialog
* Not treating a plain text message like Gecko/Firefox document content
* Etc., Etc., Etc.

The Gecko script knows nothing about those sorts of things. Those are
application-specific tasks handled in an application-specific script.

So that's a very long way of getting to this question:

>  Which script should we be using for these Mozilla mail
> clients which can't make up their mind what to be called internally?

The Thunderbird script, because it knows all about the Thunderbird-
specific objects and tasks it needs to present *and* is based on the
Gecko toolkit script so that we can do the right thing when the user is
interacting with ordinary/non-special widgets within the app.

Sorry for the long answer, but I hope it helps clarify things.

BTW, if you'd like to open a new bug for the <strike>flavor</strike>
name of the day for Thunderbird and attach a patch, that would be
awesome. Thanks!

--joanie