this needs more investigation but we need to return false from
scroll event handling in order for stuff to work. this should
not be the case and this will likely be reverted once the reason
it is required is uncovered
This method did not do what its name suggested. Replace it with
::absolute_time_to_source_beats() which already existed and
computed the same result.
Also in a NoteCreateDrag, correctly adjust note start
depending on whether we are viewing the whole source or
just the region. This part may be amended later.
Found via `codespell -q 3 -S "*.pdf,*.po,./.git,*.tosc,./waf,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch" -L acount,addin,ane,ba,buss,busses,caf,capela,devine,disconnectin,discreet,doubleclick,envolution,filetest,fo,ghandi,homs,hsi,layed,maschine,mis,nd,ontop,pass-thru,removeable,retrn,ro,scrollin,sectionin,seh,siz,sord,sur,te,trough,ue,wth`
Note that for now, this leaves save/restore of the value to the time axis view, and doesn't alter
the fact that the MidiTrack represented by the axis view continues to have its own note mode too
Clip editors show the entire source contents, which alters the conversion
process needed for dealing with pixel/length/duration values versus the
situation when only showing a region (as on the timeline)
It appears that mouse handling in MidiRegionView (now moved into MidiView)
predated the full Drag formalization. This led to inconsistencies as parts of the Drag
formalization were adopted, including the use of motion events to start a drag (this
is incorrect in the current semantics of a Drag).
This commits removes all/most of the special purpose drag handling machinery in MidiView
and uses Drags instead
in particular, rename MidiView::canvas_group_event() to
avoid confusion with TimeAxisViewItem::canvas_group_event()
since a MidiRegionView inherits from both these classes.
