combines selection related editor properties with the current editor selection.
The related editor properties are:
mouse mode,
zoom setting,
left frame of the canvas,
y origin of the canvas.
Selection state now includes region views (storing the underlying region id)
and time.
This patch also fixes a region mute undo bug.
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.
