On 12/23/2009 06:27 AM, Patrick Shirkey wrote: > 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. > > Cheers. > > -- > > Patrick Shirkey > Boost Hardware Ltd > > > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
