19 May
2009
19 May
'09
12:20 p.m.
torbenh(a)gmx.de writes:
On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko
Arnaudov wrote:
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 care about legacy. I've implemented a2jmidid to support legacy ALSA
seq stuff. I've tried to not obsolete legacy things. But when some part
is not designed to cooperate and is not extendable you have to give up.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
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.