Calendar:Tree Review

Now that things regarding the new views are startign to settle into place, the next major area of the UI that probably needs to be examined for Lightning 0.1/Sunbird 0.3a2 are the tree/list elements. There's very little code-resue going on between the two projects in this area, and one of the goals for this review, I feel, ought to be to improve that.

Current Situation

Event Lists

• Sunbird: The Unifinder is an implementation of a standard xul-tree. It is not heirarchical.
• Lightning: The Agenda Tree is an implementation of a standard xul-tree. It is hierarchical.

Task Lists

• Sunbird: Implements a standard xul-tree. It is not hierarchical.
• Lightning: Implements a richlistbox. It is not hierarchical.

One proposal for the future

At some point in the near future, Sunbird is finally going to need to solve the problem of linking selection in the task list with the rest of the UI. This isn't difficult to do, given that the unifinder provides a (somewhat hacked) model for how to accomplish this. The key point however, is that other than the types of calendar-item displayed, the underlying code for both these lists is the same.

Lightning's task list needs to implement columns. After some discussion on IRC, the general consensus seems to be, at least for the short term, to move Lightning away from the richlistbox, which does not support columns, towards a tree.

As all the different models seem to move closer together (trees+selection), and keeping in line with the current push towards xbl, the model I'm considering looks something like this:

                              _________________________
                             |                         |
                             | calendar-tree-base.xml  |
                             |_________________________|
                             /            |            \
                            /             |             \
                 __________/___   ________|______  ______\__________
                |              | |               ||                 |
                | unifinder.xml| |agenda-tree.xml|| task-list.xml   |
                |______________| |_______________||_________________|

Here, calendar-tree-base.xml would:

• implement calICalendarView
• contain a stub <tree> in it's content
• include a stub implementation of nsITreeView for controlling the <tree>
• include functions for incremental tree-rebuilding (via implementing calIObserver and calICompositeObserver)
• include functions for select events, and notifying the selectionManager

Then, unifinder.xml, agenda-tree.xml and task-list.xml would extend calendar-tree-base by including a much more detailed <tree> element and over-riding the necessary functions.

Questions

• What are the relative advantages and disadvantages of the agenda-tree vs. the unifinder? Do we need to keep both?
  • At one point I considered scrapping the unifinder in favor of a firefox-style find bar. We need to figure out the use-cases for the unifinder currently.
• Do these tree views need to implement some kind of additional calITreeView interface?
• How much of a help/hurt would this plan be towards later goals of inline editting and hierarchical task lists?