Re: French keyboard layout with Euro symbol
I sent a patch that looks like yours and it was simply refused ! I wasn't the fisrt...
<RemiAssailly(a)aol.com> wrote:
I sent a patch that looks like yours and it was simply refused ! I wasn't the fisrt...
Because there were no explanations provided except that warning message. If keyboard input works for you, there is no need to send a patch. -- Dmitry.
Because there were no explanations provided except that warning message. If keyboard input works for you, there is no need to send a patch. Dmitry,
To give the subject a second life : My French keyboard works without problems today in Wine, and Wine refuses to detect it, giving tons of keyboard mismatches when enabling +key,+keyboard. As a result, I put a comment into dlls/x11drv/keyboard.c to avoid it. If you have an idea how to track and fix it, Im okay to reenable it and do all tests needed. ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
"Sylvain Petreolle" <spetreolle(a)yahoo.fr> wrote:
To give the subject a second life : My French keyboard works without problems today in Wine, and Wine refuses to detect it, giving tons of keyboard mismatches when enabling +key,+keyboard.
As a result, I put a comment into dlls/x11drv/keyboard.c to avoid it.
If you have an idea how to track and fix it, Im okay to reenable it and do all tests needed.
As it was said already, we will need at some point to comment out that FIXME in keyboard.c. If the keyboard input works for you, then I don't see what needs to be fixed. -- Dmitry.
At least, the detection mismatches should be fixed/explained IMHO.
As it was said already, we will need at some point to comment out that FIXME in keyboard.c. If the keyboard input works for you, then I don't see what needs to be fixed.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
"Sylvain Petreolle" <spetreolle(a)yahoo.fr> wrote:
At least, the detection mismatches should be fixed/explained IMHO.
I think that this topic was explained many times already. Anyway, here is yet another attempt. 1. Keyboard detection code was introduced in order to make some picky DOS games (expecting key presses to have fixed scan codes) work with different X keyboard layouts. Since win32 apps do not depend on it that's not a problem at all for them. 2. Another problem was that each keyboard layout in x11drv had its own code page for X event to unicode translations. That's now solved as well by introducing CP_UNIXCP support. Once the underlying system has a correctly configured locale, keyboard input in Wine (as well as a general locale support) should work just fine. 3. Another (existing) problem is that each keyboard layout still has a virtual keyboard map attached to it. It's unavoidable and needed for correct support for QWERTY/AZERTY/etc. keyboard layouts, when some applications really depend on it. 4. And the last problem I'm aware of is that we need to revamp the keyboard detection code to fill the real keyboard map first, and only then create keyc2vkey array depending on the real mapping, not a hardcoded one. That's a minor problem, which I discovered recently while debugging one of my supported apps. -- Dmitry.
Dmitry Timoshkov wrote:
"Sylvain Petreolle" <spetreolle(a)yahoo.fr> wrote:
At least, the detection mismatches should be fixed/explained IMHO.
I think that this topic was explained many times already. Anyway, here is yet another attempt.
1. Keyboard detection code was introduced in order to make some picky DOS games (expecting key presses to have fixed scan codes) work with different X keyboard layouts. Since win32 apps do not depend on it that's not a problem at all for them.
2. Another problem was that each keyboard layout in x11drv had its own code page for X event to unicode translations. That's now solved as well by introducing CP_UNIXCP support. Once the underlying system has a correctly configured locale, keyboard input in Wine (as well as a general locale support) should work just fine.
3. Another (existing) problem is that each keyboard layout still has a virtual keyboard map attached to it. It's unavoidable and needed for correct support for QWERTY/AZERTY/etc. keyboard layouts, when some applications really depend on it.
4. And the last problem I'm aware of is that we need to revamp the keyboard detection code to fill the real keyboard map first, and only then create keyc2vkey array depending on the real mapping, not a hardcoded one. That's a minor problem, which I discovered recently while debugging one of my supported apps.
5. In the future, windows keyboard language APIs will need to be handled. For those to work, we must be aware of which is the current keyboard. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
5. In the future, windows keyboard language APIs will need to be handled. For those to work, we must be aware of which is the current keyboard.
This one is just a missing functionality (support for keyboard layouts), and has nothing to do with detection mismatches IMO. -- Dmitry.
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
5. In the future, windows keyboard language APIs will need to be handled. For those to work, we must be aware of which is the current keyboard.
This one is just a missing functionality (support for keyboard layouts), and has nothing to do with detection mismatches IMO.
The reason I listed it here is because in order for Wine to know what language the current keyboard is, it will also need to know what's the current keyboard. I have thought of two ways for Wine to do that - either it checks what name the symbol files is loaded as, or it scans the keymap (as it does today). Either way - it will have to have some mapping between currently loaded keymap and language. Hence the affect it has over X keyboard detection. I would appretiate it if you tell me if you think this logic is wrong. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
The reason I listed it here is because in order for Wine to know what language the current keyboard is, it will also need to know what's the current keyboard.
I have thought of two ways for Wine to do that - either it checks what name the symbol files is loaded as, or it scans the keymap (as it does today). Either way - it will have to have some mapping between currently loaded keymap and language. Hence the affect it has over X keyboard detection.
I would appretiate it if you tell me if you think this logic is wrong.
I see nothing wrong with your logic after that explanation. Yes, we do really want to know the language of the current X keyboard layout, but unfortunately I don't know a way to query this information from X, and all we have now is only the current layout detection scheme with LCID attached to each layout. -- Dmitry.
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
The reason I listed it here is because in order for Wine to know what language the current keyboard is, it will also need to know what's the current keyboard.
I have thought of two ways for Wine to do that - either it checks what name the symbol files is loaded as, or it scans the keymap (as it does today). Either way - it will have to have some mapping between currently loaded keymap and language. Hence the affect it has over X keyboard detection.
I would appretiate it if you tell me if you think this logic is wrong.
I see nothing wrong with your logic after that explanation. Yes, we do really want to know the language of the current X keyboard layout, but unfortunately I don't know a way to query this information from X, and all we have now is only the current layout detection scheme with LCID attached to each layout.
I was thinking of one of two options. Unfortunetly, both require us to know each keyboard layout we support (though, not necessarily know exactly). 1. Use the current scheme. LCID is all we really need, IIRC. 2. Use the XKB name 2 will mean that we reduce the keyboard source to a table of names, and their respective language IDs. I.e - "us" means English, "fr" means French, "he" means Hebrew etc. This will probably make adding new keyboard easier (and less error prone), but will ONLY work on XKB. Then again, keyboard selection (also part of the currently missing APIs) will only work on XKB anyways, so wer'e probably going to have to soft-depend on XKB whatever we do. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
participants (4)
-
Dmitry Timoshkov -
RemiAssailly＠aol.com -
Shachar Shemesh -
Sylvain Petreolle