29 Oct
2009
29 Oct
'09
11:18 a.m.
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
29 Oct
29 Oct
11:35 a.m.
2009/10/29 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
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.
12:04 p.m.
On Thu, Oct 29, 2009 at 10:35:30AM -0400, Paul Davis wrote:
2009/10/29 Jörn Nettingsmeier
<nettings(a)folkwang-hochschule.de>de>:
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
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. 
12:22 p.m.
On Thu, 29 Oct 2009 16:00:56 +0100, fons(a)kokkinizita.net wrote:
On Thu, Oct 29, 2009 at 10:35:30AM -0400, Paul Davis
wrote:
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(a)rncbc.org
2009/10/29 Jörn Nettingsmeier
<nettings(a)folkwang-hochschule.de>de>:
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).
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. 
11:42 a.m.
Hi,
On Thursday 29 October 2009 15:18:09 Jörn Nettingsmeier wrote:
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
12:03 p.m.
On Thu, 29 Oct 2009, Arnold Krille wrote:
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
12:03 p.m.
On Thu, 29 Oct 2009 15:18:09 +0100, Jörn Nettingsmeier
<nettings(a)folkwang-hochschule.de> wrote:
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(a)rncbc.org
12:31 p.m.
On Thu, 29 Oct 2009 16:08:01 +0100, fons(a)kokkinizita.net wrote:
On Thu, Oct 29, 2009 at 03:03:52PM +0000, Rui Nuno
Capela wrote:
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(a)rncbc.org
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.
12:38 p.m.
Rui Nuno Capela <rncbc(a)rncbc.org> writes:
On Thu, 29 Oct 2009 16:08:01 +0100,
fons(a)kokkinizita.net wrote:
multiple jack servers on different hosts? ...and using the ssh X11
forwarding feature.
On Thu, Oct 29, 2009 at 03:03:52PM +0000, Rui
Nuno Capela wrote:
first ask why you want more than one qjackctl instance running? 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.
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>
12:52 p.m.
Hi,
On Thursday 29 October 2009 16:37:31 Nedko Arnaudov wrote:
<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
1:05 p.m.
Arnold Krille <arnold(a)arnoldarts.de> writes:
Hi,
On Thursday 29 October 2009 16:37:31 Nedko Arnaudov wrote:
Not yet, I dont have multiple Linux machines, I have one.
<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'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>
7:02 p.m.
On Thursday 29 October 2009 17:04:09 Nedko Arnaudov wrote:
Arnold Krille <arnold(a)arnoldarts.de> writes:
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
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
1:47 p.m.
On Thu, Oct 29, 2009 at 03:31:24PM +0000, Rui Nuno Capela wrote:
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.
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
4:01 p.m.
On Thu, Oct 29, 2009 at 12:43 PM, <fons(a)kokkinizita.net> wrote:
On Thu, Oct 29, 2009 at 03:31:24PM +0000, Rui Nuno
Capela wrote:
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".
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.
4:27 p.m.
Paul Davis wrote:
On Thu, Oct 29, 2009 at 12:43 PM,
<fons(a)kokkinizita.net> wrote:
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(a)rncbc.org
On Thu, Oct 29, 2009 at 03:31:24PM +0000, Rui
Nuno Capela wrote:
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". 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.
6 p.m.
On Thu, Oct 29, 2009 at 07:27:08PM +0000, Rui Nuno Capela wrote:
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
6:52 p.m.
fons(a)kokkinizita.net wrote:
On Thu, Oct 29, 2009 at 07:27:08PM +0000, Rui Nuno
Capela wrote:
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(a)rncbc.org
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.
7:16 p.m.
On Thu, Oct 29, 2009 at 09:51:54PM +0000, Rui Nuno Capela wrote:
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
30 Oct
30 Oct
6:19 p.m.
Rui Nuno Capela wrote:
fons(a)kokkinizita.net wrote:
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(a)rncbc.org
ps. uber-procrastinator is loosing his grip ;)
On Thu, Oct 29, 2009 at 07:27:08PM +0000, Rui
Nuno Capela wrote:
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
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.
8 p.m.
On Fri, Oct 30, 2009 at 09:33:03PM +0000, Rui Nuno Capela wrote:
fwiw, qjackctl 0.3.5.6, todays svn head:
Will test tomorrow (time here is 23.56, so still today :-)
- 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.
8:49 p.m.
fons(a)kokkinizita.net wrote:
On Fri, Oct 30, 2009 at 09:33:03PM +0000, Rui Nuno
Capela wrote:
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(a)rncbc.org
fwiw, qjackctl 0.3.5.6, todays svn head:
Will test tomorrow (time here is 23.56, so still today :-)
- 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
11:04 p.m.
On Sat, 31 Oct 2009, Rui Nuno Capela wrote:
>> - 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.
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.)
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_ ??
may i quit medication now? :))
Can I have some of that? :-))
-gabriel
31 Oct
31 Oct
7:42 a.m.
On Fri, Oct 30, 2009 at 09:04:20PM -0500, Gabriel M. Beddingfield wrote:
On Sat, 31 Oct 2009, Rui Nuno Capela wrote:
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.
>>- 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.
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.)
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_ ??
may i quit medication now? :))
Can I have some of that? :-))
9:09 a.m.
Gabriel M. Beddingfield wrote:
On Sat, 31 Oct 2009, Rui Nuno Capela wrote:
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(a)rncbc.org
>> - 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.
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.)
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_ ??
may i quit medication now? :))
Can I have some of that? :-))
9:30 a.m.
On Sat, 31 Oct 2009, Rui Nuno Capela wrote:
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
7:49 p.m.
Gabriel M. Beddingfield wrote:
On Sat, 31 Oct 2009, 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 ;).
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
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.
8:20 p.m.
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.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
8:39 p.m.
On 11/01/2009 10:16 AM, fons(a)kokkinizita.net wrote:
On Sat, Oct 31, 2009 at 11:04:12PM +0000, Rui Nuno
Capela 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?
Patrick Shirkey
Boost Hardware Ltd
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.
9:19 p.m.
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).
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
1 Nov
1 Nov
8:26 a.m.
fons(a)kokkinizita.net wrote:
On Sun, Nov 01, 2009 at 10:38:26AM +1100, Patrick
Shirkey 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.
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(a)rncbc.org
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).
9:30 a.m.
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.
10:26 a.m.
On Sunday 01 November 2009 08:26:59 fons(a)kokkinizita.net wrote:
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.)
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 ?
12:11 p.m.
drew Roberts wrote:
On Sunday 01 November 2009 08:26:59
fons(a)kokkinizita.net wrote:
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.
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?
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
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(a)rncbc.org
11:29 p.m.
Rui Nuno Capela wrote:
drew Roberts wrote:
So call it "Save As A Preset". Sounds like it might reduce user confusion.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
On Sunday 01 November 2009 08:26:59
fons(a)kokkinizita.net wrote:
>> 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.
2 Nov
2 Nov
4:42 a.m.
On Sun, 01 Nov 2009 17:29:37 -1000, david <gnome(a)hawaii.rr.com> wrote:
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(a)rncbc.org
Rui Nuno Capela wrote:
> drew Roberts wrote:
>> On Sunday 01 November 2009 08:26:59 fons(a)kokkinizita.net wrote:
>>>> 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
8:18 a.m.
Rui Nuno Capela wrote:
On Sun, 01 Nov 2009 17:29:37 -1000, david
<gnome(a)hawaii.rr.com> wrote:
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 wrote:
> drew Roberts wrote:
>> On Sunday 01 November 2009 08:26:59 fons(a)kokkinizita.net wrote:
>>>> 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
11:08 a.m.
On Mon, 02 Nov 2009 13:17:49 +0100, 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(a)rncbc.org
3 Nov
3 Nov
4:33 a.m.
On Mon, 02 Nov 2009 15:08:20 +0000, Rui Nuno Capela <rncbc(a)rncbc.org>
wrote:
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(a)rncbc.org
On Mon, 02 Nov 2009 13:17:49 +0100, 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.
5:40 a.m.
Rui Nuno Capela wrote:
On Mon, 02 Nov 2009 15:08:20 +0000, Rui Nuno Capela
<rncbc(a)rncbc.org>
wrote:
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
On Mon, 02 Nov 2009 13:17:49 +0100, 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.
2 Nov
2 Nov
3:13 p.m.
Rui Nuno Capela wrote:
On Sun, 01 Nov 2009 17:29:37 -1000, david
<gnome(a)hawaii.rr.com> wrote:
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
gnome(a)hawaii.rr.com
authenticity, honesty, community
Rui Nuno Capela wrote:
> drew Roberts wrote:
>> On Sunday 01 November 2009 08:26:59 fons(a)kokkinizita.net wrote:
>>>> 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
1 Nov
1 Nov
10:17 a.m.
On Sunday 01 November 2009 07:43:14 Rui Nuno Capela wrote:
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. From home I
find I have a need to check something, make some changes, whatever to the
machine at work. I ssh -X in and run qjackctl. The one I left running at work
is still running, but I want the new one to connect to the same jack that is
running at work so that I can do what I need from home. Granted, there may be
issues as to which config trumps which on exit but at least I can make the
changes I need. I guess the other option would be to kill the current
qjackctl at work before kicking off the one over the tunnel. Thoughts?
all the best,
drew
2 Nov
2 Nov
8:11 a.m.
drew Roberts wrote:
On Sunday 01 November 2009 07:43:14 Rui Nuno Capela
wrote:
this is something i'm doing regularly, too. killing the existing
qjackctl is not feasible, since jack would be killed along with it,
bringing down the entire session.
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. From home I
find I have a need to check something, make some changes, whatever to the
machine at work. I ssh -X in and run qjackctl. The one I left running at work
is still running, but I want the new one to connect to the same jack that is
running at work so that I can do what I need from home. Granted, there may be
issues as to which config trumps which on exit but at least I can make the
changes I need. I guess the other option would be to kill the current
qjackctl at work before kicking off the one over the tunnel. Thoughts?
31 Oct
31 Oct
11:37 p.m.
On Saturday 31 October 2009 19:38:26 Patrick Shirkey wrote:
On 11/01/2009 10:16 AM, fons(a)kokkinizita.net wrote:
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?)
On Sat, Oct 31, 2009 at 11:04:12PM +0000, Rui
Nuno Capela 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? 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.
Patrick Shirkey
Boost Hardware Ltd
all the best,
drew
11:54 p.m.
On 11/01/2009 01:37 PM, drew Roberts wrote:
On Saturday 31 October 2009 19:38:26 Patrick Shirkey
wrote:
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
On 11/01/2009 10:16 AM, fons(a)kokkinizita.net
wrote:
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?)
On Sat, Oct 31, 2009 at 11:04:12PM +0000, Rui
Nuno Capela 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?
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.
1 Nov
1 Nov
11:21 a.m.
New subject: remote dbus and ladish. Was: gets confused when used through ssh -X
Patrick Shirkey <pshirkey(a)boosthardware.com> writes:
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>
5:44 a.m.
On Sat, Oct 31, 2009 at 10:37:17PM -0400, drew Roberts wrote:
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.
29 Oct
29 Oct
6:52 p.m.
Rui Nuno Capela wrote:
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".
5:55 p.m.
On Thu, Oct 29, 2009 at 03:01:33PM -0400, Paul Davis wrote:
On Thu, Oct 29, 2009 at 12:43 PM,
<fons(a)kokkinizita.net> wrote:
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
On Thu, Oct 29, 2009 at 03:31:24PM +0000, Rui
Nuno Capela wrote:
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. 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.
7:46 p.m.
On Thursday 29 October 2009 15:01:33 Paul Davis wrote:
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
5298
days inactive
5303
days old
linux-audio-user@lists.linuxaudio.org
49 comments
10 participants
participants (10)
-
Arnold Krille -
david -
drew Roberts -
fons＠kokkinizita.net -
Gabriel M. Beddingfield -
Jörn Nettingsmeier -
Nedko Arnaudov -
Patrick Shirkey -
Paul Davis -
Rui Nuno Capela