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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
