Chris Messina

Nope... might be a Quicklook issue? QL seems all kinds of impaired on Big Sur.

I'm not entirely sure how my comments/contributions are being received, such is the limitations of this medium. I'll presume some warriness on y'all's parts owing to prior experience, as well as an opening for me to prove my worthiness over time, like any healthy ecosystem. Given that — I'll presume that we're all interested in 1) Alfred persisting indefinitely 2) growing in utility/accessibility for all comers 3) focusing on investing in the most important/core components that enable #2. The way in which those goals might be achieved are where we each have our own unique perspective, likely biased towards our own ability to contribute. As someone who is code-aware but not code-literate, I imagine there are more people out there like me than there are like @vitor who know Alfred inside and out. So, my bias is for giving people with my level of skills more capacity to wield Alfred's powers. I'm open to learning more, but in recognizing my ignorance, am trying to advocate for tactics and strategies that will decrease the slope of difficulty for using and customizing Alfred. I'm also able/willing to back off from my advocacy if I have a deeper intuitive sense for where Alfred is going and have a general understanding of why it's going where it's going. To wit, there is no Alfred roadmap that I'm aware of — and while I do respect the wisdom that @Andrew and @Vero bring to this process, and absolutely believe that they know their audience best, I hope that my curiosity and probing isn't offensive as it derives from a place of wanting to be helpful and to contribute. But if I don't know who the audience is, and I don't know what the roadmap is, then I'm left to suggest/propose directions that are most relevant to my immediate needs/interests. I do trust that Alfred will continue to get more awesome — and I'd love to understand how to shape my contributions to support that end!

It's not clear to me whether Alfred auto-switches themes if you never change them based on the macOS setting. i.e. if you use Alfred without any customization and macOS changes appearance, will Alfred switch themes? Because for some reason my recollection is that Alfred always used only ONE theme (because I never thought to change it when my OS changed appearance). What I would expect, as a user, is that Alfred would support Light and Dark themes out of the box, without any user intervention, which is increasingly how most of my non-themable apps behave.

Fair enough. It's true — I was blown away when I discovered that Alfred support automatically switching themes based on OS-appearance! How many Alfred users have any idea though?

Well, it's just not clear to me what the path for seeing improvements to this feature would be. It has a unique UI that isn't (AFAIK?) accessible to Workflow devs, so it's not like I could build a Spotify Workflow that uses the music mini-player as it's UI. But that's basically what I'm proposing... I just have no idea how that'd happen and if it'd require a significant change in Alfred's underlying architecture.

