Jasondm007

@deanishe Agreed - it's just a problem in Alfred's preferences, as described above. And, to be clear, it's a relatively minor UX problem in the scheme of things. For the most part, I really like Alfred 4's new look. 
 
While the point about dark themes and usability across light and dark themes is fair, it's odd to rule out the use of dark iconography now in Alfred's preferences. Ignoring Alfred's longstanding use of gray/light backgrounds and black typography, there are a lot of people with vision-related issues that depend on white/gray/light backgrounds and dark text/icons for legibility purposes.
 
Not to mention the fact that Alfred's own icon is hardly visible in the settings described above. Take a look at the screenshots below. Why create visibility constraints that even the app's own icon doesn't work well under?
 

 

 

I’ve posted this as a bug but, in fairness, it’s a feature of Alfred 4 (and not a bug). Namely, some aspects of Alfred 4’s new GUI are too dark to be legible in some use cases - particularly for those who use dark iconography.  
 
In the workflows section of Alfred’s Preferences, this problem manifests itself where the icons are displayed in the inner sidebar and in the informational portion at the top of the window. In the screenshots below, note how difficult it is to see the black search / magnifying glass icon? For me, it’s more of a functionality problem than an issue of aesthetics, as I rely on the sidebar icons to quickly find the workflow I’m looking for. While the text looks good, unfortunately, the icons are no longer visible in Alfred 4.
 
Workflows - Sidebar

 
Workflows - Informational Portion (top of screen)


The second place where this issue comes up in Alfred’s Preferences is when viewing Snippets. While this problem also involves the use of black iconography - for snippet Collections, specifically - it’s only visible to those who use MacOS in dark mode (but use a light Alfred theme).  In these cases, the background color behind the collections’ windows is dark, making black icons impossible to see (see screenshot below). 
 
Features - Snippets - Collections Window

 
 
There are a ton of ways these issues can be fixed, so I thought I'd throw out a few:
Easiest fix: use lighter background colors in these cases (e.g., flipping the two purple colors in the sidebar, so the dark is on the outside) (e.g., going with a lighter gray/black in the upper information) Another fix: add another display option with a lighter color, such as those accessed via the gear next to Alfred's workflow filter (screenshot below). However, something else would have to be done about the snippets/collections problem, since it lacks such options.
 
My favorite fix: add a color palette option to Alfred's main preferences. Personally, I like OmniFocus' approach, which provides users with three options for: automatic, light, and dark modes (see screenshot below - they call the "light" version, just plain old OmniFocus). Here, the automatic mode would just follow the MacOS designation, and the others would allow users to manually place Alfred in either mode. Among other things, this would entail creating a light mode - or in keeping with OmniFocus, just a plain old "Alfred" mode - where the issues outlined above are easier to see (in addition to maintaining the lighter toolbar, which Alfred already does when MacOS is not in dark mode).   

 
Thanks for your consideration!

This workflow is officially deprecated in favour of Shrieking Chimes.
 
Control SandwichTimer from Alfred, to run pomodoros and timers. If you don’t have the app installed, invoke :sandwichtimerupdateapp to get the latest version. See the linked page for screenshots of the app in action.

Call pomo or set a keyboard shortcut to start a pomodoro timer. If another is already running, it’ll be aborted.

timer will let you set as many timers as you want, for the specified amount of time. Text after the number of minutes will be used as the timer’s title.

With both options, actioning with ⌥ will quit all instances of the SandwichTimer app.

No reason this couldn’t work as both a file action and a hotkey. The cleanest solution would be to add a new node, similar to a Browse in Alfred Action that adds to the buffer. That way we could make more complex selections, like have a Workflow that does something with some files and sends others to the buffer. It could even have an extra checkbox to Browse in Alfred after adding to Buffer — it it’s off, it just adds to the buffer, if you check it, it opens in the File Actions pane so you can immediately act on them.

I would love to start using Alfred’s file buffer more often, especially with some of the nice additions made in Alfred 4. However, Alfred is in dire need of better Finder-Buffer integration.
 
Either of the following would solve this:
a File Action that adds files to the Buffer, or a Hotkey that can be used to add files directly from Finder to the Buffer (i.e., in Preferences → Features → File Search → Buffer).  
Under the current setup, the ability to use a hotkey to file action files from Finder is great (Preferences → Features → Actions → Selection Hotkey), but it doesn’t help with situations where you want to action the file more than once. Several people have created workflows that effectively mimic Allred’s keystrokes, but they’re all pretty fragile (example). In addition, I still haven’t found any that work with multiple files.
 
This feels like something that ought to be addressed on a system-wide basis. Alfred’s a great butler, but I think he can carry even more things! 😉 Thanks for your consideration.

I'd like to open up a feature request to have "Fuzzy" matching as one of result filtering options that Alfred handles. This would improve some of my workflows quite a bit. This can be achieved by running other script based tools or implementing the search within your own script, but it would make things easier, if it was already built into Alfred.

