Issue 67316 - IM: gtk scim input. Uncommitted pre-edit buffer moves with mouse click
Summary: IM: gtk scim input. Uncommitted pre-edit buffer moves with mouse click
Status: CLOSED DUPLICATE of issue 73863
Alias: None
Product: Calc
Classification: Application
Component: code (show other issues)
Version: OOo 2.0.3
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: niklas.nebel
QA Contact: issues@sc
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-13 11:05 UTC by caolanm
Modified: 2013-08-07 15:14 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description caolanm 2006-07-13 11:05:55 UTC 
So 

under gnome
LANG=ja_JP.UTF-8
start calc
activate scim (for me ctrl+space) and select e.g. japanese/anthy
press i in a cell, the appropiate japanese character appears in the pre-edit
buffer. 
Now without pressing "return", click in another cell and the pre-edit buffer
moves around with the mouse.

Seems a bit odd, perhaps the buffer should be committed on moving to another cell.
Comment 1 frank 2006-08-08 11:17:50 UTC 
Hi Eike,

as Niklas is on vacation please have a look at this one.

Frank
Comment 2 ooo 2006-08-08 11:56:47 UTC 
Yes, the buffer should not move with the mouse click but instead the cell input
should be closed, same as with other input languages. All three CJK languages
seem to be affected, note that CTL languages are not. Reassigning to Niklas
nevertheless.
Comment 3 caolanm 2006-08-24 09:17:50 UTC 
And as part of this, perhaps pressing "accept" on the input line should also be
considered sufficient to close the cell input, so that letters still be
"pre-edited" get auto-accepted once accept gets clicked
Comment 4 caolanm 2007-01-25 12:44:47 UTC 
I believe calling gtk_im_context_reset in endExtTextInput which is called from
such mouse events will get the various engines to do what their users expect in
this circumstance

*** This issue has been marked as a duplicate of 73863 ***
Comment 5 caolanm 2007-01-25 12:45:45 UTC 
close as dup