[LAD] [Jack-Devel] more jack/qjackctl madness
marco at marcochapeau.org
Sun May 17 11:43:55 UTC 2009
On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen <fons at kokkinizita.net>
> 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.
Participez au black-out anti-HADOPI :
More information about the Linux-audio-dev