[linux-audio-dev] LASH and LASH_Terminal client flag problem

Dave Robillard drobilla at connect.carleton.ca
Thu Nov 24 02:03:51 UTC 2005

On Wed, 2005-23-11 at 12:55 +0100, Florian Schmidt wrote:
> On Wed, 23 Nov 2005 16:41:35 +1100
> Dave Robillard <drobilla at connect.carleton.ca> wrote:
> > > This remains though :) So basically apps who save state to files should
> > > ignore state files specified on the commandline when in LASH mode,
> > > except for those apps that are unable to change the state file selection
> > > lateron upon user demand (i.e. little terminal helper tools, that don't
> > > have a GUI or other means to load a different state file).
> > 
> > If it's specified on the command line, why save it as a key and/or file?
> > Pick one. :)
> No, the issue is that the user might very well invoke the client with a
> commandline option specifying a file when initially adding it to the
> session. Lateron he changes his mind and uses the app's menu to load a
> different one. This is all about apps which can _optionally_ specify a
> file via commandline (like ermmm, almost every single one) at startup.
> Then there's conflicting state info in LASH making the app load the one
> state file via commandline first and the other a moment later via the
> restore event.
> > I can put something in the docs, but it's a bit obvious and/or app
> > dependant.  Ignoring some command line arguments is an acceptable
> > solution, but so is ignoring the configure key and/or file.
> No, ignoring the state file from LASH is IMHO absolutely not an option
> as this would then mean the session is not restored in that state which
> the user saved it in. I'd say apps should rather ignore their
> commandline option when they made a sucessfull LASH connection right at
> startup.
> [snip]

Yes, ignoring the command line options is probably going to be the Right
Thing in most every case.

I think a nice easy function to tell if the app is being restored or not
would be handy (that takes argv and argc as parameters).  It's come up
in a couple other cases as well.  The only actual problem with LASH
itself here seems to be that sometimes apps just need to do different
things based on whether they're being restored, or just freshly launched
by the user.



More information about the Linux-audio-dev mailing list