Jump to content

Jasondm007

Member
  • Posts

    342
  • Joined

  • Last visited

  • Days Won

    11

Jasondm007 last won the day on February 14 2023

Jasondm007 had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Jasondm007's Achievements

Advanced Member

Advanced Member (5/5)

52

Reputation

  1. Hi @V2arK - Thanks a ton for sharing your Warp workflow! I really appreciate it. The workflow is great, and I'm looking forward to using it more!! If you update it down the road, one minor recommendation: It'd be great if the workflow would create the hidden directory for users that don't already have it. When I first tried to use the workflow, I couldn't get it to work for that reason. Apparently, Warp doesn't create the directory unless the user has already created a launch config file in the past. It was easy enough to fix (e.g., I just created a temp one through the file menu). But others may run into this problem if they haven't already created launch config files, too. Thanks again for sharing the workflow!!
  2. Hi @xilopaint - Did you ever have any luck with the new Warp URI? It looks like it's only for opening new tabs and windows to specific file locations, but I might be missing something. Like yourself, I'd love to be able to run commands in new Warp windows/tabs via Alfred (i.e., without relying on some clunky GUI-based approach). Thanks for your help!
  3. @vitor Any chances that multiple keyword support will get added for snippet-based workflow triggers? Thanks!
  4. I’d love to see an option added to Alfred that would make snippets visible in the clipboard history after they’ve been applied - and listed, in sequential order, with everything else on the clipboard. At the moment, when you use Alfred’s snippet viewer to paste a snippet into an application, Alfred adds the snippet to your clipboard. For instance, if you just hit ⌘V, you can paste it again elsewhere. If you open Alfred’s clipboard history, however, you’d never know it. Why not give users the option to show the snippets they’ve applied in their clipboard history (and, as they copy and paste other things, just move it down the history like everything else)? This would be a ton easier than forcing users to navigate back through the snippet viewer, just to apply a snippet they recently used. When applying different snippets, from different collections, it's easy to see how this feature could save people a ton of time. As far as I can tell, the only way to get around this limitation, at the moment, is to create a universal action. More specifically, the universal action is set to do a simple copy and paste from the clipboard. So, once the user has found the snippet they want to apply in the snippet viewer, they would have to (1) action the snippet from the viewer, and then (2) navigate to their new “copy and paste” universal action. Obviously, this would do the trick, as it’d get the snippet onto the (visible) clipboard history … but this is cumbersome as hell. It not only requires more clicking around, but it also necessities the foresight to anticipate when you might need to apply a snippet again, in short order, and should therefore use the new "copy and paste" universal action. While I can certainly appreciate why people may want to keep their snippet history out of Alfred’s clipboard history, the opposite has always struck me as equally plausible. There are a bunch of ways this could be implemented, but I prefer the following two options: Global Approach: In the clipboard history section dealing with snippets (Features > Clipboard History > Snippets), add a 3rd option: “Show applied Snippets in Clipboard History”. Given that Alfred already has two different options to help people integrate snippets into their clipboard history—or to, at least, provide easy access to them—this feature request doesn't seem too far astray. Snippet-specific Approach: Within each snippet, add a new option (similar to the “Auto expansion allowed” option) that users can check: “Copy to clipboard on paste”. Or, you could also just add two new options in the “Type” drop down, such as: “Plain Text Snippet - Match destination formatting on copy and paste” and “Rich Text Snippet - Retain formatting on copy and paste where possible”. My preference is for the Global Approach—or some variation of the two approaches where users could opt-in/out to everything, globally, and then opt-out/in on a per-snippet basis. But I’m open to anything!! And, just to be clear, I understand this is easier said than done … and that there would be some obvious limitations (like the fact that snippets applied from the clipboard history would no longer be dynamic, if they were previously) … but this is a wish list, right? This has been driving me crazy for years!
  5. Sorry for the slow response, @vitor. Thanks for updating the workflow! This is awesome!! Unfortunately, I received the following error when trying to generate a dictionary for DEVONthink: Am I correct that this new action in the workflow requires Xcode to be installed? I uninstalled Xcode a long time ago from my machine. But I guess I could always add it back again to get this part of the workflow up and running. Thanks again for all of your help!
  6. Hi @vitor - This week, I ran several searches on my computer to try and track down DEVONthink's sdef file (e.g., sudo find / -name *.sdef -print 2>/dev/null). However, I was never able to locate it (i.e., beyond the temp one mentioned above). DEVONthink's development also confirmed the lack of an sdef file yesterday. They indicated that it relies on an older suite of files that are internal to the package: /Applications/DEVONthink 3.app/Contents/Resources/DEVONthink 3.scriptSuite /Applications/DEVONthink 3.app/Contents/Resources/DEVONthink 3.scriptTerminology By chance, is it possible for your workflow to use these files? I suspect that I know the answer, but I thought I'd ask. Thanks!
  7. Thanks for taking a look at it, @vitor!! I'll reach out to their developers to see where it's being stored.
  8. @vitor I'm not sure if it's relevant, but DEVONthink's SDEF file doesn't appear to be located in the usual place as most applications (i.e., it's not located in the app's Contents/Resources/ folder). See screenshot below. Path: /var/folders/l1/_hr3npwn4nz5m9j85w9_6g4c0000gn/T/DEVONthink 3.sdef I don't understand enough about how this works, but when you close the window above (for the DEVONthink library) the sdef file also automatically deletes itself from that location. It's odd. To see if it changed locations, I removed DEVONthink's library from Script Editor, and then added the app back ... and its SDEF always appeared at this location (i.e., when open - otherwise it magically disappears from that location).
  9. @vitor Yeah, I've run that several times (re:forced update). But it never seems to find DEVONthink. The app's installed in my applications folder: /Applications/DEVONthink 3.app
  10. Hi @vitor - This is an awesome workflow! Thanks for sharing!! I have a couple of apps whose AppleScript dictionaries work perfectly fine (and are visible in the Script Editor's Library pane) but aren't visible in the workflow's output. Do you have any suggestions for troubleshooting these apps? For example, one dictionary that I use quite a bit, which won't load correctly, is DEVONthink 3. The other apps are all really minor; DEVONthink 3 is, really, the only important one. Thanks for any help you can lend, and for the great workflow!
  11. Sure thing, @s95hc8! While there's a lot in your post, it sounds like you just need to configure your fallback searches. To learn how to do this, check out the following link: https://www.alfredapp.com/help/features/default-results/fallback-searches/ You'll find the "Fallbacks" section down at the very bottom of Alfred's "Default Results" panel (in Alfred Preferences). In short, I think you should (1) Set Alfred to "Intelligently show fallbacks at the end of results", (2) Click the "Setup fallback results" button, and then (2.A) Remove the default fallback searches you don't use, and (2.B) Add the fallback Finder search that I sent you above (if you click the plus sign, and you've installed it correctly in your workflows, you should see it under the "Workflow Trigger" dropdown menu.) Hope this helps!
  12. When determining whether an update is available for a workflow in the gallery, from what I can tell, Alfred is only using the bundle id (under today's release candidate for 5.0.6). So, in situations where a user might unknowingly have the same bundle id as one in the gallery, Alfred may errantly tell them an update is available ... when, in fact, it's not actually the same workflow. I have no idea how common this is, but I ran into the problem with com.alfredapp.1password Is there any additional info Alfred can use to identify whether they're actually the same workflow (e.g., "Created By", "Website", etc.)? Users can always just rename their own workflows' bundle IDs, but this is obviously a little annoying. Thanks! PS - Glad to see Alfred now has its own gallery! Congrats @Andrew!! This is great!
×
×
  • Create New...