Chris Messina

It's basically an image-manipulation library for AppleScript. It's how the workflow makes the icon for your Mac.

Works perfectly now. Thank you!

To install
gem install --install-dir "{{custom_dir}}" --no-ri --no-rdoc "{{gem}}" To load from bash
So you can simply ‘require’ in ruby
export GEM_PATH="{{custom_dir}}" To load from ruby
Follow with ‘require’ as usual
$LOAD_PATH.unshift '{{custom_dir}}/gems/{{gem_dir}}/lib', '{{custom_dir}}/gems/{{other_gem_dir}}/lib'

@SJ2K
 
I have updated the workflow. and it support AirPlay
 
https://github.com/alanhg/alfred-workflows/tree/master/switch-audio
 

💯

Great! Next time, let's do this without all the drama.

Yes! This is exactly what I was suggesting — it's both more accurate and doesn't obtrusively get in the way of the default/majority case:
 

 
Thanks for hearing me out and considering this discussion and moving quickly on an implemented solution, @Andrew!
 
And thank you @Mr Pennyworth for summarizing the different perspectives and moving the core conversation forward which, in my view, resulted in a better Alfred for everyone. 😅

Yes! This is exactly what I was suggesting — it's both more accurate and doesn't obtrusively get in the way of the default/majority case:
 

 
Thanks for hearing me out and considering this discussion and moving quickly on an implemented solution, @Andrew!
 
And thank you @Mr Pennyworth for summarizing the different perspectives and moving the core conversation forward which, in my view, resulted in a better Alfred for everyone. 😅

This is now in the 4.3.2 b1219 pre-release

@Chris Messina this is indeed a UI issue, however minor, as the underlying feature works as expected (all URLs are routed via macOS).
 
Alfred should really dynamically be showing the correct default handler if possible.
 
Taking suggestions from this thread (thanks for the relevant input), I've updated Alfred to show "Open With" instead of "Browser", and the default handler will automatically update as you type, for example:
 



 
This should be in the 4.3.2 pre-release in the next few days.
 
Cheers,
Andrew

I love this discussion minus the part where @Chris Messina felt unwelcome. From my limited interactions with @deanishe and @vitor I feel damn confident that no one on this thread means to attack / argue in bad faith with anyone.
 
MacOS settings:
I don't agree with the thesis that Apple's "Default Web Browser" setting is misleading or incomplete. "Web" implies http(s), no? I don't see any ambiguity there. Apple is saying "choose an app to open http(s) urls". It is just that for all other URL schemes, Apple hasn't provided a UI. But whatever UI is present, it is precise, and complete. It claims to be about "web" and it is.
 
Alfred:
Reading the text for the "Open URL" object, presence of terms like "website's search URL" and example of twitter, I feel like there's a possibility that the original design intent behind the "Open URL" object was exclusively for http(s) URLs. The copy certainly reads like that. Another reason for me to believe so is the fact that it is grouped together with "Default *Web* Search".

To my eyes, being able to open other URL schemes with this workflow object seems like a case of "it is possible due to particular implementation details".
 
As @vitor has correctly pointed out, terms "Browser" or "Default Browser" are a bit of a lie.
Imagine the user (workflow user who has opened the object out of curiosity) experience:
- User sees that the URL is "craft://..."
- Browser is "[firefox icon] Default Browser"
- User rightly concludes that it'll open a firefox tab/window and the address bar will have "craft://..."
- User concluded wrong
- When workflow runs, craft app is opened
 
As a user, I don't like such surprises. This is where @vitor's another observation comes in.
- What fraction of users will feel "lied to"? (guess: teeny tiny)
- How easy is it for the above users to update their mental model? That is, them realizing that "when alfred says *default browser*, it means, under the hood, it is like calling 'open' without an app argument" (guess: very easy for most users)
 
My interpretation of @vitor's view is that because it is only a teeny tiny fraction of users who will ever get confused (cuz most users won't know/bother about non-http(s) schemes), and those users (not all, but most) will quickly figure what is going on, it is not worth changing the UI as it would mean complicating the UI for the other users. This is the part where I disagree. What if the said change didn't complicate stuff?
 
