vitor

Update. Added a hotkey to play the frontmost browser tab. To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

Not that I recall. Perhaps the Workflow transition from Alfred 1 to Alfred 2? Every case I remember is either a deprecation (i.e. it still works it just doesn’t get any more updates) replaced by something better or an outright change with no toggle back (though again, I’m uncertain). But the point here is different. The toggle would be a change in one place which would break a different feature and only sometimes. That would be a recipe for bug reports. To be clear, the argument as I’m making it is not necessarily that a toggle shouldn’t be added, but that doing just that would be insufficient. The solution should either be something difference or it needs some addition to what you’ve already mentioned to make it robust. That’s what’s at the core of our inquiries, to find what would work for you and also for the majority of Alfred users. Do note that @Vero and @Andrew have the final word on what goes into Alfred; it’s their app. And they choose carefully, so we should be methodical about feature requests to get at the heart of what’s important and what has a tradeoff which isn’t worth it. Finally, forgive me but I’ve been wanting to post this image for a while now. I mean absolutely nothing by it except “there’s an XKCD for everything” and this one I find particularly funny and think it fits the thread. Alt text: There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.

And corroborated by a Developer Tools Engineer. Versions of Python, Perl, and Ruby are the same as in Big Sur.

So you keep saying, but how do you know that? Truthfully, isn’t it the case that you feel it? Respectfully, I believe you’re falling into a common pattern of projecting your preferences and believing they are more common than they are. Consider that besides yourself, all three people on this thread have been monitoring this forum for a decade, and each of us reads pretty much every post. Yet, despite numerous feature requests over the years, we haven’t linked you to previous discussion on this topic. Because there are no legions of users clamouring for automatic trimming. You care about this; most people don’t. Which is fine, that’s what Workflows are for, to enable you to create your own experience. But to do that Alfred needs to be flexible, and in this situation it means not auto trimming what’s pasted into its search box. We all understand your request. But it’s one that needs to be thought through because it is a very specific solution with possible undesirable ramifications. Alfred continues to evolve. Maybe a future Alfred feature which does something different can be adapted to do something close to what you ask without the consequences of the preference toggle. But the Workflow option is pretty good. And you may make it even better: Have your new hotkey do what we discussed plus press ⌘a, meaning your text will be preselected. Then you use that hotkey as your primary way of calling Alfred and your trimmed clipboard contents will always be on hand. When that’s not what you want you can just start typing to overwrite it.

@brad parks It’s worth noting @deanishe’s suggestion can be even more convenient than what you’re asking for. Even if the newline were stripped on paste, you’d still have to do two steps: invoke Alfred and paste. With the Workflow solution, you can press a hotkey (one step) that will trim the whitespace of what you have in your clipboard and open it in Alfred’s prompt, ready for you to edit.

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. Python, Perl, and Ruby survived in the same versions as Big Sur, but PHP was removed. 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.