[PATCH] make kaccel work together with qeventloop hackage ?

Dominique Devriese devriese at kde.org
Fri May 28 21:48:26 BST 2004


Hi,

In Kig, I'm currently using QEventLoop::enterLoop for some strange
stuff using modes and such, and I was looking into a weird bug when
using accels.  The problem is in kaccel.cpp which does:

      connect( this, SIGNAL(menuItemActivated()), pAction->objSlotPtr(), pAction->methodSlotPtr());
      emit menuItemActivated();
      disconnect( this, SIGNAL(menuItemActivated()), pAction->objSlotPtr(), pAction->methodSlotPtr() );

The problem is that in Kig, the slots attached to menuItemActivated
start a new event loop.  Then, when another accel is activated in the
new eventloop, the previous slot is still connected, and it is called
in addition to the correct slot, leading to some pretty strange
behaviour.

I have attached a patch that changes this to something using QSignal,
which makes it work for Kig and should have no effect on apps that
behave themselves by not using event loop recursion.

Anyway, I know that in the long run, I'm going to have to fix Kig to
not (ab)use QEventloop, but this requires some non-trivial refactoring
and is on my longer-term agenda.  In the short term, do you think it
would be possible to commit the attached patch ?

thanks for reading this far.
domi

P.S.: The problem in KAccel could be compared to using a global object
      instead of an object on the stack.  It would also lead to
      strange problems if Qt would some day become multi-threaded, and
      such.  Maybe this could be a minor extra argument for the patch
      ?

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kdelibs-kdecore-kaccel-cpp-qeventloop.diff
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040528/20744bb1/attachment.ksh>


More information about the kde-core-devel mailing list