Community
Participate
Working Groups
The short version: On Windows, the IME implementation will generate a key-down event for each character in the IME's text, on Cocoa, it won't. The result is that the already inserted text range is deleted in the document on commit. I've only tested with the OS X "Dictate" feature. I can confirm that Eclipse behaves the same as my app: When the dictate feature tries to commit the text, the text range is deleted. The reason is the implementation of StyledText.handleCompositionChanged(). When the "commit length" equals the event's text length, the result is to be commit. First of all, the API is less than ideal, there ought to be a separate handleCompositionFinished() or similar. Second, why delete the already inserted text? I guess this may be for clients which do not handle IME input at all, so they at least receive the text as regular key-down events. However, that doesn't make much sense upon closer inspection, since clients which do not implement IME will not have inserted the IME text during the composition in the first place. Maybe it's a short way of getting the text inserted with the styles cleaned up, however, it will flicker since there will be no way of avoiding the second text insertion, char by char. The OS X implementation of IME does not generate the key-down events, so the insterted text will simply disappear once commited. My only guess is that this has never been actually tested. I guess there is no hope of changing the Windows implementation to not generate the keydown-events? Perhaps with a style bit indicating that a client wants the new behavior? A second problem at least with Dictation on OS X is that the Dictate feature remains open after commit. A commit happens once the user spoke a sentence and makes a pause, or perhaps at any random time that enough speech has been recognized. But the state of the IME is broken, the "start" location should be adopted to the new caret location, but it is not. Text is inserted repeatedly at the same original offset where the IME had been started first.
How to reproduce: * Activate dictation input in any Eclipse text editor (StyledText). The default method of activation is to double-tap the left command key. * Wait a bit for the feature to become ready (when you launch it the first time). There will be a sound and the text "Ready" beneath the microphone icon. * Speak some text. The text will be inserted in the StyledText widget with a varying delay. * Witness the text to disappear when you make a pause speaking. * Of note: Undo-steps will have been generated for inserting the text, including a final step which deletes the text. == Expected behaviour == * The dictated text remains inserted when making a pause. * The text cursor is located after the inserted (committed) text, while the dictate feature remains active and awaits more input. --- I really hope this gets some attention. For more thoughts on what is going wrong, see my initial report.
One additional note: When the keyboard is used while the dictate input method is active, suddenly there will be key-events generated after a commit-event. The commit-event deletes the input range, and the generated keyboard-events re-insert the text. I have no idea who is actually generating these events and why this does not happen right from the start. That last part would appear to be the actual bug: Why doesn't it work from the start. Of note: On Windows, the IME implementation generates the keyboard events, but not the cocoa implementation of IME.
Marking the bug as helpwanted as we don't have the time/resources to look at this issue now. If someone provides a patch, I'll be happy to review it.
Can you give me a pointer where to start investigating "who" is generating the key events after the keyboard has been used once while the IME is open? My guess is that figuring this out is the key to solving this problem. On a similar note, but this idea depends on more information obtained in the step above: Would you also care for a patch that changes the IME implementation's behaviour? I find it strange that the already inserted text is replaced once more upon commit. I am guessing the key events are generated so that applications may ignore input arriving via IME and rely on filtering keyboard events only. But I guess there are several ways to achieve the same effect.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
The bug still exists and is still relevant to us.
