hotkeys How can I quickly find hotkey combination conflicts?

[Chris Messina]

Hello! I searched across the forums and found a technical solution to locate hotkey combination conflicts, but I'm wondering if Alfred already provides an easier method (e.g. by listing the other Workflows with conflict in a ℹ️ tooltip?) or solution to locate and unset conflicts?

 

I have over 200 Workflows so inspecting each isn't efficient; I'll use the grep method meanwhile, but a UI affordance that lists all hotkey combos and which Workflows contain them would be very useful.

 

[Chris Messina]

Quick update: I was able to find the hotkey conflict, but it turns out it was in a disabled Workflow.

 

Steps I took:

1. Reveal original Workflow in Finder
2. Open info.plist in Plist Edit Pro
3. Search for "hotkey"; found "1835008"
4. Grepped through ~/Dropbox/Alfred/Alfred.alfredpreferences/workflows but found that this was not a rare hotkey combo, so instead grepped for "<string>K</string>"

5. Got two hits!

6. Opened the conflicting Workflow and discovered that it was a Disabled Workflow.

7. Unset the conflicting hotkey combo

Not an impossible process, but certainly obscure — and even moreso since I didn't expect that disabled Workflows would be considered in conflict. As such, I've posted a bug report about that.

 

[Andrew]

There is no need to do lower level searching like this, simply right click on the hotkey object and it'll show you the shared hotkey combos:

 

 

The feature to enable shared hotkey combinations was added in Alfred 4.1, and the orange highlight you're seeing isn't a conflict, it's just to make you aware that another hotkey shares the same combination. The hotkey will still work, and there is internal logic to ensure the correct one is "run". Here is an extract from the change log which explains shared hotkeys:

 

Hotkey Trigger

• The same hotkey combination can now be shared across multiple triggers matching different conditions
• Added navigation to related hotkeys on the contextual popup menu for a hotkey trigger in the workflow editor
• Prioritisation of shared hotkey to run, with the following priority:
  • In Focus match takes highest priority, e.g. Hotkey only when Safari in focus
  • Not in Focus takes secondary priority, e.g. Hotkey only when Spotify not in focus
  • Falls back to hotkey with no app specific focus configured
• Hints shown in orange if a shared hotkey combination is in use
  • Hotkey Trigger object key combo background changes
  • Subtext under the hotkey field updates with warning
• Show subtle grey background behind application icons on Hotkey Object in workflow editor where hotkey focus mode is set to "don't have focus"
• Copy and Paste of object (or object configuration) now also retains the hotkey combo
• Note that this will naturally create a conflict which you will have to manually resolve

I see that you've raised a bug disagreeing with the fact that you shouldn't be notified when a hotkey in a disabled workflow shares the same combination. I left this orange highlight in by design, as a shared combo is still a shared combo whether the workflow. is disabled or not. It's still extremely valuable to see that a combo is used in another workflow, even if it's disabled. This avoids a situation later on when the workflow is re-enabled and the user has no idea the hotkey was previously set to a shared combo.

 

Just to iterate, shared hotkey combos aren't conflicts, they were a specifically added feature, and extremely useful when paired with the Related Apps option of the hotkey. The orange is just to highlight that you're using the feature.

 

Do you still feel like there is a bug?

 

Cheers,

Andrew

[Chris Messina]

16 hours ago, Andrew said:

It's still extremely valuable to see that a combo is used in another workflow, even if it's disabled.

 

@Andrew Thank you for that detailed explanation. I understand why and how more than one Workflow can have the same hotkey combo and understand the cascading logic for determining which action hotkey combo gets actioned when triggered.

 

I do have subsequent feedback:

1. Once a hotkey combo is specified in one Workflow, I am unable to set the same hotkey combo in a different Workflow. This seems to conflict with the behavior you've said should be possible?
2. I am unable to copy and paste a hotkey combo from one Workflow to another if the destination Workflow is disabled.
3. It would be useful if "Related [Hotkey Combo]" information were contextually available/made more proximate to the "Shared with other hotkey triggers" orange text. I may have avoided going down this rabbit hole had I know that sharing a hotkey combo would cause a new menu item to appear which would reveal the Workflows that share the same hotkey combos.

I'm also pleased to find that searching for hotkey combos in the Workflows Find feature actually works! I didn't expect that — but am glad to have learned about it! 

 

[deanishe]

5 hours ago, Chris Messina said:

Once a hotkey combo is specified in one Workflow, I am unable to set the same hotkey combo in a different Workflow.

 

That usually means the first Hotkey is active in Alfred Preferences. You can't create a duplicate because pressing the key combination triggers the first Hotkey. The keypress never reaches the widget.

 

22 hours ago, Andrew said:

It's still extremely valuable to see that a combo is used in another workflow, even if it's disabled.

 

True, but it's not on the same level as in an enabled workflow. Every time I check the warning and see it's for a disabled workflow, it feels like a false positive.

[Chris Messina]

12 hours ago, deanishe said:

That usually means the first Hotkey is active in Alfred Preferences. You can't create a duplicate because pressing the key combination triggers the first Hotkey. The keypress never reaches the widget.

 

That makes sense but doesn't match my experience. I was specifically trying to setup ⌃⌥⌘K, which I'm pretty sure isn't used by Alfred.

 

12 hours ago, deanishe said:

