Hello, I would like to add a feature request that there is a condition check for if the focus is in a text field. This way, we could use keys without modifiers and still get them to work when a text field is in focus.
Cheers!
There already is a condition check to tell if the focus is in a text field. However it may depend on the app and you haven't said which app you are using. Here's how to test:
In the above example, if the Paste menu item is enabled, that (more or less) means you are in a text field, at least for some apps.
I suspect that macOS doesn't have a public API to test what you exactly want to test, or it would probably be part of KM already.
Not quite, what I am looking for. A lot of graphics apps allow you to paste graphics when not in a text field. So, that will not work for me. Too, the Finder allows you to paste file/folder objects/references. So, again, this doesn't work.
Regarding the API call, it exists, at least in Swift:
if textField.isFirstResponder {
print("Text field is in focus")
} else {
print("Text field is not in focus")
}
Though, I have to admit, I did not look into the full list of conditional options. I was strictly in the "Application Condition". I will dig further to see if something else will suit.
Thank you for the response.
¢£
Too, sorry, that API call would be to check if a specific textfield is active in an App you control. With more monkeying around, it could look like: import Cocoa
import Foundation
func isTextFieldInFocus() -> Bool {
// Get the frontmost application
guard let frontApp = NSWorkspace.shared.frontmostApplication else {
print("No frontmost application found")
return false
}
// Create an accessibility object for the frontmost application
let appElement = AXUIElementCreateApplication(frontApp.processIdentifier)
// Get the focused UI element
var focusedElement: AnyObject?
let result = AXUIElementCopyAttributeValue(appElement, kAXFocusedUIElementAttribute as CFString, &focusedElement)
guard result == .success, let element = focusedElement else {
print("No focused element or error: \(result.rawValue)")
return false
}
// Get the role of the focused element
var role: AnyObject?
AXUIElementCopyAttributeValue(element as! AXUIElement, kAXRoleAttribute as CFString, &role)
// Check if the role is a text field or text area
if let roleString = role as? String {
if roleString == kAXTextFieldRole || roleString == kAXTextAreaRole {
print("A text field is in focus")
return true
} else {
print("No text field is in focus")
return false
}
}
return false
}
// Example usage
if isTextFieldInFocus() {
// Text field is in focus, do nothing or handle accordingly
print("Text field active, continuing normal behavior")
} else {
// No text field is in focus, enact different behavior
print("No text field active, performing alternative behavior")
// Add your alternative behavior here, e.g., trigger a system action
}
Many users who use KM also use BTT. I would even highly recommend it, because the two apps complement each other well.
In any case, BTT recognizes fields without any problem. If necessary, the “main field” and the “secondary field”. It is simply a condition. I use this mainly for text strings that should only work in a certain text field.
I use this every day and can confirm that BTT does an excellent job. So, if you absolutely need it, then do it with BTT.
For example, this only works in the Devonthink search field. When I type “tt” something is triggered. If “tt” were triggered in every text field, it would of course be useless. This way, very specific needs can be satisfied 
As I said, my solution is app-dependent, and you didn't say which apps you needed this to work with.
Then why not use KM's action to execute Swift code? That's a wonderful solution. If you can make it work, many people will be happy.
1 Like
There is, unfortunately, no reliable way I have found to determine that.
In my tests using Accessibility focussed elements, it does not work reliably across applications.
3 Likes
It exists for the application. And most (all?) apps don't provide a way for another process to ask for that information.
The script you gave is using Accessibility, which isn't well supported by many apps.
The two most reliable ways to do what you want are @Frankb's suggestion of leveraging Better Touch Tool (which seems to be using some special sauce for apps where Accessibility isn't supported) or @Airy's of checking menu item availability -- you aren't limited to only one item so you can usually find a combination of items that work for a particular app.
2 Likes
And just so that this is not forgotten.
When it comes to using a letter (without modifiers) for two functions, short/long press is always a valid option.
"a" pressed short is an "a". And "a" pressed longer triggers something else.
Then it doesn't matter which field the cursor is in. You can even trigger "something else" in a text field. Just saying 