caleb531

@vitor I have at least considered that, although depending on how they edit the preview, it may not be clear how to derive the new format string. My hope is that because the Script Input and the Text View response are both displayed as separate things, that I could allow them to edit the format string and see a live preview of how it would render out. It would be the best of both worlds. And if they enter an invalid syntax for the format string (within the Script Input field), then the Text View response body would display an appropriate error message in place of a rendered preview. But you still make an interesting argument. If I relinquish my need for a preview, I could render the format string into the Text View response body in Editable mode. Then I could perhaps use the footer text to render out any error messaging. I will look into this. Thank you!

@vitor I tried the Arg and Vars utility per your suggestion, which I can certainly use to populate the "response" key in the Text View JSON that my script outputs. However, that's not the issue. I'm not talking about populating the main body of the Text View (that works fine). I'm talking about populating the user input field with a default/initial value (e.g. in the case of the ChatGPT workflow, this is the input you can type questions into). Populating an arg on my result being fed into the object seems to have no effect on the value of this field. Use Case My use case is this: I workflow offers a number of different formats for the user to choose from. Each format determines how the contents of a Bible verse will be structured. Currently, all of the formats are predetermined and cannot be edited. But I want to give the user the ability to edit any of these formats. To do this, I was thinking of letting the user choose a format from the result list I already present to them. Upon choosing a result, the user would be taken to a Text View with the raw format string pre-populated in the Script Input (this is what I am unable to do), and the main response of the Text View showing a preview of how the format will render (which works fine by itself). Please see my attached screenshots.

To clarify, my particular use case would need to pass a variable (e.g. {var:default_text}) as that initial value of the input. So I think extending the Text View JSON Format would be the most flexible approach.

Hi, Is there a way that a Text View's Script Input (the input field that can be shown above/below the response) can be pre-populated with some default value? As it stands currently, it seems the script input is always blank by default. I know I can populate the response of a Text View with whatever I want using the "response" key (per the docs), but I am talking about populating the optional input field with a default/initial value when the Text View first renders.

@vitor That's a very innovative technique, but unfortunately I don't think it solves the problem (particularly since the workflow you provided does not include a Text View). Even if I expose a variable or subtitle from my Script Filter when a modifier is pressed, my Text View (later down the chain) cannot display it dynamically. I got pretty close with a variable-based approach like the one you described. However, it seems that the Text View footer, as well as modifier subtext for connections attached to a Text View, cannot contain variables. However, modifier subtexts for connections attached to a Script Filter do correctly resolve variables. In other words, the modifier subtext field can resolve variables when attached to a Script Filter, but not when attached to a Text View. If this can be added/fixed, my problem would be solved. To demonstrate this issue, I have created a sample workflow for you to examine and run. You can download it here: https://fastupload.io/o58i5qIPG8M9ty6/file Here are the steps to explain the bug: Install the workflow linked above Type the bug keyword into Alfred Hold down the Command key; you will see the modifier subtext correctly resolving the variable I have set for that result Action either result by pressing Command+Enter Observe problem 1: after reaching the Text View and releasing the Command key, notice how the footer text statically defined in the Text View object cannot resolve variables, since {var:primary_action} is showing in the footer, rather than "Primary action for result X (from variable)" Observe problem 2: Now, if you hold down the Command key while still on the Text View, you will notice the footer does indeed change, but again, the variable in the subtext does not correctly resolve—it's showing a literal {var:secondary_action} in the footer, rather than "Secondary action for result X (from variable)"

Hi, Summary of Request: Can the Text View JSON Format be extended to allow for a "mods" object like the Script View JSON Format already supports? Use Case: I have a workflow where the modifier text is dynamic based on some preferences driven by the script. For example, I have a user preference in my workflow that determines whether the selected result copies to clipboard by default, or opens in the browser by default (with the Command key triggering whichever behavior is not the default). I accomplish this by setting a variable and then using a Conditional utility object to decide which action to take. But because I can't set a modifier on a connection after the Conditional (only before), I need to determine the modifier text before the conditional runs. So I dynamically set that modifier text using the "mods" object in each result of my Script Filter output. However, since the Text View JSON format does not allow for a "mods" object, I have to add a Conditional object earlier in the pipeline, which requires adding a duplicate Text View object with connections that are the inverse of the other text view (i.e. text view 1 has Command going to the secondary action, and text view 2 has Command going to the primary action). It's all rather complicated to explain, but it's the only solution I was able to devise to work around the lack of a "mods" object for the Text View JSON. Please let me know if you have any further questions on my particular use case, but I think it should already make sense what I am asking for.

