"Rui Nuno Capela" <rncbc(a)rncbc.org> writes:
So you
complain about qjackctl missing support for jackdbus? Having that
will be nice :)
from where i stand, qjackctl does not need jackdbus support whatsoever.
it's kind of the other way around, if i may say. and the way around is not
about qjackctl per se, but to plain old good command-line jackd.
In jackdbus system qjackctl is unusable for starting and configuring the
jack server (there is no jackd executable). However qjackctl can still
be used to monitor xruns and DSP load and as a patchbay application.
fwiw, qjackctl just runs the jackd server as
documented and interfaces to
libjack through its plain client api. it has been doing this for years and
rightly so, imo.
Yup I know that. And this is why it works as patchbay and monitor app
when used with jackdbus.
however, by having jackdbus in the picture and when
everybody would think
it would be the holy grail, it is breaking all that instead just because
it wants to rule the game on its own. it's doing it with complete
disregard to what long time qjackctl/jackd users have been thought. that's
disgraceful to say the least.
It is not breaking it is fixing issues. Or I'm wrong that qjackctl can't
show messages generated by jackd when jackd is autolaunched by regular
jack client application? Last time I checked those messages go to
application's stdout (that is inherited from the parent process - the
one of the normal jack client application).
The issue that started this holy war is that dbus enabled package that
contains also jackd got into the hands of Fons and ate his babies. The
problem is already fixed in svn. qjackctl will not work when dbus is
enabled unless both jackdbus and jackd are compiled and installed and
after the packager ignores the warning text at configure time. qjackctl
will not work because there will be not jackd executable installed.
i strongly believe that all this trouble is a matter
or something that
just has been overlooked on the jackdbus development, that is, a
misinterpretation, a bug that can be squashed right away once it's
perfectly identified.
Unless you point to what is wrong nobody who knows how jackdbus system
operates will understand what you mean.
however, if all that is due on a jackdbus design
decision instead, then i
am sorry, i'll digress. a completely new qjackctl has to be written from
the ground up. just don't ask me to do it, at least anytime soon :)
I asked you to add support for jackdbus (there are qt dbus wrappers)
more than a year ago. It was in December 2007 IIRC. Not that I hoped a
lot even back then.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>