Discussion:
[LAU] qjackctl gets confused when used through ssh -X
(too old to reply)
Jörn Nettingsmeier
2009-10-29 14:18:09 UTC
Permalink
hi rui, hi *!


two hosts connected via netjack. local host uses qjackctl.
now ssh -X into remote host, start qjackctl and hope for a forwarded
window. no luck. all that happens is that the *local* qjackctl window
pops up.

this doesn't happen with other gui apps. i use several xosviews on
several hosts frequently without problems.

any guesses as to what might be going on?

best,

jörn
Paul Davis
2009-10-29 14:35:30 UTC
Permalink
Post by Jörn Nettingsmeier
hi rui, hi *!
two hosts connected via netjack. local host uses qjackctl.
now ssh -X into remote host, start qjackctl and hope for a forwarded
window. no luck. all that happens is that the *local* qjackctl window
pops up.
this doesn't happen with other gui apps. i use several xosviews on
several hosts frequently without problems.
any guesses as to what might be going on?
guess; Qt is trying to be way too clever.

firefox does sort of the same thing - it registers some kind of
service handle with the X server, and when starting up on a given
display, a new firefox looks to see if the service already exists on
that X server.

just a guess.
f***@kokkinizita.net
2009-10-29 15:00:56 UTC
Permalink
Post by Paul Davis
Post by Jörn Nettingsmeier
hi rui, hi *!
two hosts connected via netjack. local host uses qjackctl.
now ssh -X into remote host, start qjackctl and hope for a forwarded
window. no luck. all that happens is that the *local* qjackctl window
pops up.
this doesn't happen with other gui apps. i use several xosviews on
several hosts frequently without problems.
any guesses as to what might be going on?
guess; Qt is trying to be way too clever.
firefox does sort of the same thing - it registers some kind of
service handle with the X server, and when starting up on a given
display, a new firefox looks to see if the service already exists on
that X server.
Other guess: your WM trying to be clever. It could recognise
the window of the remote app, think you want to local one and
move that to the current workspace which could result in the
two windows on top of each other.

Something like that (but harmless) happens in WindowMaker.
When you have an app icon for e.g. qjakctl, then launch it
on a remote machine, the icons 'start by double click'
function doesn't work anymore because wm thinks the app
is already running (you can still start on the icon's
menu).

Ciao,
--
FA
Rui Nuno Capela
2009-10-29 15:22:07 UTC
Permalink
Post by f***@kokkinizita.net
Post by Paul Davis
Post by Jörn Nettingsmeier
hi rui, hi *!
two hosts connected via netjack. local host uses qjackctl.
now ssh -X into remote host, start qjackctl and hope for a forwarded
window. no luck. all that happens is that the *local* qjackctl window
pops up.
this doesn't happen with other gui apps. i use several xosviews on
several hosts frequently without problems.
any guesses as to what might be going on?
guess; Qt is trying to be way too clever.
firefox does sort of the same thing - it registers some kind of
service handle with the X server, and when starting up on a given
display, a new firefox looks to see if the service already exists on
that X server.
Other guess: your WM trying to be clever. It could recognise
the window of the remote app, think you want to local one and
move that to the current workspace which could result in the
two windows on top of each other.
Something like that (but harmless) happens in WindowMaker.
When you have an app icon for e.g. qjakctl, then launch it
on a remote machine, the icons 'start by double click'
function doesn't work anymore because wm thinks the app
is already running (you can still start on the icon's
menu).
nope. it is qjackctl itself trying to be clever by going trough x11
property ownership and make sure there can only be one single instance of
it up and running.

no system-tray nor window manager in between, it's plain xlib trickery :)

cheers
--
rncbc aka Rui Nuno Capela
***@rncbc.org
Arnold Krille
2009-10-29 14:42:15 UTC
Permalink
Hi,
Post by Jörn Nettingsmeier
two hosts connected via netjack. local host uses qjackctl.
now ssh -X into remote host, start qjackctl and hope for a forwarded
window. no luck. all that happens is that the *local* qjackctl window
pops up.
this doesn't happen with other gui apps. i use several xosviews on
several hosts frequently without problems.
any guesses as to what might be going on?
Just a guess, I haven't looked at the source:

Probably all those "use one app only per X-session" check with the X-session
whether an instance by that name is already running. If yes, they just make it
focus, otherwise the app is started.

As with "ssh -X" or "ssh -Y" (later is more secure) the X-session of your
local machine is accessible from the remote machine, the remote qjackctl
checks whether an app named qjackctl is running and quits itself again...

Running multiple qjackctl instances is probably difficult at least when using
the systray icon.

Have fun,

Arnold
Gabriel M. Beddingfield
2009-10-29 15:03:00 UTC
Permalink
Post by Arnold Krille
Running multiple qjackctl instances is probably difficult at least when
using the systray icon.
++

Digging in the source, both main.cpp and the tray icon is querying the
local X Server. This makes sense, because the whole idea of the tray icon
is that you can close and restore the qjackctl app without losing the
current session.

Anybody know how to disable the tray icon feature? Maybe it will work,
then.

