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 😅).

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

Hi, Occasionally, I find myself unintentionally force quitting an application through Alfred when I didn't mean to (when I instead meant to launch an application like Forklift. Because force quitting can be a potentially destructive operation (bypassing save dialogs and such), I would greatly appreciate an option to confirm before force quitting any application (much like the Alfred confirm dialogs for "Shut Down" and "Quit All"). Thanks, Caleb

Hi, First of all, I just want to say that Alfred totally rocks, as it makes me so much more efficient. When I used Alfred 2, I would always keep the "Fade in Alfred Window" setting disabled because I liked being able to use Alfred immediately. However, when I upgraded to Alfred 3, I noticed that the Large Type overlay fades in, which I find rather annoying. I also find it inconsistent, since the overlay has no fade-out animation and since Alfred 3 has seemed to remove the "Fade in Alfred window" setting anyway. Therefore, I'm asking that the fade-in animation for Large Type be removed, or at least that a setting to disable it would be added. Thanks for considering this, Caleb

Alright, @deanishe, I've installed your updated version of the test workflow. Here's the debugger output after running it: Starting debug for 'Do More Stuff' [2016-06-02 11:44:24][utility.debug] Reading from query: passed [2016-06-02 11:44:24][utility.debug] Reading from argv: failed [2016-06-02 11:44:24][ERROR: action.script] /Users/Caleb/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Scripts /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC /Library/Python/2.7/site-packages CWD: /Users/Caleb/Dropbox/Applications/Alfred.alfredpreferences/workflows/user.workflow.3897A013-539B-4ECB-81C1-6107A9A2817A SCRIPT DIR: /Users/Caleb/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Scripts And yes, I realize there are solid workarounds. I already reverted my scripts to using {query} as they have been, though that doesn't always work for multiline input, which one of my workflow's action scripts must handle. Running Python from Bash as you suggested would fix that, and it seems like a much more elegant and reliable solution than {query}. Therefore, if all else fails with this issue, I'll probably resort to doing just that. Still, I'm fascinated by the fact that you get different results than I, and so I'm still very much interested to see if you or anyone else finds additional insight into this issue.