19 May
2009
19 May
'09
11:03 a.m.
On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis wrote:
On Mon, May 18, 2009 at 11:57 AM, Rui Nuno Capela
<rncbc(a)rncbc.org> wrote:
so please tell me why the dbus implementation CANT just read .jackdrc ?
i am really pissed on all you guys trampling on legacy stuff.
WHY cant jackdbus just use the .jackdrc if it does not find its own .xml
config ? or check, whether .jackdrc is newer than the xml ?
you always point at us saying we dont like dbus. its not about dbus. its
about dbus people ignoring legacy. stop breaking legacy !
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
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.
i'd like to clarify (again) based on ongoing conversations in #jack.
the issue that qjackctl could consider is not jackdbus, or dbus in
general. its the JACK control API that was discussed at LAC 2008.
right now, qjackctl simply claims to know how to start the JACK
server, offers a dialog to let the user pick settings, and then
constructs a set of command line arguments for jackd.
this will continue to work forever, but it is less flexible than we
would like (consider what happens every time JACK gets a new option
added (or taken away). the control API allows a control application to
query the jack server (actually, its really querying the library that
contains the implementation of the jack server that the control app is
linked with), and discover what the available parameters are etc. etc.
the dbus stuff is really mostly orthogonal to this (i stress the
"mostly") - its just another example of a control app/system. there's
no reason why qjackctl would or should want to interact with it.
however, the one area where these things overlap is "auto-start". this
is because what it means to "auto-start" a JACK server differs in the
following two scenarios:
* vanilla JACK install - there is no "jack control" system in
place or in use
* with jackdbus - there is a daemon in place listening for
requests to start/stop/reconfigure the server
in the first scenario, the ~/.jackdrc file (if it exists) takes care
of auto-start. but if jackdbus is in use, then auto-start means
something really quite different.