> On 03/25/2013 02:01 PM, Tom Breton (Tehom) wrote:
>> What do you think?
> I agree that it's not even worth paying much attention to the current
> behavior, as there isn't anything particularly good about it that needs
> to be preserved carefully.
> It seems like the thing to do is go ahead with your plan, then let's
> play with it, and see if anything needs fine tuning. It might need a
> couple of extra rules to deal with this or that, or it might come out
> just great on the first try. It seems like a good start in any event,
> and I see no reason why you shouldn't jump in and have a go.
OK, I coded it up. Since 13.04 release is in progress, I'll put it on a
new branch, say notation-move-vertically.
* In general, it works well.
* It doesn't seem like what Aere was concerned about will be an issue.
It moves OK even with all sorts of gaps between segments.
* Surprisingly, the major coding problem is making the playback pointer
visible initially. NotationWidget::slotPointerPositionChanged and
Panned::slotEnsurePositionPointerInView contain a bunch of checks, and
when I call it explicitly, one or more of the checks is failing in some
* I said that if no segment contains the playback, "use the nearest", but
now that looks to be a significant change for little apparent benefit.
(Whereas the "contains" logic just re-uses existing code) I will still
code that if people really want focus to go to the nearest segment, but
if it's not important to anybody I won't.
* I said that "I don't think it's worth doing anything about" how we pick
the initial track. But surprisingly, that part was trivial. Right now I
have it trying first the selected track, then the first track being
edited (visually highest). I would really like feedback on how people
think it should go. Me, I don't pay that much attention to selected
track, so I'd just as soon always use the first track, but it's about 6
lines of code so it's easy to change.
* Bonus: slotMoveEventsUpStaff/slotMoveEventsDownStaff are less
error-prone. No more squashing notes together in the wrong segment!
This just fell out. They use getStaffBelow/getStaffAbove too, so for
them I just passed the time the selection starts instead of playback
pointer. So now they find a reasonable target segment if available.
(They probably still kaboom if you move upwards from the top staff etc)
Tom Breton (Tehom)