Hotkeys & Results of Past Queries

[Jasondm007]

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: 

1. 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
2. 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!

[vitor]

I’m not sure I understood your situation—might be easier to explain with a video—but in the end it sounded like it could be solved by connecting the Hotkey to a Dispatch Key Combo Output that can unselect/delete the text with a → or ⌫.

[Jasondm007]

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

1. Do a quick search for the term "copyright". Then trigger the hotkey - which sends the file
2. 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
3. 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!

Edited February 28, 2020 by Jasondm007

[deanishe]

On 2/27/2020 at 2:00 AM, Jasondm007 said:

I guess I don’t understand why it stays selected once the user starts cycling through the results by pressing the down arrow key?

 

I don't think Andrew intentionally chose this behaviour. I'd submit a feature request for your suggested behaviour if I were you.

[Andrew]

There were a couple deliberate design decisions I made with this behaviour, which you've already noticed:

1. When showing Alfred with the previously typed text, this is highlighted automatically so that it can easily be overtyped.
2. Selection in macOS works by using ⌘C in any app, it doesn't matter the context, e.g. a textual path in Terminal will work as well as a file in Finder.
3. For intrinsic usability, if there is a text selection at any point in Alfred's input field, ⌘C will copy this instead of the highlighted result.

The selection in the hotkey you are using is disconnected from and agnostic of the underlying app, which is why it can't work like one of the built-in action modifiers. To clarify, you use the hotkey, it simulates ⌘C and uses the result. It just so happens that this also works within Alfred's own window because Alfred presents the results as copyable.

 

To "work around" this issue, you could always press the left arrow before using your hotkey to select the file. This would move the caret to the left of the typed query (while not invoking the default right arrow actions panel), then there is no selection in the input field, allowing for ⌘C to take the selected result.

 

As for a behaviour change, I'm not overly keen on arrow down automatically clearing the selection as suggested. This wouldn't be consistent behaviour across Alfred, and wouldn't match macOS built-in behaviour (e.g. Spotlight). This would also be inconsistent for the top result (without pressing the down arrow) vs subsequent results after pressing the down arrow and results being cleared.

 

In your workflow, you could setup the following which would achieve what you need:

 

Hotkey > Dispatch left arrow > Dispatch ⌘C > Delay 0.1 > Arg/Var putting {clipboard} into Argument > ...

 

I'll have a bit of a think about some other workarounds to this issue, but it's not a common problem as I can't remember if this has come up before.

 

Cheers,

Andrew

[deanishe]

42 minutes ago, Andrew said:

As for a behaviour change, I'm not overly keen on arrow down automatically clearing the selection as suggested.

I don't think the issue is not clearing the selection, it's Alfred passing the selected query as the arg to the next action instead of the arg belonging to the item that was actually actioned.

 

In @Jasondm007's recording, you can see that Alfred passes "'copyright" (the selected text in the query box) to the next action, although he's actioning a file item that should pass its path,  and "'copyright" is most likely a bogus value in this context because it's not a valid filepath, which is what downstream elements will probably be expecting,

[Andrew]

@deanishe I understand that... and thought I had conveyed why in my reply in the 3 bullets.

 

His hotkey takes the Selection in macOS (arbitrary selection); When text is selected in Alfred's search field, THAT is what is copied to the clipboard when you use ⌘C (which Alfred uses for selection in macOS).

[deanishe]

2 hours ago, Andrew said:

His hotkey takes the Selection in macOS (arbitrary selection)

 

Sorry. I got the wrong end of the stick (from the start). I thought he was actioning the result in the screengrab normally, not hitting some Hotkey.

[Jasondm007]

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

Edited March 3, 2020 by Jasondm007
typo

[Andrew]

@Jasondm007 for now, you could use the focused app variable, and a conditional to only press left if com.runningwithcrayons.Alfred is the front most app, a bit like this:

 

 

Everything you suggested isn't just a "simple fix" as any behavioural changes would have to be consistent with macOS and throughout Alfred's various input fields, and it would inevitably cause regression, or change of behaviour for another user who may have relied on doing something the same way for years based on something we may have overlooked here.

 

Remember that the use case you have suggested (e.g. arrow down = you don't want the selected text any more) fails to cover another case of a user manually selecting some text, then arrowing down "just because", but still wanting to keep their text selection for copy. This user may not even be showing the last typed query, so it would be inexplicable behaviour.

 

Another possible change could be something like an option to only keep the last query text highlighted for e.g. 1 to 2 seconds after showing Alfred, then move the caret to the right automatically. This would achieve a couple of things, it would give a user enough time to "type over" the query, or shortly after to amend the query. It would also, without changing selection behaviour, keep the Selected Text / Copy paradigm without regression, while working with your workflow.

 

Again, this hasn't come up before, so I'm very wary of making any changes in this area.

[Jasondm007]

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

7 hours ago, Jasondm007 said:

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

 

The focused app variable actually represents the currently focused app in the instant just before Alfred is shown with the custom hotkey.

 

If the focused app variable was arbitrarily available at any point while the workflow is running, it would almost always return Alfred as being the currently focused app.

[Jasondm007]

7 hours ago, Andrew said:

The focused app variable actually represents the currently focused app in the instant just before Alfred is shown with the custom hotkey.

 

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

[deanishe]

52 minutes ago, Jasondm007 said:

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)?

 

Does BTT's own detection not work?

 

54 minutes ago, Jasondm007 said:

like external triggers tied to BTT, snippets, etc.

 

Snippets already support focusedapp. You could pass the name/ID of the active application to an External Trigger, or use BTT to simulate a Hotkey.

[Jasondm007]

@deanishe Thanks for getting back to me!

 

1 hour ago, deanishe said:

Does BTT's own detection not work?

 

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?

 

1 hour ago, deanishe said:

BTT to simulate a Hotkey.

 

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

Edited March 5, 2020 by Jasondm007
Added link

[deanishe]

34 minutes ago, Jasondm007 said:

That's why I was asking about how to return the bundle ID of the focused app through a script.

 

Almost certainly not. If BTT can't tell when Alfred's active, neither can a script.

 

35 minutes ago, Jasondm007 said:

How does Alfred do this?

 

Alfred knows when it's active.

 

31 minutes ago, Jasondm007 said:

and I'm prone to forgetting about them - Ha

 

That shouldn't matter if you only need to use them once to set up BTT.