On Wed, 23 Nov 2005 16:41:35 +1100
Dave Robillard <drobilla(a)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.
Thoughts?
-DR-