21 Nov
2009
21 Nov
'09
8:46 p.m.
On Sat, Nov 21, 2009 at 07:30:02PM -0500, David Robillard wrote:
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.
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...
>
> It seems sort of redundant to have restoring via command line when we
> already have a restore callback that does that anyway. What if instead
> we give a unique ID to the application itself only(*). Then, before
> calling jack_client_open, the client must call
> jack_client_set_id(myappid) so Jack (and/or the session manager) knows
> what it is. The session manager can then restore it via the usual
> callbacks. Then app authors only need to implement restore once, in the
> callback, and don't have to deal with command line stuff at all (which
> can be pretty annoying in some cases). I suppose this requires that the
> command line arguments of the app are basically irrelevant though, but
> the appp could save those same settings to the save directory too...
err... which app doesnt support loading a statefile when being started
via commandline ?
i also think that the restore event only makes things more complex.
Just a thought, trying to make it simpler and purely API based.
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)
Cheers,
-dr
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language