4 Jan
2010
4 Jan
'10
8:04 a.m.
Hi,
I don't know who locked himself up after the 'LADI' discussion to
actually write an session handler for Linux. :) But in meantime Ladish
has added 'level 1' support:
"When ladish studio is being saved, applications that are run at level 1
receive the SIGUSR1 UNIX signal.
In signal handler function, a global variable can be set to mark that
save is needed. On next main loop iteration, the global variable is
checked and eventually save is made.
Save of the internal state can be made in a fixed file path, but it is
more useful to supply the file path through commandline. When starting,
app loads its internal state from the file specified. When saving, app
saves its internal state to the file specified."
http://ladish.org/wiki/level1
Ams, Jack_Mixer and calfjackhost (in progress) has already added level
1 support, and it seems to work OK (all though there are some
improvements ahead).
An advantage compared to 'LASH' or 'Ladish' support seems to be that
level 1 is pretty easy to implement by the application developers.
Now I'm wondering whether this 'level 1' could be a point of agreement
between different (potential) Session Handlers for Linux. If other
Session Handlers also adds 'level 1' support, it would make the
implementation of more then one Session Handler more easy and less
problematic for the Linux Audio world in my opinion. What do you think?
Regards,
\r
8 Jan
8 Jan
5:31 a.m.
rosea grammostola wrote:
Hi,
I don't know who locked himself up after the 'LADI' discussion to
actually write an session handler for Linux. :) But in meantime Ladish
has added 'level 1' support:
"When ladish studio is being saved, applications that are run at level
1 receive the SIGUSR1 UNIX signal.
In signal handler function, a global variable can be set to mark that
save is needed. On next main loop iteration, the global variable is
checked and eventually save is made.
Save of the internal state can be made in a fixed file path, but it is
more useful to supply the file path through commandline. When
starting, app loads its internal state from the file specified. When
saving, app saves its internal state to the file specified."
http://ladish.org/wiki/level1
Ams, Jack_Mixer and calfjackhost (in progress) has already added
level 1 support, and it seems to work OK (all though there are some
improvements ahead).
An advantage compared to 'LASH' or 'Ladish' support seems to be that
level 1 is pretty easy to implement by the application developers.
Now I'm wondering whether this 'level 1' could be a point of agreement
between different (potential) Session Handlers for Linux. If other
Session Handlers also adds 'level 1' support, it would make the
implementation of more then one Session Handler more easy and less
problematic for the Linux Audio world in my opinion. What do you think?
Hi,
No 'onlist' replies? I think it's in anyones benefit to communicate
about the goods and bads of some designs. We might learn something from
it, rearrange and improve things..
\r
8:55 a.m.
Regarding LADI Level 1...
On Fri, 8 Jan 2010, rosea grammostola wrote:
> In signal handler function, a global variable can
be set to mark that
> save is needed. On next main loop iteration, the global variable is
> checked and eventually save is made.
This totally confused me at first. "You're sending me a
UNIX signal... but then I'm supposed to answer back by
allocating a global variable? How do I do that?"
I think what you mean is to indicate that saving doesn't
have to happen in realtime, but that it can happen (for
instance) as part of the program's normal event loop. The
stuff about the global variable (or even an event loop) is
an implementation detail.
I suggest the wording be changed to say something like this:
"The application, after receiving the signal, should
save as soon as possible. However, the saving does
not have to happen in the signal-handler function
itself. (For example, you can push a 'Save Event' to
your normal event loop.)
> Save of the internal state can be made in a fixed
file path, but it is
> more useful to supply the file path through commandline. When
> starting, app loads its internal state from the file specified. When
> saving, app saves its internal state to the file specified."
This is also confusing wording (to me). Who is setting this
file path? And the commandline?? I thought we were
handling a signal.
May I suggest the following wording:
"The application is free to save state however it
sees fit (e.g. saving files to a fixed file path).
When the application is started, some means of
restoring the state needs to be given to the user,
preferably from the commandline. For example,
when the signal is received, the application will
give a string id (such as a file path) to the
user. This id may then be used as a commandline
argument to restore the state."
I think this is a good idea (Nedko or whoever dreamed it
up), and I'm willing to add it to my applications.
Peace,
Gabriel
9:47 a.m.
"Gabriel M. Beddingfield" <gabrbedd(a)gmail.com> writes:
Good wording again, I've put it on the wiki page with the correction
that "needs" is replaced with "could". There is no need, some apps
may want to operate on state in fixed location.
Regarding LADI Level 1...
It is said "set" not "allocate".
> In signal handler function, a global variable
can be set to mark that
> save is needed. On next main loop iteration, the global variable is
> checked and eventually save is made.
This totally confused me at first. "You're sending me a
UNIX signal... but then I'm supposed to answer back by
allocating a global variable? How do I do that?" I think what you mean is to indicate that saving
doesn't
have to happen in realtime, but that it can happen (for
instance) as part of the program's normal event loop. The
stuff about the global variable (or even an event loop) is
an implementation detail.
I suggest the wording be changed to say something like this:
"The application, after receiving the signal, should
save as soon as possible. However, the saving does
not have to happen in the signal-handler function
itself. (For example, you can push a 'Save Event' to
your normal event loop.)
Good wording, thanks! I've updated http://ladish.org/wiki/level1
> Save of
the internal state can be made in a fixed file path, but it is
> more useful to supply the file path through commandline. When
> starting, app loads its internal state from the file specified. When
> saving, app saves its internal state to the file specified."
This is also confusing wording (to me). Who is setting this
file path? And the commandline?? I thought we were
handling a signal.
May I suggest the following wording:
"The application is free to save state however it
sees fit (e.g. saving files to a fixed file path).
When the application is started, some means of
restoring the state needs to be given to the user,
preferably from the commandline. For example,
when the signal is received, the application will
give a string id (such as a file path) to the
user. This id may then be used as a commandline
argument to restore the state." I think this is a good idea (Nedko or whoever dreamed
it
up), and I'm willing to add it to my applications.
What are your applications?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
9:50 a.m.
On Fri, Jan 8, 2010 at 1:46 PM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
"Gabriel M. Beddingfield"
<gabrbedd(a)gmail.com> writes:
> "The application, after receiving the signal, should
> save as soon as possible. However, the saving does
> not have to happen in the signal-handler function
This is far too weak -- it _cannot_ safely be done from a signal handler.
Chris
10:06 a.m.
On Fri, 8 Jan 2010, Chris Cannam wrote:
On Fri, Jan 8, 2010 at 1:46 PM, Nedko Arnaudov
<nedko(a)arnaudov.name> wrote:
Why not?
-gabriel
"Gabriel M. Beddingfield"
<gabrbedd(a)gmail.com> writes:
> "The application, after receiving the signal, should
> save as soon as possible. However, the saving does
> not have to happen in the signal-handler function
This is far too weak -- it _cannot_ safely be done from a signal handler.
10:16 a.m.
On Fri, Jan 8, 2010 at 2:06 PM, Gabriel M. Beddingfield
<gabrbedd(a)gmail.com> wrote:
On Fri, 8 Jan 2010, Chris Cannam wrote:
A signal handler can be called at any time, so can't safely interact
with its environment (even with the heap) in any meaningful way.
e.g. C99:
"If the signal occurs other than as the result of calling the abort or
raise function, the
behavior is undefined if the signal handler refers to any object with
static storage duration
other than by assigning a value to an object declared as volatile
sig_atomic_t, or
the signal handler calls any function in the standard library other
than the abort
function, the _Exit function, or the signal function with the first
argument equal to
the signal number corresponding to the signal that caused the
invocation of the handler."
So the only thing you're allowed to do, besides exit, is assign to a
global volatile sig_atomic_t variable and return.
Realistically you may be able to get away with more than that, but
saving a document is definitely out.
Chris
This is far too weak -- it _cannot_ safely be done from a signal handler.
Why not?
11:31 a.m.
On Fri, 8 Jan 2010, Chris Cannam wrote:
So the only thing you're allowed to do, besides
exit, is assign to a
global volatile sig_atomic_t variable and return.
Thanks, I wasn't aware of that.
I was originally thinking, "it's up to the application to
figure this out... I don't care how they handle the signal
-- just as long as they save 'soon'." However, I think
putting in this warning from C99 would do well to ensure
that it's implemented properly.
-gabriel
10:03 a.m.
On Fri, 8 Jan 2010, Nedko Arnaudov wrote:
The main one is Composite[1], which will release a sampler
this month. I have some smaller apps jack_midi_clock[2]
that doesn't need to save state, and InConcert[3] that would
need to save state... but is currently not being worked on.
I've stepped away from Hydrogen[4], but if I were still
involved I would add it there as well. However, I'm sure
that Sebastian and Wolke would be interested. H2 is already
has about 99% of what's needed.
-gabriel
[1] http://gabe.is-a-geek.org/composite/
[2] http://www.teuton.org/~gabriel/jack_midi_clock/
[3] http://www.teuton.org/~gabriel/InConcert/
[4] http://hydrogen-music.org
I think this
is a good idea (Nedko or whoever dreamed it
up), and I'm willing to add it to my applications.
What are your applications?
6:37 a.m.
Chris Cannam <cannam(a)all-day-breakfast.com> writes:
On Mon, Jan 4, 2010 at 12:03 PM, rosea grammostola
<rosea.grammostola(a)gmail.com> wrote:
Currently an app cannot do it at software level. The level 1 support
just needs to be documented. In future, what levels are supported will
be indicated by fields in the .desktop files. Until then users are
supposed to know whether given app supports given level and indicate it
when they start the app. This is done by a radio button selection in the
gladish app start dialog. The dialog can be seen in the ladish-0.2
demonstration video at 0:52:
http://www.vimeo.com/8530340
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
"When ladish studio is being saved,
applications that are run at level 1
receive the SIGUSR1 UNIX signal.
How does an application indicate that it intends to "run at level 1"?
6:41 a.m.
On Fri, Jan 8, 2010 at 10:36 AM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
Currently an app cannot do it at software level. The
level 1 support
just needs to be documented.
What I mean is: if the user starts an application that has no
knowledge of LADI at all, and they check the level 1 box in ladish, is
that application then guaranteed to crash on session save and lose
their data because of an unhandled signal?
Or will ladish (and/or LADI) only attempt to notify via signal those
applications that have registered with LADI in some way? (i.e. "level
1" means "aware of LADI but that's as far as it goes")
Chris
7:01 a.m.
Chris Cannam <cannam(a)all-day-breakfast.com> writes:
On Fri, Jan 8, 2010 at 10:36 AM, Nedko Arnaudov
<nedko(a)arnaudov.name> wrote:
If user checks level 1 in ladish when starting the app, then ladish will
send SIGUSR1 to the app. If the app actually does not support level 1,
signal will be sent and chances are that default signal handler will be
executed. The default signal handler is to terminate the app.
Currently an app cannot do it at software level.
The level 1 support
just needs to be documented.
What I mean is: if the user starts an application that has no
knowledge of LADI at all, and they check the level 1 box in ladish, is
that application then guaranteed to crash on session save and lose
their data because of an unhandled signal? Or will ladish (and/or LADI) only attempt to notify
via signal those
applications that have registered with LADI in some way? (i.e. "level
1" means "aware of LADI but that's as far as it goes")
Applications cannot register themself yet. This will be possible in
future through fileds in the .desktop files. ladish will send SIGUSR1 on
save for apps that have been started with level 1 radio button selected
by user. For app "level 1" means app will save its state when SIGUSR1 is
received. Level 0 means app is usable in ladish but user will have to
save manually the internal state (it it exists). All JACK apps are
supposed to work inladish out of the box at level 0. So far we've found
only one that doesnt, beatrix. The problem was caused by the inability
of beatrix to run with current directory different from the one where
the beatrix executable is. There is a context-less (because of the
license) patch for beatrix that fixes this problem.
The other problem with some apps is fail of connection restoration
for alsa seq ports. The problem is caused by alsa client name being
different each time. QSynth does this for example. This is issue only
with alsa seq clients. JACK clients work because they are associated
with the started app through the pid and not by name.
The alsa seq support in ladish relies on a2jmidid. ladish patches only
jack midi connections.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
7:09 a.m.
On Fri, Jan 8, 2010 at 11:00 AM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
Chris Cannam <cannam(a)all-day-breakfast.com>
writes:
That sounds rather hazardous to me. To lose all of one's data instead
of saving it, after a potentially long session's work, because of a
check box incorrectly checked when starting the session, surely
wouldn't please many users?
What I mean is: if the user starts an application
that has no
knowledge of LADI at all, and they check the level 1 box in ladish, is
that application then guaranteed to crash on session save and lose
their data because of an unhandled signal?
If user checks level 1 in ladish when starting the app, then ladish will
send SIGUSR1 to the app. If the app actually does not support level 1,
signal will be sent and chances are that default signal handler will be
executed. The default signal handler is to terminate the app. Applications cannot register themself yet.
I think I must have misunderstood the use of D-BUS here, then. I had
thought that LADI was a D-BUS service which the application connected
to, so that LADI would know whether an application was running in a
"LADI-aware" state or not.
Chris
7:18 a.m.
Chris Cannam <cannam(a)all-day-breakfast.com> writes:
This is a myth. I've explained what D-Bus usage in ladish (and LASH) is
in a recent mail to this mailing list.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
On Fri, Jan 8, 2010 at 11:00 AM, Nedko Arnaudov
<nedko(a)arnaudov.name> wrote:
Please take a look at the video. You are wrong. The radio button is
selected when app is started for first time, not when "session" is
started.
Chris Cannam <cannam(a)all-day-breakfast.com>
writes:
That sounds rather hazardous to me. To lose all of one's data instead
of saving it, after a potentially long session's work, because of a
check box incorrectly checked when starting the session, surely
wouldn't please many users? What I mean is: if the user starts an application
that has no
knowledge of LADI at all, and they check the level 1 box in ladish, is
that application then guaranteed to crash on session save and lose
their data because of an unhandled signal?
If user checks level 1 in ladish when starting the app, then ladish will
send SIGUSR1 to the app. If the app actually does not support level 1,
signal will be sent and chances are that default signal handler will be
executed. The default signal handler is to terminate the app. Applications
cannot register themself yet.
I think I must have misunderstood the use of D-BUS here, then. I had
thought that LADI was a D-BUS service which the application connected
to, so that LADI would know whether an application was running in a
"LADI-aware" state or not.
7:27 a.m.
On Fri, Jan 8, 2010 at 11:18 AM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
Chris Cannam <cannam(a)all-day-breakfast.com>
writes:
*boggle*
OK... That sounds rather hazardous to me. To lose all of one's data
instead of saving it, after a potentially long session's work, because
of a check box incorrectly checked when starting the application,
surely wouldn't please many users?
Chris
That sounds rather hazardous to me. To lose all
of one's data instead
of saving it, after a potentially long session's work, because of a
check box incorrectly checked when starting the session, surely
wouldn't please many users?
Please take a look at the video. You are wrong. The radio button is
selected when app is started for first time, not when "session" is
started.
7:51 a.m.
Chris Cannam <cannam(a)all-day-breakfast.com> writes:
On Fri, Jan 8, 2010 at 11:18 AM, Nedko Arnaudov
<nedko(a)arnaudov.name> wrote:
And you are suggesting what?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Chris Cannam <cannam(a)all-day-breakfast.com>
writes:
*boggle*
OK... That sounds rather hazardous to me. To lose all of one's data
instead of saving it, after a potentially long session's work, because
of a check box incorrectly checked when starting the application,
surely wouldn't please many users? That sounds rather hazardous to me. To lose all
of one's data instead
of saving it, after a potentially long session's work, because of a
check box incorrectly checked when starting the session, surely
wouldn't please many users?
Please take a look at the video. You are wrong. The radio button is
selected when app is started for first time, not when "session" is
started.
8:01 a.m.
On Fri, Jan 8, 2010 at 11:50 AM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
Chris Cannam <cannam(a)all-day-breakfast.com>
writes:
Uh, I think you've lost me a bit, Nedko. What do I appear to be suggesting?
I'm just saying that it might not be such a good idea for a session
manager to kill applications instead of saving them, when asked to
save. Especially if that decision is based on user input that
happened a long time ago (so that the user may have done a lot of work
since making their mistake, but before discovering it was a mistake).
Since none of my applications have any support for any sort of session
manager yet, it's hardly surprising that I might be interested in
thinking about how they might behave if someone tried to use them with
one.
Chris
OK... That sounds rather hazardous to me. To
lose all of one's data
instead of saving it, after a potentially long session's work, because
of a check box incorrectly checked when starting the application,
surely wouldn't please many users?
And you are suggesting what?
8:07 a.m.
Chris Cannam <cannam(a)all-day-breakfast.com> writes:
On Fri, Jan 8, 2010 at 11:50 AM, Nedko Arnaudov
<nedko(a)arnaudov.name> wrote:
Mmmm, suggesting as proposing
Chris Cannam <cannam(a)all-day-breakfast.com>
writes:
Uh, I think you've lost me a bit, Nedko. What do I appear to be suggesting? OK... That sounds rather hazardous to me. To
lose all of one's data
instead of saving it, after a potentially long session's work, because
of a check box incorrectly checked when starting the application,
surely wouldn't please many users?
And you are suggesting what? I'm just saying that it might not be such a good
idea for a session
manager to kill applications instead of saving them, when asked to
save. Especially if that decision is based on user input that
happened a long time ago (so that the user may have done a lot of work
since making their mistake, but before discovering it was a mistake).
What better alternative you propose? ladish will implement levels 2 and
3 in future.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
8:27 a.m.
Nedko Arnaudov wrote:
I understand the concern of Chris. All though I didn't make the mistake
yet when working with Ladish.
Isn't it possible to popup some kind of warning message "you've chosen
level 1, but this is not supported by this app"
Or another solution which helps the user not making this fault?
\r
I'm just saying that it might not be such a
good idea for a session
manager to kill applications instead of saving them, when asked to
save. Especially if that decision is based on user input that
happened a long time ago (so that the user may have done a lot of work
since making their mistake, but before discovering it was a mistake).
What better alternative you propose? ladish will implement levels 2 and
3 in future.
8:32 a.m.
rosea grammostola <rosea.grammostola(a)gmail.com> writes:
Nedko Arnaudov wrote:
I understand the concern of Chris. All though I didn't make the mistake
yet when working with Ladish.
Isn't it possible to popup some kind of warning message "you've chosen
level 1, but this is not supported by this app"
Or another solution which helps the user not making this fault?
If ladish knows whether level 1 is really supporeted it wouldnt be
needed for user to specify it. Such warning message will be possible
when app (.desktop files) list is implemented. But i'd rather disallow
user to override the level from the UI, instead user can change the
.desktop file or override it with another one in the user specific
filesystem location.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
I'm just saying that it might not be such a
good idea for a session
manager to kill applications instead of saving them, when asked to
save. Especially if that decision is based on user input that
happened a long time ago (so that the user may have done a lot of work
since making their mistake, but before discovering it was a mistake).
What better alternative you propose? ladish will implement levels 2 and
3 in future.
8:57 a.m.
Nedko Arnaudov wrote:
rosea grammostola <rosea.grammostola(a)gmail.com>
writes:
It looked to me as an advantage of Ladish that I, as a user, was able to
choose on which level I want to use the application. As I see it now, I
would like to keep that possibility.
\r
Nedko Arnaudov wrote:
I understand the concern of Chris. All though I didn't make the mistake
yet when working with Ladish.
Isn't it possible to popup some kind of warning message "you've chosen
level 1, but this is not supported by this app"
Or another solution which helps the user not making this fault?
If ladish knows whether level 1 is really supporeted it wouldnt be
needed for user to specify it. Such warning message will be possible
when app (.desktop files) list is implemented. But i'd rather disallow
user to override the level from the UI, instead user can change the
.desktop file or override it with another one in the user specific
filesystem location.
I'm just saying that it might not be such a
good idea for a session
manager to kill applications instead of saving them, when asked to
save. Especially if that decision is based on user input that
happened a long time ago (so that the user may have done a lot of work
since making their mistake, but before discovering it was a mistake).
What better alternative you propose? ladish will implement levels 2 and
3 in future.
9:02 a.m.
On Fri, Jan 8, 2010 at 12:06 PM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
What better alternative you propose?
Well, I don't want to be a wet blanket, and please understand I'm
absolutely not trying to start a fight -- but my instinct is to say
"just don't do that". Sending an arbitrary signal to an application
that isn't expecting it doesn't seem like a great idea, and using a
signal for session save seems like a nasty hack already (apart from
anything else it's inviting people to attempt the actual save from the
signal handler).
The procedural difficulty I suppose is that you're trying to get
applications to take part in session management without having to get
their authors to change them significantly to do so. I can see why
that's attractive, but the SIGUSR1 method is still a code change -- it
still needs acceptance from developers, a new release of the
application, &c. Meanwhile, it makes things risky for people who want
to continue using applications that don't support it.
For my part (and I realise I'm probably inviting the wrath of Fons and
others here) I'd probably rather add some D-BUS or equivalent "proper"
message receipt to the application and be done with it. So long as
boilerplate code is readily available, that doesn't seem too painful.
The problem I have always had with most of the proposed LA session
handlers is not so much "doing the code" as "getting around to doing
the code", which basically means understanding what the code was
supposed to be in the first place -- and I suspect this problem is
commonplace, particularly for something like LASH which has always
seemed strangely demanding from the code point of view.
But, I have never tried using ladish and frankly the time taken to
write this message is probably about as much as I can afford at the
moment. If I don't properly understand its goals, I'm probably just
covering ground that you've already covered and reaching conclusions
you've already rejected, and I apologise for that.
(One idle thought is that any proper "desktop" application is going to
have to handle session save already, for the desktop session manager.
Can that be exploited?)
Chris
9:36 a.m.
Chris Cannam <cannam(a)all-day-breakfast.com> writes:
The procedural difficulty I suppose is that you're
trying to get
applications to take part in session management without having to get
their authors to change them significantly to do so. I can see why
that's attractive, but the SIGUSR1 method is still a code change -- it
still needs acceptance from developers, a new release of the
application, &c. Meanwhile, it makes things risky for people who want
to continue using applications that don't support it.
For my part (and I realise I'm probably inviting the wrath of Fons and
others here) I'd probably rather add some D-BUS or equivalent "proper"
message receipt to the application and be done with it. So long as
boilerplate code is readily available, that doesn't seem too painful.
Yes the goal is to have simple to implement state save "message" that
does not require additional libraries. Whether app developers will
implement it is of course their own decision. If their users want it
they will have to choose whether to please them or not. If their users
don't want it, and they don't like level 1, there is no reason to
implement support for it.
The problem I have always had with most of the
proposed LA session
handlers is not so much "doing the code" as "getting around to doing
the code", which basically means understanding what the code was
supposed to be in the first place -- and I suspect this problem is
commonplace, particularly for something like LASH which has always
seemed strangely demanding from the code point of view.
I dislike the LASH API too. But most importantly LASH requires apps to
link to liblash just to restore their connections. This is something
that I find... suboptimal.
But, I have never tried using ladish and frankly the
time taken to
write this message is probably about as much as I can afford at the
moment. If I don't properly understand its goals, I'm probably just
covering ground that you've already covered and reaching conclusions
you've already rejected, and I apologise for that.
Maybe you can watch the video, it is less than 5 minutes long.
(One idle thought is that any proper
"desktop" application is going to
have to handle session save already, for the desktop session manager.
Can that be exploited?)
Desktop session handler traditionally relies on X11. The trend in
freedesktop (KDE, GNOME) is to use D-Bus as IPC instead. I'm not aware
of D-Bus desktop session manager. Probably, in future, ladish could act
as a desktop session manager (via D-Bus or X11) as it is not really
limited to JACK apps, it just has some nice features for
them. Interracting with the X11 window manager is within the scope of
the ladish project. In future, ladish aims to save/restore window
properties like window position, virtual desktop and screen
(multimonitor). That said, some window managers remember window
positions and their virtual desktop out of the box. Some have
configurable set of rules for positioning windows isntead.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
9:45 a.m.
On Fri, Jan 8, 2010 at 1:36 PM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
Yes the goal is to have simple to implement state save
"message" that
does not require additional libraries.
Well, I suppose as long as users are made aware that enabling it for
applications they aren't absolutely sure support it is a dangerous
thing to do. I don't like it, I think it's a simplification too far,
but then I'm not one of the people using it.
Maybe you can watch the video, it is less than 5
minutes long.
I did actually watch that, when it was announced.
Desktop session handler traditionally relies on X11.
The trend in
freedesktop (KDE, GNOME) is to use D-Bus as IPC instead. I'm not aware
of D-Bus desktop session manager.
GNOME is starting to use one. gnome-session switched to it in GNOME
2.24, completely breaking backward compatible session management
during that release series for lots of users, including me. Badly
done, but not intrinsically technically wrong.
In future, ladish aims to save/restore window
properties like window position, virtual desktop and screen
(multimonitor).
That does sound like a desktop session manager to me.
Chris
9 Jan
9 Jan
7:24 a.m.
On Fri, Jan 08, 2010 at 01:02:55PM +0000, Chris Cannam wrote:
For my part (and I realise I'm probably inviting
the wrath of Fons and
others here) I'd probably rather add some D-BUS or equivalent "proper"
message receipt to the application and be done with it.
You may be mistaken here :-). IMHO a D-BUS message would be
much cleaner than hijacking SIGUSR1...
The thing that could 'invite my wrath' is of a different
nature:
- In a first stage, corners are cut in order to minimize
the changes required to exising apps and invite early
adoption.
- Some time later the half-baked solutions resulting from
this are cast into stone in the interest of 'backward
compatibility'.
This sort of scenario is fairly typical and IMHO it is not
a Good Thing (TM).
If an app has to perform well in a managed environment it
has to be designed for this, just as it has to be designed
to be a good Jack client. There's nothing difficult about
this, and no deep mysteries are involved. It just requires
some thinking, time and effort. Trying to skip this will
just result in more misery later, just as writing Jack apps
that are not RT-safe - once they are finished it's usually
quite difficult to modify them.
Ciao,
--
FA
8 Jan
8 Jan
5:54 p.m.
On Fri, 8 Jan 2010 09:35:01 +0000, Chris Cannam wrote:
good question. i'll add another one:
hacking a SIGUSR1 handler is dead-easy, i know, but... how one application
gets to know which filename to load/save its state from/to in the context
of ladish level 1 session ?
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Mon, Jan 4, 2010 at 12:03 PM, rosea grammostola
wrote:
> "When ladish studio is being saved, applications that are run at level
1
receive the
SIGUSR1 UNIX signal.
How does an application indicate that it intends to "run at level 1"?
5:57 p.m.
Rui Nuno Capela <rncbc(a)rncbc.org> writes:
On Fri, 8 Jan 2010 09:35:01 +0000, Chris Cannam
wrote:
good question. i'll add another one:
hacking a SIGUSR1 handler is dead-easy, i know, but... how one application
gets to know which filename to load/save its state from/to in the context
of ladish level 1 session ?
Use the current filename. If there is no current filename do what you
think is better, either show save as dialog or ignore the signal. Other
possibility is to allow supply of non-existent file path to be used for
first save in the app. Better make it non-default behaviour because it
is somewhat strange if you dont use ladish. I.e. user usually expects
start to fail if project file supplied at commandline does not exist.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
On Mon, Jan 4, 2010 at 12:03 PM, rosea
grammostola wrote:
> "When ladish studio is being saved, applications that are run at level
1
receive
the SIGUSR1 UNIX signal.
How does an application indicate that it intends to "run at level 1"?
5492
days inactive
5497
days old
linux-audio-dev@lists.linuxaudio.org
27 comments
6 participants
participants (6)
-
Chris Cannam -
fons＠kokkinizita.net -
Gabriel M. Beddingfield -
Nedko Arnaudov -
rosea grammostola -
Rui Nuno Capela