18 May
2009
18 May
'09
1:41 p.m.
On Mon, May 18, 2009 at 06:08:33PM +0300, Nedko Arnaudov wrote:
You have installed jack package that does not work
well with
qjackctl (dbus enabled one). Your application autostarted jack server
through dbus.
It did not. No jack app here uses dbus.
jackdrc style commandline options for jackd are for
jackd. They are not
used for jackdbus. They cant be used for jackdbus. Because of the object
activation works in all distributed object systems I know. This includes
DCOM and D-Bus.
What nonsense it this ? Everybody here tells me that
the dbus support is build on top of the existing C
API and nothing else, that it just a communication
layer allowing you to access the C API. Hence jackd
is the same with dbus or without. Or isn't this true,
and is the dbus support much more invasive than some
people want to admit ?
The client that autostarted a jackd did not use dbus.
When I later started qjackctl it did not use dbus.
Yet the 'jackdbus auto' daemon (which nobody needed
since all apps use the C API, but started anyway)
interferes with clients not using dbus at all.
Are you trying to say that on a jack+dbus system
*all* jack apps have to be dbus-aware (or fail) ?
So you complain about qjackctl missing support for
jackdbus? Having that
will be nice :)
Is that supposed to be funny ?
Final remark: the dbus advocates here are seriously
contradicting themselves.
1. Dbus is just a communication layer.
2. Dbus adds functionality that can't be
provided via the normal interfaces.
Both can't be true at the same time.
Ciao,
--
FA
Io lo dico sempre: l'Italia รจ troppo stretta e lunga.