Re: [g-a-devel] KISSing Collections

[Joanmarie Diggs <joanied gnome org>]

Hey Ariel.

Thanks for your response and clarifications!

On Sun, 2011-08-07 at 14:20 -0500, Ariel Rios wrote:

> Accerciser makes (or made) use of Collection.

For what purpose? I believe all it does is make it possible for the user
to see if Collection had been implemented or not and query it via
pyatspi in the ipython console. Nor am I aware of that being a change
(i.e. that it used to make use of Collection itself and no longer does).

<shrugs>

> >   My proposal: We nuke these methods which have gone unimplemented for
> >   years. In addition, the ability to specify the root object gets added
> >   to the get_matches methods.
> I agree.

Yay! :-)

> > 2. Do we really need these methods (as currently named and defined):
> >
> >   * atspi_collection_get_matches_to()
> >   * atspi_collection_get_matches_from()
> >
> >   These methods seem to suggest that an AT would want more than one of
> >   the previous/next objects. What on earth for?? In the case of
> >   facilitating navigation within the document/app, only the previous/
> >   next *single* object is needed; in the case of implementing an
> >   AT-specific tool (e.g. a 'list of' dialog), the AT would presumably
> >   want all of the objects.
> 
> The idea of this methods were that a certain point you might only have
> the reference to an object, like a link and might want to ask for all
> the links before this one or after.

That part I get -- well, most of it. It's very plausible (and the normal
situation in Orca) where the AT wants the next or previous item with
respect to the current one. What I'm questioning is the need to have all
of the links which follow, or 10 of the links which follow. I do not
believe this need exists. If I am interested in presenting the user with
a list of links in a dialog box (the sort of thing users expect a screen
reader to do), then I need all of the links; not a subset thereof. If
instead I am trying to provide a means to jump amongst links, I just
need the next link or the previous link based on the present location.
That is why I would like to keep atspi_collection_get_matches(). It's
the get_matches_to() and get_matches_from() I have no need for. Hence:

> >   My proposal: We replace the above methods with:
> >
> >   * atspi_collection_get_previous_match()
> >   * atspi_collection_get_next_match()
> >
> >   That, combined with atspi_collection_get_matches() should more than
> >   suffice IMHO.

Do you disagree?

> The idea of Collection was to enhance speed and reduce calls on the
> client side so all of these methods were created with this in mind. So
> instead of doing something like get_previous_match many times we only
> call it once on the server and then work with the data on the client.

Okay, perhaps you do. ;-) But.... When you say "we only call it once on
the server", who is "we"? If "we" are ATs like Orca, like I said, I have
no need to do what you describe and question what ATs do have this need.
Again, I just want to be able to get the next link (one), the previous
link (one), and all links so that I can provide this functionality to
Orca users.

On the other hand, if "we" means AT-SPI, then... fine. I don't care what
the underlying implementation is. But then I think those methods should
be private. And I would still like simple, straightforward methods
get_next_match() and get_previous_match().

> > 3. Do we really need the ability to specify a count?
> >
> >   This follows point 2. I want one (previous/next) or all. Why would I
> >   want some arbitrary number in between?
> >
> >   My proposal: Count gets removed from the present and/or revised
> >   get_matches methods' arguments.
> 
> Imagine that you are working on a very large html document, and you
> are asking for all the links. This can really take a lot of time (I
> tested this using one of those manuals that come on only one HTML
> page). To the end user, it seemed that the application has frozen. So
> the idea of this methods was that we could get the information in
> chunks rather than all at once.

But is this something every AT is supposed to sort out for itself? Or
can these chunks of information be dealt with behind the scenes by
AT-SPI and the non-AT apps and toolkits implementing this support?

> > 4. Do we really need the ability to specify the sort order?
> >
> >   A. Shouldn't the tab order and the flow order be the same thing?
> >   B. The main use case (IMHO) for Collection is to facilitate
> >      navigation amongst and/or examination of objects. As such, isn't
> >      the logical sort order that which corresponds to the flow/tab
> >      order?
> >   C. Do we really need to be able to reverse the order? And, if so,
> >      can't we ATs just take the resulting object list and reverse it
> >      ourselves?
> >
> 
> >   My proposal: Sort order gets removed from the present and/or
> >   revised get_matches methods' arguments.
> I vaguely remember there was a reason to have this implemented but I
> need to go back and check my notes about this and ditto for traversal
> types.

If you could do so, it would be awesome. Because honestly, I cannot
imagine wanting these items in any order other than the tab/flow order.
And if the tab order is not the same at the flow order, then that would
strike me as a bug in the app/toolkit for which they are different. But
maybe after I see the contents of your notes, I'll feel differently.

Thanks again! Take care.
--joanie