[PATCH v4 2/3] winex11: Clear only non-empty existing Composition String.

[Byeongsik Jeon]

On 4/12/22 11:19 AM, Alex Kwak wrote:
> Hi Jeon,
> 
> I tested your code with riched20 ( wine ver, windows ver )
> 
It's good point. We should not write the xim ime code based on the Wine
builtin richedit control.

> 
> For example, trying to type "가나" words.
> 
> following messages generated.
> 
> WM_IME_STARTCOMPOSITION
> GCS_COMPSTR L"\3131"
> GCS_COMPSTR L"\ac00"
> GCS_COMPSTR L"\ac04"
> GCS_COMPSTR L""
> GCS_RESULTSTR L"\ac00"
> WM_IME_ENDCOMPOSITION
> GCS_COMPSTR L"\b098"
> 
> 
> In the above scenario, STARTCCOMPOSITION does not occur after
> ENDCOMPOSITION.
> 
> in that result, "나" needs to selection. but, it isn't.
> 
> 
> In most cases, the location of the Cursor is specified for
> STARTCOMPOSITION, and in ENDCOMPOSITION, the input operation is completed.
> 
> therefore, other problems arise.
> 
OK. I agree that WM_IME_ENDCOMPOSITON should be modified.

My comment is an effort to understand the e4d94e48138f code and the
situation at the time. What needs to be modified should be modified.


I think the Wine xim ime code modification should be done after [PATCH
v4 1/3]. If we create code based on the XKey events rearranged by
process_events(), we may have a strange patch.

Since the Wine xim ime code has been written based on the current
process_events(), applying [1/3] can result in regression in some codes.
But I think this is the right direction.


[PATCH v4 2/3] is currently in rework. In the process of tracking
ImmSetOpenStatus(), I found that there were more fundamental problem. I
think it will take time to make the appropriate patch.

[PATCH v4 3/3] is also reworking. If we actively use XFilterEvent(),
Wine can generate WM_KEYDOWN message even under XIM activity.

> 
> Regards,.
> 
> Alex
> 
> 
> On 22. 4. 11. 19:07, Byeongsik Jeon wrote:
>> Hi,
>>
>> Actually, I don't know why.
>>
>>
>> ### xim server sended event sequence ###
>> preedit start::
>> preedit draw:: caret 1 chg_first  0 chg_length  0 string 'ㄱ'
>> preedit draw:: caret 1 chg_first  0 chg_length  1 string '가'
>> preedit draw:: caret 1 chg_first  0 chg_length  1 string '간'
>> preedit draw:: caret 0 chg_first  0 chg_length  1 NULL
>> preedit done::
>> lookup chars::  keycode    0 string  3 '가'                   <== HERE 1
>> preedit start::                                               <== HERE 2
>> preedit draw:: caret 1 chg_first  0 chg_length  0 string '나' <== HERE 3
>>
>>
>> I'm not sure, but if I guess. By "[PATCH v4 1/3]" issue, the sequence of
>> events changes as follows:
>>
>> ### current Wine process_events() simulated event sequence ###
>> preedit start::
>> preedit draw:: caret 1 chg_first  0 chg_length  0 string 'ㄱ'
>> preedit draw:: caret 1 chg_first  0 chg_length  1 string '가'
>> preedit draw:: caret 1 chg_first  0 chg_length  1 string '간'
>> preedit draw:: caret 0 chg_first  0 chg_length  1 NULL
>> preedit done::
>> preedit start::                                               <== HERE 4
>> preedit draw:: caret 1 chg_first  0 chg_length  0 string '나' <== HERE 5
>> lookup chars::  keycode    0 string  3 '가'                   <== HERE 6
>>
>> IME_SetResultString() is in "HERE 6".
>>
>> At this time, it is "inComp = TRUE" and WM_IME_STARTCOMPOSITION
>> occurred. it may be thought that WM_IME_ENDCOMPOSITION is necessary.
>>
>> When it and "if (!inComp) GenerateIMEMessage(imc, WM_IME_ENDCOMPOSITION,
>> 0, 0);" combine, WM_IME_ENDCOMPOSITION come out of 'if'.
>>
>> It's just guess.
>>
>>