-gabriel
Rui Nuno Capela
2009-10-29 15:03:52 UTC
Permalink
On Thu, 29 Oct 2009 15:18:09 +0100, Jörn Nettingsmeier
Post by Jörn Nettingsmeier
hi rui, hi *!
two hosts connected via netjack. local host uses qjackctl.
now ssh -X into remote host, start qjackctl and hope for a forwarded
window. no luck. all that happens is that the *local* qjackctl window
pops up.
this doesn't happen with other gui apps. i use several xosviews on
several hosts frequently without problems.
any guesses as to what might be going on?
there can only one qjackctl instance running against one X11 server.

there's a workaround however:

on the remote host/ssh session, set JACK_DEFAULT_SERVER environment
variable with some unique value, other than "default" that is.

cheers
--
rncbc aka Rui Nuno Capela
***@rncbc.org
f***@kokkinizita.net
2009-10-29 15:08:01 UTC
Permalink
Post by Rui Nuno Capela
there can only one qjackctl instance running against one X11 server.
Then it's utterly broken.
And I'm pretty sure I had more than one on the same screen
probably with an earlier version.

Ciao,
--
FA
Rui Nuno Capela
2009-10-29 15:31:24 UTC
Permalink
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
there can only one qjackctl instance running against one X11 server.
Then it's utterly broken.
And I'm pretty sure I had more than one on the same screen
probably with an earlier version.
first ask why you want more than one qjackctl instance running?

if what you want is controlling more than one jackd server, then setting
JACK_DEFAULT_SERVER with distinct environment values is the answer. i can't
really see how you can do it otherwise, no matter which qjackctl version.

btw, the X11 uniqueness code applies to qjackctl >= 0.3.3, but the
JACK_DEFAULT_SERVER descriminator only affects qjackctl >= 0.3.4

byee
--
rncbc aka Rui Nuno Capela
***@rncbc.org
Nedko Arnaudov
2009-10-29 15:37:31 UTC
Permalink
Post by Rui Nuno Capela
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
there can only one qjackctl instance running against one X11 server.
Then it's utterly broken.
And I'm pretty sure I had more than one on the same screen
probably with an earlier version.
first ask why you want more than one qjackctl instance running?
multiple jack servers on different hosts? ...and using the ssh X11
forwarding feature.
Post by Rui Nuno Capela
if what you want is controlling more than one jackd server, then setting
JACK_DEFAULT_SERVER with distinct environment values is the answer. i can't
really see how you can do it otherwise, no matter which qjackctl version.
<flame>
if qjackctl is not requriement, one can do it by accessing session buses
(D-Bus) of multiple machines through network.

/me runs back to the rebel camp :D
</flame>
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Arnold Krille
2009-10-29 15:52:16 UTC
Permalink
Hi,
Post by Nedko Arnaudov
<flame>
if qjackctl is not requriement, one can do it by accessing session buses
(D-Bus) of multiple machines through network.
/me runs back to the rebel camp :D
</flame>
Ever tried that??? I did. And as I didn't want a solution involving copying
changing(!) security secrets across machines, I wanted anonymous access to
dedicated dbus sessions.

Turns out that despite all config-file hackery this needs a custom patched dbus
server to work. The patch is less then 10 lines but the mainline refuses to
include it afaik. Which makes the whole anonymous authorization in dbus
useless.

I decided to invent my own text-based network protocol. Is easier to forward
to the next phd-student then teaching him how to handle custom patched
versions...

Arnold
Nedko Arnaudov
2009-10-29 16:04:09 UTC
Permalink
Post by Arnold Krille
Hi,
Post by Nedko Arnaudov
<flame>
if qjackctl is not requriement, one can do it by accessing session buses
(D-Bus) of multiple machines through network.
/me runs back to the rebel camp :D
</flame>
Ever tried that??? I did. And as I didn't want a solution involving copying
changing(!) security secrets across machines, I wanted anonymous access to
dedicated dbus sessions.
Not yet, I dont have multiple Linux machines, I have one.
Post by Arnold Krille
Turns out that despite all config-file hackery this needs a custom patched dbus
server to work. The patch is less then 10 lines but the mainline refuses to
include it afaik. Which makes the whole anonymous authorization in dbus
useless.
I've heard that the anonymous stuff is in git and will be released in
1.4. OTOH if I was using such thing, I'd want ssh tunelling. I havent
tried ssh tunelled dbus, but it looks someone else did:

http://wiki.openmoko.org/wiki/Remote_DBus
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Arnold Krille
2009-10-29 22:02:30 UTC
Permalink
Post by Nedko Arnaudov
Post by Arnold Krille
Turns out that despite all config-file hackery this needs a custom
patched dbus server to work. The patch is less then 10 lines but the
mainline refuses to include it afaik. Which makes the whole anonymous
authorization in dbus useless.
I've heard that the anonymous stuff is in git and will be released in
1.4. OTOH if I was using such thing, I'd want ssh tunelling. I havent
http://wiki.openmoko.org/wiki/Remote_DBus
My use-case is a trusted network of machines running self-configuring jobs
(using avahi/zeroconf for the self-configuring). With head- and disk-less
machines. No ssh needed nor wanted. Just plain anonymous dbus...

But that is a thing of the past. I have now my own text-based network-protocol
that is usable for machine-to-machine- and human-to-machine-communication.

Have fun,

