Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
When setting up the 'TemplatesImported' signal, these 2 calls appear in the c'tor for class TemplateDialog:-
boost::bind (&RouteTemplateManager::init, route_tm)
boost::bind (&SessionTemplateManager::init, session_tm)
However - '&RouteTemplateManager::init' and '&SessionTemplateManager::init' are in fact the address of the same function. This seems to be causing a problem, either for boost::bind, or MSVC (or both).
In earlier builds they were 2 separate functions. So let's put them back that way (since the current code actually crashes the compiler!!)
Labeling it "Ok" would imply that by clicking it, descriptions would be saved
without further interaction. If we did so, we would also need to add a
cancel-button or handle simple closing of the dialog window appropriately.
`.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.
