Both of these are currently needed: idle_resize() is required for
::set_height() to take effect on all affected tracks, and
::redisplay_track_views() is needed to reposition all other tracks as
necessary.
This may be incorrect, since track height changes may be driven
directly (e.g. via menu items) rather than by mouse drags. This may
need revisiting and there may need to be a way to separate dragged height
changes from others.
This allows it to be used in an idle callback. If we use
::redisplay_track_views() directly, we do not disconnect the idle
connection. This will happen automatically since the callback will return
false, but it seems better to explicit about this. Even better would be to use
::connect_once() but this may not be available in the version of glibmm that we
are using at present.
It appears that GDK/glib will not run idle callbacks with a lower priority than
HIGH_IDLE+10 *if* a new user input event is pending. This means that if mouse
motion events are arriving and causing resizes of selected tracks, the call
to ::redisplay_track_views() which is needed to update all the other tracks,
will not take place if a new motion event arrives. Changing the priority to
same as is used for the ::idle_resize() callback prevents new motion events
from being handled before ::redisplay_track_views() is called.
* cleaner table layout
* explicit options for bouncing to Trigger and Clip List
* any bounce is added to Source list, so remove that from menu
* format context menus to match "(with processing)"
* use same code structure where possible
This fixes an issue with the videotimeline not being shown
when reloading a session. Editor::set_state() restores the grid,
which in turn changes ruler visibility. This triggers
store_ruler_visibility() and the saved session state was lost.
* when a menu uses RadioActions, their initial state must be synced
* we use various methods to 'fix' this throughout the program
-> I'm forcing internal state to match in the case the Action is already active
* question: we tend to use RadioActions for all these menu items,
because they represent a choice between many options;
but do we really need to use RadioActions here?
This should not be needed, however Editor::idle_remove_tracks()
has the same priority as Editor::redisplay_track_views() and this
might save us another redisplay call.
The track-height change needs to be applied so that
vertical_adjustment max range is set correctly.
Otherwise vertical_adjustment.set_value() may fail
or scroll to the wrong position.
In 5b3eacd421 `redisplay_track_views()` was moved from
EditorRoutes to Editor. The call was delegated to the idle
thread, potentially collecting multiple calls before performing
the update.
This resulted in "Fit selection" to set the y-offset before the
height-change was applied.
When adding a note, use these criteria to choose the channel number:
* if the user has explicitly specified a note in the pulldown, use that
* if the user has AUTO selected and we are in a region, choose the nearest note's channel (consistent with velocity behavior)
* as a fallback, query the track for its channel-filter (old behavior)
After beginning an edit operation with TempoMap::write_copy(), the tempoPoint and meterPoint objects
referenced by markers are incorrect, since they refer to the original map, not the copy we are working
on. Fix this with Editor::reassociate_metric_markers()
Some instances requiring this fix may still remain
