vitor

And showing the current state. I’ve been considering for a while to add support for timed disable, but I want to do it by properly editing the right files (like the rest of the Workflow works) so it doesn’t clash with manual use. Apple has a propensity for breaking programatic ways of editing DnD with new OS releases, and macOS Monterey has a new “Focus” which might turn everything into disarray, so I’m waiting to first see how this works on macOS 12 and then decide about the timed disable.

So you’ve just updated to the new buggy shininess released by Apple. Congrats! But thread lightly. At all costs, you should avoid installing a beta macOS version on a machine with data you can’t afford to lose or waste a day resetting. In the course of your beta trial, you’ll bump into bugs and general issues. Some will be related to Alfred and Workflows, which will make you tempted to jump on this forum for help. Stop! Then wait. Ask yourself “is this a bug I should be reporting?” The closer to WWDC21, the likelier the answer is “no”. The overwhelming majority of bugs at this point will sort themselves out. And they are inconsistent. At the time of writing there have been two comments from users on the new macOS beta: one said Alfred worked, the other that it didn’t. At this point the new beta is so unstable we can’t even rely on a consistent experience between users, meaning no way to isolate and understand problems—effort spent in that direction wold be wasted. Avoid drowning the forum with unactionable bug reports. In general, if you don’t have enough knowledge or skill to figure out the cause of the problem, you should refrain from installing a beta OS. Please avoid filling but reports if that’s the case. Or file them at Apple, since it’s their end causing the breaks and giving them feedback is the point of installing their beta OS. So when should you start reporting general Alfred bugs? Look at the bug reports subforum. Do you see a “macOS 12.0 Monterey Bugs & Issues” section? If not, it’s too soon. What about Workflows? You should follow the same logic. If a Workflow stops working, either the developer will know because they are using the beta, or they won’t know and won’t be able to fix it anyway because they are not on the beta. There are exceptions to the above, but few. If you do make a bug report, please make sure to follow the instructions. Do that, and everyone will be more willing to look into your issue sooner and help get you sorted. Thank you. Have fun with the new features.

When making a request or a bug report pertaining to a specific workflow, please do not open a new thread to discuss your issue. Making a new thread, while it seems like it’ll give your problem visibility, fragments the discussion and makes it less likely the author and users of the workflow (the people who can help) will see it. Please read the Reporting Problems with Workflows topic, as it gives a nice overview on how to make a report with a better chance of being addressed. Try using the full path to the binary.

Updated the top post with information from the session. There are quotes with links to timestamps, how to call Shortcuts from AppleScript, and the help form the command-line tool. For Alfred Workflow developers, the beginning and end are the most interesting; the middle is how to build update an app to support a Shortcut.

Scriptability matters for Alfred Workflows, so this is a short thread on what we know about scriptability on the new macOS version. Discussion and new data is welcome; I’ll strive to keep this top post up to date with the most relevant information. Scripting languages might have survived another version: Shortcuts is coming to macOS, but it doesn’t mean the end of AppleScript yet: The Shortcuts app will scriptable, though the functionality isn’t yet available. It will also have a command-line tool: On June 8 there was a session going more in-depth into Shortcuts. Notable points: “We also added two new automation types for Focus and Sound Recognition”. “By the way, if your app integrates with file providers, these new Files actions will automatically work with the files that your app provides”. “We also have a new file format that lets you distribute Shortcuts as files“. (…) “This means that you can distribute your own Shortcuts on your website or in your app”. Which means we may be able to distribute Shortcuts as complements to Workflows. For M1 Macs, that may open a window to distribute everything needed to control iOS apps from Alfred. However, it’s unclear if we’ll need a ($99/year) Developer Account to distribute them in useful form, since they mention signing: “Shortcuts files are notarized by Apple to make sure they’re safe”. (…) “a new mode for sharing Shortcuts privately” (…) “Shortcuts files are signed with the identity of the person who sent them. If you need to re-sign a Shortcut, you can use the new Shortcuts command-line tool”. “Shortcuts has full support for AppleScripts and Shell Scripting”. Not dead yet! “Shortcuts is the future of Mac automation”. Taken in isolation; it’s a scary implication the other technologies are destined for the bin. But in context, they’re talking speficially about replacing Automator. “There’s a Shortcuts command-line tool which lets you list and run Shortcuts in your Shell Scripts or command-line tools”. “If you develop an app or a script that would benefit from the ability to run Shortcuts, you should use the Scripting interface. By communicating with the “Shortcuts Events” process, your app can get a list of shortcuts that the user has set up, as well as start running one. In AppleScript, you can accomplish this by telling the “Shortcuts Events” process to run a shortcut by name”: tell application "Shortcuts Events" run the shortcut named "Make GIF" end tell “Finally, macOS Monterey also includes a command-line tool that can list shortcuts and run them by name. If you have command-line tools or scripts, they can integrate with Shortcuts via this interface”. OVERVIEW: Command-line utility for running shortcuts. USAGE: shortcuts <command> OPTIONS: -h, --help Show help information. SUBCOMMANDS: run Run a shortcut. list List your shortcuts. view View a shortcut in Shortcuts. sign Sign a shortcut file. See 'shortcuts help <subcommand>' for detailed help.

