in e.g. scim-pinyin (chinese simplified) there's some inconsistency
between applications and handling an uncommitted pre-edit buffer when
the user attempts to change the input position while there are
uncommitted chars in the input buffer.
i.e.
gedit:
1) foo, active im, type w
2) highlighted pre-edit appears
3) click at start foo
4) uncommitted buffer destroyed, no commit, cursor moves to foo
5) type w
2) new pre-edit for 'w' appears at foo location
3) deactivate IM
4) pre-edit closed, no commit
5) activate pre-edit without moving location, previous pre-edit content
reappears
i.e. changing the input location destroys the contents of an ambivalent
uncommitted pre-edit buffer.
firefox:
1) foo, activate im in main window area, e.g. google input box, type w
2) highlighted pre-edit appears
3) click at start foo
4) pre-edit remains open, cursor pretends to be positioned as foo, but
pre-edit remains at original position, new chars still entered as
original position
5) deactivate IM
6) move cursor anywhere, activate IM
7) previous pre-edit content reappears
8) click in url toolbar, pre-edit content appears committed to original
location. On typing the first new letter in the url toolbar, pre-edit
area appears, and is revealed to be the same pre-edit buffer as
previously used, i.e. w already entered
9) re-click in google entry, apparently committed character disappears
i.e. attempting to change the cursor input location is ignored within
the same context while pre-edit is active, changing entry context
commits the buffer, but doesn't clear it. Single buffer used throughout
application. An uncommitted buffer follows cursor position, but is only
shown on a new key entry. Contents not destroyed in input location
change.
openoffice.org:
1) foo, activate IM in main writer window, type w
2) highlighed pre-edit appears
3) click at start foo
4) cursor moves to foo, uncommitted buffer moves with it
5) click in e.g. style name area, still uncommitted pre-edit moves with
it
6) deactivate IM, move anywhere, activate IM, uncommitted contents
appear at the new location
i.e. single pre-edit for the app, uncommitted contents remain regardless
of context change, pre-edit follows cursor. Contents not destroyed in
input location change.
Now lets take the korean hangul IM, and in...
gedit:
type o, highlight pre-edit, click elsewhere, the o is committed to the
doc at the original location, input position moves to new location
i.e. changing the input location commits and clears the contents of an
un-ambivalent uncommitted pre-edit buffer.
firefox:
type o, highlight pre-edit, click elsewhere in entry area, cursor
pretends to move, nothing really happens. click in new entry area. the o
is committed to the new entry area
i.e. *sob!*
openoffice.org;
type o, highlight pre-edit, click elsewhere in the app, cursor moves to
new location, highlight uncommitted pre-edit moves to new location.
i.e. same as i.e. ambivalent uncommitted pre-edit buffer case
So all in all I'm a little confused :-)
So, is this (effectively) the gedit/gtk algorithm, and does it make
everyone happy...
1) if there are un-ambivalent uncommitted pre-edit buffer contents then
commit on input position move
2) if there are ambivalent uncommitted pre-edit buffer contents then
ignore them on input position move
3) moving the cursor position will always clear the input-buffer
C.