[SCIM] Re: how about use postEvent instead of sendEvent in qt-immodule implementation?

LiuCougar liucougar at gmail.com
Thu Jul 1 09:03:36 PDT 2004


Anyone there has any comments about this?

Do you think this is possible and whether it will break BC?

On Tue, 29 Jun 2004 23:39:42 +0000, LiuCougar <liucougar at gmail.com> wrote:
> 
> Hi,
> 
> I have just implemented most functions for qt-immodule support of
> scim: it connected to skim to display the input window (including
> pre-edit string, candidates lookup table), maintool bar and icon
> indicator in the systray.
> 
> I just found in my box, when I am typing very fast, the preedit string
> ( IMCompose event is used to draw these preedit strings) will flicker
> somehow.
> 
> ----------quoted from Qt doc--------------
> sendEvent() processes the event immediately - when sendEvent()
> returns, (the event filters and) the object have already processed the
> event. For many event classes there is a function called isAccepted()
> that tells you whether the event was accepted or rejected by the last
> handler that was called.
> 
> postEvent() posts the event on a queue for later dispatch. The next
> time Qt's main event loop runs, it dispatches all posted events, with
> some optimization. For example, if there are several resize events,
> they are are compacted into one. The same applies to paint events:
> QWidget::update() calls postEvent(), which minimizes flickering and
> increases speed by avoiding multiple repaints.
> ------------------end--------------------------
> 
> Based up the doc, I think if postEvent is used we can implement some
> "optimization." just as qt does for  paint events: QWidget::update():
> if the user types very fast and generates several IMCompose before
> entering the next event loop, we can just abandon all of them except
> the last one.
> 
> Just a thought. Eager to hear your view about this.
> 
> Regards,
> Cougar
>



More information about the scim mailing list