Tried that but the result was the same. Also tried making a loop to rename one result at a time and thought about changing directories before doing the rename. But by that point I would already be losing any benefit of using an external program instead of doing it myself and falling again into the trap of having to test every case.

See, I told you about the limited testing! An issue of that tool (which may be addressed on a future update, they say) is that it acts on the whole path, so it may rename a directory and then can’t get to the files inside (because the parent’s name changed). So you can avoid that by not having the parent directory be named with what you want to replace. These are the types of issues I was talking about that require a bunch of testing. So as I expect you understand, I won’t keep iterating on it. If they update the tool (you may ask, I suppose) and you let me know, I may update the Workflow accordingly.

@heyJoeCampbell I had an idea and made a Workflow to satisfy what you asked for [link removed after download]. Instead of building and testing all the logic, I remembered I could use another tool for this. This received limited testing, so you use it at your own risk! I don’t think anything bad is going to happen, but who knows if you use some weird shell characters that get expanded to something they shouldn’t or the like. It’s a File Action which only works on directories, and one at a time. Select the directory, press the shortcut, then give the “from” and “to” strings you want to modify. All file and children directories will be renamed with that substitution.

Therein lies the problem. Alfred does it its way by design, and switching that interaction could break the myriad of Workflows that already exist. In that vein, it’s hard to make the argument for that change, even optionally. I’m on a phone so it’s cumbersome to do, but if you search this forum you’ll see this has already come up and been discussed at some length, though last it was discussed, Raycast wasn’t yet a thing and I’m not familiar with the popup you mention. Still, it would be preferable to continue that discussion than having to rehash the same points all over again.

@Mr Pennyworth To find URL schemes supported by an app, reading the ${app_path}/Contents/Info.plist file and looking for CFBundleURLSchemes tag if often enough. Or doing /usr/libexec/PlistBuddy -c 'print :CFBundleURLTypes' "${app_path}/Contents/Info.plist". But I think you’ll like this more: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump URLSchemeBinding. It shows every available URL scheme (on your machine). As to how to use them, that’s the job of the developer’s documentation.

If you’re prone to pressing ⇧ in a way which invokes Quick Look when you just wanted the modifier: Alfred Preferences → Features → Previews → [untick] ⇧ to Quick Look selected item. ⌘Y will still work to show Quick Look, but ⇧ will stop doing it.

You don’t need arg: null, you can simply not set it. But I’m curious as to why you want to disable QuickLook. Can’t you just not press the shortcut? And if the problem is that you’re using x-man-page://—assuming all results have it—why not remove that part and add it to the (presumed) Open URL you have later on? Same result, no need for for variables and no QuickLook. That’s the issue with XY problems. There may be a solution that works for your case (like above) but we won’t know for sure unless you explain what the real problem is.

If you want a language-agnostic way of informing users of updates, I’ve made OneUpdater. It’s designed to be easy to setup (and remove if you don’t want it anymore) and I’m available for questions. I know the feeling!

Welcome to the forums, @Torrey. I’ve got to say, really well organised Workflow and code! It’s one of those that’s a pleasure to read. I’m considering deprecating my old old Workflow and point people to yours instead. A few suggestions: Consider filling the “About this Workflow” section. Down the line, someone will appreciate that the usage information is there, and it makes the Workflow look a bit more put together.Instead of requiring an argument, you could make it so if an argument isn’t given, it will use the clipboard contents.With a Hotkey Trigger, you could also add a way to make a QR code from selected text. Looking forward to see what you make next!

