Mr Pennyworth

@Mr Pennyworth If you update to 4.3 b1199, you can now set the following pref:
 
defaults write com.runningwithcrayons.Alfred experimental.presssecretary -bool YES  
You'll need to restart Alfred after setting this preference, then subscribe to the distributed notification:
 
alfred.presssecretary  
You'll get relatively detailed output, for example:
 
{ announcement = "selection.changed"; selection = { objectuid = "D51F7B33-AE36-4A45-91FF-E983659833EF"; quicklookurl = "file:///Applications/Safari.app/"; resultuid = "user.workflow.1B09DD22-0FDA-43B0-88DE-FBC92B83DA70./Applications/Safari.app"; subtext = "/Applications/Safari.app"; title = Safari; workflowuid = "user.workflow.1B09DD22-0FDA-43B0-88DE-FBC92B83DA70"; }; view = default; windowframe = "NSRect: {{921, 884}, {718, 259}}"; }  
Announcement types are as follows:
 
window.shown - The Alfred window has been shown on the screen window.hidden - The Alfred window has been hidden context.changed - The view has changed from e.g. the default results to file system navigation selection.changed - The selected item in Alfred has changed  
The different contexts are as follows:
 
default navigation actions music (note: actions and music don't post out selection notifications)  
Important note: This feature is experimental, and there is no guarantee that it will remain in Alfred in the future. Having said that, if it's removed, it would likely be replaced with a more robust solution.
 
Let me know how you get on
 
Cheers,
Andrew

This. Foot-guns are a big no-no. Features are generally measured against what would happen if they were used with reckless abandon rather than with sound judgement and great care.

@Mr Pennyworth I'll post back in this forum when it's available, I have quite a bit of other Alfred 4.3 work remaining but this is still on the plan.
 
You won't see anything extra in the defaults read when this is available, as you'll be using a defaults write to add something.

Alfred GIF Search
Download: Gif.Search.alfredworkflow
Up-to-date README (this post is outdated)

This workflow lets you search GIFs on Tenor from Alfred.

Here's an example of searching and inserting a GIF in a google doc:


Installation
Download the latest release. In Alfred, run .setup-gif-search.
Usage
In Alfred, enter gif keyword followed by search query. Press ↩. Use arrow keys or mouse to browse the GIFs. To copy the selected GIF to clipboard: either ⌘↩ or ⌘-click To drop the GIF into apps that support it: drag from Alfred and drop into that app
Note

Firefox and Chrome don't support pasting GIFs from clipboard. That is, if you copy a GIF to clipboard and paste it, it shows up as a static image, not an animated GIF. This is not a bug in this workflow, but rather just the way these browsers have decided to handle GIFs.

Both Chrome and Firefox support drag-n-drop. If you use either of these browsers, sorry, you gotta use the mouse!

Alfred GIF Search
Download: Gif.Search.alfredworkflow
Up-to-date README (this post is outdated)

This workflow lets you search GIFs on Tenor from Alfred.

Here's an example of searching and inserting a GIF in a google doc:


Installation
Download the latest release. In Alfred, run .setup-gif-search.
Usage
In Alfred, enter gif keyword followed by search query. Press ↩. Use arrow keys or mouse to browse the GIFs. To copy the selected GIF to clipboard: either ⌘↩ or ⌘-click To drop the GIF into apps that support it: drag from Alfred and drop into that app
Note

Firefox and Chrome don't support pasting GIFs from clipboard. That is, if you copy a GIF to clipboard and paste it, it shows up as a static image, not an animated GIF. This is not a bug in this workflow, but rather just the way these browsers have decided to handle GIFs.

Both Chrome and Firefox support drag-n-drop. If you use either of these browsers, sorry, you gotta use the mouse!

A more logical solution seems to be to make OAuth less complicated. I’ve never seen anyone say they like it or found it easy to add.
 
I’m not trying to disparage your work. I don’t question you did what best you could under the circumstances, but if even the official website recommends—on the homepage—an external service to take away the pain of implementing it, it seems something else could improve in the standard itself.

 
 
Then you seem uniquely positioned for the idea above. Why not work on the generic open-source tool which would make this easier for everyone, at the same time saving whatever limited time Alfred’s sole developer has? Your request is a niche feature (in the grand scheme of Workflows) that takes a lot of (by your own admission) annoying work.
 
This is a genuine question. Is there something stopping you from working on such a tool, seeing as you have the domain knowledge and the desire to see it applied in this particular case?

With a generic tool, everyone would benefit. There’s nothing to be gained by this being implemented directly in Alfred, in the sense that an external tool would work just as well (but would have several outside advantages). Heck, if you do it I’ll even write the code and documentation on how to add the resulting token to Alfred Workflow Environment Variables. And I’ll make examples in AppleScript, JXA, and by directly editing the plist.

@vitor
Absolutely! ☺️
 
Isn't the former what most programmers strive to do?
Rigorous considerations of memory usage, cpu usage, disk IO, network latency etc, and meticulous design considerations.
So I thought it doesn't need defending. Be as it may, I stand corrected. Looking at all the examples you posted, you're definitely not averse to quick-and-dirty hacking and tinkering
The conclusion that I drew that it is a core MIT-vs-Berkeley philosophical difference seems to have been wrong!
More like it was based my own lack of foresight and all-round understanding of Alfred, and the community.
 
I see that now, and completely agree!
 
I also realize the core of my argument is likely completely wrong. I had a sample size of one. "What would I, as a user do, if workflows started slowing Alfred down?". In addition, you have years of experience, and a sample size of users at least three orders of magnitude bigger.
 
I really appreciate the patience, and the detailed and explanatory nature of your answer!
(And @deanishe and @Andrew's answers)

So many considerations and tradeoffs I hadn't even bothered to think about!
You all are the best! 🍻

@vitor
Absolutely! ☺️
 
Isn't the former what most programmers strive to do?
Rigorous considerations of memory usage, cpu usage, disk IO, network latency etc, and meticulous design considerations.
So I thought it doesn't need defending. Be as it may, I stand corrected. Looking at all the examples you posted, you're definitely not averse to quick-and-dirty hacking and tinkering
The conclusion that I drew that it is a core MIT-vs-Berkeley philosophical difference seems to have been wrong!
More like it was based my own lack of foresight and all-round understanding of Alfred, and the community.
 
I see that now, and completely agree!
 
I also realize the core of my argument is likely completely wrong. I had a sample size of one. "What would I, as a user do, if workflows started slowing Alfred down?". In addition, you have years of experience, and a sample size of users at least three orders of magnitude bigger.
 
I really appreciate the patience, and the detailed and explanatory nature of your answer!
(And @deanishe and @Andrew's answers)

So many considerations and tradeoffs I hadn't even bothered to think about!
You all are the best! 🍻

@Mr Pennyworth Just to make sure we keep discussing on the right foot, I’ll preemptively say—because we haven’t interacted much yet—I believe we’re both arguing in good faith and I intend to keep it that way.
 
 
If you send me a link defending the former, I can compare and decide.
 
 
Like making a Script Filter self-update, or a single-player or multi-player Alfred game.

I understand the tradeoff of ugly hacks; it is my opinion the tradeoffs for this one overshadow the gains. Like I said, this one doesn’t cut it for me.
 
 
 
On the contrary, I see that as fallacy fallacy.

I’m not sure how (but I’ll take a suggestion) I could’ve made my point another way; we’re talking about something that hasn’t had the time to be proven either way yet. It’s like Portugal’s drug policy: one side claimed it would lead to widespread rehabilitation and the other to widespread increased consumption. The former was right, but both could have been called slippery slopes. And the whole goal of the policy was the slope (for the better).

But back to the point, I’m perfectly justified in making that assumption, because I read almost every post on this forum and I’ve seen a request for this popup more than once. So in answer to your question:
 
 
Because they can. Read the feature requests for a while and you’ll see several that aren’t feasible or reasonable, because not everyone thinks about or understands the full implications of their ask. Which is fine; Alfred’s userbase contains plenty of non-technical users and not everyone has to know that deep down computers suck and everything is held by duct tape (to the surprise of no one, there’s an XKCD for that).
 
 
I think you’re overestimating the technical proficiency of the average user. What’s likely is that person will not understand which Workflow is causing the issue and think it’s Alfred. As above, to see that one need only read the forum questions (and once more, it’s fine that people who don’t care for technical matters to not understand the cause).
 
 
Right. Again, I’m a fan of your ingenious solutions and I’m confident you think about the implications of your work and are perfectly capable of deciding on acceptable tradeoffs. But as someone who cares enough for Alfred to read almost every forum post and spend the time to build Workflows I’ll never use, I try to think of every development as “how will this affect the community and experience as a whole”, because that has a major impact on Alfred’s future.

To end, I’ll reiterate I think you and your solutions are a welcome addition to the community and I hope we can keep arguing based on the technical merits of solutions.

Right, for the next 4.3 pre-release, I've added ⌃↑ and ⌃↓ to navigate the history in the default results at any point (even if you have typed a different query).
 
These shortcuts by default are used in macOS for Mission Control, and Application Windows, so these associations will need to be disabled in the macOS Mission Control prefs for these shortcuts to work within Alfred.
 
I should nave the next pre-release out some time this week.

@Mr Pennyworth While it's clever in concept, I'd personally discourage using the multi-Script Filter method you're using, even though it's unlikely to, in isolation, cause any performance issues with Alfred. If somebody installed multiple workflows which used the same method, then Alfred will be running multiple scripts on every keypress.
 
There is definite scope for an enhanced native command history built in to Alfred. This would take some thought and design, and would be configurable and user opt-in. I would also think about a easy-on temporary private mode, much like a browser, to prevent typed queries being stored, and also allow for expiry. The history would be likely stored in an sqlite db so it could also be accessed by workflows where necessary.
 
Further to this, one thing on my future plan is to allow users to specify specific workflow objects to be included in the default results. Again, this will require some thought as it should be a user who decides this, and not a workflow developer. This would facilitate workflows like this one, and Calculate Anything, to work without needing multiple script filters. At the point that this happens, Alfred may start profiling script tasks and warning if they are taking too long or consuming too much CPU.
 
Cheers,
Andrew

Gee, thanks! ☺️
 
Yep, very much understandable!
 
Valid points!
In fact, the points you made are a short and condensed version of all the "caveats and disclaimers" I explained here:
 
I think we differ in our core philosophies, your arguments make me believe you might be more of the "MIT philosophy" guy while I find "worse is better" more appealing (https://www.jwz.org/doc/worse-is-better.html). Furthermore, if there's something I really really want, and I have no control over "the correct way of doing it", I would rather go ahead and put together some ugly hacks till I make it work than wait for the official, correct way to materialize.
 
Disagree.
It already mixes
file searches contact searches web bookmarks calculator I would agree that Aalfred's treatment of built-in features differs from the treatment of third-party workflows.
I would agree to a modified version of the statement for sure though: "Alfred's workflows are designed to be called explicitly"
And even that, I wouldn't bet my money on. Because I don't know what goes on / went on in @Andrew's brain. Did he design it like that? Did it just happen to end up being like that? I would guess, but wouldn't claim to know.
 
I'm not at all a fan of slippery-slope statements and unjustified generalizations.
They add words to a discussion without adding any substance.
The generalization isn't justified because most workflows are meant to do something specific, and not something universal. When a workflow (like this one) is meant to do something "alfred-wide" and/or "meta", it doesn't make sense to me to discuss "what if many workflows...". The answer to "what if many workflows ...?" question is a simple one: "why would many workflows ...?". If people keep building these If a whole lot of people do not build such workflows, or if no one really wants to use them, the sustainability problem never arises. If a whole lot of people do that and a whole lot of uses start using those and it becomes a performance problem, that's such a great signal for @Andrew that there's a super-popular way people are using Alfred that he initially hadn't designed for. If it were a product that I developed and I come across such a thing, I would be thrilled to discover something like this. The best feedback a developer could get is users voting with their usage patterns than a few vocal people requesting on a forum. Several workflows competing with each other Scenario: The competing workflows make the default results not very usable or unpredictable. (doesn't apply here anyway)
Result: People disable / uninstall such workflows.
Looks to me like a problem that solves itself. I don't see why this point is relevant at all to this particular discussion The history logger doesn't compete with anything, as it produces 0 results It is not a significant performance hog as barring in-memory operations, appending at the end of a file is one of the cheapest operations there is. "Script filter for every letter"
That makes it sound like that's particularly expensive. I'm sure beneath Alfred, there is solid design and sound data structures (a trie that stores the keywords comes to mind). Even though there are more than 40 script filters in the workflow, at any given instant, it is practically equivalent to one script filter. (User types the first letter -> Alfred picks 1 among the 40: that would ideally be a constant-time operation, and a fast one at that. After the first letter, for the subsequent letters, assuming a trie-like implementation, there should be zero overhead in picking (as it already has been picked) the filter). The complaint about "one script filter for every letter" is similar to complaining about the number of entries in a hash table. The whole point of a hash table is that the size doesn't really matter, the lookups take constant time.
I'm just making this point because any non-programmer person reading your comment would get the impression that "having so many script filters is scary/heavy". I'd guess that you didn't want to create that impression either. I'm just saying that it could come across as that. So, I'm clarifying here that the number of script filters here is almost immaterial, especially if all of them are mutually exclusive. My summery technical characterization:
It is one extra script filter that runs asynchronously (like every other) that doesn't interfere with results that doesn't delay the results that is computationally damn cheap

I'm sure it was a deliberate decision to not allow user-written code to run without being explicitly called by the user. Performance is a super-high priority, and allowing arbitrary workflows to run whenever Alfred is opened isn't really compatible with that.
 
 
Me, neither, but that's the way it will go down if this Script Filter trick catches on.
 
Neither workflow developers nor users will show any restraint in building or installing such workflows because the former always think their own programs are special cases, and the latter tend not to think about such things at all.
 
I doubt we'll see official support going very far in this direction because it doesn't pass the "no footguns" test.

The "Calculate Anything" workflow does this. Ingenious and brilliant, isn't it! Blew my mind when I saw it!
https://github.com/biati-digital/alfred-calculate-anything

Alfred History Search

An Alfred workflow to search through query history, and execute queries from history.
Note: This post might be out-of-date.
Here's the up-to-date README.
 
Usage

Download the latest release

Searching Through Query History

Assign hotkey trigger (⌃R recommended) While using Alfred, press the hotkey. Alfred's query history will show up:
Start typing to search through the query history.
Actioning any of the history entries makes Alfred search that query.




Deleting Query History

Type .clear-afred-query-history in Alfred.

Icon Credits

Icon created by combining icons form flaticon made by Freepik and Pixel Perfect

@40-02 @deanishe @vitor
Here you go:
It's rough around the edges, but better than nothing

Alfred GIF Search
Download: Gif.Search.alfredworkflow
Up-to-date README (this post is outdated)

This workflow lets you search GIFs on Tenor from Alfred.

Here's an example of searching and inserting a GIF in a google doc:


Installation
Download the latest release. In Alfred, run .setup-gif-search.
Usage
In Alfred, enter gif keyword followed by search query. Press ↩. Use arrow keys or mouse to browse the GIFs. To copy the selected GIF to clipboard: either ⌘↩ or ⌘-click To drop the GIF into apps that support it: drag from Alfred and drop into that app
Note

Firefox and Chrome don't support pasting GIFs from clipboard. That is, if you copy a GIF to clipboard and paste it, it shows up as a static image, not an animated GIF. This is not a bug in this workflow, but rather just the way these browsers have decided to handle GIFs.

Both Chrome and Firefox support drag-n-drop. If you use either of these browsers, sorry, you gotta use the mouse!

Alfred History Search

An Alfred workflow to search through query history, and execute queries from history.
Note: This post might be out-of-date.
Here's the up-to-date README.
 
Usage

Download the latest release

Searching Through Query History

Assign hotkey trigger (⌃R recommended) While using Alfred, press the hotkey. Alfred's query history will show up:
Start typing to search through the query history.
Actioning any of the history entries makes Alfred search that query.




Deleting Query History

Type .clear-afred-query-history in Alfred.

Icon Credits

Icon created by combining icons form flaticon made by Freepik and Pixel Perfect

Alfred GIF Search
Download: Gif.Search.alfredworkflow
Up-to-date README (this post is outdated)

This workflow lets you search GIFs on Tenor from Alfred.

Here's an example of searching and inserting a GIF in a google doc:


Installation
Download the latest release. In Alfred, run .setup-gif-search.
Usage
In Alfred, enter gif keyword followed by search query. Press ↩. Use arrow keys or mouse to browse the GIFs. To copy the selected GIF to clipboard: either ⌘↩ or ⌘-click To drop the GIF into apps that support it: drag from Alfred and drop into that app
Note

Firefox and Chrome don't support pasting GIFs from clipboard. That is, if you copy a GIF to clipboard and paste it, it shows up as a static image, not an animated GIF. This is not a bug in this workflow, but rather just the way these browsers have decided to handle GIFs.

Both Chrome and Firefox support drag-n-drop. If you use either of these browsers, sorry, you gotta use the mouse!

FAstest eMOji Search (FAMOS)
 
Instant search for emojis in Alfred with related keywords in 25 languages and Google Emoji Kitchen integration
 
This post is outdated, link to up-to-date README
Download the latest versions: github release

FAMOS speaks many languages!


FAMOS uses emojibase, which is an excellent library, meticulously curated. So, all the languages that emojibase supports, FAMOS automatically does too.

FAMOS is the fastest!

10x to 20x faster compared to alfred-emoji and EmojiTaco!

FAMOS launches in under 20 miliseconds (imperceptible), while both the other workflows take hundreds of milliseconds to launch (very much perceptible).

The reason FAMOS exists is that I wanted my emoji picker to:
 - launch instantly
 - search with zero lag
 - let me pick skin-tones for each individual emoji

Skin-tone prefs for each individual emoji

I like my emojis to reflect my skin-tone correctly. And also hair color! That means, I might not always get both. So, I want hand-emojis to have my skin-tone, but face-emojis to have my hair-color even if that means wrong skin-tone. In addition, if you're a stickler like me, you will understand that I want one skin-tone for the palm and a different one for the back of the hand. Back of the hand is a shade darker than the palm, isn't it!
Search results show if an emoji has multiple tones available:
Hold command:

After pressing command+enter:

From now on, the chosen tone becomes the default tone for this emoji:


Feature comparison

Both alfred-emoji and EmojiTaco are excellent workflows, and they have tonnes of features that FAMOS lacks, and has no plans of implementing. You should definitely check them out!
 
 

 

Downloads
Chinese, Traditional apple  joypixels
Chinese apple  joypixels
Danish apple  joypixels
Dutch apple  joypixels
English, Great Britain apple  joypixels
English apple  joypixels
Estonian apple  joypixels
Finnish apple  joypixels
French apple  joypixels
German apple  joypixels
Hungarian apple  joypixels
Italian apple  joypixels
Japanese apple  joypixels
Korean apple  joypixels
Lithuanian apple  joypixels
Malay apple  joypixels
Norwegian apple  joypixels
Polish apple  joypixels
Portuguese apple  joypixels
Russian apple  joypixels
Spanish, Mexico apple  joypixels
Spanish apple  joypixels
Swedish apple  joypixels
Thai apple  joypixels
Ukrainian apple  joypixels
 

Took me a minute to figure out what you'd done there. That's another very clever solution.
 
 
OTOH, it also kinda is.
 
It'd be a terrible idea to convert all your workflows to run like this. But one workflow adding max. 3 results is just pure clever, imo.
 
 
No luck fiddling with the "Run Behaviour" settings?
 

@deanishe is right in pointing this out. Rather, I would even go ahead and make a guess that Alfred's not designed to be used this way.
 
However, in the spirit of tinkering, if we're okay with ugly, unwieldy hacks to just see what's possible, what you're asking @lukerooneyio, can be done.
Edit: learnt this cool trick from: https://github.com/biati-digital/alfred-calculate-anything
 
Be warned:
It is ugly
It is possible that it has performance issues
It leads to inconsistency
 
That out of the way, here's how one could go about achieving the end result of "google search suggestions in Alfred without explicitly typing a keyword".
 
Oh wait, let me clarify: we will be using keywords all right, just that, from the user's point of view, it appears as if there are no keywords involved.
 
Here, I searched for "screen", and you can see three google auto-suggestions: "screen recorder", "screener", "screenshot"

Apart from messy implementation, the two biggest issues I see with this hack are:
Predictability: Alfred's default fallback searches always appear at the very bottom. This one, on the other hand, could appear anywhere (right at the top, somewhere in the middle like this screenshot, or not at all if Alfred thinks that there are other much better matching results) Consistency: In Alfred's default search, I expect results to show instantly, and I don't expect them to change once they display on screen. Here, the google suggestions take time to show up and finalize. See the GIF: Before it finalizes on "sketches, sketchup ...", the results briefly read "speed test, sports ..."  
I believe now we're truly done with disclaimers and "why this might not be a good idea", here's the implementation, where I added 26 extra script filters to @deanishe excellent searchio workflow: (one script filter for each small-case letter)

 
This is how the default google search script filter in searchio ran:
# keyword google # with space # argument required ./search google-en "$1"  
This is how each of the script filters I added runs:
# keyword s # without space # argument required # choose only top 3 results # note the "s$1" res=$(./search google-en "s$1" | /usr/local/bin/jq '.items[:3]') echo "{\"items\": $res}"  

@chris
I've put together a small tutorial for workflow authors here:
https://github.com/mr-pennyworth/alfred-extra-pane#tutorial
 
And a few question-answer pairs for technical internals here:
https://github.com/mr-pennyworth/alfred-extra-pane#technical-qa
 
I see a few problems with swiftUI:
I would imagine there are far more workflow authors who can put together nice looking HTML than swiftUI, all the complexities of the implementation of the extra pane aside, as far as the workflow authors are concerned, I want the integration to be as simple and friction-less as possible. HTML seemed like the best choice for that. I'm not sure how code for compiled language will actually work for the previews. Let's say instead of putting an html file in "quicklookurl", we ask the workflow authors to put a swift file instead. Who compiles the code? Can swift code be even compiled on-the-fly by an app and rendered too? I haven't a clue!

Thanks @chris! When you want a panel to be shown at side, and some HTML to be show inside it, yep, you can use the AlfredExtraPane.app. All you got to do is add an html filepath to quicklookurl of the JSON and then pipe it to the app (the readme has an example).

For building something like this GIF workflow, it is true that AlfredExtraPane.app was an inspiration, but it can't just directly be used to build the GIF workflow, it isn't flexible enough. For this GIF workflow, I simply took the code of AlfredExtraPane.app and modified it to fit the GIF needs, thus programming in swift was involved and understanding how AlfredExtraPane.app works internally was a prerequisite.

Alfred GIF Search
Download: Gif.Search.alfredworkflow
Up-to-date README (this post is outdated)

This workflow lets you search GIFs on Tenor from Alfred.

Here's an example of searching and inserting a GIF in a google doc:


Installation
Download the latest release. In Alfred, run .setup-gif-search.
Usage
In Alfred, enter gif keyword followed by search query. Press ↩. Use arrow keys or mouse to browse the GIFs. To copy the selected GIF to clipboard: either ⌘↩ or ⌘-click To drop the GIF into apps that support it: drag from Alfred and drop into that app
Note

Firefox and Chrome don't support pasting GIFs from clipboard. That is, if you copy a GIF to clipboard and paste it, it shows up as a static image, not an animated GIF. This is not a bug in this workflow, but rather just the way these browsers have decided to handle GIFs.

Both Chrome and Firefox support drag-n-drop. If you use either of these browsers, sorry, you gotta use the mouse!