[orca-list] Progress update #2 on the "list of dialogs"

[Joanmarie Diggs <jdiggs igalia com>]

Here's update #2.

As you should all know by now, the binding modifier is now Alt+Shift as
per previous discussion. As a result, this:

> There are currently two unbound other "list of dialogs":
> List of lists - turns out Ctrl + Alt + L locks the session <grins>
> List of links - there is no "plain ol' links" command, so no key yet

Is also addressed. List of lists is Alt+Shift+L. List of links is
Alt+Shift+K.

In addition, I have addressed the following from my to-do list:

>   * Currently there is no spoken or brailled indication of how many
>     matches were found. You can get this via where am I in the table
>     in the meantime.

This information is now included in the title when there are results.

>   * Currently the dialog pops up when there are 0 items. Orca should
>     just present the fact that there are no matches and not waste time
>     showing a dialog.

The lack of results is now presented as a message. The dialog is not shown.

>   * Currently you are placed at the top of the list. Orca makes no
>     attempt (yet) to position you in the list based on where you were
>     on the page.

Now, if your current location is in the list of matches, you are placed
on that item within the tree. Note that it needs to be an exact match.
Examples:

* The focused item is a form field and you bring up a list of form
  fields, the selected item in the tree should be that form field.

* The current item is the 3rd heading on the page and you bring up
  a list of all headings, the selected item in the tree should be that
  heading.

* The focused item is the third link on the page. There are two form
  fields above it and two form fields below it. The selected item in
  the tree should be the first row. Orca does not attempt to put you on
  the closest form field.

* The focused item is a link within a heading and you bring up a list
  of headings, the selected item in the tree should be the first row
  and not the parent heading.

I suspect and hope that in the first three examples you agree with me
that this makes sense. But if you don't, please let me know.

As for the last one, that was a decision based on the need to be
performant. The more work Orca does putting together the list, the less
performant it becomes getting you that list. If it has to check parents
and grandparents and greatgrandparents on the off chance that it just
happens to be the container of what you are on, I think you'll find that
the cost outweighs the benefit. The current solution, with the
aforementioned exact-match row selection is performant and seems to
address the bulk of the use cases.

>   * It would be nice for Orca to say something when the table is
>     resorted. That's not limited to this feature. That's in general.
>     It may involve work on both the GTK side and the Orca side.

Done. Turns out Gtk already gives us what we need.

Thus my current to-do list is handling:

>    * It's rare, but on occasion, we have no label/name/text for an
>      object. So we either need to try harder for those oddball items
>      or verify if they are useless and never should have passed the
>      match test in the first place.
>    * I still need to figure out how best to present tables and make
>      a decision about cells.
>    * Our existing landmark and live region code isn't very reliable
>      period, so I'd like to debug that before I add dialog support.

And of course, responding to your feedback from having tested this work.

Please let me know if you have any questions. Thanks!
--joanie