19 May
2009
19 May
'09
7:47 a.m.
On Tue, 19 May 2009 10:38:24 +0200, Stéphane Letz <letz(a)grame.fr> wrote:
4) A possible proposed solution was to define 2
completely separated
packages for jack2 : the "classic" one would package the "jackd"
incarnation and allow Qjackctl and legacy control applications to be
used with it. The "D-Bus" one would package the "jackdbus"
incarnation, and provide D-Bus bas control applications (patchage,
ladi tools....). The problem of this strategy is that..., it is a kind
of complete failure regarding the way jack is supposed to be
distributed. It may even get worse if a new "jackosc" incarnation (a
one that would allow to control the server using OSC) appears a some
point in the future...
And we will all agree that this would be a packaging disaster. I package
jack for gentoo pro-audio, and I really don't know how I'd handle this one.
5) Another idea would be improve the "choice of
auto-start strategy"
by providing a runtime choice for that: a way for the user to select
between the "classic", "D-Bus", "OSC", strategy once
globally for a
given working session...
To me, this one is the cleanest of all, and would allow to keep auto-start
for those who like it with the flavor of their choice (and eventually
disable it for those who don't ?)
5) Another idea would be be to completely drops the
"auto-start"
strategy...This way we don't have multiple strategy anymore, and solve
most of the problems... but loose a feature.
Last resort but if it comes down to this, I can handle my idea of
auto-start directly inside LADITools using dbus calls. although it wouldn't
be as good as the "any client can auto-start jack" paradigm.
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais