Answers inline.
Am 27.06.2018 17:59 schrieb J. Liles:
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"
I see multiple problems with that:
-Icons should be scaled to 32x32 dynamically. A 64x64 or bigger icon is
not unusual and at the moment NSM GUI just displays them oversized
-You support the old xpm format but not svg. I realize that requires an
svg parser and renderer, nevertheless it is the reason why some icons do
not show up in NSM, like ZynAddSubFx which is svg.
-the .desktop standard allows for icons to have a different name than
the executable. NSM itself has its icon in
/usr/share/pixmaps/non-session-manager/icon-256x256.png so I think you
are aware of that lenience.
-maybe using the .desktop file would be a good idea after all :)
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?
There are multiple ways to deal with this, I think.
- Normally you connect JACK only once but you open and close a programs
GUI very often. An additional editable string that does not replace the
actual name, e.g. displayed in () would be enough. It can be saved in
session.nsm
Furthermore:
- Jack has pretty names / meta data. Metadata can be set by any client,
not only from the client within. NSM could set Jack Metadata. However,
since I know that you don't want to tie NSM into JACK this could be done
by specific client, like jackpatch. That would still require the
editable string mentioned above.
