When two keymaps are configured on the system and the current isn't the first one Blender use both #48911

New Issue

Nicolas · 2016-07-20T19:45:37+02:00

Nicolas commented

2016-07-20 19:45:37 +02:00

System Information
KDE neon User Edition 5.7 (based on Ubuntu 16.04 xenial) x64

Blender Version
Broken: 2.77a

Short description of error
I have two keymaps configured on my system (x11 keymaps). The first one is bépo (french dvorak) and the second one qwerty. When qwerty is active Blender handles hotkeys for both keymaps. For example pressing the T key opens the tool shelf, but pressing J (which is the T key on bépo) also open the tool shelf. Same behavior is observed for other hotkeys.

Behavior is not observed if bépo is the active keymap. Actually behavior is not observed if the active keymap is the first one in the keymap list.

Exact steps for others to reproduce the error

Configure two keymaps on the system (using the control panel provided by your desktop environment, I only tested with KDE).
Enable the second keymap.
Start Blender.
Press T key -> tool shelf opens (expected).
Press the key that is T on the first keymap -> tool shelf also open (not expected).

**System Information** KDE neon User Edition 5.7 (based on Ubuntu 16.04 xenial) x64 **Blender Version** Broken: 2.77a **Short description of error** I have two keymaps configured on my system (x11 keymaps). The first one is bépo (french dvorak) and the second one qwerty. When qwerty is active Blender handles hotkeys for both keymaps. For example pressing the T key opens the tool shelf, but pressing J (which is the T key on bépo) also open the tool shelf. Same behavior is observed for other hotkeys. Behavior is not observed if bépo is the active keymap. Actually behavior is not observed if the active keymap is the first one in the keymap list. **Exact steps for others to reproduce the error** - Configure two keymaps on the system (using the control panel provided by your desktop environment, I only tested with KDE). - Enable the second keymap. - Start Blender. - Press T key -> tool shelf opens (expected). - Press the key that is T on the first keymap -> tool shelf also open (not expected).

Nicolas commented

2016-07-20 19:45:37 +02:00

Changed status to: 'Open'

Nicolas commented

2016-07-20 19:45:37 +02:00

Added subscriber: @MadWatch

blender-admin commented

2016-07-20 19:45:37 +02:00

#48847 was marked as duplicate of this issue

Bastien Montagne commented

2016-07-21 17:29:11 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2016-07-21 17:29:11 +02:00

This likely the same issue as #47228, please try the latest build from our buildbot, should be fixed there (hopefully :| ).

This likely the same issue as #47228, please try the latest build from [our buildbot](https://builder.blender.org/download), should be fixed there (hopefully :| ).

Nicolas commented

2016-07-22 13:46:28 +02:00

In #48911#382704, @mont29 wrote:
This likely the same issue as #47228, please try the latest build from our buildbot, should be fixed there (hopefully :| ).

I tried 2.77-08e1bba. Issue is not fixed.

> In #48911#382704, @mont29 wrote: > This likely the same issue as #47228, please try the latest build from [our buildbot](https://builder.blender.org/download), should be fixed there (hopefully :| ). I tried 2.77-08e1bba. Issue is not fixed.

Bastien Montagne self-assigned this 2016-09-02 10:36:14 +02:00

Bastien Montagne commented

2016-09-02 10:36:14 +02:00

Yeah… in fact you are right, #47228 was for non-latin keyboards, in that case (since native first layout generates no valid X11 keytype), we can fallback to getting string value of key and convert it to our Blender event type.

But if getting keytype returns a valid value, then we stick to XLookupKeysym value for event type - and that X11 function always uses first defined keyboard layout for some mysterious reasons :(

We can try some other ways around (like, using XLookupString with only exception of main number keys to handle layers switching correctly)… But would wait for after 2.78 now, this is too risky at this stage of release cycle.

Yeah… in fact you are right, #47228 was for non-latin keyboards, in that case (since native first layout generates no valid X11 keytype), we can fallback to getting *string* value of key and convert it to our Blender event type. But if getting keytype returns a valid value, then we stick to `XLookupKeysym` value for event type - and that X11 function always uses first defined keyboard layout for some mysterious reasons :( We can try some other ways around (like, using XLookupString with only exception of main number keys to handle layers switching correctly)… But would wait for after 2.78 now, this is too risky at this stage of release cycle.

Bastien Montagne commented

2016-09-02 16:27:45 +02:00

Added subscriber: @jefrau