20 Nov
2005
20 Nov
'05
10:32 a.m.
Hi,
in the course of LASH'ifying jack_convolve i stumbled across the
LASH_Terminal client flag which specifies to LASH that the client wants
to be run in its own terminal when the session is restored.
The code for this is in
liblash/loader.c:121
The problem i see is: when the client in the term exits (either by means
of LASH telling it to, or by sending i.e. a SIGINT), it just drops to a
bash prompt instead of exiting the terminal.
For reference i have included the code in question below. I also wonder
why it is necessary to start another bash anyways? I tried to remove the
extra bash call and use xterm -e command_buffer directly, but then the
program doesn't even start correctly.
Any other thought on this?
static void
loader_exec_program_in_xterm(int argc, char **argv)
{
size_t command_size;
char *command_buffer;
char *xterm_argv[6];
command_size = get_command_size(argc, argv);
command_buffer = lash_malloc(command_size);
create_command(command_buffer, argc, argv);
xterm_argv[0] = "xterm";
xterm_argv[1] = "-e";
xterm_argv[2] = "bash";
xterm_argv[3] = "-c";
xterm_argv[4] = command_buffer;
xterm_argv[5] = NULL;
/* execute it */
execvp("xterm", xterm_argv);
...
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
21 Nov
21 Nov
9:13 p.m.
On Sun, 20 Nov 2005 16:32:21 +0100
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
The problem i see is: when the client in the term
exits (either by means
of LASH telling it to, or by sending i.e. a SIGINT), it just drops to a
bash prompt instead of exiting the terminal.
Hmm,
this line seems to be the culprit (liblash/loader.c):
#define XTERM_COMMAND_EXTENSION "&& sh || sh"
as this basically makes sure the xterm is not exited. So maybe this is
even expected behaviour. Hmm, i simply replaced it with "" and am happy
now. Maybe this should be made configurable. Perhaps as an option which
can be specified when restoring a session (default should be xterms
close after the client in them terminates).
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
11:35 p.m.
On Tue, 2005-22-11 at 03:13 +0100, Florian Schmidt wrote:
On Sun, 20 Nov 2005 16:32:21 +0100
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
I don't know of anyone else actually using the terminal client stuff
anyway, so I might just remove that part if there's no objections...
-DR-
The problem i see is: when the client in the term
exits (either by means
of LASH telling it to, or by sending i.e. a SIGINT), it just drops to a
bash prompt instead of exiting the terminal.
Hmm,
this line seems to be the culprit (liblash/loader.c):
#define XTERM_COMMAND_EXTENSION "&& sh || sh"
as this basically makes sure the xterm is not exited. So maybe this is
even expected behaviour. Hmm, i simply replaced it with "" and am happy
now. Maybe this should be made configurable. Perhaps as an option which
can be specified when restoring a session (default should be xterms
close after the client in them terminates).
22 Nov
22 Nov
2:01 p.m.
On Tue, 22 Nov 2005 15:34:14 +1100
Dave Robillard <drobilla(a)connect.carleton.ca> wrote:
> this line seems to be the culprit
(liblash/loader.c):
>
> #define XTERM_COMMAND_EXTENSION "&& sh || sh"
I don't know of anyone else actually using the
terminal client stuff
anyway, so I might just remove that part if there's no objections...
Personally i have no objection to removing the XTERM_COMMAND_EXTENSION.
There's another issue though with LASH which again might be due to my
limited understanding of it.
Imagine starting a lash client where you specify a state file on the
commandline (i.e. someone sent you a synth patch and you want to use it
in one of your projets now).
Ok, so you start your synth as
mySynth AwesomePatchStateFile
This is the commandline LASH will remember for this client app. Now
during the course of the LASH session the user chooses to load a
different statefile via the apps menu. Then the user chooses to save the
LASH prject and then close it (the synth will then save the current
statefile to the dir specified by LASH).
Now what happens on restore?
Well, the client will be started by LASH with the commandline
mySynth AwesomePatchStateFile
and right after starting up it will get a Restore_Data_File (or whatever
it was called) event from LASH which tells it to use a different
statefile (the one from the LASH project dir).
So basically the client loads two statefiles right after the other.
Which is a waste of cpu cycles and might generally be a nuisance for all
kinds of reasons.
I ardour i try to hack around this by stripping "offending" commandline
options from argv before passing it to lash_init.. If this is the
recommended way of solving the problem, i'd suggest the docs should be
updated to reflect this. For different app designs the solutions might
of course look different, so the docs should at least point out the
problem.
Any thoughts?
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
2:20 p.m.
On Tue, 22 Nov 2005 20:01:05 +0100
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
I ardour i try to hack around this by stripping
"offending" commandline
options from argv before passing it to lash_init..
Actually this doesn't work right.
so the docs should at least point out the problem
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).
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
23 Nov
23 Nov
12:42 a.m.
On Tue, 2005-22-11 at 20:20 +0100, Florian Schmidt wrote:
On Tue, 22 Nov 2005 20:01:05 +0100
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
If it's specified on the command line, why save it as a key and/or file?
Pick one. :)
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.
-DR-
I ardour i try to hack around this by stripping
"offending" commandline
options from argv before passing it to lash_init..
Actually this doesn't work right.
so the docs should at least point out the problem
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).
6:55 a.m.
On Wed, 23 Nov 2005 16:41:35 +1100
Dave Robillard <drobilla(a)connect.carleton.ca> wrote:
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.
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. :) 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.
Example usecase:
- add seq24 and om/om_gtk to a LASH session. load stuff via the
respective menus of the apps.
- add jamin to the LASH session and specify a setup file on the
commandline
- drats, wrong jamin setup. So user selects a different one from the
menu.
- user hits LASH session save in lash_panel causing ardour to send its
session file to LASH and jamin saves its whole setup file into the LASH
specified dir.
- user closes LASH session
- user restores it at some latter time -> here the jamin setup file
which was stored in the lash dir should be the only one getting opened.
Ignoring the lash data is not really an option. Ignoring the commandline
option in the first place is one.
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
9:04 p.m.
On Wed, 2005-23-11 at 12:55 +0100, Florian Schmidt wrote:
On Wed, 23 Nov 2005 16:41:35 +1100
Dave Robillard <drobilla(a)connect.carleton.ca> wrote:
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.
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-
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. :) 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]
6821
days inactive
6824
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
2 participants
participants (2)
-
Dave Robillard -
Florian Schmidt