[Dev] 0.7 summary table implementation thought
john at osafoundation.org
Mon Dec 5 15:17:18 PST 2005
I agree that the summary view isn't a great fit for the grid -- the grid
has zillions of features and the summary only uses a small number of
them. All we really need is an x vs. y table of attribute editors. One
of the features that the grid implements, which we would have to
implement ourselves, is all the nuances of handling selections (e.g.
multiple selection) caused by mouse click, (e.g. with shift click,
control click) which is platform specific. However, the Calendar also
needs better selection support, so maybe we could come up with a way to
do it in both cases. If we do end up using CalendarCanvas we should
probably refactor out the calendar specific methods.
Bryan Stearns wrote:
> I've been kicking this idea around in my head, and looking at the 0.7
> summary-table spec has prompted me to send it to the list...
> We've currently got a summary Table implementation based on wx's Grid
> mechanism; it provides a framework for presenting a list of items in
> rows & columns, with scrolling support, hit testing, etc. It also
> comes with some architectural structure (most in my face, the
> editor/renderer mechanism) that constrains our implementation a
> little; our thinking occasionally stumbles over UI issues like
> sections, etc, that don't naturally fall out of using the wx Grid.
> In thinking about future needs for the table, it occurred to me that
> we've already got the CollectionCanvas that knows how to present items
> of varying geometry on a variably-sized canvas with scrolling,
> dragging, and hit-testing. It seems like it'd give us more flexibility
> in evolving the summary view in the future. (As a bonus, it already
> uses David's header widget.)
> So: should we think about building the 0.7 summary table on top of
> CollectionCanvas instead of the Grid?
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Dev" mailing list
More information about the Dev