Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...

PrevNext  Index
DateTue, 19 May 2009 20:09:18 +0700
From Patrick Shirkey <[hidden] at boosthardware dot com>
ToStéphane Letz <[hidden] at grame dot fr>
CcJack devel <[hidden] at lists dot jackaudio dot org>, Linux Audio Developers <[hidden] at lists dot linuxaudio dot org>
In-Reply-ToStéphane Letz Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Stéphane Letz wrote:
>
> Le 19 mai 09 à 12:37, Rui Nuno Capela a écrit :
>
>>
>> On Tue, May 19, 2009 10:32, Stéphane Letz wrote:
>>>>
>>>> (there are two 5)'s above but i'll refer to the first one)
>>>>
>>>>
>>>> i vote for the 5) auto-start strategy. user selects which one he/she
>>>> prefers. the default should be "classic" and i would add fallback to
>>>> "d-bus" and/or "osc" whatever. i still fail to see the problem of
>>>> honoring .jackdrc if it exists on your home directory. ie. if .jackdrc
>>>> exists then do the "classic" auto-start; if not, check d-bus service;
>>>> etc.
>>>>
>>>> byee --
>>>> rncbc aka Rui Nuno Capela [hidden]
>>>
>>>
>>> But since some applications like Qjackctl or Ardour write  this
>>> ".jackdrc" file in a possible hidden way for the average user, then
>>> the system possibly goes back in the "classic" auto-start strategy,
>>> without any knowledge of that.
>>>
>>
>> qjackctl can already opt to not write any .jackdrc. ardour may vary. i
>> would assume it to use the jack control api in a near future. the same
>> would apply to qjackctl. then everybody will be happy again ;)
>>
>> i was asking for a default strategy, call it "auto", which will try
>> "classic" first, then "d-bus", then whatever.
>>
>> the main question, at least in my mind, is all about *which* settings 
>> will
>> be used to auto-start the server, isn't it? an explicit command line, as
>> in "classic", should *always* take precedence over the settings in any
>> internal configuration database, which i think the "d-bus" honors 
>> instead
>> and that latter behavior is being the root of all "d-bus" evil. scnrt ;)
>>
>> cheers
>> -- 
>
> My feeling is that is we choose the runtime auto-start strategy, then 
> we should not mix anything concerting setting management. Each 
> "incarnation" of server has it's own view of setting management and 
> this has to stay completely separated from any other view. If the used 
> chose "classic" auto-start strategy (that would stay the default yes) 
> then he is supposed to know that he has to use "classic" control tools 
> (Qjackctl..). If the user chose  "D-Bus" auto-start strategy, then he 
> knows he has to use D-Bus aware control tools only and so on...
>


While this may work in the short term in terms of saving valuable 
resources for other more important tasks I think you already know that 
is in not acceptable in the medium to long term as it will just confuse 
the f out of the "average" user requiring them to know the difference 
between the competing standards. Tooltips might help here but there are 
plenty who don't know how to read a tooltip also.

However if the goal is to have this problem completely fixed and 
transparent before the average user is expected to use the system then 
proceed as outlined above as it is reasonable from an end user pov to 
set limits as such in the short term.



--
Patrick Shrkey
Boost Hardware Ltd.
PrevNext  Index

1242738518.28219_0.ltw:2,a <4A12AF7E.5060805 at boosthardware dot com>