Created attachment 84357 [details] [review]
first pass at this

Notes:  This seems to work fine going forward from list to list.   It *mostly* works going backwards from list to list.  On occasion, in nested lists, it jumps over a list it should stop at.  Compare going forward versus going backward using http://svn.gnome.org/svn/orca/trunk/test/html/lists.html I'm not yet sure if this is related to how we work our way up the hierarchy in findPreviousObject() or something else. 

Currently, when you land on a list item using L/Shift+L, the first item in the list is announced but the bullet or number isn't.  This is consistent with line navigation and -- I'm guessing -- is something we'll want to handle in getLineContentsAtOffset().

You'll notice the keybindings include CONTROL.  That's related to the issue in bug #416853.

Finally, I gave ngettext a shot.  I just followed Rich's example in nautilus.py..  Will, are we supposed to start using ngettext for all strings or just when we are using substitution?

> Finally, I gave ngettext a shot.  I just followed Rich's example in
> nautilus.py..  Will, are we supposed to start using ngettext for all strings or
> just when we are using substitution? 

We should always use _(""), except when dealing with strings contain singular/plural references that are dependent upon the numerical parameter being passed in (e.g., "item" vs. "items").  In addition, we also need to avoid concatenation of words to make sentences.  An example is how negation is handled in French: "I do not know" becomes "je ne sais pas", where the "ne" and "pas" are the negating words.  So, where we might think "I do" + " " + "know" and and "I do" + " " + "not" + " " + "know" would be valid, such fine-grained string concatenation falls flat when translating to French.

So...the better thing to do for this patch might be:

            itemString = ngettext("List with %d item", 
                                  "List with %d items", 
                                  nItems) % nItems

Note that bug 412200 is a bug to help us track i18n/l10n issues.  I expect we will learn a lot when going through the various strings in Orca.

Re ngettext, thanks!!  I know I'm planning on learning a lot w.r.t. i18n/l10n. :-)

Looking at why navigating by previous list isn't working the same way as navigation going forward:  The lists that we are skipping over happen to be in the ancestry of the current list.  From the Lists Test Page:

- listing item
    * first sublevel
          o look for the bullet on
                + each sublevel
                + they should all be different, except here.

When you are in this nested list

                + each sublevel
                + they should all be different, except here.

the previous list is *I think* the one beginning with "look for the bullet on."  From there the previous list would be the one beginning with "first sublevel."  Finally, from there, the previous list would be the one beginning with "listing item".

Assuming we agree on the definition of previous list....  :-) When we use findPreviousRole():

[...]
        while obj:
            ancestors.append(obj)
            obj = obj.parent

        obj = self.findPreviousObject(currentObj)
        while obj:
            if (not obj in ancestors) and (obj.role in roles) \
               and (not self.isLayoutOnly(obj)):
                return self.findFirstCaretContext(obj, 0)
            else:
                obj = self.findPreviousObject(obj)
[...]

obj eventually becomes the previous list but is ignored because it's in ancestors.  So....  Do we modify findPreviousRole() to handle the case of nested items such as lists (and, I assume, tables)?  Or do we address these cases in goPreviousList() and (presumably) goPreviousTable()?  The latter certainly seems safer.... :-)

Created attachment 84440 [details] [review]
revised version - seems to work

While handling the nested items situation in goPreviousWhatever() might be safer, handling it in findPreviousRole() seemed cleaner.  :-) This version of the patch seems to work as expected both moving forward and moving backward.  The change to findPreviousRole seems safe and should allow us to easily add additional cases as they come up (tables and blockquotes spring to mind).

I did not make parallel changes to findNextRole() because we don't have this issue going forward -- that I've noticed anyway.

Thoughts??

Hey cool!  Looks good to me.  I say go ahead and commit it and close this as FIXED.

Created attachment 84602 [details] [review]
revision to handle items nested within the list item

Turns out things can be nested inside a list item such as:  
<ul>
<li><p>My item</p></li>
</ul>

In this case the caretContext will be inside the paragraph and the parent will not be the list.  As a result, we'll move to the list correctly, but Orca will claim that the list has 0 items and incorrectly report the nesting level.  This version makes sure that we've found the list before counting items and looking at nesting.  Only change between versions:

             parent = obj.parent
+            while parent.role != rolenames.ROLE_LIST:
+                parent = parent.parent

Will, shall I commit this version?

Looks good.  Thanks for catching that.  Go ahead and commit.  :-)

Thanks for the review!  Committed.  Closing as FIXED.