On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen <[email protected]> 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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