Arnold
f***@kokkinizita.net
2009-10-29 16:43:33 UTC
Permalink
Post by Rui Nuno Capela
first ask why you want more than one qjackctl instance running?
I'm routinely running audio systems consisting of more than
one machine, with usually all but one headless. And occasionally
I want to manually verify/modify jack connections on the remote
machines. So running 'ssh -X somehost qjacktl' is expected to
work, as it should for any X11 app, and must not depend on
conditions that don't matter.
Post by Rui Nuno Capela
if what you want is controlling more than one jackd server, then setting
JACK_DEFAULT_SERVER with distinct environment values is the answer. i can't
really see how you can do it otherwise, no matter which qjackctl version.
If you want to avoid having two instances of qjackctl on
the same jack server (why, it should just work), then
checking for existing windows clearly is the wrong way
to do it. No X11 app should ever care where its display
is located physically and which other windows exist on
it. Being on the same display doesn't imply anything
about the location of the application itself.

Ciao,
--
FA
Paul Davis
2009-10-29 19:01:33 UTC
Permalink
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
first ask why you want more than one qjackctl instance running?
I'm routinely running audio systems consisting of more than
one machine, with usually all but one headless. And occasionally
I want to manually verify/modify jack connections on the remote
machines. So running 'ssh -X somehost qjacktl' is expected to
work, as it should for any X11 app, and must not depend on
conditions that don't matter.
although in theory i agree with you fons, i note that firefox and a
few others from the mozilla stable have realized that with
"heavyweight" X apps, this is not *always* true.

i certainly think that for an app of qjackctl's size/nature, checking
to see if its already running *on the JACK host* can make sense, but i
don't see how it makes sense to ask the same question about a display
server. what is the scope of the resources that qjc has implicit
control over? the audio interface and/or jack server on a given host.
what is the scope of the resources that the X server has implicit
control over? itself and the screen it controls. given that these are
not linked, and qjc is a lightweight application, running N or more on
the same X server seems to me to be something that should "just work".
Rui Nuno Capela
2009-10-29 19:27:08 UTC
Permalink
Post by Paul Davis
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
first ask why you want more than one qjackctl instance running?
I'm routinely running audio systems consisting of more than
one machine, with usually all but one headless. And occasionally
I want to manually verify/modify jack connections on the remote
machines. So running 'ssh -X somehost qjacktl' is expected to
work, as it should for any X11 app, and must not depend on
conditions that don't matter.
although in theory i agree with you fons, i note that firefox and a
few others from the mozilla stable have realized that with
"heavyweight" X apps, this is not *always* true.
i certainly think that for an app of qjackctl's size/nature, checking
to see if its already running *on the JACK host* can make sense, but i
don't see how it makes sense to ask the same question about a display
server. what is the scope of the resources that qjc has implicit
control over? the audio interface and/or jack server on a given host.
what is the scope of the resources that the X server has implicit
control over? itself and the screen it controls. given that these are
not linked, and qjc is a lightweight application, running N or more on
the same X server seems to me to be something that should "just work".
well, i can put there an explicit command line option, say `qjackctl -X`
that will turn off the X11 display uniqueness check. additionally, i can
make it user configurable through the setup dialog, as usual

what else?
--
rncbc aka Rui Nuno Capela
***@rncbc.org
f***@kokkinizita.net
2009-10-29 20:56:55 UTC
Permalink
Post by Rui Nuno Capela
well, i can put there an explicit command line option, say `qjackctl -X`
that will turn off the X11 display uniqueness check. additionally, i can
make it user configurable through the setup dialog, as usual
There is *no* rationale at all for an X11 display uniqueness check.
It should *never* be enforced. There *may* be a rationale for not
having two qjackctk instances trying to control the same jackd, but
that is a compeletely different thing.

If you are going to work on command line options, *please*
add one that allows to select the jack server that qjackctl
will connect to instead of just using an environment variable.

Ciao,
--
FA
Rui Nuno Capela
2009-10-29 21:51:54 UTC
Permalink
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
well, i can put there an explicit command line option, say `qjackctl -X`
that will turn off the X11 display uniqueness check. additionally, i can
make it user configurable through the setup dialog, as usual
There is *no* rationale at all for an X11 display uniqueness check.
It should *never* be enforced. There *may* be a rationale for not
having two qjackctk instances trying to control the same jackd, but
that is a compeletely different thing.
If you are going to work on command line options, *please*
add one that allows to select the jack server that qjackctl
will connect to instead of just using an environment variable.
okidoki :)

however, i must say there's already support for just that although
indirectly, through qjackctl presets.

in summary, you can have presets with different server paths, for
instance, one preset named as MYPRESET for which the server path is
"jackd -n MYJACK", where MYJACK will be the server name. then you can
invoke it trough the command line as

qjackctl --start --preset=MYPRESET

right, but that only works for _starting_ servers, not to attach to
already existing ones. that would be the precise purpose of the new
command line option you're asking for (-n, --server-name=[label], sets
the default server name) perhaps, right?

please note, that's also what the environment variable
(JACK_DEFAULT_SERVER) already does as part of the jackd specification
(jack 1 at least), so the new option will be an added convenience

