Feature Request: Interactive mode

[replete]

Hello,

I like Raycast and have been hoping at some point to see the script command functionality extended further, this perhaps overlooked feature I considered most promising to the platform when I switched from Alfred, being able to easily to bridge CLI apps to GUI without needing to build a webapp or learn an API. I could see this direction in the script command functionality and fully expected this to happen at some point, but it hasn't yet so I thought I'd try and communicate what I imagined some time ago:

Behaviour

• addinteractive mode option to script properties
• upon activating an 'interactive' mode script command (with or without parameters) a 'sub-menu' (I can't recall your nomenclature) appears (like with extensions) which is populated by the script itself (allowing dynamic values) composed of 'sub-menu items' made up of Label and value. The script waits for input, and upon selection of the menu option the script continues with whatever values you selected.

Script Example

For example I am writing a bash script to change my monitor refresh rate easily without loading System Settings. I want this to be available in the Raycast GUI without writing an extension.

The 'interactive' script:

1. Checks that the utility exists (displaymode) which will change the display mode for us
2. grep the output from the utility about the current display mode
3. grep the available refresh rates for the current display resolution from the output of the utility
4. Populate a sub-menu in Raycast GUI with available refresh rates for the current resolution
5. Upon menu item GUI selection, continue the waiting script by passing in the selected value
6. Script executes the displaymode utility with arguments composed of the selected hz value given by raycast and the current resolution from the current display mode
7. Utility executes, resolution changes, raycast GUI closes when the script exists

To achieve this currently requires writing a whole extension or hardcoding some values in a script command with a single script command parameter.

How this might work

When the 'interactive' mode script activates, the script command executes but instead of closing immediately, the Raycast UI opens to an unpopulated sub-menu. The script executes and will communicate the menu item values (label, value, command?) to the parent process (if it's a node application there are a few ways to do this e.g parentPort?) which will populate the GUI menu items while the script command waits for input. When the GUI option in Raycast is selected, input is provided to the script child process which resumes execution in the same instance.

Of course for each script command type (node, ruby, bash etc) the implementation would be slightly different (e.g. waiting for input) but I think this would enable some powerful script commands without too much added complexity.

Not sure how receptive you are to such feature requests but I thought I'd share this anyway, I've switched from Alfred and this enhanced functionality would be super useful. This is just the simplest way I could think to explain it

Phil

[dehesa]

Hey there @replete,

Thank you very much for the detailed feedback. I love it! I do understand what you want and it is indeed useful. Currently in Raycast the distinction is:

• Fairly simple stuff: Script-Commands
• Anything else: Custom extensions

We haven't put much effort in Script-Commands lately, although it is not forgotten and we are actually releasing some small enhancements for it soon. What you are suggesting will blur the previously described lines. Nothing wrong with that, but we do tend to push people into extensions because they are much more flexible, allow versioning and updates, they are easier to install for non-technical people, etc. Being honest, I am not sure we (Raycast) will go into the direction you are suggesting. We might since we are also heavy users of scripts, but there is currently no plan for it.

In any case, I will copy-paste your feedback to our internal feature requests for Script-Commands and I want to thank you again for writing it. For the time being, I will suggest you to check the extensions out, since they are easier to write than you might think. By the way, there is currently an extension doing something similar to your display example.

[replete]

I understand, business model wants ecosystem development. No worries.

I wouldn't underestimate the value of this kind of feature extension to developers though, who appear to be a dominant part of your userbase, who for the most part I think likely won't be bothered to make a repo, open up an IDE, learn API, write app, compile app, etc to make something more convenient especially as most of the time its just passing some CLI arguments with a bit of filtering. A few will of course, thankfully, but I believe this because there are plenty of things I've wanted that don't exist as extensions and I know its going to be take way longer to write an extension than writing a script. And with these kind of apps extensions break, so what do you - debug the third party thing (which mostly isn't fruitful or just takes too long) or write a bash script? I still have alfred for a few things! It would just be cool to feasibly use raycast for everything instead of having to save random CLI strings in text files which pretty much everybody does

I wouldn't normally be so invested in talking about a software desire or whatever, but for productivity the omnibox model for general computing is a powerful pattern (notice how its appearing in more and more apps - but still not photoshop ffs) and its like nobody's quite solved the problem properly yet but certainly raycast has made a great dent in the problem where things like Alfred were just too complex and often broke, but its still not in that 'easy to set up' zone where it really could be, for the most part its patching CLI to a friendlier GUI - if productivity is the goal then its gotta be quick to work with, we all basically just want to be able to do the repetitive tasks from the same place and something like this would. Then again maybe there's a business incentive to not make it too good for devs..

Kind regards, Phil

[dehesa]

I hear you Phil and I will bring it up internally. Again, thank you for the write up.

By the way, if we don't implement more stuff more quickly is because we are not even a handful of engineers. It is surprisingly hard to find good macOS engineers out there. If you are one or do you know some, I would appreciate if you can see/forward our careers page along.

[replete]

No worries, apologies I was in a rush writing that and smashed send before expressing gratitude for the great software you guys have made. I hope you continue in your success. I'm going to have a go at writing an extension or something along the lines of above. I'm not a macos developer unfortunately, but wish you the best in fulfilling that role. Phil