On 4/29/20 10:01 AM, rosea.grammostola wrote:
Probably some useful comments in a background discussion by Jonathan
for future reference:
"The short version is "it's not possible". Command line arguments are
not compatible with session switching, which is a stupid limitation to
impose just out of laziness (and, let's be clear, the presence of
things that are configurable only by command line options is just
that, laziness, even when I do it...).
There are several options:
1) Patch the program to encode the relevant options in its project
file and rather than (exclusively) on the command line.
2) If the options are major features, such as e.g using X11 vs Wayland
for the GUI or something, they would probably be better encoded in the
executable name rather than the arguments. This is how non-mixer and
"non-mixer-noui" work (one is just a symlink to the other, the
executable detects its name and behaves accordingly).
3) (the user can) write a shell script (called whatever) that just
"exec"'s the program with the desired arguments. This will still be
compatible with NSM (as in this way you are guaranteeing that the
commandline arguments to every instance of this program will be the
same). If you were doing anything fancy with determining the arguments
manually, you'd get into trouble.
4) Run the program under NSM proxy (losing all but basic SM
functionality).
The only way I could change NSM to enable this would be to remove
functionality (specifically, session switching without restarting
applications), which is something I see as conforming to the lowest
common denominator. Command-line arguments in Linux Audio are going in
the wrong direction UX wise, I think, if we want everything to have a
GUI.
So, why don't these LV2 plugin hosts just open a GUI for instance that
lets you choose a plugin, and save that info in thier project file? I
don't really see why command-line arguments should be involved. Does
anybody really want that (again, it's kind of poor UX)?"
In addition: from the topic 'Future of Non Session Manager?' on this
mailinglist:
2) Did you write somewhere why programs with command line options do not
fit the nsm design? If not already, would you please briefly outline why
that is the case?
"Briefly, NSM supports state updates without restarting clients.
Programs which accept state via command-line arguments require a restart
to update their state. Or if they don't, then there is
ambiguity/conflict created between this static state provided on the
command-line and the dynamic state provided at runtime. Supporting
command-line arguments would be regressive, IMHO, and enable a more
fragile system. It also crosses a some structural boundaries (where do I
store the arguments? Where does the interface for entering them go?)
NSMProxy solves this problem in a more explicit, well-structured way
(arguments are stored in NSMProxy project files, NSMProxy provides the
interface, manages starting/stopping, Unix signal quirks, etc.)"
