On Friday 25 Feb 2005 16:36, Chris Cannam wrote: > On Wednesday 23 Feb 2005 22:29, Guillaume Laurent wrote: > > 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 [...]
Actually no, maybe forget I said that. The Staff and LinedStaff stuff doesn't gain us much, but it does gain us _something_ (lines and barlines) and it's there and working OK. We haven't had many problems with it lately. Same goes for the MatrixItem/ViewElement stuff -- it turns out it's really overkill, but it's not exactly problematic and the tricky bits to do with updating the view elements on segment changes and so on have already been dealt with. Both of these are clear enough from a design perspective, it's not like they're particularly messy in and of themselves, there's lots of code in the tool classes etc that knows how to deal with them already, and it's all in better shape than the segment canvas ever was. The only thing there that's really still a mess is dealing with selection, and perhaps that just calls for a single separate selection-related refactoring exercise. No, what _is_ a problem is the QCanvas and its limitations, and the consequent use of things like matrix transforms everywhere for zooming. So how about we just look for a more lightweight way to replace only the QCanvas and eliminate the transforms? Something that bases its horizontal scaling purely on an existing RulerScale, that takes advantage of the fact that we know the elements are in a particular order and some of them (the lines etc) don't need to be interacted with, and so on. Perhaps it could work a bit like the canvas from the point of view of drawing lines (the line items in LinedStaff attach to it as if it were QCanvas, and it handles them in a similar way) and then handle the matrix ViewElements directly by picking them out of the MatrixStaff (because they're all the same and tidily ordered) instead of dealing with QCanvasRectangles as graphical objects per se. It would still be necessary in this model to sweep the matrix items and give them all new positions when the zoom changed, but calculating the positions is very cheap, it was creating and destroying all the canvas items that was expensive before, and we wouldn't need to do that. The other advantage of doing this would be that it might point to a way to optimise the NotationView in a similar fashion -- something that the current CompositionView treatment never will, at least not without a prohibitive amount of work (because of the sheer quantity of code that deals with NotationElements and the like). What d'you think? 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
