Re: winex11.drv: Transmit WM_DEADCHAR messages to applications
Simon Lipp <sloonz(a)gmail.com> wrote:
+ * Moreover, let dead chars be processed or we will never have + * WM_DEADCHAR events
That's how it's supposed to work. Wine should never generate WM_DEADCHAR message, it relies in the driver to handle dead keys and generate final events. X11 even has an ability to support user defined key sequences which are handled by XFilterEvent and which will be broken by your patch. -- Dmitry.
That's how it's supposed to work.
But it doesn’t work that way under Windows. Shouldn’t Wine try to stick to Windows behavior as close as possible ?
Wine should never generate WM_DEADCHAR message, it relies in the driver to handle dead keys and generate final events.
I’m sorry but I fail to see any incompatibility between the two alternatives. Wine can generate WM_DEADCHAR messages AND let X/input method handle the real processing (and the generation of the final event) ; this patch never skip the XFilterEvent call, so it’s still up to your favorite IM to generate the final char from the keystrokes sequence.
X11 even has an ability to support user defined key sequences which are handled by XFilterEvent and which will be broken by your patch.
Are you speaking about XCompose or things like ibus ? Both still looks like OK with this patch (tested with wine’s notepad, ibus-anthy and XCompose keys from http://bepo.fr/).
On Apr 16, 2013, at 3:43 AM, Simon Lipp wrote:
That's how it's supposed to work.
But it doesn’t work that way under Windows. Shouldn’t Wine try to stick to Windows behavior as close as possible ?
Wine should never generate WM_DEADCHAR message, it relies in the driver to handle dead keys and generate final events.
I’m sorry but I fail to see any incompatibility between the two alternatives. Wine can generate WM_DEADCHAR messages AND let X/input method handle the real processing (and the generation of the final event) ; this patch never skip the XFilterEvent call, so it’s still up to your favorite IM to generate the final char from the keystrokes sequence.
For what it's worth, that agrees with my understanding, too. The Mac driver supports dead keys in the manner that Simon suggests. It generates WM_KEYDOWN for dead keys and returns -1 from ToUnicodeEx() for them, which causes TranslateMessage() to post WM_DEADCHAR. When a subsequent key completes the sequence, ToUnicodeEx() returns the completed character(s) as indicated by the Mac keyboard layout. It all seems to work fine. (It also doesn't interfere with some local, in-progress work to support input methods.) Nothing about posting WM_DEADCHAR takes control over the ultimate translation of keys into characters away from the driver or the windowing/input system with which it interfaces. -Ken
Simon Lipp <sloonz(a)gmail.com> wrote:
That's how it's supposed to work.
But it doesn’t work that way under Windows. Shouldn’t Wine try to stick to Windows behavior as close as possible ?
It depends.
Wine should never generate WM_DEADCHAR message, it relies in the driver to handle dead keys and generate final events.
I’m sorry but I fail to see any incompatibility between the two alternatives. Wine can generate WM_DEADCHAR messages AND let X/input method handle the real processing (and the generation of the final event) ; this patch never skip the XFilterEvent call, so it’s still up to your favorite IM to generate the final char from the keystrokes sequence.
You never know which events are supposed to be part of dead code sequencies, so trying to interpret them or inject some events may lead to unpredictable results.
X11 even has an ability to support user defined key sequences which are handled by XFilterEvent and which will be broken by your patch.
Are you speaking about XCompose or things like ibus ? Both still looks like OK with this patch (tested with wine’s notepad, ibus-anthy and XCompose keys from http://bepo.fr/).
Something like that, usually ~/.Xkbmap makes it easy to play with. -- Dmitry.
Wine should never generate WM_DEADCHAR message, it relies in the driver to handle dead keys and generate final events.
I’m sorry but I fail to see any incompatibility between the two alternatives. Wine can generate WM_DEADCHAR messages AND let X/input method handle the real processing (and the generation of the final event) ; this patch never skip the XFilterEvent call, so it’s still up to your favorite IM to generate the final char from the keystrokes sequence.
You never know which events are supposed to be part of dead code sequencies, so trying to interpret them or inject some events may lead to unpredictable results.
This patch does not let pass every single dead sequence without check. It only let pass events which are really dead keys, that is, for keysyms that are dead keys for XKB (before any interpretation by the IM) ; for example if you type "ha" with anthy neither "h" nor "a" events will pass, only the final one for は.Same with Xcompose: Compose+ss will not generate any message outside the final WM_CHAR ß (because s is not a dead key for XKB, even if it is for XIM in combinaison with Multi_key). The only change is for things like ^+e = ê (which will add a WM_DEADCHAR for dead_circumflex), where an additional WM_DEADCHAR will be sent. It’s very unlikely that applications will get troubled by this additional message since they already receive it when running on Windows.
X11 even has an ability to support user defined key sequences which are handled by XFilterEvent and which will be broken by your patch.
Are you speaking about XCompose or things like ibus ? Both still looks like OK with this patch (tested with wine’s notepad, ibus-anthy and XCompose keys from http://bepo.fr/).
Something like that, usually ~/.Xkbmap makes it easy to play with.
Well, I use XCompose on a daily basis with wine + this patch without any issue. Can’t tell for other IMs (XCompose works only with XIM so I stick to it), but basic tests with ibus+anthy shows no issue as well.
participants (3)
-
Dmitry Timoshkov -
Ken Thomases -
Simon Lipp