Katie Capps Parlante wrote:
* 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.
This is true, but this could also be easily abstracted into a sub-class
of CollectionCanvas (see below)
*
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.
Actually, the CollectionCanvas has moved towards something closer to
the grid - at least, it maintains a separate list of the on-screen
items...
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.
I think its possible that we could develop the grid with a slight
variation on what Bryan is suggesting:
CollectionCanvas
/ \
CollectionGrid GraphicalCanvas
\
CalendarCanvas
so basically, CollectionCanvas might get some of its stuff broken
out into GraphicalCanvas that might only be relevant to the
CalendarCanvas
Anyway food for thought. I'm still on the fence :)
Alec
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
|
