-unique flag doesn't work
starting Pd with the -unique flag fails to spawn a separate instance of Pd (or do anything, really).
Activity
Also, the beta versions of 0.13 don't yet support multiple instances of nw.js.
Even if -unique doesn't work (yet), it would be nice to have purr-data open a patch in an existing GUI instance. According to the comments in the code this isn't possible right now, since it's not clear how to send the filename(s) to the nw.js instance. Maybe this helps? http://docs.nwjs.io/en/latest/References/App/#event-openargs
I figured this out-- I was testing with nw.js's default app, and there's a bug with the "open" event in that case. But it looks like it works with the Purr Data app.
That will let us open files in the running instance. The only problem left is what to do with the extra Pd process that gets started. I need a function to connect to it and tell it to exit.
But it looks like it works with the Purr Data app.
That's very good news! I usually prefer to launch patches from the file manager, and I can't tell you how often I already double-clicked on a file and sat there waiting, then realizing that purr-data was still running. :)
Do you have some corresponding JS code to share? Maybe as a diff? I'd really like to give this a try asap.
The only problem left is what to do with the extra Pd process that gets started. I need a function to connect to it and tell it to exit.
That sounds like a standard IPC problem. If it can be done in Tcl, there must be some way in JS, too. If I'm not mistaken, the newly started process already waits for the GUI to respond in some way. I don't have the time to take a deeper look at the startup code in s_main.c and pd.tk right now (have to teach tomorrow and Friday) , but I'll do so as soon as I can (no later than the weekend) and see whether I can get that part working.
Edited by Albert GräfTry right-clicking on the Pd console and choosing "Inspect". Then choose the "Console" tab and type:
nw.App.on("open", function(data) { console.log("data is " + data) });Now when you try to open a file with Purr Data you'll get a message to that devtools console with all the startup flags.
First problem is that Pd does not currently send the list of files to open when starting the GUI. It just sends some paths, a string, and the port number for the socket connection.
Second problem is I have no idea whether one could append the entire list of files. Because it has to work when globbing, too-- you could potentially have 100 files appended there, and that needs to work across all platforms. (Plus make sure that paths with spaces work properly across all platforms, too.)
Third problem is that when the "open" event triggers, the GUI needs to take the port number of the new Pd process, connect to it, and tell it to exit without the GUI also exiting.
Instead of stuffing a bunch of file paths into the GUI call, we can start investigating a way to have the single GUI talk to more than one Pd process.
Initially we can just set it up so that the GUI can receive a list of files to be opened from a secondary Pd process, send a message to exit the secondary process, then send a message to the first process to open those files.
Instead of stuffing a bunch of file paths into the GUI call, we can start investigating a way to have the single GUI talk to more than one Pd process.
Let's do this in baby steps, shall we? Otherwise it's never going to get done. :) Making the nw gui work with different client sockets per canvas is going to be some work, as the infrastructure isn't there yet (afaict). We can think about that later.
I've got the simple solution (stuff args into the GUI call, pick them up via nw.App.on("open"), and terminate the secondary instance by sending the appropriate FUDI message) working now. That's the functionality that I need most urgently in the courses. Just pushed that to my release branch and building packages right now. I'll send you a pull request after giving it some more testing in the courses later this week. If you want to take a look before that, you can find the changeset here: https://git.purrdata.net/aggraef/purr-data/commit/05bbcee9
I should add that my implementation is only tested on Linux. Something similar should probably work on the Mac, too, if /bin/sh is a real Bourne shell which understands
"$@"(but in any case it should work with bash).As usual, Windows is going to be a pita, so I didn't bother updating that part of the code yet. In principle, the same kind of approach should work there, but of course the globbing needs to be done manually (mingw has glob(), so that shouldn't be too hard). Windows' ridiculous 1024 byte command line limitation will be a problem, of course. But it should be possible to pass at least a few files that way, and that's what most users need anyway. Well, I guess I'll have to leave that to someone else (you?), since I don't have a Windows build system set up for purr-data yet.
I wrote a comment about aggraef/purr-data@05bbcee9
Unfortunately it doesn't show up anywhere in the recent activity history.
Anyhow, I think it's possible to fix this using a socket connection to the secondary process without too much trouble.
The only lingering issue is what happens on OSX when the GUI is the one that spawns the Pd process. But that might be as simple as adding an OSX-specific conditional to the "open" callback.
fixed with cb9dd051
mentioned in issue #638
mentioned in merge request !347 (closed)
