When using the emoji widget, I find that it works fine in apps like WeChat and Final Cut Pro, but most other apps don't accept the input. Web browsers, messages, etc don't accept the input. For example, in this post. If I tap an emoji, it highlights on the touch bar but doesn't input it. Anyone know why?
Mh, seems to work fine here. What kind of keyboard layout are you using? Which version of BTT?
Innnnnnnnteresting, that was the problem but it doesn't really make sense to me why. I use the Dvorak-Qwerty layout. The one where typing is Dvorak and keyborad shortcuts are Qwerty. It works fine in all apps if I have the standard US layout on, and only works in some apps if I have Dvorak-Qwerty on.
Any idea why this would be the case? I would think it would either work in all apps or none.
I have only recently made the paste action keyboard layout agnostic. Could you try the latest alpha?
It says "BetterTouchTool 3.167 is currently the newest version available." Is there a later version?
That should be the latest one. Mhh then there might still be a problem with retrieving the correct key position for your v key. I'll try to reproduce this with Dvorak Qwerty tomorrow!
It's interesting because if I tap the emoji I want and then press Command-V it pastes the correct emoji. I think there is a bug in MacOS's handling of the Dvorak-Qwerty layout. In my browser, if I press Command-V, it pastes correctly as it should. But in BTT if I press Command-V, it comes out as Command-K. So I added a trigger to the emoji widget to keyboard shortcut Command-K and now in my browser it pastes properly even though the correct shortcut should be Command-V.
This has been a significant problem for me for a while because ever since MacOS High Sierra, the handling of this layout has started to change application to application. If you are able to figure out what's causing this issue, I would be so thankful. But I don't think this is BTT's fault, so I don't think you'll be able to fix it.
Thanks for the quick reply!
I'm pretty sure it's a BTT issue. However being keyboard layout agnostic is really complicated on macOS, so I wouldn't be surprised if other apps also contain that bugl
I would think Apple of all developers would be able to get it right! Safari behaves properly, Final Cut Pro does not. This is a source of endless frustration for me, especially because it used to work properly and now it doesn't.
If you do figure out what the problem is, could you let me know? I've reported this over the phone and screenshare to Apple on several occasions and they can't seem to figure it out. I would love to get it fixed!
The underlying problem is that macOS by default only gives you the physical location of a key, denoted by a key code. So for example v is 9 on QWERTY (and most other layouts), but some different number on Dvorak. Apps that use the basic APIs for shortcut handling will work fine because these high level APIs handle everything automatically, however apps that do custom stuff like BTT (and probably Final Cut), need to make sure they always translate the key correctly. Therefore these apps must look up (via some complicated and barely documented APIs), which key code belongs to a specific letter for the current keyboard layout and keyboard type.
Innnnnnnteresting. That explains a lot. I just got off the phone with Final Cut support and they apparently brought the problem up to the engineering department when I contacted them about a year ago, and they still haven't been able to figure it out. Then for some reason we lost communication. So now the issue has been reinstated and they're working on it again. Hopefully they realize it's an issue and reach out to the MacOS department to update the API, making your job easier! They're supposed to get back to me on the issue in a few days, so if they give me any helpful information, I'll update you.