[immodule-qt] Re: commit while preedit is being kept (Re: svn repository malfunction)

[Zhe Su]

Hi,
  Currently I only know this two input methods which have this
behaviour. But I think it's enough.
  IMO, such model looks so strange. When I want to commit a string to
client, why IMStart must be sent first? Why the committing string
action must be sent with IMEnd?
  Any other input method frames work do not have such limitation. For
example, in scim, IMEngine can commit string any time by calling
commit_string, no matter whether there is a preedit string or not. In
order to support such model with scim api, IMEngine must call
hide_preedit_string before commit_string and then show the
preedit_string again by calling show_preedit_string and
update_preedit_string. It's so inconvenient.
  As a workaround, scim-qtimm backups the preedit string and redraws
them just after committing a string. It works but looks ugly.

  IMO two events will be enough here, one is to update the preedit
string, one is to commit string. eg. IMUpdatePreeditString,
IMCommitString.

Regards
James Su

On Fri, 10 Sep 2004 07:46:36 +0900, YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> At Thu, 9 Sep 2004 09:59:11 +0800,
> james.su at gmail.com wrote:
> >   I found a design issue of qt immodule. There are only three IM
> > events: IMStart, IMCompose and IMEnd. A string can only be committed
> > to the client by IMEnd event.
> 
> Yes, this model inherits Trolltech's original XIM
> implementation. At least Qt/Embedded's own input method facility
> is also using same model.
> 
> >   But, some input methods may want to commit a string to the client
> > before the end of composing (while displaying a preedit string).
> 
> Did you say that m17n-latin-post and m17n-vi-viqr are such IM?
> 
> Regardless of the answer, please let me know (other) such IMs as
> examples. Actual implementations will indicate real requirements
> to make proper decision.
> 
> > In
> > this case the preedit string will be erased, because IMEnd has been
> > sent to commit the string. Then the input method must restart
> > displaying the preedit string by resending IMStart and IMCompose
> > events. It's so inconvenience.
> 
> I think that a protocol translator which sends IMEvents
> appropriately based on asynchronous preedit-update/commit
> request from such IMs can resolve such issue, as short term
> solution.
> 
> >   Please have a look at the design of gtk immodule, the preedit string
> > and commit events are separated to each other completely. Input method
> > can commit string to client anytime, no matter whether there is a
> > preedit string available.
> 
> I know the design of GTK. But I didn't know the specification is
> intended feature.
> 
> Because the change involves quite wide spread of code, platform
> and persons, we must be careful to change the model. Let me know
> anything about such IMs to decide whether we should change the
> model or not.
> 
> > On Thu, 09 Sep 2004 02:01:44 +0900, YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > At Thu, 9 Sep 2004 00:10:31 +0800,
> > > james.su at gmail.com wrote:
> > > >   Please test the unified patch with m17n-latin-post and m17n-vi-viqr
> > > > input method via scim-qtimm. And compare with the behaviour of
> > > > scim-gtkimmodule, you may find some strange issues.
> 
> -------------------------------
> YamaKen  yamaken at bp.iij4u.or.jp
>