nvUltra in background can steal shortcuts from foreground
Completed
**Version**: 1.0.0 (71)
# Reproduction
1. With any editable note in the foreground, press `⌘O` to open a new folder.
2. Press `⌘B` (I know, that wouldn't normally do anything in a file dialogue window, but this is a stock shortcut and I don't know if there are any collisions between what a file dialogue takes and is default in the menu system---I noticed it with a custom shortcut, `⇧⌘H`, which would normally navigate a file dialogue to Home).
In the background, you may need to move the non-modal dialogue around, you will note that asterisks have been inserted into the text.
I first noticed this happening with another program entirely (and like I say, with custom shortcuts, being driven by BetterTouchTool, no less), and so I dismissed it on account of how many unusual variables were involved, however since I can see it happening from within nvUltra itself it appears to be a broad problem---and hopefully fixes how LaunchBar can't really be used on top of nvUltra, once fixed. :)
Whenever any tool comes up that doesn't lock focus, like a modal dialogue, or is the type of software that doesn't switch which is active, then shortcuts which should go into the foreground receiver end up beign sent to nvUltra's topmost folder window.
-
Just for clarity, this is happening when running nvUltra with the Dock icon hidden?
0 -
The example you describe (with the open dialog) isn't really stealing shortcut. The shortcut is typed while nvUltra is active, it's just that the shortcut is being sent to the first object that responds to it (e.g the editor window), rather than "dying" at the open dialog that doesn't handle it. I'll look at this.
I would need to know more about your Launchbar issue, but I don't see how nvUltra could be "stealing" anything that should go to another application, with the sole exception of the global hotkey, where that behavior is expected.
0 -
I do have the option disabled to hide it from the Dock, so it is operating as a "normal" application in that regard...
But, with further experimentation, it does seem like BetterTouchTool might be the critical ingredient, rather than a tool like LaunchBar which kind of floats over other applications (like Spotlight might). It is interesting that a tool like that has some of the same properties as a file dialogue window does, but I think that's all there is of interest in that relationship. I have run additional tests, and reproduced the issue in TextEdit as well, by assigning the Font;Format;Outline menu command to ⇧⌘H, and then attempting to navigate to home while the Open dialogue is in the foreground. The selected text in the background is outlined, rather than the expected behaviour.
So my guess is it is an issue with how BTT uses the Accessibility system to route shortcut overrides, and maybe it's not even a problem in newer OS versions (still on 10.14.6), as while BTT is demonstrating the issue, that's surely an Apple bug where accessibility should ideally target the foreground key focus element.
There are some quirks with using BTT for keyboard overrides, and this is probably just one of them. I do like it for most things though since it tends to be more reliable at triggering dynamically generated menu commands and such, than System Preferences (never mind you can sync your custom shortcuts and back them up).
Thus this can be closed I think, unless you can think of a way around that!
0 -
I *think* that I can figure out how to disable some of the menu items when a text view is not open, but it is a lower priority as this will take some time to revisit responder chains and GUI validation for not a lot of payoff. There are other higher priority issues in front of the line....
But, as you note -- it it happens with TextEdit, then the general problem does not seem to lie with nvUltra but either with UI expectations or with BTT specifically.
0
Please sign in to leave a comment.
Comments
4 comments