Jasondm007

@vitor I would definitely echo @politicus statement about how awesome this workflow is! It's definitely near the top of my most used workflows. Somewhat related to @politicus question about blacklisting items, is it possible to exclude temp/invisible items? I might be wrong, but the issue seems to be limited to Microsoft Word files. When I run your workflow, it always shows a handful of Word files that start with "~$". I notice them whether I run the workflow on my Downloads or Desktop folders, etc. Thanks again for sharing the workflow!

@deanishe Thanks for getting back to me! Not from what I can tell (at least, not in the same way that every other app-specific shortcut on my computer works with BTT). That's why I was asking about how to return the bundle ID of the focused app through a script. There's has to be a general way to do this outside of Alfred, right? How does Alfred do this? It's not really Gremlin water, right? I thought about going this route previously, but didn't like the idea of adding a bunch of new (intermediary) hotkeys to Alfred. They're prone to breaking (and I'm prone to forgetting about them - Ha).

@Andrew OK - I think I understand what you mean here. Thanks! I'm sure I'm using the wrong terminology here, so please bear with me. But in layman's terms, I was wondering how I could tell other apps, like BTT - which I often use to kick off Alfred workflows - whether Alfred is the focused app (i.e., since the frontmost app-related checks, that I'm familiar with, won't work). Is it possible in a script (in any language) to tell whether Alfred is the focused app (i.e., that his search bar is open)? Put differently, if I launch a shortcut with BTT (or anything outside of Alfred) and I want it do something different when Alfred's search bar is open, how can it identify whether Alfred is the focused app? How would I code something like that in bash/applescript/python/whatever (re: return bundle ID of focused app)? Perhaps I'm in the minority on this one, but if you're using other things to kick off Alfred workflows - like external triggers tied to BTT, snippets, etc. - I still think having a general "focusedapp" variable would be useful - separate and apart from the hotkey object - in the same way Alfred allows people to use {clipboard}, etc. Thanks again for all of your help! You're the best!!

@Andrew Thanks for getting back to me, and for your recommended approach above. I've been using it today, and it's working great. I was hesitant to copy things to the clipboard in this fashion, but everything seems to be working fine. To be honest, I had largely stopped using app-specific hotkeys with Alfred (for the depletion reasons we discussed previously), and I did not realize that the focused app variable worked with Alfred (i.e., so that it returned Alfred as the focused app). While I'm obviously not much of a coder, I assumed that it wasn't possible based on our previous discussion about Alfred never being the frontmost app. Out of curiosity, is there a way to use the "focusedapp" variable in Alfred without relying on hotkey (directly through Alfred or through a script that could be added to a workflow, etc.)? In other words, is it possible for other scripts/workflows to know if Alfred is the focused app/window/etc? That would be really helpful for some other workflows that I kick off with external triggers, and for some other apps that I use BTT with, which have shortcut conflicts with Alfred (or that require me to use modifiers that I can never remember). Regarding future UX changes, I never claimed that any of my proposals were a "simple"! 😉 In fact, I have no idea how difficult any of this stuff is (just that it takes me forever). In fact, I assumed that Alfred works something like Gremlins, and that you just added water for new features? Ha In any case, I think your timed suggestion above is perfectly reasonable, and would work great! However, I also wouldn't be terribly concerned about the "just because" use cases either. If I wasn't clear in my previous post, I should have indicated that the cursor shift would only occur at the outset when the old query is actually present and after the user hits the down arrow (i.e., not a new one or a modified one - just an old query). Of course, I have no idea whether that's technically feasible... Just add water, right?

