On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko Arnaudov wrote:
> "Rui Nuno Capela" <rncbc@email-addr-hidden> 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.
and why is this sooooooooo complicated ?
why not think a bit about legacy ?
this "i dont care for legacy" attitude is the problem. and it does not
help to say we think "dbus eats babies". this is just a cheap excuse.
we are pissed because you dont care.
and i am starting to care less and less for all this shit too.
>
> > 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>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
-- torben Hohn http://galan.sourceforge.net -- The graphical Audio language _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/mailman/listinfo/linux-audio-devReceived on Tue May 19 20:15:02 2009
This archive was generated by hypermail 2.1.8 : Tue May 19 2009 - 20:15:02 EEST