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. 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? Failure practically guaranteed, and I see you're doing something else instead of calling it now, but the function's still there. (At the least, that function should do it the other way around -- recompute the graphical extents from the stored times and see if they match the extents on screen.) > [...] It's quite conceivable to have those rects bear double > coordinates rather than int, though. No, you're missing the point. The graphical bits should use ints. If we're ever doing a calculation whose result depends on whether the graphical values are stored as ints or doubles, then it's practically guaranteed that we're making a mistake in the first place. 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. Want to compare a rectangle with a segment to see if its extents are the same? Convert the segment's times to graphical coordinates and compare those: don't convert the rectangle's coordinates to times. Want to draw a repeating trail for a segment? Calculate the location of each repeat in time and convert it to graphical coordinates when you draw it: don't start from a given graphical coordinate and repeatedly add a given graphical increment (as both the old and new segment canvases do, or did -- I've actually just fixed this in the 1.0 branch if you want an example of what I mean, and yes, it did result in a user-visible error). Want to draw bar lines? Calculate where they are in time coordinates, and then convert each one of those: don't calculate how far apart they are on the screen and then draw at those intervals. Want to refresh some segment rectangles after the canvas has been scrolled or zoomed? Look up their times and reconvert them: don't just translate or scale their previous graphical coordinates. 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've been trying to adapt the same pattern over the matrix but it's > proven much harder than I thought, partly because I tried to leave > the notation working but there's quite a lot of common code between > them (the whole Staff system). 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. Maybe you should take that approach -- can the Staff (and layout objects if you wish) from the matrix altogether. Do that one on a branch though if you're going to. Chris ------------------------------------------------------- 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
