On 12/23/2009 01:32 AM, Gabriel M. Beddingfield
wrote:
On Tue, 22 Dec 2009, alex stone wrote:
And I can
be OK with that... as long as it's in the specs that it should
work this way.
But at the moment, it's not well defined what is part of the "state,"[1]
nor
what should (and should not) be saved in a "jacksession" directory, nor what
can be expected WRT portability.
But it was defined. A file that showed the saved state of each app
present in the session, and a list of all connections that were
current at the time the session was saved. Couldn't be simpler.
So, if 'Foomatic DAW' saves state with a one-liner like
this:
<foomatic_session id='EBC429B5-373B-4840-8CCA-99FBE045EF82' />
That satisfies the requirements of your sentence.
Jack_session has gone a bit further already.
char *
session_callback (jack_session_event_t code, const char *path, const char *uuid, void
*arg)
It's not exactly portable because it relies on the app to do all the
work with file storage. To make it portable would require an addition to
the yet to be written management interface. Functionality could be added
to create a portable archive file of the session with a single click. We
already have the path for each clients internal data folders so all that
would be needed is to add a small function to the interface to copy them
to a new location, and compress the complete set of files.
That seems like a quick and efficient method of enabling session transfer.
My list of requirements for the session management interface is growing
but I'm happy to see them becoming more defined.
1: Provide options to user for handling client renaming issues with
clients that are already running.
- killing already running apps before loading a session
- attempting to rename the apps without restarting them
- load a new jack instance and connect it with via netjack
- load a new jack instance and connect it directly to the already
running jack instance. Should be ok with a multicore and plenty of
memory but is it possible to define a jack instance as a parent for a
jack child instance?
2: Provide one click archive feature to allow session transfer. Copy
client data folders to a new location, and compress the complete set of
files.
3: Define default behaviour in a config file.
I would be very happy to have this in place and it would accomplish
everything that I currently need for desktop session management. With
the exception of having a jack menu on the window decorations title bar
for each client and handle the session and connections management
through that. With the above in place I can wait another 10 years for
integrated desktop window manager functionality to arrive :-)
integrated desktop window manager functionality
That should be on some packaging and promo material somewhere real soon now.