[LAD] Session Handlers and 'level 1' support

Nedko Arnaudov nedko at arnaudov.name
Fri Jan 8 13:36:06 UTC 2010


Chris Cannam <cannam at 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100108/3f7f7bf3/attachment.pgp>


More information about the Linux-audio-dev mailing list