I've implemented something like Cocoa Keyboard Shortcuts in Dialog without an Edit Menu for an LSUIElement application. In fact, to try to make sure I was not missing some obscure standard keybinding that I might forget to include, I just grabbed a standard "edit" menu and loaded it out of a nib file and then used my NSApplication subclass's sendEvent: to invoke its performKeyEquivalent: . This works as I expect.
However, the character palette (or "emoji picker", or "Emoji & Symbols") is not explicitly in this menu, so when I hit the hotkey (⌘⌃Space) nothing happens. Examining the objects, this is what I expect. However, when I hit this hotkey in a normal application, I see the Edit menu flash as if that's where the key's defined, even if it isn't. Stranger still, 🌐 still works even though the control-command-space one doesn't.
Where is this keyboard shortcut supposed to be handled? I don't want to do anything particularly custom here, I'd just like to correctly set up the default text-editing behavior that other apps get.
Related
I use Cmd-. (Command-Period) as a common hotkey in my IDEs (go to definition), but recently the IDEA/JetBrains IDEs have started to re-interpret this key combination as the escape key. I can't figure out what exactly changed on my system to make this start happening. There was probably an OSX update or two which happened between the last time it worked and when I noticed the new behavior.
In the IDEA keymap menus, when I hit Cmd-. in the search-by-key dialog, it inserts the Esc glyph, the the behavior of the rest of the app seems to follow suit, it's just acting like Esc.
This issue seems to be specific to the IDEA-based apps. It reproduces in PyCharm, GoLand, and Android Studio. Cmd-. still works as expected in iTerm2, Cocoa Emacs, and the OSX system shortcut settings window.
Any idea of how I can bring back Cmd-., or at least interpret it as something other than Esc?
Unfortunately, there's no way to stop interpreting Cmd-. as Esc. However, as a workaround, you can try assigning the shortcut in a keymap XML file.
It may help in some cases, e.g. it works for opening tool windows, but it doesn’t work with Find in Path because sometimes the dialog gets closed (both meta . and Esc are invoked).
In Preferences | Keymap, set some shortcut to the desired action, and exit IDE
Open settings directory: https://intellij-support.jetbrains.com/hc/en-us/articles/206544519
Open a keymap XML file under "keymap" directory
Find the action changed in step 1, and change the "first-keystroke" parameter of the "keyboard-shortcut" node to "meta period". So it will look like:
<keyboard-shortcut first-keystroke="meta period" />
I want to add custom actions to every window's title bar context menu. The goal is to add an option like in the task view where you can move a window to a different virtual desktop. I was able to do this with hotkeys using GlobalHotKey and WindowsDesktop packages in C#. But I want to do it in the UI as well similar to some Linux desktop environments.
I know you cannot normally do this with the registry like you can with other context menus. When creating your own application I know you can use GetSystemMenu, AppendMenu, etc. and override WndProc to handle it. But this obviously will not work for what I am intending.
The application Moo0 Window Menu Plus achieves the desired effect but I have no idea how they do it.
I have a feeling the solution is probably somewhat hacky but I would still like to know how it could be done. I am open to using any language to achieve this.
You need to inject into the process, that is the only way to add a menu item.
A shell hook will notify you with HSHELL_WINDOWCREATED when a appropriate window has been created. You can then inject into the process (with another hook type or CreateRemoteThread). Once you have your .DLL in the process you can subclass the window and change the system menu.
You need to create both a 32-bit and 64-bit injection .DLL and I would recommend that you write it in native code, not C#.
Any solutions out there for dealing with google script code-editor turning "forward delete" into a "kill line" binding? I'm used to the hidden cocoa/emacs derived navigation keys. Google decided to mess with control-d.
Clarifications:
This occurs when using the code editor. (edit-view?)
I would rather stop the google behavior than cope with it.
To understand more how fluid the control-key navigation can be
(and therefore how annoying when missing), try this...
set caps-lock to be the control key
open a cocoa browser like Safari and
start a script at https://script.google.com/
switch briefly to address bar
hit ctrl+a (goes to start of line)
hit ctrl+d (characters get deleted 1 at a time)
hit escape
switch to script area and try same thing (whole lines get munched!)
If you mean while you're working on your program in that editor, press the forward-delete key. On Apple's laptops and wireless keyboard, it's fn-delete (where by “delete”, I mean the backward delete, the key that is a.k.a. “backspace”).
You could try KeyRemap4Macbook.
Today I noticed that this problem no longer exists. So when editing a script file in the macro editor, emacs shortcuts WORK as expected. I cannot tell if they simply removed a bug or override, or actually patched it to work.
I am trying to make our application properly handle international input. Since we handle text input and font rendering ourselves, I wrote custom code to handle the respective WM_IME_* messages.
Now, this all works fine, with one exception: When our applications main window is open, the Language Bar will not let me pick any options. I can set the input language to Japanese or Korean, but the menus for choosing the input methods (like Hangul or Hiragana) are not shown. Then, when I open another window (any other window, be it one of our application windows, or a standard "save file" dialog), the options appear. Once there, they will stay, even if I close the other window. IME input will then work as expected in the main window. But, as explained, only if I open another window first.
Now, how does windows decide whether it should display the input method options or not? It appears that windows does not recognize our main window as Unicode capable for some reason. How can I fix that?
Thanks in advance for any suggestions,
jonas
Edit: One more strange thing i noticed is that for my main window (which will not let me change input methods), I will get a WM_INPUTLANGUAGECHANGEREQUEST message when i change the input language - which I pass on to DefaultWindowProcW. For the windows which let me change the input method, i don't get the request, i just get a WM_INPUTLANGUAGECHANGE message (which I don't get for the other window).
Ok, after a long search I've been able to find out what is breaking this. We are calling SetFocus on a child window in response to WM_FOCUS messages, so that a specific child window always gets focused when a window is brought to the front. Apparently, this confuses window's IME code, and makes it unaware that the window can handle IME input.
Some notes
Text Service is works per window, not system wide, so even its turn on in one window, another window will still need to turn it on, (unless user set it as default)
And Text Service is not working in any windows, to enable that, target computer need to enable following setting on
I'm building some code completion style text expansion functionality for text areas and inputs in a web application. I'm trying to work out a safe keyboard shortcut for invoking the completion proposals for browsers running on Mac OS X.
I've eliminated some potential candidates:
Command + Space - activates the Spotlight search field
Control + Space - activates the context menu in Firefox
Esc - cancels any background XMLHttpRequests in Firefox
That leaves Option + Space. I'm aware that may conflict with tools like Ubiquity, but that's something we don't expect our audience to be using.
Are there any conflicts I may have missed with Option+Space? Or do you have a better idea for a keyboard shortcut, and why?
A lot of Mac OS X apps use Option + Esc to do code completion or code hints.
Some kind of tab shortcut sounds like the best and most intuitive approach - users should be used to the 'type-tab-type-tab' workflow - maybe combine it with a modifier if it only wants to be optional.
As I recall, Visual Studio and TextMate both use tab to code-complete. In Visual Studio an intellisense menu pops up as you start typing and tab acts as the selection confirmation.
In TextMate, you start typing part of a command then hit tab to activate said command's associated "bundle". The associated bundle typically generates a code snippet and fills in any dynamic parts of the snippet as you type.
Come to think of it, most command lines work this way as well, auto-completing file names and paths when tab is pressed after typing a few characters.
EDIT: You say tabs are needed for field switching in a web interface, but you may want to try intercepting the keyboard event in the textfield, and check if they're started typing a macro. If they have, auto-complete and swallow the key by returning false; if not, simply let the command bubble through.
I discussed these ideas with our design team. One of them suggested using Control + Enter, which is what we decided to go with. This causes forms that only contain a single input field to automatically submit in Firefox, but we deal with that by preventing the default action caused by the event.
I re-assigned the Spotlight command to Command + Shift + Space. This is easily done via Prefrences.App