When some other transport related session event (anything that
requires non_realtime_work_pending, e.g. PostTransportOverWrite)
coincides with SessionEvent::AutoLoop, the auto-loop event
was removed from the main event queue and executed as one-shot
immediate event.
While looping the AutoLoop event needs to remain on the main
event queue.
`butler_transport_work()` may be called for various reasons,
notably PostTransportOverWrite. At that point in time the
transport may still be rolling or stopping with rtloc already
set.
This can cause DR::Underruns since seek clear the entire
disk reader buffer.
This is needed to properly decrement "should_do_transport_work".
After a seek the DR:_pending_overwrite flag will have been
cleared, so not much extra work happens here.
The left edge of a region on the the editor is rounded to be
on a pixel. When zoomed out, the position corresponding to that
pixel is not usually identical to the region's position().
We need to correct for this as best as possible, while keeping
peaks aligned to pixels.
Previously loop-wrap around asked the butler to perform
a unnecessary seek operation next time it is summoned.
If the butler is then summoned for a PostTransportOverWrite
event, the seek causes a DR::Underrun.
The signal would be emitted while the session was temporarily renamed,
making it appear that we had switched to the new session, despite instructions
not to do so. We had not actually done so, but the saved-as name would show up
on window titles.
Popup Dialog Windows never unset the modal flag.
e.g. Session > Save Snapshot & switch.
Furthermore a 2nd dialog was able to get the menu stuck
forever (e.g. Snapshot & Switch .. -> Replace existing?
In order for the Filechooser Location widget to work two
things need to be setup, which only the FileChooserDialog
does:
* subscribe to Widget's "response-requested" signal
* call should_respond () hook from top-level window's
default handler.
The Location Entry emits "activates-default". In case of
the Dialog, that calls the dialogs response callback,
which then calls ` _gtk_file_chooser_embed_should_respond`.
That handles changes made by the user to the location entry.
-=-
Gtk::FileChooserWidget does not handle this, "response-requested"
signal is not exposed, nor is _gtk_file_chooser_embed_should_respond
available outside Gtk.
This change at least selects the file in the treeview, which
allows further handling, without interfering with FileChooserDialog's
behavior.
