Bugzilla – Full Text Bug Listing
| Summary: | [misc] Adopt new IME support - was: SquigglesStrategy draws on top of IME text | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Felipe Heidrich <eclipse.felipe> | ||||
| Component: | Text | Assignee: | Platform-Text-Inbox <platform-text-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | daniel_megert, thatnitind | ||||
| Version: | 3.3 | ||||||
| Target Milestone: | 3.4 M3 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 205794, 205795 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
As far as I understand so far, it will be way more complex:
>but model
>(StyledTextContent) is changed during the process of composition
This means the (I)document gets changed and hence all listeners that listen for document modification will be notified and act upon it. That it renders on top of spelling errors is just one small example. Another would be any builder (like JDT) that reports errors once the document gets changed. Also, I guess using Ctl+1 to 'Rename in file' (puts line around all identical elements and updates while you type) in the Java editor will show problems. Can you test that for me?
Just to clarify: the spelling error will be correctly shown once IME mode is exited, right?
>As far as I understand so far, it will be way more complex: Yes, only testing will show us the extent of the problem. As for the ctrl+1 case, I think we are okay here: 1. If the editor loses the focus (to the on top shell) the composition text is commited. 2. the keys (arrow up and arrow down, which allow you to select your options in the ctrl+1 for example) are filtered by the IME. Note: The IME has the top priority handling keys. > the spelling error will be correctly shown once IME mode is exited, right? Yes (didn't test, but I'm think it will work). Once a japanese word is commited every letter of word will be sent separately via keydown events for the application to have the chance to process it. I'm not sure whether I can change that as it completely breaks the document protocol. We'll see. See also bug 202340. Dani, fixing this should improve the performance on bugs such as Bug 113241. TextLayout only draws runs/styles that are inside of the clipping. I've fixed the draw over problem by using the new text styles. Available in builds >= I20071009-0800. Note that this fix makes the final result look bad as the squiggly line is now not continuos once the IME string is inserted (see bug 205795). This fix depends on SWT providing an SWT.UNDERLINE_SQUIGGLE text style (bug 205794 ): if we don't get that style we have to revert to our old one for things that aren't problems (e.g. bookmarks) and hence this bug will partially come back. Also, this does not resolve bug 113241. >Also, this does not resolve bug 113241. Wrong bug number it sould read: Also, this does not resolve bug 202340. |
Created attachment 77479 [details] screenshot Version: 3.3.0 Build id: I20070828-0800 Now StyledText has inline input method (used to be over the spot). This means that CJK text that is still being composed is insert in the widget. Verify and Modify events are not sent till the text is commit, but model (StyledTextContent) is changed during the process of composition. One problem that I detected already is that spell checker process this composition text and draws on top of it (see the attachment). I think of a couple solutions: a) reimplement SquigglesStrategy to use StyleRange.underlineStyle = SWT.UNDERLINE_ERROR and StyleRange.underlineColor = color; b) add API to StyledText to return the offsets of the composition text.