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