Open grammoboy2 opened 2 weeks ago
If this is by design, then it's the only NSM client I know of, that is doing it this way.
Maybe NSM-Proxy comes close. I think it kills its own GUI (process) by SIGTERM.
I believe I have duplicated the issue. When I set up a session in Agordejo, I see a non-working qseq66 entry and a working seq66 entry. Not sure what is up. I also found some minor lapses in configure.ac that I am fixing as well.
Thanks for the report!
I've been testing against old code (version 0.99.7 works properly) using nsm-legacy-gui because it outputs messages to the console. 0.99.16 starts qseq66, which then seems to spawn "seq66". If I stop qseq66, it stops both entries. If I start qseq66 again, another instance of seq66 is added to the client list. Still struggling with this one.
I think I've got it fixed (in "wip" branch). Need to test a little more and do some cleanup. Then I will do your pull request. Fingers crossed, resting for now. The code change between 0.99.10 and 0.99.11 caused the issue. That was long ago; that'll teach me not to test NSM handling. :-(
I've added a pull request for the desktop file with NSM keys, but before you merge it, please check first if qseq66 is actually working in NSM, otherwise it would be better to leave it out for the time being.
It looks like it announces with two processes to the NSM daemon or something. Currently I don't have the time myself to test it further and to do follow up testing, sorry.
edit:
This is one added qseq66 client.
If this is by design, then it's the only NSM client I know of, that is doing it this way. If it can't be avoided, it might be better if the main qseq66 process is owning the other started process and kills it when the main process gets a
SIGTERM
signal from the NSM daemon and don't let that second process announce to the NSM daemon. But I don't know the details of how seq66 is doing this. Ideally the NSM daemon is the 'owner' of all the processes it starts and it just started one process here.