FEST

Keyboard mappings depend also on OS, not only on locale

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: FEST-Swing 1.2a4
  • Fix Version/s: FEST-Swing 1.2rc
  • Component/s: Swing
  • Labels:
    None
  • Number of attachments :
    0

Description

Keyboard Mapping depend on the Locale and the OS, so for a particular language, it can have multiple keyboard mapping.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Alex Ruiz added a comment - - edited

Hi Olivier,

Mappings are now selected by OS and locale. How the mapping is selected:

  1. Try OS-Family + country + language: KeyStrokeMappingProvider_win_en_us
  2. Try OS-Family + language: KeyStrokeMappingProvider_win_en
  3. Try language: KeyStrokeMappingProvider_en

The picker will try one by one, if none if found it will load the default mappings for English.

I thought about doing the same for parsing files, not only loading mapping classes. What I thought is that parsing files is more of a "testing" activity, I mean testing that a mapping for a OS + locale is correct. Once the content of the file is correct, it can be converted to a mapping class, to avoid parsing during the execution of the test suite. WDYT?

Thanks!
-Alex

Show
Alex Ruiz added a comment - - edited Hi Olivier, Mappings are now selected by OS and locale. How the mapping is selected:
  1. Try OS-Family + country + language: KeyStrokeMappingProvider_win_en_us
  2. Try OS-Family + language: KeyStrokeMappingProvider_win_en
  3. Try language: KeyStrokeMappingProvider_en
The picker will try one by one, if none if found it will load the default mappings for English. I thought about doing the same for parsing files, not only loading mapping classes. What I thought is that parsing files is more of a "testing" activity, I mean testing that a mapping for a OS + locale is correct. Once the content of the file is correct, it can be converted to a mapping class, to avoid parsing during the execution of the test suite. WDYT? Thanks! -Alex
Hide
Permalink
Olivier DOREMIEUX added a comment -

Hi Alex,

Great!
Converting it to a class mean more work for you.
I think that the mechanism should be available at any time, it will help people that don't have the correct mapping yet.

This mapping could change depending how you solve FEST-320. Actually the mapping file can become much smaller.

Thanks,

Olivier

Show
Olivier DOREMIEUX added a comment - Hi Alex, Great! Converting it to a class mean more work for you. I think that the mechanism should be available at any time, it will help people that don't have the correct mapping yet. This mapping could change depending how you solve FEST-320. Actually the mapping file can become much smaller. Thanks, Olivier
Hide
Permalink
Alex Ruiz added a comment - - edited

Hi Olivier,

Yeah...it will be more work on my part, but so far I think it's worth it

I was thinking about FEST-320 a lot today. If we implement a mapping for VK codes we will end up with the following:

character 'a' -> VK_A -> VK_Q

this is going from the regular mapping to the VK mapping. I start to finding it confusing to have two sources of truth, plus adding support for VK mappings doesn't seem that trivial either. For example, if a character mapping is incorrect, we wouldn't know which mapping (regular or VK) is the incorrect one. I'd like to propose to just keep the regular, existing mapping:

character 'a' -> VK_Q

WDYT?

Thanks!
-Alex

Show
Alex Ruiz added a comment - - edited Hi Olivier, Yeah...it will be more work on my part, but so far I think it's worth it I was thinking about FEST-320 a lot today. If we implement a mapping for VK codes we will end up with the following: character 'a' -> VK_A -> VK_Q this is going from the regular mapping to the VK mapping. I start to finding it confusing to have two sources of truth, plus adding support for VK mappings doesn't seem that trivial either. For example, if a character mapping is incorrect, we wouldn't know which mapping (regular or VK) is the incorrect one. I'd like to propose to just keep the regular, existing mapping: character 'a' -> VK_Q WDYT? Thanks! -Alex
Hide
Permalink
Olivier DOREMIEUX added a comment -

Hi Alex,

Yes this issue is not easy.
The way I look at it. There are 2 mapping, since the english keyboard is the reference.
The first mapping is to convert from the English keyboard to the country/OS keyboard, it's a simple mapping telling only the difference between the reference and the country, VK_Q -> VK_A, ... . This would solve a lot of problem
The other mapping is for doesn't exist on the englisk keyboard like éèçà€ ....

So when sending some VK event is sent it needs to check if it needs to convert, if not use the default.
When a key is typed, it needs to check if the key is not on the reference keyboard, and then what key are used to access it.
Since I don't know in detail all your code, maybe I am missing some crucial issue or some special cases.

Thanks,

Olivier

Show
Olivier DOREMIEUX added a comment - Hi Alex, Yes this issue is not easy. The way I look at it. There are 2 mapping, since the english keyboard is the reference. The first mapping is to convert from the English keyboard to the country/OS keyboard, it's a simple mapping telling only the difference between the reference and the country, VK_Q -> VK_A, ... . This would solve a lot of problem The other mapping is for doesn't exist on the englisk keyboard like éèçà€ .... So when sending some VK event is sent it needs to check if it needs to convert, if not use the default. When a key is typed, it needs to check if the key is not on the reference keyboard, and then what key are used to access it. Since I don't know in detail all your code, maybe I am missing some crucial issue or some special cases. Thanks, Olivier

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.