On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen <fons@email-addr-hidden>
wrote:
> The only argument pro using dbus I'v heard so far
> is that it permits run-time discovery of new backends,
> internal clients and their parameters.
That's unfair. Read the archives. There are more arguments to that.
> Dbus assumes there is a local login, without that
> there is no session bus, and things don't work.
> Most of my audio machines are headless, there is
> no local login, but I still expect things to work,
> and that, IMHO, is not unreasonable.
It is not unreasonable. No one said you *had* to use dbus. This needs
fixing and until it is fixed, packagers should be advised to disable dbus.
> If it doesn't add any functionality that can be
> provided in simpler ways, and if it doesn't work
> in some perfectly legal use cases, there is no
> reason for having it.
The code for the legacy behavior might make jack a few lines lighter, but
have you looked at qjackctl's code ? Starting jack via some pseudo command
line scripting using Qt and c++ is not something I'd like to maintain. The
thing is, Rui had no choice since it is the only way one could build a
control application with the legacy jack. That's one of the things a
control API is meant to change.
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun May 17 16:15:03 2009
This archive was generated by hypermail 2.1.8 : Sun May 17 2009 - 16:15:03 EEST