Bug 370485 - [General]Support keyboard navigation for explorer tree.
Summary: [General]Support keyboard navigation for explorer tree.
Status: RESOLVED FIXED
Alias: None
Product: Orion (Archived)
Classification: ECD
Component: Client (show other bugs)
Version: 0.4   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 0.4 RC1   Edit
Assignee: libing wang CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 369738
Blocks: 349591
  Show dependency tree
 
Reported: 2012-02-02 14:39 EST by libing wang CLA
Modified: 2012-02-04 14:40 EST (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description libing wang CLA 2012-02-02 14:39:40 EST 
Bug 369738 addresses the model level iteration on a tree.
It requires a tree object(currently it is a list of first level children but easy to change to a ROOT object) with all the nodes having "parent" and "children" properties. It provides where the "cursor" is when the caller asks to "go forward or backward". I think this is the very core and generic part when we iterate through a tree.

What it does not provide yet are those functions like expand/collapse but we will get them free from our model-renderer-explorer pattern.

If we will have a tree iteration handler we can integrate our *explorer stuff  with the TreeIterator. This handler will handle the 4 arrow and enter keys. It will also surface all the navigation functions in case it is needed to navigate from tool bar.

In searchExplorer.js, I've already handled theses cases so I need to generalize this to another layer, say, call it "TreeIterationHandler".

The existing TreeIterator is not limited to the model-renderer-explorer pattern. It will stand there no matter how we will re-render our tree model in the future.
Comment 1 libing wang CLA 2012-02-02 14:46:04 EST 
Talked to Susan, Guide line for tree grid.  http://www.w3.org/TR/wai-aria-practices/#treegrid.

I do not think we will implement the full spec here but just a subset of the 4 arrow and enter keys. The main thing we want to make sure is to avoid conflicts from the guide line.
Comment 2 libing wang CLA 2012-02-02 16:01:49 EST 
Bug 370496 has relationship with this bug.
If we want to toggle check box then we may think about that bug together.
Comment 3 libing wang CLA 2012-02-03 11:20:44 EST 
I will not generalize the "select all" as I mentioned before(bug 370496).
My plan is to have  a new "TreeIterationHandler", which holds a generic explorer. The existing contract is that explorer has a renderer, renderer has a model, hence we can use the model to create the TreeModelIterator.

All the common iteration/expand/collapse behaviors will be implemented in the "TreeIterationHandler". In 0.4, FileExplorer and SearchExplorer will consume this. We will think about a consuming this in all *explorers but that will be post 0.4.

Some design details:
1.In the model level, we need a new contract to provide the first level children.
  By default, it should be root.children. Some times you do not want to iterate every node(e.g. search result may have file nodes that are stale. They are rendered, but iterator does not need it).

2.The default behavior after iterator++/-- is just to move the "cursor" in the table row. Optional callbacks can be provided for the post behavior.
For example, in search page the callback will change the context tip while in replace page it will change the diff view, etc.