On Sun, 2009-11-22 at 01:46 +0100, torbenh wrote: > On Sat, Nov 21, 2009 at 07:30:02PM -0500, David Robillard wrote: > > On Sat, 2009-11-21 at 19:03 -0500, David Robillard wrote: > > > Ah. Maybe not very portable? > > well... commandline parameters are not totally portable, thats true. > thats why i basically avoid to say that its commandline parameters. > on windows or osx, it might be something different. > > also i dont have a restore callback. > hmm... you proposed one int other mail i guess...
I assumed it was a possible value of jack_session_event_t, but I see it's not. n/m > i also think that the restore event only makes things more complex. It allows loading a different session without shutting down the app entirely, but I guess that's no big loss. Apps shouldn't take forever to start up anyway :) (plus it's much more bug prone) > > On second thought, I see the utility of command line stuff, though maybe > > it should be sent as argc and argv for more portability and less > > nuisance for apps that just want to pass them straight through? (no need > > to assemble an actual command line string, which is both annoying and > > not portable) > > on windows you only have an args string. > however i dont see what an app which cant save its state. (iE > jack_netsource, should do ?) Not sure what you're getting at here. Of course apps have to save their state, that's the whole point? > snprintfing some commandline string shouldnt be a problem at all. > i dont see why this should be so complicated. I don't think this makes it more complicated, but it does make it portable, standard C, and makes sense for libraries/plugins; but I don't really care enough to argue about it. If jack_initialize and friends took an argv that would be a strong argument for it, but they just take an arbitrary string, so I guess that's an argument to use a string. For internal clients the returned string would not be a command line but the argument to jack_initialize -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