I think this conversation could devolve if we're not careful, but let me acknowledge both your and @vitor's point that Alfred is a one-man show when it comes to maintaining the core — and that I imagine the codebase is pretty sprawling — so my comments/feedback/suggestions are in no way to knock on @Andrew's efforts (to the contrary)! That said, I want Alfred to be even more amazing — but you have to be pretty savvy to get the benefits. And so I wonder if certain parts of Alfred should now be spun out into open source components or refactored as UI APIs that Workflow devs could also contribute to (i.e. through open source contributions)? The music mini-player is one clear example of a component that could use some love from the community and enable the community to serve itself better. If @Andrew doesn't want to hire more help and there's an anti-VC sentiment here, there is still a question about how to grow the community of participants (presuming there's an appetite for that — I certainly want to make it easier for people to benefit from and participate in the Alfred community!) and make it easier for Alfred to tackle a wider set of use cases without overburdening @Andrew. There are arguments to be made against offering more avenues for open source contributions (i.e. healthy open source projects don't happen for free and without a lot of overhead) and one could argue that the Workflow system is sufficient as it is... but I'm just looking at shareable UI components (for authorization, for playing media) and wondering if the community could contribute more to Alfred Core in a productive way? Well, besides the fact that (AFAIK) you can't order Alfred on a CD and need the internet to buy the Powerpack... no, Alfred Core doesn't connect to the internet that much... but it also integrates Web Searches, Web Bookmarks, the Dictionary integration looks up information on Wikipedia... Anyway, my perception is that Alfred is software that helps me use my computer more efficiently and for me, 95% of that work is online and through web services these days. I know looking at the competition isn't what should drive one's roadmap, but the competition for Alfred's role on the desktop is heating up and 1) there are a bunch of good/interesting ideas in some of that competition and 2) given my above thoughts about growing the community of contributors (which is ultimately self-serving, since the better Alfred gets for everyone, the better Alfred gets for me), I'm mildly worried that more newcomers will bypass Alfred and join those newer projects instead, which is fine — but not so fine if we want to attract the best and most interesting contributors...

I set a domain env variable, so perhaps it's not being substituted/passed resolved to Quicklook?

It's better...! Now it reads "Search for '' in Spotlight". Also, it is not normal that when I key down to an option from the List Filter and hit the "shift" key, an empty Quicklook preview appears?

Fair enough. I will submit that my suggestion needs much more detail before it can be evaluated as a proposal. My original issue had to do with seeing and using other Alfred Workflow from the time before an OS-level Dark Appearance, and noticing that Alfred's UI is somewhat impaired as a result of iconography that assumes only the Light Appearance. Since both Light and Dark Appearances will be the norm going forward, I'm just trying to think of ways to make it easier for Workflow developers to support both Light and Dark modes by taking advantage of available resources, rather than, say, having Running with Crayons have to invest in their own bespoke icon set. I'll continue fleshing this out and when I have something more concrete (i.e. best practices, etc) will report back!

Not sure how to frame this, because I don't know how Alfred thinks about media and music playback beyond the native apps macOS comes with... but the built-in Music mini-player works only with Music.app (né iTunes) but seems somewhat antiquated now that podcasts and shows have their own apps: TV.app Podcasts.app While I understand a music mini-player isn't meant to be holistic in nature, I do wonder if it might be possible to make the mini-player pluggable in order to support other music services (i.e. Spotify, YouTube Music)? I currently use Spotificious but it would benefit from the richer interface of the mini-player: Like, Spotificious works, but it's not nearly as functional as Alfred's mini-player: but I think it'd be quite the improvement to Alfred to support other Music Services similar to Sonos: Anyway, I'm filing this under Themes because there are some visual inconsistencies in the mini-player UI and so I figured I'd bring up this broader question ahead of diving into specific theming details related to the mini-player to get the general temperature.

Huh, I hadn't thought about that. I didn't realize that people use Alfred disconnected from the internet.

The Feather Icons are released under MIT license, although there are only 286 compared with SF Symbols's 2400. Are you open to using Feather icons? Also, Apple states: So as long as Alfred isn't using them in "app icons, logos, or any other trademark-related use", this implies that use in interfaces would be fine, since they "shall be considered to be system-provided images". Given that Alfred already uses many system-provided images, using SF Symbols seems an extension of that existing behavior. For example: Again, my goal/intention is to make it easier for Workflow developers to support Light and Dark Appearances. Of course we can leave it up to each Workflow developer to source their own icons for each appearance mode, and trust each to do a good job selecting consistent icons, but this seems like overhead that many Workflow devs would possibly prefer to avoid, if possible. I suppose I'm biased to making it easier for people to make Workflows that offer good looking interfaces in both light and dark modes with less effort. Is that also something that you are interested in, or not so much?

Just dropping more evidence of a pattern I'm seeing in cloud-connected software... this time in Linear.app.

Oh! Thanks! They're all available on GitHub! https://github.com/chrismessina?tab=repositories&q=theme

This is a very basic workflow that allows you to set a keyboard shortcut/hotkey to open the current browser's URL on Brandfetch. I'm sharing it primarily as a demonstration of this technique, which was discussed in this thread with guidance from @vitor. 🎩 Get Brandfetch Toolkit for Alfred

Gorgeous!! Rounded search box with indented text: Rounded scrollbar: Aligned horizontal separators:

There are, but these are specifically offered by Apple for the purpose of incorporating into software UIs. At least if Alfred wanted to provide consistency in visual styling, SF Symbols would be a solid start. I also love the open source Feather icon collection.

Very svelte!

Yes, I was thinking that Alfred could add support for SF Symbols as a source for Workflow iconography (similar to emoji): A Workflow dev could provide their own monochrome template image PDF/SVG/vector icon that could be given similar treatment — and it would be nice if appropriate icon coloring were provided for free, as suggested in this documentation.

@Alan He Just spotted this workflow, might be of interest: https://github.com/Acidham/alfred-airpod-connector

@Alan He I tweaked index.js to add some context to each option (the line `title: "Switch to " + item,`), but I'm getting an empty row as a result. Any idea why? console.log( JSON.stringify({ items: audios .map((item) => item.replace(/(^(\n|\s)|(\n|\s)$)/g, '')) .map((item) => ({ title: "Switch to " + item, arg: item, subtitle: item === currentDeviceRes ? 'selected' : '' })) }) );

I realize I may be the only one who cares so much about theming, but what can I say? I do! It occurs to me that for some Workflow icons won't work well (i.e. black icons) in Dark Themes. Workflow builders assume they're fine because they work in Light themes, but then become harder to see in Dark themes. Example: I think it might be possible to detect whether someone is using a Dark or Light theme using some logic in the Workflow, but then each Workflow would need to repeat this logic. @Andrew Given how widespread the Light and Dark Appearance UIs are becoming, is it possible for Alfred to support icon switching in Dark Themes?

Got it. And you're using Node and not Perl. I personalized the keywords to "output" and "input" (based on my muscle memory with the previous Workflow) and adjusted the text of the notifications to be a little clearer: Audio could not be switched to {var:device} Audio switched to {var:device} Thanks for sharing!

How is this different than @mikegrb's Audio Device Workflow?

Just launched another theme! This one was inspired by Google's iOS Widgets. It uses Google Sans as its typeface. Eager for the next update to Alfred so I can match the rounded corner design better... @Andrew says it's in the works! 🎩 Download theme