Jump to content


  • Posts

  • Joined

  • Last visited

Contact Methods

  • Twitter
  • Website URL

Recent Profile Visitors

706 profile views

theSquashSH's Achievements

Helping Hand

Helping Hand (3/5)



  1. @Andrew sorry for the tremendously late reply. I can confirm the issue is still happening in the latest version (Alfred 4.3.4 on macOS 11.2.3). Several Alfred features that require simulating key commands don't work, including "Show Large Type" and some of my workflows. I just tested the Lock command in Alfred and it didn't work either, so something seems to be preventing it from simulating key events in general. I have all permissions checked for Alfred under System Preferences > Security > *, so I don't think it's that. Any ideas? (and the others ^, e.g. Files and Folders, Automation, etc. are all checked as well) Thanks for the help!
  2. I'm still experiencing this issue today on macOS 10.15.7 (19H15), with Alfred 4.3 Build 1205 (Monday 14th December 2020). I have no language inputs enabled on my system other than English (QWERTY), so I don't think it's an issue specific to users with Pinyin input enabled. My workflow to reproduce the issue is in the screenshot below (inside the Large Type action is just `{query}`). It never triggers however because query is always empty. If I change it to `{query} abcd` it triggers but shows only `abcd` in large type, confirming that the key command is working fine, it's just the pass "Selection in macOS" that's failing to grab text from the active application. I've already tried removing all of Alfred's permissions in System Preferences and re-enabling, as well as restarting Alfred and the computer altogether. Nothing seems to fix it, "Selection in macOS" is always empty regardless of which foreground app I try triggering the workflow from.
  3. I think you can solve that by issuing an exclusive lock on the db while modifying it: PRAGMA locking_mode = EXCLUSIVE; BEGIN EXCLUSIVE; I plan on adding that to my alfred-clipboard.sh script in the future when I implement timstamp rewriting to make the history infinite: BTW if anyone is looking for a full script example that can clone, read, merge, etc otherwise poke into the Alfred clipboard db, you can find the source for my implementation here: https://gist.github.com/pirate/6551e1c00a7c4b0c607762930e22804c
  4. I made a Workflow out of it, unfortunately the ergonomics are really bad because Alfred doesn't expose the clipboard-style preview pane UI to Workflows. With script filter output you can only display short snippets in the list. Without the longer preview, it's really hard to tell which matches are correct and I found it next to useless. Thanks for that tip about the timestamps! I completely forgot about the Mac epoch having a different start date. I think the best long-term solution right now is to rewrite the Alfred sqlite db in place periodically to bump all the timestamps so that nothing ever expires. It's a hack, but lets me keep using the nice preview pane UI and the native Alfred search instead of a script filter workflow. The workflow can be found here: https://github.com/pirate/experiments/blob/master/Infinite Clipboard History.alfredworkflow (you'll need the script above to use it)
  5. +1 I'd be willing to pay >another $30 on top of my existing Legendary license for unlimited clipboard history, and I'd fully accept any CPU/Memory hit necessary to get it. I use Clipboard History as a general buffer for everything in my life, and losing everything beyond 3 months is a frequent source of headache. Here's a small sample of a few recent things I've lost due to history expiring: flight confirmation details commit summaries with commit ids (detached commits that are hard to find due to deleted branches) important UUIDs ssh public keys many many many file paths (lots of obscure config file paths that I never bother to remember) entire config files blog post drafts comments on social media form fields on websites It's always stuff that I don't realize at the time would be important later so it would be pointless to try and use snippets for most of these. Having a massive index of every meaningful string that's passed through my brain is incredibly useful. If needed you could hide "6 months" "12 months" and "unlimited" behind an "Advanced settings" pane and display a big warning about potential performance downsides. For now I just periodically back up `~/Library/Application\ Support/Alfred/Databases/clipboard.alfdb` to a separate folder, and merge the rows in it with a main database. This at least allows me to query further back by querying the merged database directly. Maybe I'll build a workflow to do that if I have time, but no promises. I've created a script that handles the backup of the db, merging it with an infinite-history sqlite db in my home folder, and searching functionality. /* Delete any items that are the same in both databases */ DELETE FROM merged_db.clipboard WHERE EXISTS( SELECT 1 FROM latest_db.clipboard latest WHERE $UNIQUE_FILTER ); /* Insert all items from the latest_db backup */ INSERT INTO merged_db.clipboard SELECT * FROM latest_db.clipboard; Full source: alfred-clipboard.sh (it's a fully functional infinite-history solution for Alfred, with backup, search, exporting, etc.) One thing I want to try is periodically overwriting the Alfred internal db with my merged one, and translating all the older timestamps so that they're artificially set to something within the last 3 months, that way I can accumulate infinite history without Alfred attempting to expire anything. In theory it should work fine, I'll probably update my script to do that sometime in the next week. One thing I cant figure out though is the format of the timestamps (e.g. `584601195`), they're not valid UNIX timestamps, they must be offsets in seconds from some custom hardcoded date. When I tried prepending `1` to make it something like `1584601195`, it becomes a valid unix timestamp, but the time is ~4 months in the future! If anyone has more info on the schema, let me know. I also tried hacking around the limit by changing the Alfred binary directly but unfortunately I was only able to find the limit in the .nib file (which is useless as it's just the GUI definition). I'd have to properly decompile Alfred it to find the actual limit logic... $ ggrep --byte-offset --only-matching --text '3 Months' \ '/Applications/Alfred 3.app/Contents/Frameworks/Alfred Framework.framework/Versions/A/Resources/AlfredFeatureClipboard.nib' 12590:3 Months (Now I just have to convince the Google Chrome team to also allow storing browser history longer than 3 months... then the two biggest sources of data-loss pain in my life will be eliminated).
  6. Please add this! The "open alfred" action in remote pops up alfred on my computer, great! now I can type in commands just like I could on my computer... but wait! not so fast, theres no keyboard! It would be so easy to add an option to send keystrokes, that way I can trigger my existing workflows and do anything on my system just like normal alfred. I love having these buttons for convenient commands, so I only tap once to do things, but we should have them in ADDITION to normal alfred behavior, not instead of it. Thanks!
  7. This is a limit imposed by UNIX, not Alfred, but the error message shown is slightly confusing, and there should be a way to overcome this issue. Right now, selecting more than exactly 260527 characters on my system and using it in an Alfred workflow (with the Argument:'selection in OS X' setting) as "{query}" will throw an error. You can see your system's bash argument character limit with: getconf ARG_MAX Alfred should allow a way to pass the selection as stdin instead of a quoted and escaped string, otherwise there is no way around this hard limit, and Line-Counting workflows, etc. are useless for larger bodies of text. ^ Confusing error message when selecting too much text. ^ A workflow example that would trigger this. echo "{query}" > .wordcount echo "Characters: "$(wc -m < .wordcount)" Words: "$(wc -w < .wordcount)" Lines: "$(wc -l < .wordcount) rm .wordcount
  8. Found a way to do it! Automator's built-in "Website Pop-Up" feature can render html and js even: http://macosxautomation.com/lion/websitepopup/index.html
  9. For anyone who's found this on google, I've managed to hack together a HUD style workflow where the user selects text in OSX, presses a key command, and then an html popup is generated. I used automator's built-in workflow "Website Pop-Up" http://macosxautomation.com/lion/websitepopup/index.html
  10. I already have them and use them frequently, what I use Alfred's Large Type for is specifically highlighting one small segment of code and making it huge, as well as readable.
  11. As a coder I often use Alfred's wonderful large type key command to quickly display snippets of code to colleagues without all the other distractions on my screen. If alfred provided built-in syntax it would make this much nicer. If built-in is too heavy, I'd be happy to do the syntax highlighting myself, but alfred still needs to provide a method of colorizing Large Type output through a workflow. ASCII escape sequences are one option, but I'm sure our friends at HQ can think of a better solution.
  • Create New...