Daisuke reported some bugs, and he received this mail from Trolltech:

------
Subject: Re: [Issue N12454]  [PATCH] I found a solution about "The execution 
position of XFilterEvent is not suitable"
Date: 2002/12/21/00:19
From: [EMAIL PROTECTED]
To: Daisuke Kameda <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]

On Thursday, 19 Dec 2002 2:03 Daisuke Kameda wrote:
> Hi.

Hello Daisuke,

> [EMAIL PROTECTED] wrote:
> > I'm sorry, but I don't really understand what your patches are
> > supposed to fix. Could you please explain and tell us which bug
> > reports in KDE you were referring to in your last email?
>
> One is http://bugs.kde.org/show_bug.cgi?id=50748 . This bug report is
> that Ctrl+i, Ctrl+p, Ctrl+o and Ctrl+m which are XIM shortcut keys,
> such as kinput2+Canna, don't operate correctly in the input area of
> KHTML. (You will be able to confirm the right operation of a shortcut
> key by Emacs etc.)
>
> Another is http://bugs.kde.org/show_bug.cgi?id=50386 . Although this
> bug report is FIXED, what was solved is only the input itself.
> Shortcut keys of XIM don't operate correctly like the 1st.
>
> I checked that action of Ctrl+p is not right in the composer of KMail
> too. Moreover, I have heard that the same problem exists also in Opera
> on Qt 3.0.x. In present code, possibility that the same problem will
> occur in other applications is high.

It seems that something in KDE is filtering out keyevents.  As I recall,
KDE implements some sort of global accelerator that works on raw X
events.  This is most likely the cause of the problem.

> By the way, I remade the patch. The basic concept is same. Whichever
> patch attached is applied, all events are surely passed to
> XFilterEvent.
>
> The reason for having made two patches is explained.
>
> I thought that the relation of Widget might be changed without
> returning TRUE, when a qt_x11EventFilter function was executed. Then,
> I thought that keywidget which is set as the object of XIM should not
> have been influenced in such a case, and I made
> "qt-x11-free-3.1.0-fix-callPosition-XFilterEvent-2002121701.diff".
>
> If such a thing cannot happen, I think that
> "qt-x11-free-3.1.0-fix-callPosition-XFilterEvent-2002121702.diff" is
> simple and good solution about this problem.

This patch is the simplest and most correct.  The other patch adds new
functions to the QApplication API, which breaks forward compatibility.

I have adopted this patch into the 3.0.x and 3.1.x versions.

Thanks for the report and patches :)

> Please review these patches again :).
>
>
> --
> Daisuke Kameda <[EMAIL PROTECTED]>

--
Bradley T Hughes
Trolltech AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway
------

His patches are here:
http://www.kde.gr.jp/patch/qt-x11-free-3.0.5-fix-callPosition-XFilterEvent-20021220.diff
http://www.kde.gr.jp/patch/qt-x11-free-3.1.0-fix-callPosition-XFilterEvent-20021217.diff


Reply via email to