[LAU] qjackctl gets confused when used through ssh -X

[Patrick Shirkey]

On 11/01/2009 01:37 PM, drew Roberts wrote:
> On Saturday 31 October 2009 19:38:26 Patrick Shirkey wrote:
>    
>> On 11/01/2009 10:16 AM, fons at kokkinizita.net wrote:
>>      
>>> On Sat, Oct 31, 2009 at 11:04:12PM +0000, Rui Nuno Capela wrote:
>>>        
>>>> my bad. that particular qjackctl -X command line option was in fact
>>>> suggested by me but, well, just didn't make through implementation ;).
>>>>          
>>> The option in the setup dialog creates a chicken/egg situation.
>>> If the 'single instance' restriction is active you don't even
>>> get a chance to change it. Unless you are so extremely clever
>>> to realise that in order to enable a qjackctl instance on a
>>> remote machine you first have to modify the configuration of
>>> the local one. It makes sense, yes, lots of.
>>>
>>> Just like some other things in qjackctl's setup.
>>> If I want to change where qjackctl's main window will
>>> appear on the desktop, I have to
>>>
>>> - Move it to the required place.
>>> - Open the setup dialog.
>>> - Make some unwanted change.
>>> - Undo that unwanted change.
>>> - Click 'Save', which without the two previous actions
>>>     remains disabled. Why is it disabled ?
>>>
>>> And still I've not seen any rationale for ever enforcing
>>> a single qjackctl on any X server.
>>>        
>> I guess it's because currently the change state is held in memory
>> whereas allowing multiple instances will not provide a way to update the
>> change state without a significant modification to the existing code?
>>      
> Well, when I run one on my local machine, I want any changed configs to be
> stored for the local setup. When I run one remotely through an ssh tunnel
> say, I want any changed configs to be stored for the remote setup. (I think.
> Does that make sense?)
>    
>


I don't see much point of storing a local copy of a ssh tunneled config 
file. If you are tunnelling the config file should be accessed from the 
remote machine. It's different if you are using multiple qjackctls on 
the same desktop and connecting to local jackd instance/s as well as 
netjack'd instances on remote machines. That seems like a heavy deal and 
as Nedko has mentioned previously it can actually be managed by the LADI 
tools now although that requires running dbus too which is not to 
everyones liking.

IIUC, the main problem right now is that only one instance of qjackctl 
can be run on a desktop. It also cannot connect to two different 
instances of jack dynamically. It appears to be a limitation of qt but 
if not it still requires some fairly tricky code to be integrated to the 
backend of qjackctl and ability to handle multiple config files, 
lash/ladi sessions, etc...

There are a couple of ways to handle this with either multiple instances 
connecting to explicit running servers or one instance with multiple 
tabbed windows for each running server instance.

Of course, Rui is more than capable of implementing both options but 
afaik until now neither have been explicitly flagged for development 
priority. Also there was a slight expectation that LADI tools would make 
qjackctl redundant or even unnecessary but that has not been that case 
in the slightest.





Cheers.


Patrick Shirkey
Boost Hardware Ltd