The Alfred documentation lists a number of Alfred-specific environment variables I can use in my workflow scripts. In my case, I'm using alfred_workflow_bundleid and alfred_workflow_data in my workflow. For example, here's some Python code from my workflow that uses these environment variables. Certainly, I can expect these variables to exist in Alfred 5, but I'm unsure of Alfred 4 support, so I've added hardcoded fallback values just in case. WORKFLOW_BUNDLE_ID = os.environ.get('alfred_workflow_bundleid', 'com.calebevans.youversionsuggest') HOME_DIR_PATH = os.path.expanduser('~') LOCAL_DATA_DIR_PATH = os.environ.get( 'alfred_workflow_data', os.path.join(HOME_DIR_PATH, 'Library', 'Application Support', 'Alfred', 'Workflow Data', WORKFLOW_BUNDLE_ID)) So how far back are these supported? Are they available in Alfred 4 or 3? https://alfredapp.com/help/workflows/script-environment-variables/ Thank you in advance! Caleb Sidenote: I originally posted this question on Twitter and was directed to ask it here on the forums.

@vitor ⌥↩ did the trick. Thank you! It's not the most developer-friendly, since it's not clear that the input has multiple lines in it. But the workaround isn't that bad. @vitorThis feature request was mostly inspired by your comment on my workflow submission for the Alfred Gallery, where you suggested that a Text Area would be more user-friendly, and I agree. But to make that work, I would need a straightforward way of supplying a default value (containing multiple lines) to this Text Area field.

Hi, Suppose I have a "Text Area"-type User Configuration field that should have one value on each line of the text area. This might make it easier to edit for the user than one long comma-separated string value. However, Alfred 5's current form item for Text Area fields uses a single-line input for the "Default Value" field, meaning you cannot "enter" down and add a new line with the next enumerated default value. Adding `\n` does not seem to work either, as it renders as a literal "\n" when populating the user-specific values (e.g. on workflow install). Is there a workaround for this? Would you consider making this "Default Value" field a proper text area for the "Text Area" user configuration type? I understand that configuration values are exposed as environment variables, however environment variables still certainly allow newlines (tested in both bash and zsh to be sure). Please see my attached screenshots for reference (apologies if they appear huge—blame the Retina display 😅).

This is a workflow I created for searching for your church's Planning Center account for people, such that you can easily look up phone numbers and email addresses. There are two configuration options to connect you to your Planning Center account; the README include details on how to generate these tokens. Main Page: https://github.com/caleb531/planning-center-alfred Alfred Forum Post: N/A Dependencies: none Documentation: in GitHub README (the About section in the workflow itself points to this page) Screenshots: see attached

This is a workflow I created for searching for a Bible verse or topic in just a few keystrokes. The workflow is configurable, albeit with a custom preferences system because of the complex nature of how the preferences relate to each other (e.g. the list of available version/translations is scoped to your selected language). Main Page: https://github.com/caleb531/youversion-suggest-alfred Alfred Forum Post: https://github.com/caleb531/youversion-suggest-alfred Dependencies: none Documentation: in GitHub README (the About section in the workflow itself points to this page) Screenshots: see attached

This is a workflow I created for quickly opening the conference URL (Zoom, Google Meet, MS Teams, etc.) of your next calendar event. https://github.com/caleb531/open-conference-url There is no associated Alfred Forum post, but you can see by the GitHub stars and past issues that I am not the only user of the workflow. 😅 There are no dependencies or unsigned binaries in the workflow (icalBuddy used to be required, but it has since been removed to make the workflow more portable and to bypass permission issues). A screenshot (with shadow and the default Alfred theme) is attached.

This is a workflow I created for quickly playing a song, artist, album, or playlist in the Apple Music app. Link to GitHub repository Link to original Alfred forum post There are no dependencies besides running macOS Catalina or later. The latest documentation on how to use can be found in the latest GitHub README. Screenshots (with shadows and the default Alfred theme) are attached.

With the "new normal", many of us are working from home and jumping from one virtual meeting to the next to the next: from Zoom to Google Meet to GoToMeeting, etc. To save the pain of scrambling to open your next meeting link, I have written a workflow just for that! It's called "Open Conference URL", and its usage is simple: type conf to see your upcoming calendar events. Hit Enter to launch Zoom/Meet/etc. immediately. And even if you are 15 minutes late, the workflow will know what to do. (Download Workflow) If there are no nearby calendar events, the workflow displays all events for today: Download Workflow For documentation on all the configurable preferences, see the project's GitHub page: https://github.com/caleb531/open-conference-url