1 Sep
2014
1 Sep
'14
5:19 p.m.
On Mon, Sep 1, 2014 at 3:28 PM, Philipp Überbacher <murks(a)tuxfamily.org> wrote:
I guess this packaging trick would work, but for some
reason I really
don't like it.
Well... it is the best way to have NSM-supporting programs announce
that they support NSM, but also gives an opportunity to say "use this
icon file for display in the NSM UI", and various other tweaks...
An alternative idea: NSM could ship with a list of
programs that are
supported, including the information since which version nsm is
supported. It could then check the installed version and I guess the
tricky part is to do that reliably.
Not good: parsing output of programs to identify NSM is a
horrible, tedious and error prone "solution"... or "not solution".
Another idea: NSM could keep a list of nsm-capable
programs that were
started on this particular machine. Once you started zynaddsubfx
through nsm it will show up on the list.
Possible, installing a new machine, or
users who are just starting won't
know what programs support it: as you mention about discovery.
I feel strongly that the solution here should instantly make it easy
for any application to announce its NSM capability, and that no
user interaction should take place (as begining users won't know that).
Finally just having bash completion would be helpful.
I've not yet coded that type of functionality: but I presume some
regex search on the contents of $PATH is sufficient. Perhaps there's
a library for such out there.
Actually jackconnect already does something similar,
just the other way
round. NSM waits for a certain period until all clients are loaded and
sent ready. If some clients are not fast enough or ports are not there
it still says that the session has been established and after that
happened jackconnect starts to connect the ports that are there and
ignores the ones that are not there.
Actually JackPatch just scan's the JACK graph when new ports arrive,
and attaches them if it "knows" about them in the save-file. There is
no delayed loading and such AFAIK.
Doing something similar is probably not hard, a
jackstart client would
need to figure out when jack was successfully started (not sure how
hard that is) and signal nsm to start all other clients.
Yep: it doesn't need to explicitly be "JACK started" as such, just a
"pre-startup" command, that announces "OK" when its done its
setup-job. It can continue to run, and have different / related
functionality then.
A more generic client that could do the same thing
for other clients could be useful,
but I guess not necessary unless someone actually comes up with a need
for it.
I program as concise and generic as possible:
when somebody does find a use, it will already be supported.
Cheers, -Harry