On Sunday 13 September 2009, Shelagh Manton wrote: > Maybe you could borrow a paradigm from graphic drawing programs where > there are layers, one *is* the base layer
The problem with doing that kind of scheme with Rosegarden is that it is something like a GIMP where all the images are open on the same big canvas, and you have multiple discrete chunks of "base layer" that you can move around all on that same canvas. As long as these discrete chunks only butt up against each other, but never overlap, there is no problem. The trouble comes when you overlap one chunk of base layer with another. A new layer is created spontaneously, and one segment or the other is promoted to that new layer. Both of these were "base layer" segments to begin with, so which one of them is promoted, and which one is retained on the base layer? Now what happens when you drag both of these over some third segment? I think the only way to solve those issues would be to give segments themselves the ability to possess layers, and stop allowing segments to overlap at all. The idea of segments possessing layers unto themselves has always been appealing to me, but we have a whole lot of existing infrastructure designed around a different concept, and it's much easier to continue working within that framework than it is to introduce such big changes and then sort out all the consequences. For one thing, when loading an old data file, which is something Rosegarden has always done exceedingly well, wherever segments overlap, they would have to be split off onto as many tracks as it took to contain them all without overlaps, and users would be left to convert them to layered segments manually, if desired. Importing something into this scheme would represent a pretty fundamental and permanent change to the original structure, and this fact in of itself would present sharing problems for users on either side of the file format version transition point. True, we've introduced changes before that would be lost when loading and saving the file with an old version of Rosegarden, but nothing that would alter the data this fundamentally. It's something to think about, although that in of itself is not the reason not to do layered segments at this time. It's just a question that such a large scale rewrite is out of scope for Thorn, and we've got to come up with some other solution in the interim, whether we should ever implement segment layers or not. As far as interim solutions go, Julie's "expand onto separate staffs" vs. "compress onto one staff" idea could not only be workable in the interim, but in the long term too, and could obviate the need for segments to possess layers at all. Sometimes it is difficult to decide whether it is best to keep working on the old clunky wiring or blow the buliding up and start from scratch with a better design. All of our decisions in this area so far have involved electrical tape and wire nuts. For instance, the reason we're using overlapping segments for notation layers at all is because one day someone overlapped some segments full of notes, and observed that the notation view could already make sense of the situation for free. Now we've got the same sort of thing going on in the matrix too, with the as yet incomplete but very plausible ability to overlap multiple segments on the same notation canvas. It seems far more likely as a practical matter that we will continue working with the overlapping segment paradigm, and layered segments will never happen, no matter how much I've always been fascinated with the concept. -- D. Michael McIntyre ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