@Andrew Thanks a ton for responding to my message! I really appreciate you walking through everything. That’s very kind of you. As far as behavioral changes go, perhaps my use patterns are just a little different from the norm? While I’m not so concerned about consistency with Spotlight - after all, if I liked it, I wouldn’t be such a huge fan of Alfred 😜 - I can certainly appreciate the speed for others who might want to quickly enter a new search (i.e., because the query’s text is still highlighted). The reason I suggested shifting the cursor to the right of the query (after the user hits the down arrow, and cycles through their old results), is that, at that point, I rarely ever decide to enter a totally “new” query. Once I’ve decided that I want to act on another document from my previous query - and I’ve pressed the down arrow to navigate to the document - I rarely ever need to immediately enter a new query. In most cases, I just want to act on the file. And, if the file is not in my previous query - because I’ve lost my marbles, and can’t seem to find it - then I’m more likely to modify the query than to create an entirely "new" one (i.e., add or replace a term; not come up with an entirely new term or set of terms). As a result, for me, shifting the cursor to the right after hitting the down arrow makes more sense. It not only solves the hotkey problem, but it’s also more responsive to my use patterns (now I don’t have to press the right arrow key, the query is ready for modification, not clearance). However, if your usage stats say that people are more likely to start anew - even after cycling through a few documents in their history with the down arrow - then sticking with the current behavior probably makes more sense. Regarding your suggestion about mimicking the dispatch right arrow, I’ve never been a big fan of this approach because of its specificity to Alfred. I use this shortcut in several different apps to open files, like Finder, HoudahSpot, Alfred, etc. (and I don’t want to eat up more global shortcuts than necessary - or, more importantly, than I’ll remember). I have no idea about their technical feasibility, but would any of these options work (re: feature requests)? Add a new 3rd option to Alfred’s Advanced “History” settings, that enables the desired behavior (re: query text highlighted until the user presses the down arrow, which causes the cursor to shift to the right of said text) (or make it the default behavior, if there’s evidence that others are also more inclined to modify the search than clear it). To be clear, in this scenario, I still think it's imperative to highlight/select the query until the user presses the down arrow. Add a new special setting/action/option to Alfred’s hotkeys, that users can enable or select, which (1) still works in other apps, (2) but in Alfred, knows to only ever copy the selected result/file (i.e., never the query’s text). Add something to Alfred that allows external scripts to know when Alfred's search window is open/frontmost. We’ve talked about this before, so I won’t belabor it here. Of course, this would make it easier to operate as a global shortcut because users could just make the script operate differently for Alfred than it does for other apps (e.g., click the right arrow before copying the file path). Unlock the default action modifiers found in Alfred’s Advanced settings, such that users can include their own workflows with external Trigger IDs (i.e., beyond merely as a default fallback option). Ideally, they could use a dropdown, just like how “Workflow Triggers…” button works on a “Call External Output” object. While it's not ideal, I use this shortcut so much that I could live with losing one of the general action modifiers. I'm sure some of these suggestions are a little ridiculous, so please feel free to laugh at me. I can take a joke! Thanks again for all of your help with everything!

@vitor Thanks for getting back to me! I initially considered doing what you mention above, but was hoping there was an easier way of dealing with the issue. As I mentioned above, it seems like more of a UX issue than anything. I just have to remember to hit the arrow, if I'm looking at the results from a previous query. To illustrate the description from my previous post, I've put together a short video. It's scaled down to meet the size restrictions here, so my apologies for its quality. I've attached the hotkey to a Large Type output, so it's easy to see what I mean about how the hotkey operates (however, this is just for illustration purposes - as well as the doctored username). In theory, I'd like the hotkey to send the file each time. But as you can see in the video, unless I manually unselect the previous query, it will send its text. In the video, I: Do a quick search for the term "copyright". Then trigger the hotkey - which sends the file Open Alfred, which is still displaying my previous query's results, and try to use the hotkey on the same file - which sends the query Do the same thing as above, except this time I move the cursor to the left before triggering the hotkey - which sends the file Thanks for any help you can lend!

Is there a way to configure a hotkey so that it always passes a selected/highlighted file in the results? More specifically, I have Alfred set up so that, when he opens, he shows his previous search results (Advanced - History). Assuming there’s an old query to display, by default, Alfred automatically selects/highlights the text from the previous argument. This text also stays selected/highlighted until the user clears, modifies, or unselects it (e.g., right/left arrow keys). As a consequence, if you use hotkeys to pass files to workflows (i.e., setup w. Section in macOS & Pass through to workflow), then you always have to remember to unhighlight the text from your previous query before using the hotkey. This is true even in situations when you’ve used the arrow keys to navigate to a particular file in your results. Under the current setup, Alfred’s hotkey will passes the text from the old query because it’s also technically selected/highlighted, and it appears to take precedence over any files/results that you also might have selected at the same time. Is there a way to either: Configure a hotkey so that - at least, when it comes to Alfred’s search window - that it never acts on the query/text and only acts on a selected result/file (e.g., in the same way Reveal in Finder and other alternative actions in Alfred still seem to work even when the old query text is highlighted)? OR Automatically unhighlights/unselects the text from the previous query once the user presses the down arrow key to go through the old results? To be honest, I’m a little surprised this isn’t the default behavior. While I like the fact that the text from the previous query is automatically selected when Alfred is first opened - i.e., because it’s easier to just start a new query by simply typing, which wipes out the old text - I guess I don’t understand why it stays selected once the user starts cycling through the results by pressing the down arrow key? Obviously, this is the easiest way to start a new query (less clicks/keys) but the tradeoff is that users have to remember to unselect the old query each time if they want to use a hotkey to pass a selected file (i.e., assuming there isn’t a more sophisticated hotkey setup than the one described above). For new users, it’s also got to be pretty confusing - since the GUI makes it look like two things are selected/highlighted (i.e., the query and the result/file), and one would assume that if you've taken the time to scroll down to a file in the results that you would want to act on the result and not the query. In any case, am I overlooking something here? Beyond just remembering to unhighlight the old query - or setting up a proper filter, etc - is there another way to accomplish this? I feel like I'm overlooking something really silly here.🤦‍♂️ Thanks for any help you can lend!

