Jump to content

Custom keyboard layouts not supported?

Recommended Posts

  • 1 month later...
  • 7 months later...

@Jakub Sypiański Could you start by providing more insight into what your setup is and what specifically isn't working, as your current report is very vague? E.g. are you exclusively working in that keyboard layout or are you switching around between multiple layouts? 


If your keyboard layout is always set to Bepo, and you set your hotkeys to a particular combo, the keycode will be set to the physical keys combination. Unless there's something completely different in the way that keyboard layout works compared to other ones, this should work as expected. If you switch keyboard layouts frequently, however, you'll need to press the same key locations, rather than the same letters (e.g. Cmd + 4th key from the left, rather than Cmd + E).


As you observed, this isn't an issue that's been raised by anyone else to date, but if you provide more details, we might be able to point you in the right direction to get the results you want. :)







Link to post

Thank you! I'll try to do my best.

It's the snippets that don't work with Bépo. They work correctly with Dvorak and Qwerty. In case of Bépo the keyword does disappear, but the snippet doesn't reappear.

Keyboard shortcuts in workflows work correctly and according to the Bépo layout.

What further information can I provide you with?

Edited by Jakub Sypiański
Link to post

I don't know how Alfred works internally, so I may be wide of the mark here, but I suspect it's because the V key isn't where it normally is. Dvorak puts ⌘V on the same key as on a QWERTY keyboard (even though V is on a different key), so a simulated keypress still works as expected (which according to the linked post is the only way to trigger a clipboard paste).


Although @Andrew changed the behaviour of Hotkeys to properly track keyboard layout changes in Alfred 4, it's possible he didn't do the same when it comes to simulating paste via ⌘V. (Again, this is an educated guess).


Also, could you not format your comments in weird ways? It's quite distracting.

Link to post

Thank you for your comments, it makes sense. However, I use Bépo–⌘Qwery, so ⌘V is exactly where it should be (even though V is on a different key). It works for normal copy-paste and it works as expected. The only problem is with Alfred's snippets. I need each time to temporarily switch the layout, get the snippet and revert to Bépo...


In the "Dvorak ⌘Qwerty" layout everything works as expected, including the snippets.


Let's see what the team say.


(As for the formatting, I have no idea why my comments appeared formatted initially.)

Edited by Jakub Sypiański
Link to post

Alfred should discover the correct combos / key codes per keyboard layout used. I've just tested with a few obscure built-in Apple layouts with Alfred's internal logging running and Alfred adapts accordingly.


There is a chance that being a custom layout, Bépo may have an underlying mapping issue. We also can't discount that Apple's custom keyboard layout handling could be iffy.




Link to post
  • 3 weeks later...

The conclusion from two weeks of using several custom keyboard layouts extensively: Alfred is not compatible with copying. I need to switch to one of the layouts provided by Apple to do anything that involves Alfred.


It seems that is the problem is that Alfred tries to use ⌘c shortcut while copying, but uses instead the qwerty letter that originally lies in the place where C is in the given layout. 


Here is how i figured it out.


Things that not work with with custom layouts are snippets, while snippet menu and clipboard menus copy to clipboard instead of pasting to the frontmost app. Nothing interesting here. What seems crucial is that keyboard shortcut that involve text selection behave strangely.


With customised Dvorak:

a) in apps that support any action involving ⌘i, they perform that action (most often italicising the word selected) and then they open Alfred window. But instead of seeing a prefix (from the workflow) and the previously selected word, see only the prefix. This happens independent of the original keyboard shortcut for the workflow.

b) in an app that does not support any ⌘i shortcuts, these workflows act as expected


In Dvorak the letter "i" is at the place of qwerty's "g",  and in place of qwerty's "i" we have "c". So my idea is that instead of ⌘c, Alfred sends ⌘i. To confirm this, I tried bépo. Here "c" is at the place of qwerty's "h". And indeed when I try mapped a random action in my browser to ⌘h and tried to used a keyboard shortcut with text selection with bépo, this action was performed (and Alfred window opened with the prefix but no text). 


I'd gladly help with any logs that you'd need and do anything you need in order to help you resolve this.


PS Naturally I tried forcing Alfred in the settings to always use one of the standards layout, but it didn't help. 

Edited by Jakub Sypiański
Forgot something.
Link to post
6 hours ago, Jakub Sypiański said:

It seems that is the problem is that Alfred tries to use ⌘c shortcut while copying, but uses instead the qwerty letter that originally lies in the place where C is in the given layout.


That sounds about right. Alfred uses keycodes under the hood (at least for user-set Hotkeys, so likely also for its own), and keycodes map to physical keys, not the letters on them.


Presumably, this is very common behaviour, and Apple's own keyboard layouts have extra smarts for dealing with this situation.

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...