+1 from me (to nobody’s surprise).
 
I would definitely love to see some more options for Alfred’s filtering. Fuzzy, OR, AND, and perhaps XOR (which is generally unintuitive, but sometimes useful).
 
Fuzzy search, in particular, allows users to train Alfred to adapt to the way they think/work. The way filtering currently works, I rather have the feeling that I’m learning to adapt my queries to what suits Alfred.

I'd love to see each file's tags listed in the information provided by File Navigation's Preview Panel. Tags seem more important than most of the info that is currently listed (e.g., app the file opens in, date created, etc.). Why not list the file's tags there? 
 

 
 
At the moment, Alfred doesn't have an easy way for viewing or modifying tags, and this seems like a good first step that won't demand a complete overhaul of anything.
 
Ideally, I'd love to see Alfred have its own file action for tags, too, which allowed users to view the file's current tags and modify them as needed (without requiring users to remember their list of tags, etc.). Relying on Finder's "get info" feature is a little clunky, as it requires leaving Alfred, etc. I have some workflows for adding or removing tags that I often use, but they're not very flexible (e.g., they don't tell me which tags are already on the file, they don't dynamically tell me which tags are in use on my system, etc.). Lastly, I'd love to see tags visually incorporated into Alfred's main search results (favorite suggestion here), but I guess that's for another day!
 
Thanks for listening!

Here, try this:
 
https://www.dropbox.com/s/cn5blbpf4flq70g/Active Windows.alfredworkflow?dl=0
 
If you don't have Skim installed it may crash.  If so, try setting the environment variable to just Preview

Yeah I’m actually working on a workflow that will do this, with any app that supports Applescript including preview. Might be a week before i can get it done.

Just added one to this workflow, keyword is fat - Finder active tabs - because FT kept bringing up FaceTime.
 
The only catch is that AppleScript treats every tab as a separate window, so if you have multiple windows, they will all appear in the results.

@Andrew Thanks for the clarification on the JSON Config utility! In past attempts to fix the workflow after the upgrade I had mistakenly used the curly brackets {} and not the parentheses () with query, which explains why it didn't work.
 
Also, thanks for the File Filter update in 4.0.2. It works perfectly without the JSON Config utility! It's a million times easier now!!
 
Unrelated to this thread, but thanks for fixing some of the dark mode-related quirks in 4.0.2. It looks great!
 
Thanks again for all of your help, and attention to everything! Honestly, I don't know how people work without Alfred. Hope you have a great weekend!

4.0.2 is now in pre-release, so you should be able to reliably use {var:tag} directly in Alfred's Fields prefs instead of needing to configure it in JSON.

@Jasondm007 I've taken a quick look at this - you're missing the query field in your fields, so Alfred doesn't know you want to narrow things down.
 
In both Alfred 3 and Alfred 4, your JSON would need to look a bit more like this (note there are normal brackets around the query value to tell Alfred to use the typed {query} instead of the fixed {query} passed into the JSON config😞
{ "alfredworkflow" : { "arg" : "*", "config" : { "fields" : [ { "not" : false, "split" : true, "field" : "kMDItemDisplayName", "value" : "(query)", "words" : true }, { "field" : "kMDItemUserTags", "split" : false, "not" : false, "value" : "{var:tag}", "words" : true, }, ] } } } It's also worth noting that I'm making a couple of tweaks in Alfred 4.0.2 which will make using {var:} much more robust within the "Fields" prefs directly (this was added as a v4 feature), so you won't need to use the JSON config at all.
 
I'll be getting 4.0.2 in pre-release today.
 
Cheers,
Andrew

You're the best, @Andrew. Thanks for taking a look at it!

Who cares as long as it works, right?

I'm sure the dumb luck is on my end! Ha

Exactly, that helps for me: Log-out/log-in after doing that.

The thread about what? I don't believe I deleted anything... I'll go looking for it

I've posted updated workflow to github with permission from Carlos.
 
Link to repository
 
Direct link to the Workflow file

Since moving my snippets from TextExpander to Alfred, I have added a lot of snippet triggers to my workflows.  However, using the snip keyword and/or the snippet viewer, the only results shown are snippets, not snippet triggers.  Could we have the option to include snippet triggers in these results as well?
 
 

@Bhishan I've implemented this in a much larger workflow, so I'd recommend downloading @Andrew's posted above (July 18, 2018) - which fixes the original workflow:
 
 
I just checked, and his Dropbox upload still works.

I have something in the works which I think will make you very happy with regards to this. That's all I'm saying for now
 

I guess that mostly explains why no such workflow currently exists…
 
For my part, I'd very much like such a workflow. Perhaps @Andrew can weight in regarding how feasible it is.

@Jasondm007 oh, thank you sir!

It's a bit tricky, I tried addressing it a few times, but the implementation always was hella unstable, so I gave up trying (for now).

I hope, when I have some free time I will get to it, it's the biggest limitation so far.

The messages like yours are very encouraging, thank you for that! :)