Have a nice weekend! Yep, that might be relevant for Bug 3 but from my tests it depends entirely on if QuickLook was actioned and dismissed or not. I wouldn’t be surprised it it were Apple’s bug, but it seems related to whatever causes Bug 2 (which, again, may be Apple’s fault, but perhaps it’s workaroundable).

On the /usr/bin/osascript, you should remove the comments at the top. They don’t make sense in this context. On the /bin/bash, use with input as argv, never with input as {query}. The latter is a legacy option and requires some escaping (which you’re not doing!). You’ll need to change {query} to ${1} in your code for it to work. Finally, replace 'Access-Token: <API Access Token Here>' with "Access-Token: ${API_TOKEN}" (important: note the quotes were changed to double quotes). Then go into your Workflow configuration (where you wrote the “About”) and add a new Workflow Environment Variable named API_TOKEN, set your own API token in the value, then select “Don’t export”. That way it’s easier for users to use your Workflow, because they don’t have to mess with the code; they add the variable where it’s supposed to be stored. Plus, you don’t have to worry about manually removing your own token every time you make an update. Let me know if anything was unclear. 14 days. In theory. They’re constantly being discontinued and picked back up; no idea what’s going on over there anymore. First they launched. Then they were discontinued. Then they were bought/sponsored by some “decentralised cloud storage” company and the uptime was terrible, constantly down (I know who I’ll never do business with!). Then alpha.transfer.sh was officially recommended (but not on the website, you had to know who to ask) as the good version that was up more often (not always). Then they were discontinued again. Now they’re back up, no idea why or by whom. All the while I keep removing and adding it from my Workflow and scripts. When it’s up, it’s super convenient. It supports uploads via curl’s --upload-file while most others use --form file=@ which has specific quoting rules; has short but non sequential URLs; the name is part of the URL; files can be previewed online; and they don’t stay up for long so less chance of them being nabbed by some random person.

Reserving this post for a possible related Bug 4, if I bump into any.

Bug 3 Keep the modification from step 2. I.e. “Don’t close the Alfred window on actioning result” has to remain. Run qlbug. ⇧ or ⌘Y any result to see a preview. Stay on the same result or move to another; it does not matter. Press ↵. Again, three things will happen: A webpage will open.Alfred’s window will remain open.QuickLook will be dismissed. Now press ↵ on any result, it doesn’t matter if it’s the same or you moved. Alfred’s window will be dismissed. But this bug has a few more tricks up its sleeve! Because even if you dismiss QuickLook the first time before pressing ↵, Alfred’s window will disappear.

Bug 2 Make one small change to the Workflow. Double click the Script Filter → Open URL connection and select “Don’t close the Alfred window on actioning result”. Now run qlbug. ⇧ or ⌘Y any result to see a preview. Press ↵. Three things will happen: A webpage will open.Alfred’s window will remain open.QuickLook will be dismissed. Now move to a different result then press ⇧ or ⌘Y. It will not work! You’ll need to press it a second time for it to appear. However, if instead you stay on the same result, pressing ⇧ or ⌘Y will work and show the preview.

Bug 1 Run qlbug. Then move down to another result and press ⇧ or ⌘Y to see a quicklook preview of the page. While the preview is open, press ↵. It will open the webpage (this is not important, you can close the tab). Now the kicker: open Alfred and press ↑ to rerun the last command, and the actioned result will be at the top! If you keep repeating this, the selected results will pile up at the top. It almost seems like intended behaviour, except: If the quicklook preview is not active at the time the result is actioned, the behaviour will not happen.1If you set it to “Don’t close the Alfred window on actioning result”, the behaviour will not happen.If instead of ↑ you retype the same command, the behaviour will not happen.No result has a uid. The combination of all these is what makes me think it’s a bug and not intended behaviour. 1. Even if you had gathered multiple results at the top, actioning another without QuickLook will undo the behaviour.