True, but it's not on the same level as in an enabled workflow. Every time I check the warning and see it's for a disabled workflow, it feels like a false positive.

 

I agree, which is part of my feedback. I also feel like it's a false positive, which conflicts with @Andrew's perspective.

[deanishe]

9 minutes ago, Chris Messina said:

I was specifically trying to setup ⌃⌥⌘K, which I'm pretty sure isn't used by Alfred.

 

I didn’t say Alfred is using it. I’m talking about the other Hotkey you created with the same key combination as the new one you’re trying to add.

[Chris Messina]

10 minutes ago, deanishe said:

I didn’t say Alfred is using it. I’m talking about the other Hotkey you created with the same key combination as the new one you’re trying to add.

 

Ah you're right! I misread your comment. And yes, I believe that's also correct — e.g. that the hotkey combo is being triggered as you try to add it, which means it never reaches the widget.

 

And given that, the logic that @Andrew specified seems even more obscure, which is what lead me here in the first place: I have two Workflows that interact with Kaleidoscope, one that I made and one that the Kaleidoscope developer offered. I wanted to use the familiar hotkey combo (⌃⌥⌘K) in the developer's Workflow, but it was unknownst to me already registered in my disabled Workflow. Since I didn't realize I had a disabled Workflow that already "claimed" that hotkey combo, I was going out of my mind to figure out where or which app might be using that hotkey combo outside of Alfred because I couldn't use that hotkey combo within Alfred. It was silently failing without any kind of error message to inform me that the hotkey combo I wanted to use was claimed by being intercepted by a disabled Workflow. 

 

I mean, this just doesn't make sense — and perhaps this is a bug? — but if you try to add a hotkey combo that's already assigned in a disabled Workflow, you'll be unable to register that hotkey combo in an enabled Workflow! Why would the disabled Workflow hotkey combo be triggered when I attempt to use that hotkey combo?

[deanishe]

3 minutes ago, Chris Messina said:

Why would the disabled Workflow hotkey combo be triggered when I attempt to use that hotkey combo?

 

If the other workflow is disabled, then it should work. I'd consider that a bug. You might have to temporarily assign the other Hotkey to a specific app to get Alfred to accept the Hotkey.

 

FWIW, it's only Alfred's UI that won't play along. If you copy and paste the Hotkey configuration directly from one info.plist to the other in a text editor, Alfred will accept it.

[Andrew]

You should be able to set the hotkey on an object if it's in a shared combo which is not currently active in macOS (e.g. workflow disabled, or related app set). I have just tested this works, so this leads me to think there may be a hotkey coordination issue happening at a lower level if this combo isn't making it through to the prefs for you.

As a workaround, you can copy and paste Hotkey workflow objects (or their configuration on the popup menu), so you can just copy that from the disabled workflow for now. No need to dig down into the plist.

 

Let's pause this conversation until I've had time to take a deeper look.

[Chris Messina]

Ok — FWIW, here's a recording of what I'm seeing. 

 

https://www.dropbox.com/sh/ytxsarp7z62jwe8/AAD4VD0ye6Yn4-hRlOlL9REea?dl=0

 

You'll see a hotkey combo being triggered in the overlay, which is when I'm hitting ⌃⌥⌘K. You'll see that I can not actually set that hotkey combo when it's already used by another Workflow.

 

Thanks for taking a look!

[Andrew]

I've managed to reproduce it and can see what is happening under the hood, and can see why this has led to confusing behaviour.

 

We have quite a high support load at the moment with people upgrading to Monterey, so I can't promise an imminent fix, but I'll try to get it sorted for the next pre-release.

[Chris Messina]

Super, appreciate the validation!  

[Chris Messina]

On 12/6/2021 at 3:05 PM, Andrew said:

I've managed to reproduce it and can see what is happening under the hood, and can see why this has led to confusing behaviour.

 

@Andrew it appears that control-based (^) conflicts are still incorrectly being detected in disabled Workflows in Alfred 4.6.5 [1298]. 

 

As you can see, I installed @dfay's CaseConverter 3.0 workflow and disabled 2.1.1a, but the HotKey block in 3.0 is showing a conflict w/ the disabled Workflow:

 

[Andrew]

@Chris Messina the fix means you should be able to set the combo you want now (if it's also used in a disabled workflow), Alfred's preferences was incorrectly preventing this before. It still shows in orange to notify you that it's a shared hotkey.

 

It's likely that I'll show it in a different colour in the future to differentiate between "shared with active" and "shared with disabled" workflows.

[Chris Messina]

9 hours ago, Andrew said:

It still shows in orange to notify you that it's a shared hotkey.

 

Ok, yes — I understand that the fix improved the logic so conflicts wouldn't prevent assigning hotkeys that were set in disabled Workflows. 

I think my confusion came from seeing the colored hotkey and assuming that it meant that it was set for two different workflows... perhaps in addition to separate colors (to indicate severity of the issue (e.g. Warning vs Failure)), you might separate "Related Hotkeys in Enabled Workflows" from ""Related Hotkeys in Disabled Workflows"? Or even just add (Disabled) to the name of the workflow in the Related menu?

[giovanni]

@Chris Messina you might want to try this I just posted, which shows conflicting hotkeys and shows a different icon (🟠) if a hotkey is only shared with a disabled workflow. Feedback appreciated!