Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments

PrevNext  Index
DateTue, 19 May 2009 15:13:14 +0200
From [hidden] at gmx dot de <[hidden] at gmx dot de
To[hidden] at lists dot linuxaudio dot org, JACK Developers <[hidden] at jackaudio dot org>
In-Reply-ToNedko Arnaudov Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Follow-UpNedko Arnaudov Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko Arnaudov wrote:
> "Rui Nuno Capela" <[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
> [hidden]
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev


-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
PrevNext  Index

1242739247.28980_0.ltw:2,a <20090519131314.GD25440 at siel>