Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 370485

Summary: [General]Support keyboard navigation for explorer tree.
Product: [ECD] Orion Reporter: libing wang <libingw>
Component: ClientAssignee: libing wang <libingw>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: john.arthorne, maxli, simon_kaegi, susan
Version: 0.4   
Target Milestone: 0.4 RC1   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Bug Depends on: 369738    
Bug Blocks: 349591    

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.