e Alt-Shift to switch layouts, so the real problem is not
related to Alt interpretation of Cmd, but to incorrect emulation of
Windows behaviour when a keyboard layout switch hotkey is pressed.
On the other hand, Option is labeled as Alt, and works this way with
the X11 driver, so it seems logical
On Oct 9, 2013, at 4:49 PM, Phil Krylov wrote:
> Thanks!
You're welcome.
> Do you consider adding an option to stop interpreting Command as Alt?
I have not considered it. What would be gained? Do you want the Command key
interpreted as the Windows key? Do you want something else to happen w
Thanks! Do you consider adding an option to stop interpreting Command as Alt?
On Thu, Oct 10, 2013 at 1:30 AM, Ken Thomases wrote:
> ---
> dlls/winemac.drv/cocoa_window.m | 22 --
> dlls/winemac.drv/macdrv_cocoa.h |2 ++
> dlls/winemac.drv/macdrv_main.c |7 +++
> 3
et\Control\VMM32Files,,,""
HKCU,Software\Microsoft\Protected Storage System Provider,,,""
HKCU,Software\Wine\MSHTML,"GeckoUrl",,"http://source.winehq.org/winegecko.php";
+HKCU,Keyboard Layout\Preload,,,""
This should be done somewhere in the keyboard layout code, not in
wine.inf.
\MSHTML,"GeckoUrl",,"http://source.winehq.org/winegecko.php";
> +HKCU,Keyboard Layout\Preload,,,""
This should be done somewhere in the keyboard layout code, not in
wine.inf.
--
Alexandre Julliard
julli...@winehq.org
Altan Íz³dogru wrote:
My computer works with Linux 8.2. I have tried to install (to execute) a
Windows Program on my Computer. The wine-program started and
the windows sreen appeared. Suddenly the programm stopped and I
got the message:
Your keyboard layout was not found
My computer works with Linux 8.2. I have tried to install (to execute) a
Windows Program on my Computer. The wine-program started and
the windows sreen appeared. Suddenly the programm stopped and I
got the message:
Your keyboard layout was not found!
Using closest
uébec only carries them.
Besides, it's only a patch, someone already did the dirty work of making
the XFree86 symbol file, plus the console layout for iso-8859-1, plus
the utf-8 console layout, plus the Wine layout ;-)
> > I added the proper keyboard layout, and, apart from the fact th
Le sam 04/12/2004 à 11:15, Jean-Michel Dault a écrit :
> Le sam 04/12/2004 à 07:20, Dmitry Timoshkov a écrit :
> > "Jean-Michel Dault" <[EMAIL PROTECTED]> wrote:
> > > I'm doing a pilot project for the Quebec government, and we have one
> > > m
Please use this new patch instead.
There were a few mismatches in my previous patch, I tweaked it a bit,
and now I get a perfect score of 127.
trace:keyboard:X11DRV_KEYBOARD_DetectLayout Attempting to match against
"Canadian CAN/CSA-Z243.200-92 keyboard l
Le sam 04/12/2004 à 07:20, Dmitry Timoshkov a écrit :
> "Jean-Michel Dault" <[EMAIL PROTECTED]> wrote:
> > I'm doing a pilot project for the Quebec government, and we have one
> > major problem: they have a keyboard layout that's unsupported by Wine,
&g
"Jean-Michel Dault" <[EMAIL PROTECTED]> wrote:
> I'm doing a pilot project for the Quebec government, and we have one
> major problem: they have a keyboard layout that's unsupported by Wine,
> though it was commited to XFree about 3 years ago.
What do you mea
[this time to the list in order to mark this as answered]
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> XFree 4.3 would do about this. setxkbmap il would only give Israeli
> keyboard layout. In order to get the current behaviour, one would have
> to do "setxkbmap
nd "il" layouts.
#3 possibly is a most difficult step. At least I don't know how to do that
using standard approaches provided by XF86Config.
After that, MappingNotify should really do its work and make Wine to change
internal keyboard layouts and therefore HKL identifier.
XFree 4.3
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> The idea I had, for which I cannot state whether it's feasible or not,
> is to get the mapping from XKB, and prepare a list (group 0 - US, group
> 1 - IL, group 2 - RU). Then, whenever we get a "next group" or "prev
> group", just send out the prop
Dmitry Timoshkov wrote:
Hello,
note to Shachar:
this implementation doesn't really work due to "merged" keyboard
layouts we have. I.e. since we have Israelian keyboard layout
with both english and hebrew characters, after the MappingNotify
event we're still using the same
u 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
ate 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 onl
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> 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),
a
"Shachar Shemesh" <[EMAIL PROTECTED]> 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
uced 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 f
ome 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 translatio
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.
_
"Sylvain Petreolle" <[EMAIL PROTECTED]> 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/ke
> 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 keyb
<[EMAIL PROTECTED]> 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.
I sent a patch that looks like yours and it was simply refused ! I wasn't the fisrt...
Hi Jerome,
It seems your patch includes a currency sign '¤' instead of the Euro :
Altgr-E and Altgr-$ look the same (0xA4.)
Please use the unified format when sending patches.
=
Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net)
ICQ #170597259
Say NO to software patents
Dites
28 matches
Mail list logo
