chrillek

I can't reproduce this (Sonoma 14.1.1, Alfred 5.1.4). But then the folder you mentioned is empty here. I have the workflow in this folder /Users/ck/Library/Mobile Documents/com~apple~CloudDocs/Alfred/Alfred.alfredpreferences/workflows/user.workflow.8750F239-B45D-49D4-94B6-9A1BD6B1DB68 (as I use iCloud sync). And in the folder, there are three files -rwx------@ 1 ck staff 193043 26 Nov 15:15 data.json -rwx------ 1 ck staff 10699 27 Okt 2022 icon.png -rwx------ 1 ck staff 9687 29 Okt 2022 info.plist So, the data.json is fairly recent. And the info.plist, which _is_ the workflow. I also ran the current version of data.json (see here: https://raw.githubusercontent.com/Fyrd/caniuse/main/fulldata-json/data-2.0.json) through a validator and that came out fine. The error itself is raised by Apple's framework when it tries to parse the JSON it downloaded from GitHub. I just tried doing that here and it worked without a glitch, too Perhaps you can provide more information, e.g. the content of the folder you mentioned above? It's difficult to fix an error that one can't reproduce.

Thanks for clarifying.

I'm using Ventura 13.1 with Alfred 5.0.6 on Intel Silicon. Currently, my wallpaper is set to use an album in Photos and select a new random image from it every hour. In a workflow, I download an image from the web and try to set it as the wallpaper. Downloading works ok, and the automation task "Set wallpaper" runs without an error. If I use "Get path to wallpaper" after that, I see the correct path. But the real wallpaper, i.e. the one on the screen, is not changed. Is that expected behavior and perhaps connected to my system setting of "album, change randomly every hour"? Edit: After changing the wallpaper setting for this desktop to "use an image", the workflow works. I'm uncertain if it's intentional that "Set wallpaper" works only with a particular system setting, though.

I see. So I was trying to solve a non-existing problem. Thanks for clarifying!

In my understanding, Configure Workflow should be set up by the developer to provide reasonable default values. That's why the label is "Default Value". My idea was - to provide some kind of default value for a workflow - to provide a method for the user to change that value to something else If and when the user changes this value with the provided method, how are they going to see the current value? When they open the configuration dialog, all they'll see is the default value set by the developer, not the current value set by themselves. Or is this the wrong approach and should I rather use an environment variable for this user modifiable setting?

No. The window is closed. And I restarted Alfred, out of superstition. Setting the value of "TestUser" to "them" and then running the workflow shows that "TestUser" is "you" even _before_ the script is run. Now, the _correct_ value (i.e. "you") is stored in prefs.plist, while info.plist contains <key>userconfigurationconfig</key> <array> <dict> <key>config</key> <dict> <key>default</key> <string>them</string> <key>placeholder</key> <string></string> <key>required</key> <false/> <key>trim</key> <true/> </dict> <key>description</key> <string></string> <key>label</key> <string>TestUser</string> <key>type</key> <string>textfield</string> <key>variable</key> <string>TestUser</string> </dict> </array> It seems that info.plist stores the default user config value and doesn't change it, while it _does_ change the environment variable's value (as is reflected in info.plist _and_ the dialog). OTOH, prefs.plist stores the _current_ value of the user config value, which the dialog does _not_ show.

While this seems to be fixed with 5.0.6, the display in the "User Configuration" tab showing the default value does not change. So, it's possible to set a user config value to "B" while the tab still shows "A". I think that's a bit unfortunate. Shouldn't the dialog reflect the current setting? If so, the label should be changed from "default" to "current", too.

Good to learn something new. I wasn't actually aware of the fact that most Unix file systems do not track creation time. In that case, I'll go with the modification time – pointless to go hunting for a non-existing value. Thanks a lot!

There are "Get path access date" and "Get path modification date". But I'm unable to find "Get path creation date". Is it intentionally missing or am I overlooking something?

Works as described. But I suggest adding a more in-depth explanation to the documentation, like "in the image, both triggers run all four connected objects". Or perhaps choosing a simpler example?

Any news on this?

The sample workflow is here https://bru6.de/jxa/downloads/test.alfredworkflow Alfred 5.0.5, macOS Ventura 13.0.1 Initially, it uses a User Configuration variable "TestUser" set to "me" and no environment variables. Triggering the script action with Cmd-1 runs a short JXA script: function run(argv) { const app = Application("Alfred 5"); app.setConfiguration("TestEnv", {toValue: "you", inWorkflow: "testconfig.bru6.de"}); app.setConfiguration("TestUser", {toValue: "you", inWorkflow: "testconfig.bru6.de"}); } Afterwards, the "Environment Variables" pane contains a new environment variable "TestEnv" with "value" you. The only User Customization variable "TestUser" is still "me". Perhaps I'm doing something stupid here? Edit: If I remove the User Configuration Variable "TestUser" completely and run the workflow again, "TestUser" is created with the correct value in the Environment Variables. Edit: The same happens with AppleScript (just tried that since sometimes JXA/JavaScript doesn't work as it should)

