Jump to content

[WIP, POC] Spotlight like rich preview pane for alfred workflows

Recommended Posts

Link to better quality videos

Download the code and play around: https://github.com/mr-pennyworth/alfred-extra-pane



Q: What is it?

A: An app that workflow creators can add to their script filters


Q: What does it do?

A: It renders html from quicklookurl of every item in the json.


Q: How does it do it?

A: By intercepting the json and by monitoring up-arrow and down-arrow keypresses.


Q: How to add it to a workflow?

A: By adding it to the script filter. Here's an example (from the workflow in the above GIF): notice how everything remains the same, just that at the very end, json needs to be piped through the helper app

# Before:
items=$(curl '' --data "{ \"q\": \"$query\" }" | jq '.hits')
echo "{ \"items\": $items }"

# After:
items=$(curl '' --data "{ \"q\": \"$query\" }" | jq '.hits')
echo "{ \"items\": $items }" | 'AlfredExtraPane.app/Contents/Resources/scripts/alfred-extra-pane'


Q: Sounds great! Now tell me everything that's not working!

A: This is more of a proof-of-concept and very rough around the edges.

  • Things that are easily doable, but haven't been done yet (contributions welcome! :) )
    • change appearance automatically based on alfred's themeauto-theme.png
    • make other things configurable like dimensions
  • Things that seem doable, but quite difficult with my knowledge of macOS GUI programming (which is about a week)
    • let alfred remain horizontally-centered when the pane is not present, and when the pane appears, make the "alfred+pane" combination horizontally-centered (by moving both the pane and alfred window to left)
  • Things that seem doable, but require guessing about alfred's inner workings:
    • as @deanishe points out, alfred builds "uid-based-knowledge". that means if the returned json has an uid field, alfed can use that later to re-order items while displaying based on whether of them were previously actioned on. the knowledge is an sqlite database, so that's the easy part. the not-trivial part is to figure out how alfred sorts the items.
      • Workaround: if you want to use this tool in your workflow, don't add UIDs to your json. One perfect use case for this is the dictionary workflow in the GIF. You looking up a word in the dictionary is a very weak signal that the word is important (many times, it is actually a signal that it is now less likely that the word will be looked up)
      •   This is a GUESS based on LIMITED observation.
          sorting is based on
          1) how many times an item has been actioned (freq)
          2) latest timestamp of action               (timestamp)
          primarily sorted based on freq, ties are broken by timestamp
          special case:
          if the script filter has executed without an argument,
          and one of the resultant items has an entry in the latching table,
          the item goes to the top, irrespective of the above sorting.

        The above algorithm has been implemented and seems to match alfred's sorting.

  • Things that seem impossible to me:
    • take into account mouse scroll interactions. right now, when selected row changes because of a mouse hover, the pane doesn't update, and will continue to show the old preview. As mouse hovers over various rows, the pane updates correctly, as long as Alfred's results have not been scrolled using mouse.



Edited by Mr Pennyworth
Link to post
6 hours ago, Mr Pennyworth said:

Things that seem impossible to me

This is a really interesting idea, but I think there’s a fundamental flaw: Alfred doesn’t always show results in the order they are in the JSON file.


If items have UIDs, Alfred will apply its “knowledge” and sort the results based on previous user behaviour.


If I understand the way your app works correctly, that means your previews will often be out of sync with the results if UIDs are used.

Link to post

@deanishe @Andrew I totally get the idea that an HTML preview-pane isn't widely useful, and probably doesn't even fit into Alfred's core design philosophy. However, I think some workflows' UX could benefit considerably if they had such an option available.


This POC could suddenly become so much more polished and robust if there was a Distributed Notification for "result selected/highlighted" that external processes could subscribe to. The data for that notification would contain entire json for the highlighted result. Then, instead of manually tracking keypresses and mouse-movements like the tool does now, it could simply subscribe to such a notification. It would also remove the need to crudely guess how alfred's "knowledge" works.


I know it's quite unlikely that such a thing will be implemented, as I can already see so many reasons not to. I just wanted to pick your brain about what your reasoning would be...

  1. Performance: posting distributed notifications slows stuff down.
  2. Feature/code bloat: not worth adding to Alfred's codebase something that'll only be used by some obscure tool.
  3. Non-trivial implementation: would need time/refactoring disproportionate to usefulness.
  4. Undesirable extension: don't want to expose weird APIs.
  5. Priority: proposal sounds good, but there are just way too many things with greater priority that it'll be a very long time to come to this.
  6. Undesirable functionality: want to discourage such "alfred companion tools".

If I were the developer, my reason to not implement would've been some combination of the above. How about you?

Edited by Mr Pennyworth
Link to post
4 minutes ago, Mr Pennyworth said:

an HTML preview-pane isn't widely useful


It's a feature I'd very much like to see, tbh.


I don't think the distributed notifications are likely, for the reasons you give.

Link to post
2 minutes ago, deanishe said:

I don't think the distributed notifications are likely, for the reasons you give.

Yep. I tried to make that list exhaustive.
What I'm curious to know is which among the above are @Andrew's reasons.
(must admit I'm clinging onto the teeeny tiny hope that he replies "no reason not to... watch out for it in some future release". but short of that, it's just a good thing to know the "why" :) )

Link to post

Hey! I forgot to chime in when I saw this originally - very impressive! Richer content natively within Alfred is something which has always been on the plan for the future, but this really does provide a solid stepping stone.


It wouldn't be a huge amount of effort to post a distributed notification for the quicklookurl, but due to a whole host of reasons (of which you outline some above), I wouldn't make Alfred post this by default.


Having said that, for fun, I wouldn't be adverse to make it a defaults write on Alfred's prefs just to see this working better, and see where you take it :)




Link to post
8 minutes ago, Andrew said:

Native richer content natively within Alfred is something which has always been on the plan for the future

Yayy! Awesome to hear that!!


9 minutes ago, Andrew said:

Having said that, for fun, I wouldn't be adverse to make it a defaults write on Alfred's prefs just to see this working better

🎉🥳 you're the best!
Keeping my fingers crossed! 🤞🏼

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...