[Interest] [Qt4.8] UI events coming through despite QEventLoop::ExcludeUserInputEvents

[Andreas Pakulat]

Hi,

On Fri, Nov 7, 2014 at 1:12 PM, René J.V. <rjvbertin at gmail.com> wrote:

> On Friday November 07 2014 12:44:27 Andreas Pakulat wrote:
> >Looking at that backtrace I don't see UserInput events. At least
> >QTimerInfoList::activateTimers suggests a QTimer fires, thats not a
> >UserInput nor a UserInterface event.
>
> You may be right, I noticed that too. Sadly it's not easy to do
> post-mortem debugging here. I actually *use* the software, running in full
> debug mode would likely make it unbearably slow :) and I know too little of
> KDE's PIM APIs.
>
> This backtrace however doesn't seem to imply a timer but rather a true UI
> event:
> https://bugs.kde.org/show_bug.cgi?id=340624


I don't see any user input events there either. The crash is triggered from
an invokeMethod call which seems to be triggered from a dbus connection. So
even if the dbus message is triggered through a user event (like clicking
in the menubar or so) thats not possible for Qt to see anymore since a dbus
event may also come from a commandline app running in the background or
something else. So if libdbusmenu-qt just invoke's qactions or their
connected slots directly when the user selects something in the menu (I'm
assuming this is the hack that (K)Ubuntu uses since some releases to get a
cross-application menubar like on MacOSX) instead of posting a user-input
event to the event loop you could argue they're doing that wrong. One could
also argue that the menu shouldn't be accessible anymore during this
'shutdown' procedure...

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20141107/c3f96cc4/attachment.html>