Thanks noisneil You're right, it probably doesn't work for Alvaro, but it works for me.
By the way, I just noticed that "special" keys also work as triggers. So Spacebar, fn, Enter, Delete, esc, Arrows.
Thanks noisneil You're right, it probably doesn't work for Alvaro, but it works for me.
@Frankb Sorry I've just woken up so my brain isn't working yet... Do you mean that "special keys" work for selecting macros in a palette?
The palette and the macros in the palette
so you could type fn (opens palette) then again fn triggers macro
Sorry, not true. fn opens the palette, then another key is needed, but can be a "special keys"
eg. fn + enter, or a letter, number...
Those keys are probably best avoided for triggering macros directly, as they are commonly used for in-app functions, but in theory any key can be used as a hotkey, yes. The fn key would be an exception, provided you have access to your function keys without it or if the function keys aren't needed.
@noisneil I tried your new approach, it is nice and simple to configure, great idea! However, probably the problem is that this feature should be included in the KM package itself to handle it right with care. I do really appreciate your effort and kindness, but those are some cons I found while using your approach:
- Since it is based on an external tool, it is a bit messy. If you mistake the spelling of your shortcut you have to manually close KeyboardLocker by pressing ⌘Q. Probably a timer could be added to abort the current key sequence and quit KeyboardLocker if 3sec has been elapsed or something like this.
- Pressing enter to validate the input is not very nice according to my taste, (but I understand it has some advantages too). It would be nice if as soon as a string matches the keyboard is unlocked and the macro fired.
- The KeyboardLocker notification is distracting, but this is a minor problem, Im pretty sure this can be fixed or another similar programs can be used for the same purpose.
In conclusion, I think your approach is great, probably the best so far... but it could be even better if KM add this behavior as a new kind of trigger.
I am trying to understand @kraftyDevil script and adapt it to my needs to see how it performs. I also tried BTT and it is nice, but it is not exactly what I expected either.
I think it is nice to be able to share this kind of knowledge, it can be helpful for many people and luckily help to improve KM itself.
Thank you! I will come back to this post soon to add my own conclusions about all suggested methods
eg, this works. fn opens palette, triggers are Enter, Spacebar, esc
I agree that locking keyboard input is a compromise. It's worth noting however, that if you mis-type your string as one that isn't recognised by the Switch/Case group, hitting Enter will quit KeyboardLocker and complete the macro without performing any actions. So you can hit Enter rather than ⌘Q.
I agree and it can easily be done with a timeout pause instead. I would personally find it annoying to have to wait before the macro executes, which is why I opted for hitting Enter instead, but it's still a compromise. The way you asked to trigger the macros isn't something natively supported by KM, so our best options will still involve compromise. We've explored some ways to get your preferred method of triggering to work but, for the moment, perhaps you should consider others.
In terms of practicality, @Frankb's suggestion of using palettes is probably the most flexible and user-friendly option. However, if you prefer not to see a palette, then I think this one might be most suited to a practical workflow.
For the sake of completeness, here is another option for using strings as triggers. You will need to be aware of whether or not you want the typed string to be deleted. If the typed string enters unwanted text in your app, you will probably want to turn this feature on; if it doesn't, then you will probably want to leave it off.
As you can see, I've set multiple typed string triggers for the Merge macro that are mirrored in the Switch/Case group.
To use this, trigger the Activate macro with ⇧⌘M and type your string trigger.
NB: I just edited the above macro to include an activation timeout.
The limitations of KM Conflict Palettes is probably the entire reason I've been seeking a better input method like the one in this post.
Maybe a more in-depth explanation of these palettes from yourself or @Frankb would help.
I would explain it but I don't understand them beyond the default Conflict Palette – which I think is so-so but not great.
The reason being that the letter-by-letter selection option in the default Conflict Palette breaks down when the names of your macros start getting too similar.
For example, here are the names of some of my macros and what KM expects me to press after the initial 'I':
Expected letters have been bolded and capitalize for detail:
InsErt Row Above
InsErt Row Below
InsTall Beta Build
InsTall UAT build
I > E to Insert Row? I > R would be more intuitive.
I > T to Install Beta? I > B works better.
These resolutions makes no sense so then you have to spend too much time trying to find the next letter in the Conflict Palette – for which the rule by default is – "resolve to the next character that differs".
Honestly, if KM could change this Conflict Palette character resolution method then I wouldn't need any of the custom macros we've made in this thread.
In addition to the default, it would be useful to have these user configurable options when resolving macro names in Conflict Palettes:
- Resolve to the next character after a space (if one does not exist, then use the default)
- Resolve to the next capital letter (if one does not exist, then use the default)
Using #1, my Conflict Palette would look like this after inputting the first 'I':
Insert Row Above
Insert Row Below
Install Beta Build
Install UAT build
Much better – because now "Insert Row Above" is now I>R>A, which is easier to remember.
This would allow me to think about keypresses as I have named my macros and not by some heuristic that breaks down with macros too similarly named.
Notice this is the same mechanism that @AIvaro wants to use. It blocks input and you can enter a sequence to launch a macro.
I'm not sure where you'd specify this in KM if it were an option. Preferences?
So, while I definitely have issues with the default Conflict Palette – I would be interested to see how a custom one would address this issue
To clarify: I have not suggested conflict palettes. You cannot select your own triggers there.
I mean normal palettes. There you can select your own triggers. Letters, numbers or shortcuts. Keys like spacebar, fn, enter, delete, esc, arrows are also possible. And the benefit: None of this is passed to the front app. the visible palette (for one action) acts like a key blocker
This is the palette I suggested. fully configurable:
And this is a conflict palette. No arbitrary triggers (Predefined by KM):
The problem is that the triggers in paletts are limited to one character or a shortcut (two characters).
I'm not sure if that's smart or dumb....
What about "Trigger Macros by Name"?
Add a unique "string" in front of the actual name of the macro
eg. call the Macro
.cap - capitalize text
open the search window "Trigger Macros by Name" with a shortcut
This "Enter" is harmless for any other app, because KM is the front app as long as the search window is visible.
This seems safe, easy to set up and uses only functions of KM.
Ooh interesting. I wonder if there's a way to make a version of the Trigger Macro By Name macro that restricts its scope to a single group? Would remove the need for a "." at the start of the string. You'd still need to hit Enter, which isn't what @AIvaro would like, ideally, but I like your thinking.
Actually, the more I think about it, this would be functionally identical to using my prompt idea, so maybe it's not worth the hassle?
you can customize the "initial search" and which macros are searched for
and yes restrict it to a single group
"You'd still need to hit Enter, which isn't what @AIvaro would like"
Correct. But there ist Enter and Enter. THIS Enter is alway just in KM.
Ah yes, of course. So this is a good alternative to the prompt if you prefer the look of it.
I'm curious of the purpose of the '.' prefix.
Also, I know this suggestion isn't for Conflict Palettes, but this naming convention actually works pretty well for them, which don't require an 'Enter'.
I did some fancy renaming of my macros to include my "⇧⌘I" trigger and here's what Conflict Palette looks like for my previous example:
Here it is in 'Trigger Macro by Name' form:
Whether using 'Trigger Macro by Name' or Conflict Palette, a couple issues remain:
- The interactive element only responds to the prefix which means I have to focus there instead of the name of the actual macro. It's not ideal but workable
- The list is sorted by my prefix, which separates the "Install" and "Insert" macros, unfortunately
I think what I really want is a Conflict Palette where the selected character resolves to the next character after a space, as opposed to one that resolves to the next differing character
All our solutions have advantages and disadvantages. Your solutions prove deep knowledge about KM. My suggestions are rather simple and practical.
Nothing is exactly what Alvaro is looking for. And I doubt that it can be implemented with any software. His requirements are partly a contradiction in itself.
This is not an accusation, just an observation. His fear of doing something bad with Enter is unfounded. With the palettes, as with "Trigger Macros by Name", Enter or any other key is only passed to KM. For safety, this is even supported visually. He doesn't want the solution with "KeyboardLocker" because that is an external app. But he doesn't want an internal KM solution either. Although both achieve the same goal: not giving input to another app.
Of course, wrong manipulations can always happen. But this is possible with every solution.
To your question kraftyDevil: I'm curious of the purpose of the '.' prefix.
The idea was to have a unique "string" that doesn't produce conflicts, so you don't have to choose from different options. This makes the process faster. That's why I never talked about "conflict palettes", but about normal palettes. There the trigger can be chosen freely.
@Frankb By limiting the scope of the palette to one dedicated group, surely you don't need to use the "." at the start of the string...?
I agree that your suggestions are the most logical and practical. Been fun trying to find permutations though!
I wonder if this could be something for Alvaro .... even if he is long gone
Thank you Frankb,
I'm not scared pressing enter, just a preference. What I meant to be "dangerous" is to send key strokes to the focused App. I don't want to use shortcuts as text expansions, I won't be on text-input context (thus it could be potentially dangerous, not only enter, any other key too).
Palettes and all this stuff are great, but they were not my first preference. Maybe I have to stick with them, but I'm still looking for other alternatives. You said that my requirements are probably impossible to achieve with any program but as a programmer, I don't see anything too absurd in what I was asking for. Anyhow, in case there is not anything like that, then I will use some of your suggestions.
Thank you for all your help people, this is a very healthy community.