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

[Paul Davis]

On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz <letz at grame.fr> wrote:
> After all these discussions on JACK2, D-Bus and Qjackctl issues, here are
> some general comments:
>
> 1) JACK2 *default* compilation mode defines the same starting scheme at
> JACK1 was doing. So (beside possible bugs) it is supposed to be completely
> "interchangeable" with JACK1. It can be controled with Qjackctl as usual.
>
> 2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus based
> control application... (jack_control is a simple python example of a control
> application part of the package). Using JACK2 compiled in D-Bus with
> Qjackctl is a "receipe for trouble", even if if can be done in some simple
> use cases. (The point is that in this case the client auto-start feature
> starts the "jackdbus" exe instead of "jackd" with all of the related
> "settings" issues).
>
> 3) The port issue Fons told about in Qjackctl  0.3.4 seems to be a Qjackctl
> bug, so has to be fixed at the right place.
>
> I don't see right now any raisonable way to fix this mess, better than
> adding even more complexity in the design... (Nedko any idea?) Otherwise I
> guess the only way is to make this totally clear for packagers :  1) is the
> standard way that maintains complete compatibility with legacy applications
> and control applications. 2) is the "new" way to be used with new D-Bus
> based control application (patchage ??)...  So it would mean 2  separated
> packages.

this sounds like a mess. there is a control API. i believe it was
agreed that the control API could be accessed directly (from C/C++
etc), or via other systems for which translators/layers were added
(e.g. DBus). i can see no reason why anyone would want to use choose
between a JACK server that can be controlled via either DBus or the
control API but not both. what is going on?