On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko Arnaudov wrote: > "Rui Nuno Capela" <[email protected]> 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 > [email protected] > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
