Re: [Dev] 0.7 summary table implementation thought

[Alec Flett]

As the current maintainer of CollectionCanvas, my mind has already started trying to map out how we'd do this. For those of you unfamiliar, CollectionCanvas is actually the base class, underneath CalendarCanvas, that does some of the GUI work that's not calendar-specific. It leaves any view-specific behavior to the base class. And so be honest, I'm really on the fence on this one. On one hand, I think we would gain a tremendous amount of flexibility here, and I think we could get some good performance out of a lightweight grid-like implementation. There is only one toplevel widget, the canvas itself, so that view/exposure management is cheap as is the use of system drawing resources. On the other hand, I think CollectionCanvas is still fairly primitive.. and while its use has been proven with CalendarCanvas, its never had a second use. It has never dealt with any kind of ordering, its main loop expects to be calling Draw() on a list of "canvas items", and it leaves actual geometry/layout issues to the base class. This is not to say it couldn't improve though. I'd say right now, the next logical use of CollectionCanvas would be some sort of thumbnail canvas for photos or something... so a grid? Maybe! To give everyone an idea, CollectionCanvas manages the following for the calendar: 1) drag and drop, including drag-within-the-canvas and drag-outside-the-canvas 2) mouse event handling, mostliy for hit and resizing (including the actual drag) 3) selection management, including multiple selection and such 4) painting and paint events management 5) a few platform-specific issues with focus and such All of this is obviously necessary for grid, but a few basic things we'd need to worry about 1) sorting 2) more complex hit-testing - i.e. to allow clicking specific regions within an "item" 3) finer grained drawing - i.e. per-row drawing/exposure/etc... Alec 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? ...Bryan _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 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