@dfay & @xilopaint - Thank you both so much for sharing your workflows for splitting double paged PDFs. You guys are a lifesaver! I have been doing this manually in Adobe Acrobat for eons - and cursing every moment of it. Can't thank you both enough!!

@deanishe Thanks a ton for getting back to me! While I understand what you mean conceptually, most of this is a little above my skillset. Let me do a little research and tinkering around, and see if I can stitch together some kind of a test workflow to share. Thanks again!!

@deanishe This is probably a stupid question, but is it possible to feed the output from the mdfind command directly into the "scopes" field of a File Filter (using a JSON Config utility)? In short, I'd like to create a standard File Filter for searching within a set of folders with a specific tag ("Notes"). Because these folders fluctuate, however, I didn't want to just drag a set of static folder locations into the File Filter's Scope panel. Instead, I was hoping to feed the "scopes" field of a JSON Config utility the output of the following search (mdfind 'tag:Notes AND kind:folder') - which would then set the scope for the File Filter. As always, thanks for your help!

Thanks a ton @brunoc!! I really appreciate it.

@GuiB Thanks for the suggestion. I was actually trying to trigger Alfred's "Open with" file action directly (or any other file action, for that matter). I wanted to attach a global shortcut to it (because I hate right-clicking things and bumbling around with the default "Open with" contextual menu in Finder and other apps). Alfred's file action for that is much easier for me to see and it avoids the mouse. Thanks again!

Thanks a ton, @deanishe!! I was trying to avoid going down the GUI route - because I have a few similarly named file actions that I've created - but perhaps I'll just rename them and use your method. @Andrew Out of curiosity, has there ever been any discussion about allowing this though the action command? Relatedly, I've always thought it'd be nice to have a workflow object that operates like the "Call External Trigger" with a dropdown where the user could select a given file action to execute on the output (e.g., default actions, and ideally user created file actions, too) 🙏

Is it possible to use the action command to call a specific file action? For example, when actioning a file could I trigger Alfred's "Open With..." file action? Relatedly, if this is not possible to accomplish this with the action command, is it possible through some other means (i.e., specifically targeting Alfred's Default Actions, not user created ones - that would be easy)? Thanks for your help!

@Mpco Thanks for sharing this Alfred workflow for DEVONthink. It's fantastic! One quick question: Is it possible to switch the default search results action to open the file in DEVONthink (i.e., instead of an external editor)? I tried merely adapting the configured connection between workflow actions, so that the "Open With External Editor" requires users to hold command and the "Open with DEVONthink" doesn't require anything, but it doesn't seem to work. From what I can tell, the script filter is passing the file path to the "Open with DEVONthink" action instead of the UUID? Is there a minor change that can be done to the script filter or the search.js file to accomplish this? Thanks for your help! And, thanks again for sharing this workflow!! PS - Apologies for the duplicative post to GitHub, as I thought others in this forum also might know to tweak the workflow.

@brunoc Thanks for sharing this workflow. It's fantastic - and has really improved my experience with DEVONthink! Thanks a ton!! Quick Question: Is it possible - either with some modifications to the "search groups" portion of the workflow or by creating a new action - to include Global Smart Groups? I use these a ton, and would love to quickly access them in the same manner that your fantastic workflow does for normal groups. Thanks again!

