On Friday 25 February 2005 17:36, Chris Cannam wrote:
> On Wednesday 23 Feb 2005 22:29, Guillaume Laurent wrote:
> > No graphic objects are really stored
>
> The rectangles are clearly stored, at least for some length of time.
Look at CompositionView::drawContents(). It calls
m_model->getRectanglesIn(<the area to redraw>), which returns a rectcontainer
(so yes, you might argue they are stored "for some length of time"), the
rectangles in this container are drawn, and then they are discarded (actually
what really happens is that to avoid silly copying the rectcontainer is a
data member of the model, which fills it up at each call to getRectanglesIn()
and passes it as a const ref).
> Why otherwise do you have that function that tests whether something has
> been changed by comparing its stored time extents with times calculated
> from the approximated rectangle extents?
Because I was being stupid when I wrote it. That function is broken and no
longer used, I'm now using a simple bool flag local to each tool to get the
same result. OK, I forgot to explain what happens when you're interacting
with the whole thing :
What QCanvas::collisions(point) is replaced by
CompositionModel::getItemAt(point), which constructs CompositionItems on the
fly. Like the rectangles above, these items, although being more or less the
equivalent of QCanvasItems, are kept by the tools for only as long as the
interaction lasts, and like the rects they are discarded immediately
afterwards.
> The point is that we need to avoid _ever_ converting from graphical
> coordinates to time coordinates, except when the user is explicitly
> setting a new time for something based on moving it on the screen, and
> then ints are perfectly adequate because they're the resolution the
> user is seeing anyway.
Which is basically what happens when the user is interacting with an item,
right ? So when he does that, he changes the values of the current
CompositionItem. Once he's done, the changes to that item are reflected on
the model. That's the only case when this kind of computation is done.
> So:
> > Basically, it's a Model-View pattern. There's a model on the
> > Composition (CompositionModel), which only computes what rectangles
> > represent a given time segment.
>
> It doesn't though, does it? It computes the rectangles that represent a
> given graphical coordinate segment. Why not pass it an actual time
> range (plus y-coords as you wish), keep time values for x coords in the
> items, and then convert them in CompositionView::drawContents etc?
> Otherwise, you'll have to mix ints and timeT values in the item to get
> it to do the right thing with repeats (because you can't store the
> repeat duration in graphical coordinates without some risk of rounding
> errors).
I'm probably too weary to give this a proper answer but I fail to see the
difference between what you suggest and what I actually do. In both cases,
you have an x,y-based drawing area on one hand, and a timeT,TrackId-based
data structure on the other. So what difference does it make that I'd convert
the timeT to x coord in the View as you suggest, or in the Model as I
currently do ? (except that it breaks the clean seperation I've tried to
maintain between the view being strictly x,y-based and the model being all
timeT,trackId-based).
> Well, there are various conflicting forces at work here. It's possible
> that losing the Staff from the matrix might not bother anyone much,
> because the benefit it conveys is fairly minimal anyway -- it's more
> handy as a way of requiring the Staff code to be able to handle diverse
> layouts than as something we actually need in the matrix.
Precisely, the Staff would be a great basis for the model, so I'd rather keep
it around :-).
--
Guillaume.
http://www.telegraph-road.org
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
