Hey there, thanks for your response to my previous question, that approach worked well. I’ve got a mocha testing sidebar running that displays it’s results in a tree. It works well, but depending on the size of the test suite you’re running it can look unresponsive if it’s running a while. I’d like to display some kind of progress indicator (for now just working/not working, but someday I might build a json-stream reporter that would allow me to do %complete)
Also, I’m trying to run the same test via the terminal using something like:
/usr/bin/env osascript -e "tell application \"Terminal\"
if not (exists window 1) then reopen
do script \"cd /Users/khrome/the/project/path; mocha\"
which works fine in the terminal, and seems to execute successfully via Process, but doesn’t seem to result in a notification. any clue what I might be doing wrong?
I think the problem is you asked 2 different questions in one and I got confused because they are not related.
For the sidebar progress indicator you could try making a treeview item that has a text character that you can update on a timer so it looks like its animating, like | / – \ |, or . .. ... ...., etc. Or even a [...... ] to show percentage progress. I have tried this before and it works ok but was too jarring for short progress that takes less than a few seconds.
Also maybe possible to update the icon image for the treeview item on a timer so you can do like an animated gif. I have not tried that.
I would love to see some sort of progress indicator as a built in feature.
I considered using an ASCII spinner, but it seems like the sidebar just willl be redraw flooded the whole time. I felt like that might have some power impact should I be running a suite that takes 10-15m. I’m probably over accounting for the effect.
Any ideas on the AppleScript issue? It runs fine standalone and errors if I have a syntax error, but if I run it through Process in the app, I get errors if there’s a syntax error, but nothing and no sideeffects if the correct command is run.
You can redraw just the one treeview item, and redraw it at a slow interval like once per second. Doesn’t have to be spinning rapidly.
With the AppleScript, because you’re opening an external terminal and running the script there, there’s no way for the exit signal to get back to Nova. The process you ran the AppleScript with is not going to be able to see the exit signal from that other terminal window. You’ll have to figure out of some other way to send the signal back to Nova.
There may be some way in the AppleScript to get the exit code from the Mocha script and then use conditional statements or a try block to then pass an exit code back to the process that started the AppleScript.
Another possibility is to start another Process from Nova that runs a shell script that watches for signals, and then when Mocha exits you can pass a signal back to the other process that’s listening for that signal.
I don’t know the exact details on how you would do this, but that’s the concept I would try to develop.
I don’t think the issue is the exit signal… (the script launches a command in the terminal, so it’s really just mutating a field from the package and then launching a terminal window with that command/location). I believe my current approach is the second you mention (spawning a process). mocha.novaextension/main.js at master · khrome/mocha.novaextension · GitHub Like I mention above I get failures back like I expect to, when something is malformed, but when it should successfully execute… just … nothing.
Perhaps some context is helpful: the idea is you can run the same script through the GUI or launch it in the terminal (so what I’m really looking for is a side effect of execution, rather than the successful return… this is helpful for a script that has a redirect, like a browser test as well as to view any inline log output from the test, should it be failing).
Status code 0 means success. Anything above 0 is an error. Look up unix exit status codes.
My guess is that no matter what, your Applescript is going to return 0 because the Applescript itself will have successfully completed – its only job was to start Mocha in an external terminal window. The Mocha terminal window is a separate process from the Applescript. Nova gets the status code from the first process, but not the second. You may be able to tell Applescript to listen for the Mocha window’s exit status code and then return it back to Nova, like I said earlier. But the issue is they are separate processes so Mocha’s status code is not going to be automatically passed back to the first process and back to Nova unless you tell it how to.
The problem is that Terminal window (either the topmost open window or a new one if there is no open window) notification DOES NOT HAPPEN, so there’s no secondary script to monitor. If the Applescript was successfully invoked a terminal window should appear.
As noted above if I alter the script to be syntactically incorrect I get error output from that, so clearly applcscript is preprocessing. It seems to work perfectly up to the point it crosses that inter-app boundary, then nothing. Again all these commands work perfectly in the terminal or an isolated node.js script.
(also do script is going to wait until the return from that precess before the osascript process returns, which is why when you execute it in the commandline it waits for the side effects to execute before it returns control)
Ok I misunderstood. There must be a language barrier. What do you mean by “notification” when you say “notification does not happen”? I thought you meant the script’s exit code. Do you mean in the macOS Notification Center sidebar?
Sounds like you’re saying the terminal window doesn’t appear at all and mocha doesn’t even start running.
I use applescripts in my extension and they work fine. But I put them inside their own .sh script file. Maybe give that a try.
Take a look at this example:
The $1 and $2 are parameters that you can pass into the .sh script.
Interesting, as I recall telling Nova to do things does work, it’s just when I told Terminal to do something from the Nova Process that I got this odd non-reactivity. I’ll try it as a shell script and see what happens, if that works I can add a bunch of argument passing to actually sort the dynamic use case. Will report back after I try that.