This only applies to people using PopClip with the “Dvorak - QWERTY ⌘” keyboard layout, so I wouldn’t expect it to be a high priority. Also, I wonder if it might be down to Apple and can’t be fixed, but here goes…
If I select the default “Copy” popup option in PopClip while using Safari, the macOS Mail client opens and creates a new email with the webpage, it doesn’t Copy.
The “Dvorak - QWERTY ⌘” layout, part of macOS, is a sort of hybrid input that sends the normal QWERTY keys when function keys are used. What seems to be happening is that when I use the “Copy” button it’s activating the “Email This Page” command, which is on ⌘I. Pressing the I key when using Dvorak gives C. So it’s as if something is mapping the Copy popup button back to ⌘I on keyboard, and then activating that command instead.
I haven’t as far as I know had anything like this using any other app with the keyboard layout. I think it only applies to Safari, too. Copy works in other apps, so it’s not sending ⌘I everywhere.
[By the way - and this part is completely a macOS irritation, nothing to do with PopClip - I’d turn this keyboard command off as a workaround if I could, but I can’t seem to do this because the usual way to remap a keyboard shortcut needs a menu command to work, and the “Email This Page” isn’t in any Safari menus (it’s on the Share button and the keyboard shortcut only).]
An interesting one. This rang a bell and sure enough, I know issues with this keyboard layout were reported in the distant past, and at one point I got it working (see relnotes from PopClip 1.3… ) but I haven’t had to touch anything anything to do with the keyboard layouts since that time. So, I guess something has changed. I’ll make a note to dig deep into the code to figure out what is going on!
When using a regular DVORAK keyboard, PopClip correctly detects it and presses the right key codes for that layout.
But when using the “QWERTY ⌘” variant, PopClip has to press the QWERTY version of the key because it’s pressing it with ⌘. This doesn’t happen automatically, so PopClip needs to adjust specially.
PopClip checks for this keyboard layout by looking at the keyboard layout name:
- (NSNumber *)keyCodeForChar:(NSString *)character
{
if ([[self.keyboardLayoutName lowercaseString] isEqualToString:@"dvorak - qwerty ⌘"]) {
if ([character isEqualToString:@"X"]) {
return @7;
}
else if ([character isEqualToString:@"C"]) {
return @8;
}
else if ([character isEqualToString:@"V"]) {
return @9;
}
}
NSNumber *result=_charToKeyCode[character];
NMLogFine(@"got %@ for char %@ from dict", result, character);
return result;
}
For years, it worked, but now it doesn’t. The reason? Apple changed the dash in the layout name from a hyphen - (ASCII/UTF-8 2D) to an en dash – (UTF-8 bytes E28093). So the string match broke.
I’ll roll out a beta soon with a fix; however, I’m deep in some other changes at the moment so I won’t be able to do it for a bit.
One of the interesting things about making an app — especially one that integrates closely with the system and with other apps and services — is that I get to learn about all the niche and unusual apps and configurations people use. If PopClip breaks it, I usually find out eventually.
) but I haven’t had to touch anything anything to do with the keyboard layouts since that time. So, I guess something has changed. I’ll make a note to dig deep into the code to figure out what is going on!