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

[fons at kokkinizita.net]

On Sun, Nov 01, 2009 at 12:43:14PM +0000, Rui Nuno Capela wrote:

> 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.

Indeed. And one of the settings that are saved is the screen
position of the main window. So the 'Save' button should be
enabled when that position has changed, instead of requiring
the user to make and then undo another change for the sole
purpose of enabling 'Save'. And it would just be easier to
keep it always enabled.

> 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.

So to enable a second qjackctl on the same screen (which has
no relation at all with the one that is already running), I
first have to quit the one that is running. Where's the logic ?

> 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.

So why then is there a 'Save' button at all ?

> 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?

The path. Why does the user have to know the name of the author (or an
acronym based on it) to find a config file ? In earlier versions he had
to know the name of one of the tools used.
 
> getting back to the ot:
> ...

> what doesn't make sense, to me at least, is having two (or more)
> qjackctl instances running against the _same_ jack server.

It makes sense if you run them on different machines. And you
may want to do that for example when setting up or testing a
distributed system. Having to run between a studio and a machine
room just to check/modify some connections is a waste of time.
As would be having to quit the instance in one place just in
order to be able to run one in the other every time you move
between the two locations.

> 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.

On the contrary, it would be very useful. And with a clean model/
view/control architecture having two views and controllers should
just work.

> again, the single
> instance restriction is just to enforce that wasteful and redundant
> scenario won't happen easily.

Assuming that you don't want two or more qjackctls on the same jack
server, enforcing a single instance per screen is the wrong way to 
ensure that condition. Screens have nothing to do with jack servers.
You can have all four combinations of (same/different server) and
(same/different screen). Only one of them (same screen and server)
isn't very useful.
 
> truth is, qjackctl is showing its age and legacy status.

At the CdS I still have 3.2, and I can have up to four
qjackctls, controlling jack servers on four machines,
on the same and only screen. It happens regularly when
testing new software. If with the current version that
is no longer possible that is not due to age or legacy
status, but to a conscious decision the consequence of
which is to reduce functionality.

hth,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.