seq192 headless doesn't work with NSM
grammoboy2 opened this issue · comments
Would be interesting case for a network session probably, but currently seq192 without gui is not working with NSM.
It checks the NSM_URL, it announces, but also with :optional-gui:.
It doesn't bind the SIGTERM signal
Save doesn't work
https://github.com/jean-emmanuel/seq192/blob/master/src/seq192.cpp#L307
Should it be able to save state when used with seq192-control?
When running it on a lightweight headless system like a raspberry pi during a live performance or installation for example?
Incoming nsm messages were not processed in headless mode, it's now fixed.
Merci. Seems to work.
One particular thing I don't fully understand in the NSM code:
// make sure nsm server doesn't override cached visibility state
nsm_send_is_shown(nsm);
1) why do you need to make sure the server doesn't override and why don't you want that to happen?
2) why does it send shown, while seq192 is hidden at first launch?
I think this shouldn't be send when global_no_gui is set at least.
Seq192 is 'flashing' here, because it first shows and then directly hides it's gui.
[ray-daemon]Client 'seq192_2' sends gui shown
[ray-daemon]Client 'seq192_2' sends gui hidden
https://github.com/jean-emmanuel/seq192/blob/master/src/seq192.cpp#L116
1/ Because some managers may want to save/restore visibility state by themselves while the API says it's the client's responsibility (managers attempting to do so are legimate in my opinion since many client apps don't save the visibility state).
2/ It's a gtk limitation, I can't make it start hidden.
1/ Because some managers may want to save/restore visibility state by themselves while the API says it's the client's responsibility (managers attempting to do so are legimate in my opinion since many client apps don't save the visibility state).
"It is the responsibility of the client to remember the visibility state of its GUI across session loads. "
So you're right. I know the original author prefers to save all client related states in the client project file format and I think it's good to stick with that. It says that the client should store the visibility state in it's own project. Not sure if this also says that a NSM GUI can't overrule this state (which doesn't work 100% reliable if it would). It doesn't have to store the client visibility state for this. In such case it's either hidden, show or let client restore it's state from it's own project file. In any case I don't think it works well if the client now starts battling with the NSM GUI. "You want to overrule me, sorry mate, not allowed!". Don't make the client responsible for the sins of the NSM GUI. :)
2/ It's a gtk limitation, I can't make it start hidden.
Ah serious? Bummer.
I know the original author prefers to save all client related states in the client project file format
Do you have any evidence ? There's nothing in nsm's code that indicates that.
In any case, unless there's an actual issue caused by this one line of code, I don't see any reason to discuss it further. It does the job as far as I can tell and is harmless otherwise.
Now I feel I should warn you I'm a bit tired of reading / deciphering these fuzzy, overly long and somewhat dubiously quoted reports of yours. I'm still giving you the benefit of the doubt but honestly I'm less and less convinced of your good will here and might well start ignoring you at some point for my own sake.
So and why should I accept this accusations? Who do you think you are to state this so frankly? You just fixed a issue brother, reported by me.
The quote is here and no I don't have to accept this. WTF.
"Architecturally, I prefer for all state to be in the client's own project
format."
https://www.mail-archive.com/non@lists.tuxfamily.org/msg00455.html
Fault is on me, I misread that quoted sentence and thought you were referring to the nsm session which you were not, obviously. I'm sorry for that.
"dubiously quoted reports of yours" "less convinced of your good will"
This didn't make any sense in this topic... Should make you think.
Apology accepted.
Indeed, I'm taking some time off without email notifications, too much github for me lately it seems.