PS - While it’s easy enough to create a File Action to reveal aliases in the same manner as everything else in Finder (tell application "Finder" to reveal thePath), this doesn’t solve the more common problem - where users rely on "cmd + ↩︎" to “Reveal in Finder (if local)”.

When handling aliases for files/folders - either when browsing or through the usual search - I wish Alfred’s "Reveal in Finder" actions actually revealed the alias and not the file the alias is pointing to. In the scheme of things, while this is a relatively minor issue, it has always driven me crazy. This behavior is not only odd when dealing with the usual search results, but it's especially jarring when browsing in Alfred. If I use "cmd + ↩︎" to reveal an alias that I'm looking at when browsing in Alfred, I doesn't make any sense to me why Alfred's default behavior would be to reveal the actual file and not the alias. It's confusing enough with the usual search results, and it's especially odd when browsing. I can understand why revealing the actual file from an alias can be useful, but this has always struck me as odd that it’s the default behavior. Why not add this as a file action behavior (if people want it)? Or, at least provide users with an option in the “Advanced” panel where users can turn on/off how Alfred reveals aliases?

Thanks for your consideration, @Andrew!! Not that BTT should be the gold standard, but when there's a conflict created by the user (e.g., assigning the same key combination to the same app with focus) BTT just gives a remedial selection where the user can select which hotkey/action the user wants to trigger (based on the titles the user gave them in BTT). For some users, I suspect they're happy to have this sort of a "true" conflict and to rely on the dialog to select the appropriate action each time. For me, however, it's just helpful to realize when I've screwed up and need to go back and reassign a different key combination. Or, on the rare occasion where I do want both using the same key combination in the same app, then I create menu in Alfred to tie them to (i.e., so I don't have to use BTT's ugly dialog). I'm sure there are better ways - like internally checking and providing feedback to the user as they're setting the key combination in Alfred, etc. - but BTT's approach works pretty well, too.

Thanks for your help, @deanishe & @vitor!! I'm glad to hear that I'm not just overlooking something. In any case, I took your advice and reposted it in the Feature Request section:

At the moment, when you assign a key combination to a particular hotkey in Alfred, it keeps you from using the same key combination with a different hotkey. While this make sense in most scenarios, when the hotkey is assigned to a particular app - as specified in the Related Apps panel of the hotkey, and selecting the option that limits the hotkey to when the app takes focus - it seems unnecessary to restrict the user from using the same key combination with other apps that might have focus. As a result, I'd like to request this feature be added to Alfred. Without this ability, it causes users to have to come up with increasingly ridiculous key combinations that they can never remember (OK ... that I can never remember 😉). Or, to rely on another intermediary app - like the Better Touch Tool - to assign app-specific shortcuts that are attached to External Triggers in Alfred. BTT is great, but let's cut out the middleman and keep Alfred's shortcuts in Alfred!! Thanks for your consideration! PS - This request comes from a previous that can be found here:

Is it possible to use the same key combination in different hotkeys when they're assigned to different apps? In other words, can I assign the same combination of keys to different apps (by adding the app to the Related Apps panel of the hotkey, and selecting the option that only activates it when the app has focus)? This is something that has always confused me about Alfred, so I wanted to check to see if I was doing something wrong. From what I can tell, Alfred won’t let you assign the same key combination to more than one hotkey - even when they only operate when different apps have focus. To get around this issue, a long time ago, I stopped adding hotkeys directly in Alfred and started adding External Triggers that I assign to a keyboard shortcut in the Better Touch Tool app. But this has always struck me as odd. Am I doing something wrong here? Is this possible in Alfred? Thanks for your help!

@Andrew Many thanks for the clarification! This all makes perfect sense - even to a scripting neophyte, like myself! If Alfred can't take focus as a frontmost app, is there a different way to check (via AppleScript) whether his window is open? Thanks again for all of your help!

Hi @Vero - Does this still work in Alfred 4 & Mojave? If I've enabled Compatibility Mode for Focusing in Alfred's Appearance options, and I run the script below - while Alfred's search or file action window is open - shouldn't "Alfred" or "Alfred 4" show up as the frontmost app (i.e., as frontAppName in script below)? Or does the Focusing option control something else? Thanks for your help! tell application "System Events" set frontApp to first application process whose frontmost is true set frontAppName to name of frontApp end tell

The update is awesome, @sballin!! Thanks a ton!!!