On Monday, September 19, 2011, Ian Gardner wrote: > I'm happy to look at implementing these differently if we decide so. For > example, we could resize all segments in the link group from the left when > resizing one of them.
I played around with resizing both ways, and came back up to the top of this message to delete all my first reactions and start over again. First, resizing from the right... I'm not sure if it's a bug or a feature the way this works. If you have three linked segments, you can resize any one of them to different lengths on the right. Let's say you end up with sizes l-2, l+1 and l+3. If you go into the l+3 segment and add notes to the very end, the l+1 segment lengthens, and you end up with two l+3 and one l-2. The shorter segment stays shorter, no matter what you do to the tail end. I can see that being potentially useful as a feature. Say you're composing a canon with the same part in different tracks, staggered in time, and you need to bring it all together at the end and write a different ending segment for each part. I can also see it being terribly, terribly confusing. I'm almost inclined to say that resize should only work on the master, and if you try to resize any of the copies, from either direction, it just fails silently. I haven't been able to find a way to determine which segment carries the "I am master" property though, if any does. It looks like after there are links, everything isLinked() == true and the segments don't have a common getRealSegment() pointer, but act more like a linked list or something. The idea of "I am master" and "I am slave" seems to be weak, or non-existent, based on a little bit of time faffing about without really studying your implementation. Of course even with a clear master/slave relationship, and resizing only working on the master, you still have hard questions what to do about the start times of all the slaves when resizing from the left. Do you leave the start time where it is, and effectively slide everything back when length disappears off the left end, or do you effectively move all the slaves forward in time? I'd say those questions are just about hard enough to justify doing exactly what you're already doing as the only sane answer. If it's too hard to guess the right thing to do, punt, take a deep copy, and if that wasn't what the user wanted to do, that's what undo is for. They'll figure it out soon enough. > Also we could, when cutting a range from or pasting > a range into a linked segment, honour the range cut or paste in all the > links too. This might get messy though! Doable though I'd have though. Ugh. That makes my head hurt just thinking about it. What do you think about when you paste a range that inserts a slice into any linked segments, they just become deep copies? Is that what you're already doing? If so, that gets my vote. You could drive yourself nuts trying to do it any other way, and I think this is another place where you should probably punt. -- D. Michael McIntyre ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
