On Wed, May 30, 2018 at 2:13 PM hgn <[email protected]> wrote:
> Hello list,
>
> regarding the Non Session Manager:
>
> 1) Icons: Are there multiple ways the NSM GUI fetches icons? If I saw
> that correctly it takes the DESKTOP file into account, but even if I
> type the wrong name for a client, specifically synthv1 instead of
> synthv1_jack the icon still shows up.
>
It doesn't use the desktop file. session-manager.C:get_program_icon()
searches the following more or less standard paths for an icon matching the
executable name:
"/usr/local/share/icons/hicolor/32x32/apps/%s.png",
"/usr/local/share/pixmaps/%s.png",
"/usr/local/share/pixmaps/%s.xpm",
"/usr/share/icons/hicolor/32x32/apps/%s.png",
"/usr/share/pixmaps/%s.png",
"/usr/share/pixmaps/%s.xpm"
> 2)Save Show/Hide GUI: Would it be the responsibility of a client or of
> the NSM GUI to keep track of the optional GUI hidden/show flag? For
> usability I would welcome it to have that in the session format and not
> in a programs save file.
>
It's currently the program's responsibility. From the API doc:
1.2.4.1. Optional GUI
If the client has specified the optional-gui capability, then it MUST send
this message whenever the state of visibility of the optional GUI has
changed. It also MUST send this message after it's announce message to
indicate the initial visibility state of the optional GUI.
It is the responsibility of the client to remember the visibility state of
its GUI across session loads.
Architecturally, I prefer for all state to be in the client's own project
format. We've seen how confusing the alternative can be with e.g. LV2.
>
> 3) Is there an existing workflow recommendation do deal with multiple
> instances of the same program in the same session? Is there an option,
> as the end user/musician, to rename clients? An additional pretty name.
> If one is working with a very modular setup, lets say multiple times
> synthv1, it becomes impossible to distinguish between them in the NSM
> GUI.
>
Clients are already assigned unique names for JACK reasons. Although these
might be useful for distinguishing multiple instances, they're not very
descriptive. Non Mixer has the "instance-name" option (not for use with NSM
though).
Technically, using the current version of the API, a client could provide
whatever name it likes for the 'application_name' parameter to NSM announce
message (so long as this matches the client name it gave to JACK. This
would obviously require the client to provide its own method for specifying
the name, and it would be the client's responsibility to store it. I think
that's the way I'd prefer to handle it. Adding an 'instance name' to the
API would seem to over-complicate things.
If the 'instance name' were entirely managed by NSM (that is, edited in the
NSM gui and stored in the NSM session file), that would still leave out the
JACK client name, which might make things confusing (i.e. the client block
in NSM is called "Non-Mixer DRUMS" and the JACK client is called
"Non-Mixer.qzvf4")
Also, if it's in any way dynamic (that is, can be edited while the client
is running), that creates a big complication for matching the JACK name, as
there's still no client rename function in JACK and it's not exactly
trivial to pull off smoothly (non-mixer has to deal with this issue due to
having a client per strip).
What are your thoughts on allowing this kind of discrepancy between the
JACK client name and the NSM client name?
> Greetings,
>
> hgn
>
>
>
>
