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

[Rui Nuno Capela]

fons at kokkinizita.net wrote:
> On Sun, Nov 01, 2009 at 10:38:26AM +1100, Patrick Shirkey wrote:
> 
>> 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?
> 
> That does not affect multiple instances running on 
> different hosts (but displaying on a single one).
> 
> It has always been possible to run more than one jackd
> on the same machine (using different soundcards). 
> If after > 5 years of existence qjackctl still can't 
> handle that that situation, what's can be expected for
> the future ? (It's probably the result of using the
> toolset's (Qt) default configuration system, which 
> also results in the config file ending up in the
> wrong place).
> 

there's nothing to do with qt or whatever. while on the setup dialog,
save/ok buttons are only enabled when at least one of the settings have
changed.

like most global application options, and the already infamous single
application restriction option in particular, it only takes effect
_after_ you quit and start qjackctl later. again, that's nothing to do
with the wrong place of the qjackctl configuration file but _when_ the
changes are committed to it: at program exit.

btw, the configuration file is in ~/.config/rncbc.org/QjackCtl.conf.
you're not supposed to mess around with it, unless you know what you're
doing. whatever you do, do it when no qjackctl instance is running,
otherwise it will get automagically rewritten when it quits. and if you
have several instances of qjackctl going on, then you must know that the
changes you do on the _last_ one that terminates are the ones that will
prevail to the next. anyway, you better leave the file alone, only
qjackctl itself is supposed to read or write to it, so what's wrong with
the place?

getting back to the ot:

you could always run qjackctl against several servers and hosts, but you
 always needed to tell which server via JACK_DEFAULT_SERVER environment
variable. now, with this latest change (qjackctl 0.3.5.7, svn head) you
can name the server via the command line directly.

the server name, when given implicitly by JACK_DEFAULT_SERVER _or_
explicitly via the newer qjackctl -n/--server-name command line option,
adds to the unique instance identifier iif the single instance
restriction is in effect. when in effect, you can only have one qjackctl
instance running against each server name.

what doesn't make sense, to me at least, is having two (or more)
qjackctl instances running against the _same_ jack server. if you do
that, it will be just a waste of resources and prone to confusion and
race conditions that you should avoid at all times. again, the single
instance restriction is just to enforce that wasteful and redundant
scenario won't happen easily.

now, issue as come of age when Jörn (and others before him, the trouble
is not new, has been mentioned before on the lists) wanted to run one
qjackctl instance locally and another from a remote host via X tunneling
(ssh -X). as both qjackctl instances will run against the same X
display/server and the default jack server name is implicitly the same
(literally "default"), qjackctl will pick up the same unique indentifier
and guess that an "equivalent" instance is already up and running. and
will pass over window control to it, bailing out the newer on the block.

truth is, qjackctl is showing its age and legacy status. its design has
some lurking short comings and flaws that gets exposed when is tried
against new ways and use cases for which it wasn't designed or required
for. the latest changes are just patches, in the medical sense,
workarounds to cope with this new use cases.

hth

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc at rncbc.org