Jasondm007

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

Thanks! @xilopaint

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!

No problem, @Andrew. Thanks for the update!!

@vitor Any chances that multiple keyword support will get added for snippet-based workflow triggers? Thanks!

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!

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!

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!

3 hours ago, vitor said:

Indeed that will be the cause. I’ve poked a bit around the app but didn’t find it either. If you’re able to contact them and get how they’re storing it, I may be able to add support for it in the workflow (using that folder won’t work, because it’s not a fixed path for all users).

Thanks for taking a look at it, @vitor!! I'll reach out to their developers to see where it's being stored.

@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).

@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

 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!

+1

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!

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!

4 hours ago, Vero said:

If it happens in a repeatable way, could you try identifying whether anything in particular happens on your Mac prior to bookmarks becoming inaccessible?

Sure thing, @Vero! Thus far it's been incredibly sporadic. For instance, it'll happen twice in a day, and then it won't occur for a couple of weeks. It's really quite odd. As result, I have't been able to tie it to any particular Alfred or System related activities yet. But I'll let you know if it starts occurring more frequently or if I get a better sense of what's triggering the behavior. Luckily, as I mentioned previously, just restarting Alfred has always fixed it immediately ... so it hasn't been that big of a deal. Thanks again!

On 11/12/2022 at 5:15 AM, Vero said:

@Jasondm007 The outcome of @dwdblogger 's issue was that his Google Chrome profile's bookmarks file was corrupted. He fixed the corruption and the bookmarks became searchable again.

 

Might give you some hints as to what's happening on your Mac as well.

Thanks @Vero. Unfortunately, the only source I've selected for Alfred to use is Safari. So that can't be the issue.

@dwdblogger & @Vero - FWIW, I started having this problem this month, too. Though it's never been a problem previously. Luckily, it's only happened 2 or 3 times. The good news is that simply restarting Alfred has fixed it every time.

I'm still on Monterey 12.6.1, Safari 16.1, Alfred 5.0.5

38 minutes ago, vitor said:

 

You don’t set it to space, you set it to '. Because when you have Quick Search enabled, that’s the character that gets output. Make sure your File Filter has with space disabled.

Thanks a ton, @vitor!! I tried that setup when troubleshooting, but I didn't realize that the trick was to actually leave Quick Search enabled. I just assumed the default results would still be there, but that doesn't appear to be the case. Thanks!!

Hi @vitor & @deanishe - Closely related to this thread's topic, do you guys know if it's it possible to effectively create your own quick search mode by: (1) disabling the real Quick Search (Prefs > File Search > uncheck "Enable Quick File Search mode"), and then (2) setting up a File Filter whose keyword is just a space?

Every time I try this, Alfred automatically blanks out / removes the space in the keyword field of the File Filter (i.e., which you can tell by just reopening the File Filter ... and, of course, its lack of results).

In any case, while I love the simplicity of triggering a file search with a simple space bar tap, in Alfred, I'd like to refine the types of files that I see in the results. For instance, I really don't need to see "json" or "icon?" files in the default Quick Search results (any many others that I don't regularly interact with). Unfortunately, Alfred's "Don't Show" settings aren't terribly helpful for excluding this garbage either (... not garbage, just stuff I'd rather use file filters to locate). In short, I wish that Alfred would allow for more specific file type exclusions in its "Don't Show" settings, but until that happens, I'd love to just trigger my own file filter with a space-based keyword.

Thanks for any help you can lend!

1 minute ago, vitor said:

 

@xilopaint is building a Python3 library for workflows. One of the things it allows you is to call a notification with the workflow’s icon. Which is exactly what notificator does, so that’s what the library uses—it includes the full script. I was letting @xilopaint know I made an update, so the library could be updated to ship the latest version (which is the one I support).

Got it! Thanks!!

On 10/1/2022 at 8:05 AM, xilopaint said:

 

Added.

@xilopaint & @vitor - My apologies for what is probably a stupid question, but what is the "Python3 library inclusion"? Is it a python version of your Notificator or something else entirely? Thanks!

No problem. Thanks, @vitor!!

16 hours ago, vitor said:

Add them to the Spotlight Privacy tab in System Preferences.

Thanks, @vitor! This sounds like the most reasonable approach. The guess the only downside is that now Spotlight (and other apps that rely on Spotlight data) won't be able to see them either. But that's not a big deal for me! Thanks a ton!

While I intend to adopt your suggested approach, out of curiosity, are you aware of any problems that might be caused by tagging or commenting on applications? For instance, would other users inherit the tags? Do they get overwritten when they're updated? Or are there more severe functional problems they might cause, etc.? Just curious. Thanks!

Thanks, @vitor!! Glad to hear it's "fixed/updated"

Have a great weekend!