[Dev] implementation ideas for "sections"

[Alec Flett]

So John, Jeffrey, and I have been discussing some suggestions for how we 
might implement "sections" as Mimi has described them.

The basic ideas I've pulled out of the design sessions are:
1) There are initially 3 sections, one for each of "now", "later", and 
"done"
2) We might allow other arbitrary groupings depending on other 
attributes - i.e. by subject, by 'who', etc
3) The sections have headers and are collapsible
4) There is one giant scrollbar to scroll the whole display, rather than 
scrollbars per-section - so that, for instance, you could scroll the 
"later" section right out of view.

There are some open issues, that both influence, and depend on design 
decisions:
1) When a section is scrolled out of view, does the section header stay 
in view? (seems like yes, we'd like it to stay in view if at all 
possible, but I'm not 100% sure.. that would probably be very nice for 
just 3 sections, but really bad for more than 5-6)
2) Where does the header for the columns live - above all the 
sections/data or one header per section? (seems like ideally just one 
header)

There are a few possibilities on the table right now:
1) Have a bunch of grids, and use a 3rd-party widget to collapse the 
sections. In the background, keep the grid columns aligned. The grids 
would all live together on the same wx.Panel, which would scroll in some 
fashion.
 There are some details to this implementation which would need further 
clarification:
   a) How do we actually size each grid widget on screen? As we scroll, 
do we tell each grid widget to get smaller and larger, but suppress the 
per-grid scrollbars? John thought this was unnecessary, that we could 
just tell the grid to be exactly the right height to fit the number of 
rows in the section, and that the grid wouldn't try to draw the rows 
that weren't on screen. I thought that the grid would still be 
allocating data structures just to maintain its own geometry, but we 
weren't sure if that was actually true or not.
   b) would that make it hard to allow section headers to remain on 
screen, since you'd essentially have to move them within the Panel so 
that they were always in a visible part of the Panel. And if that's the 
case, wouldn't they overlap with the grid? We'd have to hide the grid I 
guess, especially since wx doesn't like overlapping child windows.
   c) It would be easy to do a unified header widget, since it would 
live outside of any of the grids, and would just make sure all the grids 
stayed in sync.
   d) if we started sectioning on another attribute, there would be a 
lot of tear down and rebuilding of grids - but maybe that's ok

2) Use the grid as it stands now, but delineate certain rows as section 
header rows. The grid scrolls as normal, but when drawing a row of data, 
we would essentially be offsetting the grid row by the number of headers 
above that row. i.e. If we drew a "now" header at row 0 in the grid, 
then the data would start at row 1. If the "later" header was at row 33, 
we'd display the 32nd item in the collection at row 34 because the "now" 
and "later" headers were above this. Issues around this:
    a) where do we do this translation from data row -> grid row and 
vice versa? Seems like wxTableData (or a derivative) is a good candidate
    b) how do we draw sections headers? It seems possible to put a 
widget in a particular cell, but is there a way to indicate to the grid 
drawing code that you want a cell to span multiple columns? i.e. it 
would be nice if we could just put a "section header widget" in the 
first cell of the section header row, and draw all the way across the grid
    c) We'd just use the normal grid header, which is ugly - so we'd 
have to figure out a way to integrate davids' ColHeader widget into the 
grid. This would be a nice thing to give back to the wx community, as we 
think they want this anyway.
    d) section collapsing and keeping section headers on screen would be 
pretty easy - just a modification to the wxTableData data/grid row mapping.

I personally prefer 2) - I think its more likely to lead to a cleaner 
design in the long run, plus be easier to implement in the short run. 
The one thing I am worried about is 2b) but I'm pretty sure we can come 
up with some workarounds even if we can't make cells span all columns.

Alec