Since I think we agree in the general case we want to be able to
handle an arbitrary number of sections, the question which Alec
raises of whether the header stays visible if the section scrolls out
of view is very relevant. My opinion is that we shouldn't keep the
header on the screen if its section would otherwise be offscreen.
I also think that managing screen real estate when you have a lot of
sections is generally a tricky issue. One idea is to have three
states, not two, for every section. open, closed, and hidden.
Hidden sections take up 0 rows. OK, so you ask how do you know that
they are there at all. Easy. You put some sort of mark along side
of either the section above or below. Clicking on it or whatever
reveals it. Hovering over the mark could show names of hidden
sections. I've always wanted this in my outline editor.
On whether every section should have the same columns, I am inclined
to say yes.
On Jan 27, 2006, at 3:01 PM, Alec Flett wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