Here's a mock:

- instead of "Browser:" it says "Open With:"
- instead of "[Firefox Icon] Default Browser" it says "[Generic Mac Icon] MacOS Default"
 
To my eyes, this change won't add or cause any confusion for the majority of users (who are concerned only with *web*).
At the same time, it eliminates the confusion for the minority too (who would enter "craft://..." and get confused as to why the dropdown has only web browsers)
 
TL;DR: Presently, the following are simultaneously true
As @Chris Messina pointed out, the UI is wrong in some cases. (It shows "[firefor icon] Default Browser, but opens in Craft, which is not a browser) As @deanishe pointed out, most users learn that even though the UI is wrong, the actual behavior is correct. Not all users, because Chris just gave us a data point. As @vitor pointed out, changing UI is a bad idea if it improves experience of a tiny minority while making it worse for the majority. @vitor what do you think about my proposed changes? Do you think it'll degrade the "most users'" experience?
@Chris Messina what about you? Do you think these changes that I suggested would go a long way in addressing your complaint (which is my complaint too, by the way)?
 
@Andrew it would be awesome if you chimed in. You're the OG and solo designer, and looking at Alfred, an outstanding one!
- Do you see this as an issue or non-issue?
- What do you think of the proposed changes?

I’d say the issue might be the amount of back and forth. There are three Alfred veterans trying to help on this thread (and in your others, there were multiple as well). In general, one of us is enough and the others move on to help someone else or only make a small comment for completeness. But since you continue to argue back (not a criticism), the others will try to further clarify the points already made and fill any gaps, which makes it so you have more people to respond to (while we still only have one each—you).
 
 
Yes, but to be honest the example answer you gave is to me the one which feels patronising. It’s essentially what’s already been said but with a “good job, here’s a cookie” in there. I wouldn’t enjoy receiving it, and I wouldn’t feel genuine giving it unless I were truly impressed by the idea (admittedly a high bar). It may have made sense to make such a comment at the start of the conversation, but I entered late into it—when specifics are what matter.
 
Frankly, I need to be direct to be efficient because I assist a crap ton of people daily, both here and on Homebrew Cask plus other projects. The vast majority of people I interact with in this manner find it perfectly fine, so I know it works for me.
 
Everyone has their style, so perhaps ours clash. I’ll pay attention on the next chance we have to interact, and perhaps deliberately pass on it. Again, I understand how you may have found my comment insulting (and I apologise for that) but I expected the previous rapport to have made it less probable to have been interpreted as such, not more.
 
Surely none of us imagined we’d spend so much of a Sunday discussing this. I understand and accept your side of it. I expect you accept mine. Have a great week!

On behalf of the thousands of UI designers upon whom the world depends, I take umbrage with characterizing UI design as the least of the world's software design problems.
 
But I will otherwise ignore it because it is irrelevant to my original point, which was about the "truth" in the interface, which you seem willing to accept as a "lie" for "practical" reasons, which is your wont to do.
 
I prefer to stay stuck in my theoretical bubble if it allows me to pursue increasing honest or accuracy with the users of software that I design or contribute to.
 
 
 
On the contrary, I am interested in expanding the use cases and generative outcomes that users of Alfred perceive based on the accuracy of its interface.
 
That Apple hasn't made this shift in the General preference pane doesn't mean that Alfred wouldn't benefit its users by indicating that routing via URL schemes is an increasingly common pattern, and that URL schemes may be handled by native apps and not just "web browsers".
 
A more compelling argument (that would take into consideration your metaphorical "negative numbers") would be that all apps should now and forever forth be considered "browsers" because any app can register one or more URL schemes into LaunchServices and thus can be refined according to the previous paradigm without disrupting it. This is more akin to expanding the set of "counting numbers" to the set of all "real numbers", which is more inclusive and still as accurate.
 
--
 
Regardless, if you didn't like my proposal, you could have just plainly said so without disparaging me as a "fellow designer".

In case anyone wants to really get nuts with fine-tuned URL scheme management, I suggest checking out Finicky. It's up on GitHub:
https://github.com/johnste/finicky
 
It lets you route URLs to different apps using rule-based logic. So you could make URLs containing *.google.com open in Chrome, and still keep Firefox as your default browser (example).

Yeah. I did bind my fn+arrow-keys to control my Sonos using your workflow 👍🏽

Glad I inspired you! 😅
 
Very creative theme!

Thanks to Chris Messina, and his top-notch non-stop themes, I had a shot at one inspired by mymind (for which I have a few spare invites in case anyone would like to try it out! 😉 )
 
Download here
 
 

 
Requires Alfred Powerpack

Yet if you scan the whole app, there’s no detections. VirusTotal found a single hit from one antivirus vendor which I never heard about. I trust Alfred’s team and maliciousness doesn’t even enter the equation, but in the spirit of thoroughness (e.g. maybe the development machine was compromised) I decided to search online for VEX.Webshell.
 
All I found were matches by Bkav Pro, and all of them were false positives. This specific case with Alfred had already been discussed in Reddit.
 
There’s nothing to worry about.

@SJ2K @Alfred User As explained above by @deanishe, when this occurs, it's down to another app, plugin, or macOS feature locking secure input - and potentially not correctly releasing it when it's done.
 
A few people make reference to Chrome earlier in this thread, and certainly some Chrome plugins (off the top of my head, I know LastPass was an issue at the time) don't correctly release secure input when it's done.
 
Alfred doesn't interfere with the macOS secure input feature and, needless to say, cannot "cancel" or remove another app's secure input, as this would defeat the purpose of that feature.
 
Based on our daily use of Catalina on numerous Macs and generous testing of Big Sur so far, we haven't come across this issue; Snippets are life for me, I don't go an hour without using them, so you can trust we're testing this very thoroughly  
 
I'd take a look at what non-native apps, plugins and helpers you have running on your Mac. Then create a brand new user account temporarily, and ensure that none of these apps or background tools are running there. What behaviour do you see on that second account? 
 
It is difficult to troubleshoot when "loginwindow" is all macOS reports, and much easier when there's an obvious culprit like in the example above where macOS reports that iTerm 2 has secure input, but with the steps above, you should be able to work out what's the cause of your recurring secure input issue.
 
Cheers,
Vero

You can also set it as a fallback result so that it always appears (at the bottom of the Default Results panel):
 

 
Select Ecosia from your Custom Searches:
 

 
And now it'll always appear:
 

You can just double tap your action key (configured in Alfred's Features > Actions > Show Actions) e.g. if you have right arrow configured to show actions, search for an app, then double tap right arrow to the get the recent actions.
 
I have a ticket which will allow further control over the Action in Alfred workflow object based on this suggestion:
 
 

Hi @DaveDay, welcome to the forum.

I’m afraid Alfred’s native dynamic placeholders can’t do that. You’d have to use a Snippet Trigger with a script to generate the date.

This Python script prints the date of the following Monday. Adjust FORMAT to get the date format you want.
 
#!/usr/bin/python3 from __future__ import print_function from datetime import date, timedelta # date format # https://docs.python.org/3.9/library/datetime.html#strftime-strptime-behavior FORMAT = '%Y-%m-%d' one_day = timedelta(days=1) # start counting from tomorrow d = date.today() + one_day while d.weekday(): # Monday = weekday 0 d += one_day print(d.strftime(FORMAT), end='')  

Hey guys, I just installed Big Sur on my MacBook Pro and just noticed that Alfred wasn't there with the Mojave Theme I was using, so I decided to create one and there it is.

Hope y'all like it.
 
You're free to use it wherever as you want.
 
Download: https://github.com/felipemeamaral/alfred-big-sur-dark-blue
Obs: You have to be using Alfred 4.3+ to install this theme.
 
And Happy 2021! 😎

Happy to kick off 2021 with a new workflow to quickly access Instagram's web features. It's not very clever but it just speeds up the way I access parts of Instagram.
 
Supports keywords like @, #, dms, my, and download.
 
Get Instagram Toolkit for Alfred
 

Try ShortcutDetective from this page. It might be able to tell you what the shortcut’s assigned to.
 
https://www.irradiatedsoftware.com/labs/