For some reason, grabbing the magic keyboard focus makes scroll stop working
regardless of what MRV::canvas_group_event() returns. I can't figure out any
reason to grab the keyboard in this case anyway, so I just removed it.
Also simlify MRV event handling code in general.
No functional changes in this one (for easier auditing), but towards having
round up/down only if necessary modes, rather than kludging around that
situation with a double round as we do currently.
This cleans up a lot of false-positives in static analysis
and also helps compilers to optimize code paths in general.
(tagging the fatal stingstream operator as ‘noreturn’ is
far less trivial)
Fix crash with midi-regions (they have a frame-handle but no x-fade).
fixes 2nd part of #5992 (backtrace 20141021-B)
This is nicer in one way: When the cursor is "trim" the x-fade
context menu is no longer accessible.
And a bit worse: The x-fade context menu is only accessible on the
small fade-handles (boxes) and on the x-fade itself.
Problem: mouse-scrolling over a MIDI region in internal edit mode
never released “magic widget focus” (mod keys and global scrolls after
that were ignored). -> added to leave_notify.
Also, the MouseModeChanged signal needs to be emitted when internal edit,
mode changes in order to trigger MidiRegionView::mouse_mode_changed(),
which in turn releases the magic focus while still hovering over a MIDI
region.
TODO: needs undo. only works in top quarter of automation lane. selection model feels weird sometimes. needs to show gain curve when you are using Range tool
To handle any further issues like this, I generalized and added an optional argument specifying that the canvas=>trackview transform is required, thus
centralizing where this done.
The idea now is that a scroll group item can be added to the canvas which will causes its children to scroll in either or both
directions (horizontal or vertical). There are few complications: the position() of the ScrollGroup is ambiguous depending
on whether you want it with scroll taken into account or not, so Item::canvas_position() was added, which defaults to
the same value as Item::position() but is overridden by ScrollGroup to return the position independent of scrolling. This
method is used when translating between item/canvas/window coordinate systems.
Note that the basic idea is that we MOVE the scroll group when a scroll happens. This mirrors what happens in the GnomeCanvas,
where Nick Mainsbridge came up with a great idea that allowed unification of the time bar and track canvases.
Add a value for Ripple to EditMode enum.
Add Ripple edit mode to edit mode dropdown, by adding it to the
Editor::build_edit_mode_menu() helper function, and remove the old code that
added items to the (now unused) Editor::edit_mode_strings.
Add the regions that should be affected by the drag to RegionDrag::_views so
that the drag carries them along automatically.
Use a copy of the RegionList in Playlist::core_ripple(), since bad things
happen when iterating over regions and they get moved around in the list.
Handle rippling in removal of regions from playlist.
When dragging in ripple mode, exclude all regions that lie before the
original start position of the selected regions being dragged from
rippling: this is what Mixbus does.
Make editor dragging respect snap-to settings, by using the existing
compute_x_delta() function, which did almost the right thing. Move setting
of _last_frame_position out of that function so all ripple-dragged regions
can move.
Ripple when dragging from region list: even though Mixbus doesn't do this, it
seems like a good idea.
Prevent multi-track selection being dragged across tracks, by making
RegionMotionDrag::y_movement_allowed() virtual, and overriding it in
RegionRippleDrag to forbid dragging of selections containing regions on more
than one track to dofferent tracks in ripple mode.
Remember which TimeAxisView a ripple-mode drag that's allowed cross-track
drags started from, so that the effect of rippling regions after any region
that's dragged off that track can be undone.
This started happening more frequently after this function started to be called more often (which was the right thing to do, but
had this side effect (now fixed).
Many more changes than I would typically like in a single commit, but this was all very intertwined.
Vertical scrolling using track-stepping still to follow.
On clicking on a region that is part of an active edit group with the
'selection' property enabled, its equivalent regions also become selected.
Thus, there's no need to reset the selection to the equivalent
regions when performing mouse drags on the region, and trim/fade in/fade
out/move/copy will always operate on the existing region selection if there
is one.
Fixes#5515.
Also make it work for pencil.
This is the canonical Ardour MIDI noob "I can't even create notes, this crap is
impossible to use or doesn't work at all" use case:
1) Create MIDI track
2) Click in that track, with object or pencil tool
3) ** A region is created ** - aha!
4) Click in that region, notes are created
Breaking step 3 ruins everything. Please don't.
git-svn-id: svn://localhost/ardour2/branches/3.0@13932 d708f5d6-7413-0410-9779-e7cbd77b26cf