cheers
--
rncbc aka Rui Nuno Capela
***@rncbc.org
f***@kokkinizita.net
2009-10-29 22:13:00 UTC
Permalink
Post by Rui Nuno Capela
okidoki :)
however, i must say there's already support for just that although
indirectly, through qjackctl presets.
in summary, you can have presets with different server paths, for
instance, one preset named as MYPRESET for which the server path is
"jackd -n MYJACK", where MYJACK will be the server name. then you can
invoke it trough the command line as
qjackctl --start --preset=MYPRESET
right, but that only works for _starting_ servers, not to attach to
already existing ones. that would be the precise purpose of the new
command line option you're asking for (-n, --server-name=[label], sets
the default server name) perhaps, right?
please note, that's also what the environment variable
(JACK_DEFAULT_SERVER) already does as part of the jackd specification
(jack 1 at least), so the new option will be an added convenience
As usual, command line paramters should take precedence over
environment variables, which take precendence over per-user (~/*)
configuration files, which take precedence over global (/etc/*)
configuration.

For me, the ideal situation would be that

qjackctl --preset=XYZ

would use ~/.jackdrc-XYZ, or without -n, just ~/.jackdrc.

This would mean that qjackctl wouldn't have to store any jackd
configuration itself, just its own. It could still offer to edit
the named .jackrc-* via the config dialog.

Ciao,
--
FA
Rui Nuno Capela
2009-10-30 21:33:03 UTC
Permalink
Post by Rui Nuno Capela
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
well, i can put there an explicit command line option, say `qjackctl -X`
that will turn off the X11 display uniqueness check. additionally, i can
make it user configurable through the setup dialog, as usual
There is *no* rationale at all for an X11 display uniqueness check.
It should *never* be enforced. There *may* be a rationale for not
having two qjackctk instances trying to control the same jackd, but
that is a compeletely different thing.
If you are going to work on command line options, *please*
add one that allows to select the jack server that qjackctl
will connect to instead of just using an environment variable.
okidoki :)
however, i must say there's already support for just that although
indirectly, through qjackctl presets.
in summary, you can have presets with different server paths, for
instance, one preset named as MYPRESET for which the server path is
"jackd -n MYJACK", where MYJACK will be the server name. then you can
invoke it trough the command line as
qjackctl --start --preset=MYPRESET
right, but that only works for _starting_ servers, not to attach to
already existing ones. that would be the precise purpose of the new
command line option you're asking for (-n, --server-name=[label], sets
the default server name) perhaps, right?
please note, that's also what the environment variable
(JACK_DEFAULT_SERVER) already does as part of the jackd specification
(jack 1 at least), so the new option will be an added convenience
fwiw, qjackctl 0.3.5.6, todays svn head:

- Server name command line option added (-n, --server-name).

- Single application instance restriction option added (X11).

byee
--
rncbc aka Rui Nuno Capela
***@rncbc.org

ps. uber-procrastinator is loosing his grip ;)
f***@kokkinizita.net
2009-10-30 22:57:05 UTC
Permalink
Will test tomorrow (time here is 23.56, so still today :-)
Post by Rui Nuno Capela
- Server name command line option added (-n, --server-name).
- Single application instance restriction option added (X11).
Could you be a bit more clear about the latter ? This reminds
me of one of my friends (a doctor in medicine, and would-be
programmer) providing an option in one of his works:

Not use printer ? Yes/No/Default

:-)
--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.
Rui Nuno Capela
2009-10-31 00:02:43 UTC
Permalink
Post by f***@kokkinizita.net
Will test tomorrow (time here is 23.56, so still today :-)
Post by Rui Nuno Capela
- Server name command line option added (-n, --server-name).
- Single application instance restriction option added (X11).
Could you be a bit more clear about the latter ? This reminds
me of one of my friends (a doctor in medicine, and would-be
Not use printer ? Yes/No/Default
aha, do i diagnose a ms-dos abort/retry/failure syndrome?

now, "Single application instance" means that you now have an option to
turn off that dreaded x11 uniqueness restriction you pissed about.

bad news is, you'll have to turn if off, yes, just because its on by
default :)

good news are, your choice will prevail. until you decide otherwise, of
course. unlikely but feasible, ntl

may i quit medication now? :))

cheers
--
rncbc aka Rui Nuno Capela
***@rncbc.org
Gabriel M. Beddingfield
2009-10-31 02:04:20 UTC
Permalink
Post by Rui Nuno Capela
Post by Rui Nuno Capela
- Single application instance restriction option added (X11).
Strictly speaking, this says that if you use the command line switch...
then it will _enable_ the single application instance restriction.
Post by Rui Nuno Capela
now, "Single application instance" means that you now have an option to
turn off that dreaded x11 uniqueness restriction you pissed about.
And here you are saying that it does the _opposite_. (The switch
_disables_ the restriction.)
Post by Rui Nuno Capela
good news are, your choice will prevail. until you decide otherwise, of
course. unlikely but feasible, ntl
And now are you saying that it's a _toggle_ ??
Post by Rui Nuno Capela
may i quit medication now? :))
Can I have some of that? :-))

-gabriel
f***@kokkinizita.net
2009-10-31 10:38:37 UTC
Permalink
Post by Gabriel M. Beddingfield
Post by Rui Nuno Capela
Post by Rui Nuno Capela
- Single application instance restriction option added (X11).
Strictly speaking, this says that if you use the command line
switch... then it will _enable_ the single application instance
restriction.
Post by Rui Nuno Capela
now, "Single application instance" means that you now have an option to
turn off that dreaded x11 uniqueness restriction you pissed about.
And here you are saying that it does the _opposite_. (The switch
_disables_ the restriction.)
Post by Rui Nuno Capela
good news are, your choice will prevail. until you decide otherwise, of
course. unlikely but feasible, ntl
And now are you saying that it's a _toggle_ ??
Post by Rui Nuno Capela
may i quit medication now? :))
Can I have some of that? :-))
Don't take it ! And Rui, quit it ! Now !
That medication is AFAICS the only way to explain
the existence of this restriction' :-).

No rational motivation for it was ever offered,
it looks just like an arbitraty way to reduce
functionality. Qjackctl has been working quite
nicely without it for five years or so.

Ciao,
--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.
Rui Nuno Capela
2009-10-31 12:24:20 UTC
Permalink
Post by Gabriel M. Beddingfield
Post by Rui Nuno Capela
Post by Rui Nuno Capela
- Single application instance restriction option added (X11).
Strictly speaking, this says that if you use the command line switch...
then it will _enable_ the single application instance restriction.
Post by Rui Nuno Capela
now, "Single application instance" means that you now have an option to
turn off that dreaded x11 uniqueness restriction you pissed about.
And here you are saying that it does the _opposite_. (The switch
_disables_ the restriction.)
Post by Rui Nuno Capela
good news are, your choice will prevail. until you decide otherwise, of
course. unlikely but feasible, ntl
And now are you saying that it's a _toggle_ ??
Post by Rui Nuno Capela
may i quit medication now? :))
Can I have some of that? :-))
pardon my severely broken english :(

actually, the "option" was "added" to the qjackctl setup dialog (gui),
in the form of a toggling checkbox.

there's no "single application instance" option from the qjackctl
command line (cli).

sorry
--
rncbc aka Rui Nuno Capela
***@rncbc.org
Gabriel M. Beddingfield
2009-10-31 12:30:44 UTC
Permalink
Post by Rui Nuno Capela
actually, the "option" was "added" to the qjackctl setup dialog (gui),
in the form of a toggling checkbox.
there's no "single application instance" option from the qjackctl
command line (cli).
OK, that make more sense. :-) Earlier there was discussion about a -X
command line option... and so that's what I was thinking of.

Peace,
Gabriel
Rui Nuno Capela
2009-10-31 23:04:12 UTC
Permalink
Post by Gabriel M. Beddingfield
Post by Rui Nuno Capela
actually, the "option" was "added" to the qjackctl setup dialog (gui),
in the form of a toggling checkbox.
there's no "single application instance" option from the qjackctl
command line (cli).
OK, that make more sense. :-) Earlier there was discussion about a -X
command line option... and so that's what I was thinking of.
my bad. that particular qjackctl -X command line option was in fact
suggested by me but, well, just didn't make through implementation ;).

cheers
--
rncbc aka Rui Nuno Capela
***@rncbc.org
f***@kokkinizita.net
2009-10-31 23:16:52 UTC
Permalink
Post by Rui Nuno Capela
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.

Ciao,
--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.
Patrick Shirkey
2009-10-31 23:38:26 UTC
Permalink
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
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?



Patrick Shirkey
Boost Hardware Ltd
f***@kokkinizita.net
2009-11-01 00:15:25 UTC
Permalink
Post by Patrick Shirkey
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).

Ciao,
--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.
Rui Nuno Capela
2009-11-01 12:43:14 UTC
Permalink
Post by f***@kokkinizita.net
Post by Patrick Shirkey
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.org
f***@kokkinizita.net
2009-11-01 13:26:59 UTC
Permalink
Post by Rui Nuno Capela
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.
Post by Rui Nuno Capela
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 ?
Post by Rui Nuno Capela
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 ?
Post by Rui Nuno Capela
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.
Post by Rui Nuno Capela
...
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.
Post by Rui Nuno Capela
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.
Post by Rui Nuno Capela
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.
Post by Rui Nuno Capela
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.
drew Roberts
2009-11-01 14:26:04 UTC
Permalink
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
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 ?
Is it that the save commits to an in memory config change but that change does
not effect the on disk config file until program exit?

I sometimes switch between my usb sound card and my internal soundcard. I stop
jack, bring up the setup, switch presets from usb441 to int48, click ok,
restart jack. Then reverse it by switching back to usb441 from int48. Perhaps
the on disk config file will never get changed to the int48 config?

all the best,

drew
(who doesn't feel like testing this theory at this time.)
Rui Nuno Capela
2009-11-01 16:11:57 UTC
Permalink
Post by drew Roberts
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
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 ?
the "save" button is to save current settings and only those as a named
preset.

those settings are the ones seen in that particular page
(Setup/Settings), being the ones strictly related to jackd arguments.

the "save" is about creating/updating a named preset. it is _not_ to
save nor commit the program configuration state to disk. still that only
occurs on program exit.

the other setup pages, Options, Display and Misc., all refer to global
user configuration options that refer to qjackctl behavior per se, not
the jack server settings.
Post by drew Roberts
Is it that the save commits to an in memory config change but that change does
not effect the on disk config file until program exit?
exactly. again, if you have several local instances of qjackctl running,
their configurations will most probably clash and step on each other
toes and only the last one that exits will prevail. that applies to
window positioning as well, the position of the last quitting is the one
that will get restored next time qjackctl starts.

configuration is read at qjackctl startup, changed in memory during
runtime and committed to disk on exit. that's one of the biggest and
fundamental reasons for the single application instance restriction.

again, you as human user, are not supposed to touch the configuration
file, so don't you bother where it's located nor named after
Post by drew Roberts
I sometimes switch between my usb sound card and my internal soundcard. I stop
jack, bring up the setup, switch presets from usb441 to int48, click ok,
restart jack. Then reverse it by switching back to usb441 from int48. Perhaps
the on disk config file will never get changed to the int48 config?
when you switch to a particular preset, that will affect the default
preset name that will get selected next time qjackctl runs (if you don't
call it explicitly through eg. qjackctl --preset=int48 command line)

hth
--
rncbc aka Rui Nuno Capela
***@rncbc.org
david
2009-11-02 03:29:37 UTC
Permalink
Post by Rui Nuno Capela
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
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 ?
the "save" button is to save current settings and only those as a named
preset.
those settings are the ones seen in that particular page
(Setup/Settings), being the ones strictly related to jackd arguments.
the "save" is about creating/updating a named preset. it is _not_ to
save nor commit the program configuration state to disk. still that only
occurs on program exit.
So call it "Save As A Preset". Sounds like it might reduce user confusion.
--
David
***@hawaii.rr.com
authenticity, honesty, community
Rui Nuno Capela
2009-11-02 08:42:17 UTC
Permalink
Post by david
Post by Rui Nuno Capela
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
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 ?
the "save" button is to save current settings and only those as a named
preset.
those settings are the ones seen in that particular page
(Setup/Settings), being the ones strictly related to jackd arguments.
the "save" is about creating/updating a named preset. it is _not_ to
save nor commit the program configuration state to disk. still that only
occurs on program exit.
So call it "Save As A Preset". Sounds like it might reduce user confusion.
eats precious screen real estate, which is already bloated.

if you take a closer look, for quite some time (since ever?) the "Preset
Name:" label, the preset name edit-box and the "Save" and "Delete" buttons
are all on the same line and in this sequence, an usual pattern for preset
management (found on all of my apps, btw:) and if you hover the mouse on
the "Save" button the tool-tip balloon will tell you that it "Save settings
as current preset name".

ain't that enough?
--
rncbc aka Rui Nuno Capela
***@rncbc.org
Jörn Nettingsmeier
2009-11-02 12:18:11 UTC
Permalink
Post by david
Post by david
Post by Rui Nuno Capela
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
again, that's nothing to do
with the wrong place of the qjackctl configuration file but _when_
the
Post by david
Post by Rui Nuno Capela
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
changes are committed to it: at program exit.
So why then is there a 'Save' button at all ?
the "save" button is to save current settings and only those as a named
preset.
those settings are the ones seen in that particular page
(Setup/Settings), being the ones strictly related to jackd arguments.
the "save" is about creating/updating a named preset. it is _not_ to
save nor commit the program configuration state to disk. still that
only
Post by david
Post by Rui Nuno Capela
occurs on program exit.
So call it "Save As A Preset". Sounds like it might reduce user
confusion.
eats precious screen real estate, which is already bloated.
agreed. still, it would be cool to save qjackctl state explicitly, not
just on exit. i've been hit by this a number of times already. scenario
is this:

you are testing some bleeding-edge jack checkout on a brand-new,
pre-alpha rt kernel patch with highly demanding clients. every two
minutes, jack goes down in flames, often taking qjackctl with it (or
vice versa). the settings are not saved. on the next testing iteration,
stuff magically works (or ceases to work), because the settings are not
what you think they are.

since it only bites when you're testing, i've never got around to
reporting explicit state save as a feature request, but now i've learned
i'm not alone, i will :-D

rui, how about saving state whenever the "OK" button in the setup dialog
is pressed?
Rui Nuno Capela
2009-11-02 15:08:20 UTC
Permalink
On Mon, 02 Nov 2009 13:17:49 +0100, Jörn Nettingsmeier
Post by Jörn Nettingsmeier
you are testing some bleeding-edge jack checkout on a brand-new,
pre-alpha rt kernel patch with highly demanding clients. every two
minutes, jack goes down in flames, often taking qjackctl with it (or
vice versa). the settings are not saved. on the next testing iteration,
stuff magically works (or ceases to work), because the settings are not
what you think they are.
since it only bites when you're testing, i've never got around to
reporting explicit state save as a feature request, but now i've learned
i'm not alone, i will :-D
rui, how about saving state whenever the "OK" button in the setup dialog
is pressed?
sure. qjackctl 0.3.5.8 will get that later tonight on svn.

cheers.
--
rncbc aka Rui Nuno Capela
***@rncbc.org
Rui Nuno Capela
2009-11-03 08:33:37 UTC
Permalink
Post by Rui Nuno Capela
On Mon, 02 Nov 2009 13:17:49 +0100, Jörn Nettingsmeier
Post by Jörn Nettingsmeier
you are testing some bleeding-edge jack checkout on a brand-new,
pre-alpha rt kernel patch with highly demanding clients. every two
minutes, jack goes down in flames, often taking qjackctl with it (or
vice versa). the settings are not saved. on the next testing iteration,
stuff magically works (or ceases to work), because the settings are not
what you think they are.
since it only bites when you're testing, i've never got around to
reporting explicit state save as a feature request, but now i've learned
i'm not alone, i will :-D
rui, how about saving state whenever the "OK" button in the setup dialog
is pressed?
sure. qjackctl 0.3.5.8 will get that later tonight on svn.
better yet,

qjackctl 0.3.5.9 (svn) might work ootb without being confused anymore when
used through `ssh -X`, even though the infamous single instance restriction
is in effect: the origin hostname is now taken into account when discerning
qjackctl instances against a X11 display server.

have a nice week :)

cheers
--
rncbc aka Rui Nuno Capela
***@rncbc.org
Jörn Nettingsmeier
2009-11-03 09:40:41 UTC
Permalink
Post by Jörn Nettingsmeier
Post by Rui Nuno Capela
On Mon, 02 Nov 2009 13:17:49 +0100, Jörn Nettingsmeier
Post by Jörn Nettingsmeier
you are testing some bleeding-edge jack checkout on a brand-new,
pre-alpha rt kernel patch with highly demanding clients. every two
minutes, jack goes down in flames, often taking qjackctl with it (or
vice versa). the settings are not saved. on the next testing iteration,
stuff magically works (or ceases to work), because the settings are not
what you think they are.
since it only bites when you're testing, i've never got around to
reporting explicit state save as a feature request, but now i've
learned
Post by Rui Nuno Capela
Post by Jörn Nettingsmeier
i'm not alone, i will :-D
rui, how about saving state whenever the "OK" button in the setup
dialog
Post by Rui Nuno Capela
Post by Jörn Nettingsmeier
is pressed?
sure. qjackctl 0.3.5.8 will get that later tonight on svn.
better yet,
qjackctl 0.3.5.9 (svn) might work ootb without being confused anymore when
used through `ssh -X`, even though the infamous single instance restriction
is in effect: the origin hostname is now taken into account when discerning
qjackctl instances against a X11 display server.
more power to you, rui!

just built svn, and it works like a charm.
thanks a lot.


best,

jörn

david
2009-11-02 19:13:13 UTC
Permalink
Post by david
Post by david
Post by Rui Nuno Capela
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
again, that's nothing to do
with the wrong place of the qjackctl configuration file but _when_
the
Post by david
Post by Rui Nuno Capela
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
changes are committed to it: at program exit.
So why then is there a 'Save' button at all ?
the "save" button is to save current settings and only those as a named
preset.
those settings are the ones seen in that particular page
(Setup/Settings), being the ones strictly related to jackd arguments.
the "save" is about creating/updating a named preset. it is _not_ to
save nor commit the program configuration state to disk. still that
only
Post by david
Post by Rui Nuno Capela
occurs on program exit.
So call it "Save As A Preset". Sounds like it might reduce user
confusion.
eats precious screen real estate, which is already bloated.
if you take a closer look, for quite some time (since ever?) the "Preset
Name:" label, the preset name edit-box and the "Save" and "Delete" buttons
are all on the same line and in this sequence, an usual pattern for preset
management (found on all of my apps, btw:) and if you hover the mouse on
the "Save" button the tool-tip balloon will tell you that it "Save settings
as current preset name".
ain't that enough?
Is enough for me. Just was mentioning a thought since it seemed like
some people were confused about just what the Save button was saving ...
--
David
***@hawaii.rr.com
authenticity, honesty, community
drew Roberts
2009-11-01 14:17:24 UTC
Permalink
Post by Rui Nuno Capela
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.
Rui, here is one example of why you might want such a thing to be possible.

Say I am at work, I start up qjackctl and start jack. I go home.
Jörn Nettingsmeier
2009-11-02 12:11:37 UTC
Permalink
Post by drew Roberts
Post by Rui Nuno Capela
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.
Rui, here is one example of why you might want such a thing to be possible.
Say I am at work, I start up qjackctl and start jack. I go home.
drew Roberts
2009-11-01 02:37:17 UTC
Permalink
Post by Patrick Shirkey
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
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?)
Post by Patrick Shirkey
Patrick Shirkey
Boost Hardware Ltd
all the best,

drew
Patrick Shirkey
2009-11-01 02:53:20 UTC
Permalink
Post by drew Roberts
Post by Patrick Shirkey
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
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
Nedko Arnaudov
2009-11-01 15:20:22 UTC
Permalink
Post by Patrick Shirkey
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.
Yesterday, I've booted my wife`s windows machine from an Ubuntu LiveCD
and made some remote dbus tests. There are two options to initiate this
through ssh.

The first one is to start socat[1] at both sides and use tcp for
connecting them:

dbus app <-> unix socket <-> socat <-> tcp over ethernet <-> socat <-> unix socket <-> dbus daemon <-> dbus app

The other one is to use gabriel [2] at client side. Gabriel uses libssh
[3] to setup socat remotely and tunnels the dbus traffic over ssh
tunnel:

dbus app <-> unix socket <-> gabriel <-> ssh over ethernet <-> socat <-> unix socket <-> dbus daemon <-> dbus app

Gabriel`s approach is of course better in long term, because dbus
traffic is encrypted and because it sets remote part automatically. Bad
news about gabriel is that last commit is from February 2007, it needs a
patch to work with latest libssh (0.3.4) and it allows only one client
to use the local unix socket.

Both approaches have restriction because of the EXTENRAL dbus
authentication mechanism. That mechanism sends unix user id and it is
matched remotely. So in order remote dbus to work, uids should be
same. Of course this is lame and I already have plan for this: the
client side (gabriel/ladish), can get the remote uid through ssh and
change the uid "token".

Plan for the remote capable ladish is to take the gabriel`s
approach. Requirements for the remote (aux) hosts will be - ssh server,
dbus, jackdbus and socat. Requirements for the local (central) host will
be ssh client, libssh, dbus, jackdbus, ladish. ladish will provide dbus
service that will act as manager for remote dbus connections. Such
service could be reused for other remote dbus purposes and as such could
be a separate project (or could be made as part of gabriel).

Multihost ladish is planned for the 2.0 release and wont happen anytime
soon unless someone with high motivation steps to work on this.

I'd like to ask users of multiple-jack-servers-on-same-host (Fons?) to
explain what it is used for and how it works. As I personally dont use
such setup I can't make ladish suitable for such setups without
feedback. Same applies for remote jack management and netjack but I've
gathered some knowledge because of the obvious netjack popularity.

[1] http://www.dest-unreach.org/socat/
[2] http://gabriel.sourceforge.net/
[3] http://www.libssh.org/
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Patrick Shirkey
2009-11-01 20:25:06 UTC
Permalink
Post by Patrick Shirkey
Post by drew Roberts
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.
OK, I see I wasn't clear. For the tunnel case, I would want any changes to the
config to be saved on the machine at the remote end of the tunnel, not the
local end.
I was thinking the other way round. Thanks for clarifying.
To my way of thinking, when I run a program on a remote machine down an ssh -X
tunnel, I want to program to run on the far machine and the display to show
up on the local machine. At the same time, This program should behave as if
it is running on the remote machine. At the same time, I want to be able to
run the same program on the local machine. This program should behave as if
it is running on the local machine (that is, normally.) It should not matter
which program I kick off first, the local or the remote. Firefox, for one,
does not behave this way for me and I don't like the fact.
Can someone explain to me my error if I am thinking in a boneheaded way about
this issue?
Not boneheaded. The only assumption is that you should be able to run
two instances of the same app at the same time on the same machine
within the same x session. There are lots of apps that don't allow this.
Instead they allow for multiple windows but they are all running of the
same instance.

In this case qjackctl appears to do neither unless you set the correct
settings in the env var or the just added commandline switch. Although
according to Fons this behaviour is new and in the past it was not
necessary to do either.


I guess that firefox doesn't let you start an instance over the tunnel
and then open a window on the local desktop too?


Cheers.


Patrick Shirkey
Boost Hardware Ltd
f***@kokkinizita.net
2009-11-01 09:40:52 UTC
Permalink
Post by drew Roberts
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?)
Sure, and that's how it works. The two have nothing to do with
each other. Yet, for some reason the default is that they don't
want each other on the same screen.

Ciao,
--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.
Jörn Nettingsmeier
2009-10-29 21:52:28 UTC
Permalink
Post by Rui Nuno Capela
well, i can put there an explicit command line option, say `qjackctl -X`
that will turn off the X11 display uniqueness check. additionally, i can
make it user configurable through the setup dialog, as usual
what else?
make it a conditional compile:

#if (M_PI == 4)
...
#endif

:-D


honestly, i think this should default to "off".
f***@kokkinizita.net
2009-10-29 20:51:28 UTC
Permalink
Post by Paul Davis
Post by f***@kokkinizita.net
Post by Rui Nuno Capela
first ask why you want more than one qjackctl instance running?
I'm routinely running audio systems consisting of more than
one machine, with usually all but one headless. And occasionally
I want to manually verify/modify jack connections on the remote
machines. So running 'ssh -X somehost qjacktl' is expected to
work, as it should for any X11 app, and must not depend on
conditions that don't matter.
although in theory i agree with you fons, i note that firefox and a
few others from the mozilla stable have realized that with
"heavyweight" X apps, this is not *always* true.
I'd agree that expecting to see a YouTube video over a
remote X connection is asking for trouble. But apart
from that, what could be the problem (assuming the app
is not written in some braindead way) ?

Anyway this is not the same criterion. Qjackctl *does* work
perfectly with a remote X server, and its performance in such
conditions is not the reason why only a single instance is
allowed on any X server. The point I object to is that the
reason that is put forward for doing so doesn't make sense.

Ciao,
--
FA
drew Roberts
2009-10-29 22:46:25 UTC
Permalink
Post by Paul Davis
although in theory i agree with you fons, i note that firefox and a
few others from the mozilla stable have realized that with
"heavyweight" X apps, this is not *always* true.
Just for the record, the way firefox works bugs me no end. (It also causes me
goodly amounts of grief. I think these two may be related. ~;-)

all the best,

drew
Loading...