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