Mr Pennyworth

Hi @Andrew, I forgot to ask this last time! How do I find out when this lands in Alfred? Right now, after each pre-release build update, I run the following two commands and see if there's anything of interest there: defaults read com.runningwithcrayons.Alfred defaults read com.runningwithcrayons.Alfred-Preferences Is that the correct way of checking?

@runningwithscissors: Here's a modified one where in addition to the original workflow, it also changes any double spaces to a single space. http://www.mediafire.com/file/oze6vq4pucs7qnq/Paste_without_newlines.alfredworkflow/file

@flome Seems like BigSur has some weird issues: https://developer.apple.com/forums/thread/665661 Try this command in terminal: launchctl load -wF ~/Library/LaunchAgents/alfred-clipboard-history-ocr.plist (It is a one-time thing)

This is great! Thanks!

@dood yep, it'll definitely be helpful! In addition to the in-Alfred debug log, also useful would be the debug logs for 'AlfredGifBrowser'. Here's how to collect it: Run `killall AlfredGifBrowser` in terminal Open the workflow folder in terminal Run `AlfredGifBrowser.app/.Contents/MacOS/AlfredGifBrowser` (this will make the logs appear right in the terminal) Run the workflow v0.0.3 and press the arrow keys so that it crashes

@evanfuchs Interesting... Given that the GUI import isn't working anyway and you had to import using the command line, here's something you can try: Look at the command you used for importing the oxford dictionary. In that command, after the word 'import', you had to provide the path to the '.dictionary' file, right? Run the same command, but this time, change that path to the appropriate path from '/Users/xxx/Library'... Also if you could tell me what such a path looks like, I can add it to the workflow so that the dictionaries in this library folder are also detected by the workflow.

It only lists dictionaries that are installed/available on your system. They are in /System/Library/AssetsV2/com_apple_MobileAsset_DictionaryServices_dictionaryOSX/ And not all of them are importable. To get a list of all the importable ones, run these in terminal: cd '/System/Library/AssetsV2/com_apple_MobileAsset_DictionaryServices_dictionaryOSX/' python -c 'import glob; print("\n".join(glob.glob("*.asset/AssetData/*.dictionary")))' If the above shows multiple dictionaries, but still not the .dict-import command in Alfred, I believe it might still be because of the bug I mentioned earlier. In that case, I'm afraid you'll have to import them manually just like you imported this oxford one. OTOH, if the dictionaries aren't present at all on your system, you can download/enable them by opening Dictionary.app, and then going to preferences.

Ah! the theming looks unfortunate While I figure out how best to fix it, here are your two options: Change Alfred's theme to one where color of Alfred's window is different from color of the text in search bar (right now, in your theme, both of those colors are white) If you don't want to change the these, alternatively: open this file '/Users/<username>/Library/Application Support/Alfred/Workflow Data/mr.pennyworth.betterDicts/<dict-ID>/html/dict-entry.css' (by using appropriate <username> and <dict-ID>) At the top, you'll find some code like this: :root { --secondary-label: var(--result-subtext-color, #eee); --text: var(--search-text-color, #eee); --link: var(--result-text-colorSelected, var(--link)); } html { background-color: var(--window-color, #1d1e28); color: var(--search-text-color, #eee); } in the html part, change the background-color from --window-color to --search-background After that, run killall AlfredExtraPane in terminal (so that the viewer would be restarted and would pick up changes we made)

Can you share the command you ran before (the one with tmp) and the command you ran now? Just want to make sure that the tmp part is the only thing that changed and nothing else got unintentionally changed... From the output, it appears that something else also changed apart from tmp...

@evanfuchs aw man that's the worst. A bug that goes away when run from terminal. That's a known bug with no solution yet https://github.com/pyinstaller/pyinstaller/issues/5109 But in my trials that bug wasn't getting triggered. I have tested this workflow only on Catalina by the way. Are you on Catalina or some other version? While I think about how I could go about debugging / diagnosing this, you could manually import a dictionary. By running the same command as above, but using '/Users/<your username here>/Library/Application Support/Alfred/Workflow Data/mr.pennyworth.betterDicts' instead of /tmp/. That's hoping that even though the bug affects the import, maybe it won't affect the lookup 🤞🏼

@evanfuchs could you try the following? Open the workflow folder in terminal and run ./BetterDict.app/Contents/MacOS/BetterDict listUnimported /tmp/ The output will contain path to the macOS dictionary file for the Oxford Dictionary. Let's say it is /a/b/c Then, run this command: killall alfred-dict-server; killall BetterDict; ./BetterDict.app/Contents/MacOS/BetterDict import '/a/b/c' /tmp/ The above command is basically for importing and extracting the dictionary into the temporary folder instead of the workflow data dir. We want to run BetterDict from terminal because we want to see why the "BetterDict error" appeared. (unlike the GUI version, this time, you'll get the error logs in terminal)

@chriswebb Can you click on "Open in Terminal" (as shown in your screenshot) and then try each of these commands and tell me the outputs? xattr -d com.apple.quarantine ./BetterDict.app xattr -d com.apple.quarantine ./BetterDict.app/Contents/MacOS/BetterDict ls -alh ./BetterDict.app/Contents/MacOS/BetterDict chmod +x ./BetterDict.app/Contents/MacOS/BetterDict After running them all, also check if the workflow starts working, and if not, lemme know what the log looks like

@dood whoa! that sounds like such an ordeal and so much trouble I wish I could help, but I'm not able to replicate the issue Here's what I did: Downloaded and ran v0.0.3, worked as expected Created another user account on my macbook (so alfred gets to have a clean slate), then repeated (1), again worked as expected Installed Alfred on a spare macbook I have, then repeated (1), couldn't trigger the bug At this point, I don't have much to go on... Are you on macOS other than Catalina? I have no means of testing on versions other than Catalina Does AfredGifBrowser.app have the required accessibility permissions? Does deleting it from accessibility permissions and adding again help?

@chriswebb is the workflow enabled? Can you share a screenshot of the workflow editor? Also, the debug logs...

@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! 🍻

Hey @chris, I'm not saying you've formed such an impression, but in case that you have, I want to clarify, if my understanding of how Alfred works is correct, that number of script filters in itself shouldn't be a performance concern. The calculator workflow needs to deal with numbers, so it has 10 script filters. This one needs to deal with all strings, so it has more than 40. That no way makes it 4 times worse. Imagine, instead of 40, I had added one script filter each for all the letters in extended ascii, or, for that matter, all the unicode code points that I want (that would mean hundreds, even thousand script filters). The important point is, all these filters are mutually exclusive. At any time, at most one of them is active. So, 40 or 400 or 4000 filters, performance implications are almost same (except for how much RAM alfred uses) as long as they remain super cheap in terms of individual filter performance (which is the case here), and as long as they don't overlap (which, again, is the case here). @Andrew, I'm curious... Am I totally off the mark here? Or it makes sense but not entirely? Or it makes a lot of sense?

OMG!! dayum! my bad at creating that impression! I so didn't come up with it independently! Learnt from that workflow and all credit belongs to them. I had mentioned it here but should've mentioned in our discussion the other day too! (which I just edited to reflect the origin of the idea)

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

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

@swiggy if you want to search through previous queries, you can use this workflow:

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

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

oh wow!! Just switched from "wait until previous script finishes" to "terminate previous scripts" So much snappier and much less flickering! No idea why I had set that setting in the first place 🤦🏻‍♂️

@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!