I started by reporting one bug and in the process found two more. Making a single thread for them, as they’re all related to QuickLook inside Script Filters. I’ll post one reply per bug for simplicity. They can all the reproduced with the same Workflow. It’s very simple, just a Script Filter connected to an Open URL. The Script Filter’s code is: echo '{ "items": [ { "title": "Example", "arg": "https://example.com" }, { "title": "Alfredapp", "arg": "https://www.alfredapp.com" }, { "title": "Wikipedia", "arg": "https://en.wikipedia.org/wiki/Main_Page" }, { "title": "DuckDuckGo", "arg": "https://duckduckgo.com" } ] }' Quick Links: Bug 1 Bug 2 Bug 3

I used it exclusively for middle-click (open link in new tab) at first. Somewhere along the way I got the idea of extending that use to pinch in for closing tabs, pinch out for reopening closed tabs, rotate left to switch to the left tab and rotate right for the right tab. Though I get @apjcs‘s desire to not have multiple app’s running. I’m the same and go to great lengths to make Alfred be my one app as much as I can.

You should, though. Because someone will have to come up with it, and the more work you do beforehand to help, the likelier it is to happen. You’re a designer, coming up with how it should work given the constraints is your strong point. I’m not disputing in the slightest that Markdown is easier to work with. I made a whole Workflow around it, after all. I’m trying to help you see the obstacles so we can surpass them. But other users do, and if Alfred were to commit to having this feature, those people (and their needs) would have to be taken into account as well. Wouldn’t work. Base64-encoding the image wouldn’t make them show up in RTF. When thinking about this feature, you have to forget Markdown and concentrate solely on RTF, because that would be the output format. I understand that. Though note my suggestion works today, and what you’re asking for may never come. Anything is more productive than nothing, and the anything we have right now isn’t bad. I fleshed the idea at length, explained the manners in which it couldn’t work, came up with ways it could work, introduced questions that need to be resolved before implementation, suggested an interface for it, offered a workaround, and volunteered to take your input directly to improve what already exists and is within my power to change. Sincerely, I have no clue how you take “rejecting the idea” from there. Everything in my post was in good faith and is about trying to make your idea a reality in any form. I give up.

There’s another request for this (or something similar) somewhere on the forums. Thing is, Markdown is just plain text; that’s its whole value proposition. It exists as a simple way to create HTML, which is itself just plain text; it’s the browser that parses it into something different. That’s what SnippetsLab does, it parses the Markdown in its own app. Meaning the result is dependent on the application you paste to, not the one you paste from (i.e. Alfred cannot have control over it). The closest we could get to a universal solution would be parsing the Markdown into RTF and then pasting that, which I do with MarkdownTransform. While a possibility, I will point out it’s rife with tradeoffs. The way I do it is by first transforming from Markdown to HTML and then the HTML to RTF, but the bigger issue is the disparity of features. There is a lot that Markdown supports that RTF doesn’t and some things RTF needs that Markdown doesn’t consider, so the question as to what to do in those cases would need to be fleshed out first. Examples: RTF needs a defined font family. Seems easy enough to have an option for it. What do we do about colours? Seems reasonable to ignore those. But then what do we do regarding images and other unsupported things? Do we just strip them out from the snippet’s result1? Seems unexpected, but then does Alfred need to warn you of whatever will be stripped before you save your snippet? None of those is insurmountable, but it seems the new mode would amount to a plain text box with a Rich Text preview with missing features that removes some of your text. With that in mind, seems to me a superior solution would be to manually convert your Markdown text to Rich Text first then pasting that into Alfred. That way you already see what the result will be and can tweak it to add extra stuff. You can already accomplish that via MarkdownTransform, right in the new snippet box: write it Markdown, select the text, press the shortcut. I’m open to suggestions regarding the output of my converter. It’s essentially CSS and nothing is set in stone. 1. That’s what I do in MarkdownTransform, but an opinionated Workflow as more flexibility of choice than a native feature baked into Alfred.

CleanMyMac is particularly aggressive. It considers universal binaries “system junk” and offers to strip the part not appropriate for your current architecture, breaking apps in the process. For future reference, consider /System/Library/CoreServices/Applications/Storage Management.app as a more manual way of finding what’s eating up your disk space. Didn’t you by any change setup Alfred’s Syncing? If so, even if your Workflows were deleted you might be able to recover them as some services (like Dropbox) allow you to restore deleted files.