Re: [g-a-devel] KISSing Collections

[Ariel Rios <ariel gnu org>]

Joanmarie,

I developed Collection years ago and I want to answer some of your
questions and points. It has been years so I will do my best to
remember everything. I am going to be as concise as I can but I can
talk in more detail if you need so.


> 0. Background and Use:

> * Personally, I cannot imagine other ATs having vastly different needs
>  or use cases with respect to Collection.
>
Accerciser makes (or made) use of Collection.

> 1. Do we really need these (not-implemented) methods?
>
>   * atspi_collection_is_ancestor_of()
>   * atspi_collection_get_active_descendant()

I was working for IBM and then under a Mozilla grant. It was decided
that I would only do the most important methods and thus some of them
were never implemented. The API was not designed by me and I remember
having a lot of problems (just as you are having now) trying to
understand what every method was supposed to be doing. At the end I
had to do some changes to the API proposed.

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

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

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

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.

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

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


ariel


>
> 5. Do we really need the ability to specify the tree traversal type?
>
>   typedef enum {
>       ATSPI_Collection_TREE_RESTRICT_CHILDREN,
>       ATSPI_Collection_TREE_RESTRICT_SIBLING,
>       ATSPI_Collection_TREE_INORDER,
>       ATSPI_Collection_TREE_LAST_DEFINED,
>   } AtspiCollectionTreeTraversalType;
>
>   As you might have guessed, my proposal: nuke it.
>
> 6. Recurse and Traverse? What are these even for? Aline asked us on
>   several occasions as part of her most awesome documentation work. And
>   the consensus of those of us who have been around is that we don't
>   know and will have to dig through the AT-SPI code in order to sort it
>   out. If no one even knows what these things are for or why they might
>   be of benefit to an AT are they a) worth keeping around and b) worth
>   asking apps and toolkits to implement -- and then expecting them to
>   do so in a consistent fashion??
>
>   My proposal: If there is indeed a compelling reason to keep these
>   things around, it should be made much more obvious to us -- and then
>   clearly documented for implementors. Otherwise, I think these need
>   removing.
>
> Thoughts?
> --joanie
>
> _______________________________________________
> gnome-accessibility-devel mailing list
> gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>