If this question is already answered somewhere, please direct me to it – I didn't find anything on it. What I'd like to do: Given a user config variable, say "TARGET", with a default value provided. Provide a command/keyboard shortcut to change this value persistently from within the workflow What I tried: Alfred's JXA/JavaScript method 'app.setConfiguration(name, {toValue: "new value", inWorkflow: "bundle.id"});' This works fine with an environment (!) variable in that it changes it to the "new value" (or creates the variable if it doesn't exist). This variable appears in the "Environment tab" of the workflow configuration However, for a variable in the user configuration, the code doesn't change the value. From the script documentation, I'd understand that it should, though: "Modify workflow user configuration value, or set environment variable" What works _temporarily_ is using the JSON Config action. Is there an approved way to change a user configuration variable programmatically?

While in the official page on "Junction" (https://www.alfredapp.com/help/workflows/utilities/junction/) the image clearly suggests that it connects two triggers to four objects. Seemingly without using modifier keys to select the different objects. And I'm still not sure if/how the modifiers will or will not be passed through the junction. See the image below from the DEVONthink workflow. I'd love to tidy that up – can Junction do that, and if so, _how_?

I saw that after my post, when I discovered this official page. Which is not exactly easy, given that there's no index and no table of contents for the documentation.

Which begs the question why argv is an array/list in the first place. The syntax is borrowed from C/Shell and the idea of arguments being separating arguments by spaces. The semantics are different. Anyway, it is at it is.

The currently proposed (https://www.deanishe.net/post/2018/10/workflow/environment-variables-in-alfred/#javascript-jxa) method to query an environment variable relies on the getenv function from stdlib. Unfortunately, this approach will crash the script if the variable is not set. I suggest a more robust approach: ObjC.import('Foundation'); // statt ObjC.import('stdlib'); const env = $.NSProcessInfo.processInfo.environment.js; // env is a JavaScript object containing NSStrings const envVar = (env.foo && env.foo.js) || 'default'; This is fine for a single variable. If you need to inquire several, use a function like so: ObjC.import('Foundation'); // statt ObjC.import('stdlib'); function getenv(variableName, defaultValue) { const env = $.NSProcessInfo.processInfo.environment.js; // env is a JavaScript object containing NSStrings return (env[variableName] && env[variableName].js) ||defaultValue; // .js converts the NSString to a JavaScript one } const foo = getenv('foo', 'default'); This variant is robust, i.e. it does not crash the script if the environment variable is not defined. As this is not a question, the post might be better suited for the "advanced workflow tips" section, but I can't post there.

I don't quite understand how "Junction" is supposed to work. The text and image in the documentation are not helping, either. Consider two script filters with four outgoing connections (enter, ctrl+enter, fn+enter, opt+enter) to four other actions. Would I simply connect the two script filters to the left side of the junction (incoming) and the connections to the four actions to its right side? If so, how are the modifiers (ctrl, fn, opt) handle – does junction simply "know" what to do? Or is it not suitable to organize this kind of setup?

The documentation says I should pass argv instead of query because argv is properly quoted. Now, when I pass argv, I seem to get all arguments to the filter as a single string in argv[0]. Is that assumption correct? If so, it might be worthwhile mentioning it in the documentation – it is very terse on (not only these) details. And what exactly would be the difference between passing argv and query in this case (script filter with osascript/JavaScript)?

Thanks for getting back to me. I guess I was making it overly complicated. I'll play around with it (instead of just thinking about it) and see where it gets me.

I apologize for the longish title, please shorten as you see fit. What I want to achieve: - The user selects an URL and activates Universal Actions - They get presented with the choice to search for that URL in DEVONthink's url fields - When they choose that action, the appropriate script filter runs and - shows the result from DEVONthink in a new Alfred window, clicking on one of them takes the user to the appropriate record in DEVONthink. I'm fine with the first three points, they work. However, I have no idea how to present the found records to the user again for selection. In an Alfred workflow, that kind of happens automagically when it "sees" the JSON object with the items. But it seems that Universal Actions work very differently – is it somehow possible to achieve what I want or am I getting the idea of Universal Actions utterly wrong?

Say if you’re the author or submitting someone else’s workflow. I'm the author. Share a link to its thread on the Alfred Forum, if available. Share a link to its main page (e.g. GitHub). https://github.com/chrillek/DT-Search-JS If it has dependencies, say what those are unless they are explicit in the About or README. Since the workflow is written in pure JavaScript/JXA, it has no dependencies. Note This is a revised version of an earlier DEVONthink workflow which relied on Python. It adds a "search in group" function to that earlier version.

Say if you’re the author or submitting someone else’s workflow. I'm the author. Share a link to its thread on the Alfred Forum, if available. Share a link to its main page (e.g. GitHub) https://github.com/chrillek/caniuse-workflow If it has dependencies, say what those are unless they are explicit in the About or README. Written in JavaScript/JXA, so no dependencies Screenshots are in the README on GitHub. Note: The workflow relies on static data provided by the author of caniuse.com. These data are updated whenever they are older than a week, which requires an internet connection and some time, since the file is larger than 1 MB. Also, it does not contain all data available online on caniuse.com, but only those available through said file. Notably missing are some entries from MDN.

Just updated the repo. The workflow can now also search in groups only. And there are some images (though I had to redact them a bit for obvious reasons)

Of course, it's a brilliant candidate ... oops, sorry, didn't want to brag. I'll try to provide some screenshots later.