[Dev] 0.7 summary table implementation thought

[Katie Capps Parlante]

Hi Bryan,

I'm sypathetic to the idea of having a lightweight "CollectionGrid" that 
works and plays well with AttributeEditors and Collections -- this may 
end up being the right thing to do.

I'm not sure that subclassing CollectionCanvas helps much though, for 
some of the reasons Alec mentions below. A few thoughts:

* Hit testing in a grid should probably be pretty different than in the 
canvas. In a grid, you can calculate which cell you'll land on, where 
the canvas is designed to be pretty flexible -- its "cells" know their 
location.

* The grid's mechanism for accessing Items in the Collection may end up 
being fairly different, and it is very important to get this right to be 
able to handle very large collections in the grid. A grid can make 
grid-specific assumptions about which items are on screen.

A thumbnail canvas was indeed the next suggested use of the 
CollectionCanvas, we'd hoped to try it out at the end of 0.5. :( We've 
been talking about doing a parcel sprint, perhaps this could be one of 
the activities.

At any rate, I wouldn't block on reuse of CollectionCanvas for exploring 
a lighter-weight Chandler-needs grid. If it turns out to be helpful, 
though, even better.

Cheers,
Katie

Alec Flett wrote:
> 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