If the "Sorry I cannot do that" dialog is displayed from
FloatingTextEntry::use_text(), the entry is still visible and accepts
[focus] events. Also the dialog returns focus and multiple
idle_delete_self() will be called for an Entry that's already being
deleted.
Issue #7429 reports that that clicking a route of an already selected group
does not update the editor mixer strip selection. To fix this we call
Editor::set_selected_mixer_strip() at the end of
RouteTimeAxisView::selection_click();
The overhead of maybe calling it twice should be toleratable, as
::set_selected_mixer_strip() checks, if the route is already the current mixer
strip route before setting it.
* If the use-time-rulers-to-zoom option is enabled, -all- cursor drags can zoom.
* Behavior has been tweaked so it is easy to scroll without zooming, if you want to.
Depend on Changed() signals alone, which are usually much less frequent
than rapid-timer events.
As side-effect we now need to make the widgets insensitive when
playing automation. Previously the user could not change the value because
the Timer periodically reset it.
`.config/ardour5/(templates|route_templates)`.
We put as toplevel directory of the archive `templates` or
`route_templates`. Then no matter if the user imports a session template or a
route template archives, we always put them into the correct folder.
As now the user can also import route templates while the
SessionTemplateManager is visible and vice versa, we need to signal the
successful import to the corresponding template manager. Therfor we introduce
the signal TemplatesImported.
Don't use this now, except for testing as the archive format will change.
TBD:
* error handling
* check template would be overwritten by import
* dinstinguish between session and track templates
This concernes:
* LV2 states:
LV2 states are stored in the template directories and their paths are stored
int the template files using absolute paths. Therefore we have to adjust the
template-dir property of every lv2 node referring to a state dir.
* Names of route templates.
The name of the route template is stored in the first child of the xml root
node in the property `name`. This needs to be adjusted when renaming the
template.
By now we rely on that only lv2 states and the route template name need to be
adjusted on renaming a template.
Following measures:
* Split up into two classes
* TemplateDialog: the general dialog
* TemplateManager: A widget to rename and remove templates
* Make TemplateManager abstract and derive a class for session templates and
one for route templates. This is needed, as session templates and route
templates are stored in a different way. Thus we need different methods to
rename and remove them.
Goal is to a simple dialog that can rename and remove templates. This is
helpful in order to keep the template list tidy.
So far it works for session templates. Track templates tbd.
