Jump to content
Jakub Sypiański

Custom keyboard layouts not supported?

Recommended Posts

This is a huge problem for me. I understand that you are not going to leave everything and start working on an issue that seems to affect only me. But maybe you have some clues or hypotheses at least? Is there something I can check? Please let me know if you read this.

Share this post


Link to post

@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. :)

 

Cheers,
Vero

 

 

 

 

Share this post


Link to post
Posted (edited)

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

Share this post


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.

Share this post


Link to post
Posted (edited)

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

Share this post


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.

 

Cheers,

Andrew

Share this post


Link to post

Thank you for looking to that. I too have the impression that the problem lies in the fact that this is a custom layout. I'll try other custom layouts when I'll have a free moment.

Share this post


Link to post
Posted (edited)

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.

Share this post


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.

Share this post


Link to post

Alfred fully relies on standard Apple APIs to obtain the key code / key mappings which are used when simulating key combinations.

 

I've added a ticket to look into this more deeply, but I can't promise any timescales as this is the first time it's come up and it has to be treated as a corner case.

 

Cheers,

Andrew

Share this post


Link to post

I would really appreciate that. It is a pain to use Alfred with a custom keyboard, I need to switch to qwerty every time I need to do something involving Alfred... I love Alfred and I'm a mega supporter, but this is really a big bump for me.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...