21 Nov
2009
21 Nov
'09
11:25 p.m.
On Sun, 2009-11-22 at 01:46 +0100, torbenh wrote:
Not sure what you're getting at here. Of course apps have to save their
state, that's the whole point?
On Sat, Nov 21, 2009 at 07:30:02PM -0500, David
Robillard wrote:
I assumed it was a possible value of jack_session_event_t, but I see
it's not. n/m
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 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 ?) 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