Fons Adriaensen writes:
> On Mon, May 18, 2009 at 06:08:33PM +0300, Nedko Arnaudov wrote:
If i got it right (dbus enabled libjack.so) then every jack app on your
machine uses dbus.
>> jackdrc style commandline options for jackd are for jackd. They are not
I dont get what you are talking about. Please explain.
> The client that autostarted a jackd did not use dbus.
libjack.so will not start jackd if compiled in dbus. Actually it can but
only if jack server start through dbus failed. Obvisouly it didnt
because you said that it got started with wrong arguments, right?
> Yet the 'jackdbus auto' daemon (which nobody needed
again if you have jackdbus enabled libjack.so all your clients DO
interact with dbus.
> Are you trying to say that on a jack+dbus system
NO. dbus knowledge is behind libjack. But yes, they load libdbus.so when
they are started. Maybe you want to verify that with ldd?
>> So you complain about qjackctl missing support for jackdbus? Having that
> Final remark: the dbus advocates here are seriously
it is distributed object model. this somewhat bigger than IPC.
> 2. Dbus adds functionality that can't be
and no again
It can be added. You can reinvent the wheel. You can reuse other already
invented mechanism. D-Bus was choosen because it is already quite
widespread in Linux systems.
> Both can't be true at the same time.
they are both false but even if they were true they can be both true,
according to my understanding of logic :D if A and B are not corelated
then A and B can be true at the same time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----