NSTableView vs MBTableGrid - the trial

The main cello UI is comprised of three views, FrameView TimeLine and ActionView. Together these views comprise the majority of the editing functionality. My intention was to start with the FrameView. The FrameView is used to draw the the items at a given point in time. So when you sketch, say, a box you do this in the FrameView. It seemed like the most important view to start with. There is, however a really close linkage between the views - so starting with the TimeLine view seems the simplest. We shall see:

In the PC version the time line looks like this:

It is more-or-less a list of a single column with row and column headings. The row headings contain active controls - as do the rows themselves. The column heading is a has the time-ruler and is also active.

As far as implementing this in cocoa I can see two choices

• Implement this strange list like thing myself
• Use the cocoa NSTableView

The best course does not seem immediately obvious to me. One of the benefits of writing a blog is that when writing things you can think about them in a slightly different way. One of the things that occurred to me while writing this is that the table is not actually a table of a single column - it can be thought of as a table of many many columns. Each time interval (typically something like 1/15th of a second) can be thought of as a single column - this would seem to offer some simplifications in the implementation.

In trying to determine the best course of action I have tried to enumerate the various things that need to be done with the time line.

• Items in the row header need to be editable.
• Items there are buttons and popup menus in the row headers
• Rows need to be selectable
• Cells have items that can be added/deleted and removed
• Some items can stretch over more than one cell
• Items that stretch over more than one cell appear as a "whole" - they are drawn as a whole
• There is a row (the sound track row) that does not (currently) have any editable elements.
• The width of the row area needs to be resizable
• The header area is not a standard table header

Looking at this I can try and figure out what the best way forward should be. Also into the mix comes MBTableGrid - a set of classes that draws a "Spread Sheet" type widget written by Matt Ball - that could be a basis for a non-list approach. The Author has solved a number of the problems that I would face - there is a separate row/column area, it supports inline editing. The code can be found here.

The NSTable approach has a few stumbling blocks:

• Tables don't have row headers - this could be be implemented by a separate parallel - list. you just have to sync the scrolling and selection.
• I would need a different header - fortunately the table header can be sub-classed.