> 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.

OK.

> [...]
> 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
unobvious way.

 * 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)



------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

Reply via email to