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

[René J.V. Bertin]

On Friday November 07 2014 14:16:07 Andreas Pakulat wrote:

> 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

Ah, yes, that's quite possible. A debugging nightmare, that whole DBus thing ...

> 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

Sure, but isn't the outgoing event a UI event, or should I say, isn't the event being treated as if it were a user input event?

> 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.

Who's they here? Sounds like the libdbusmenu-qt devs?

> One could
> also argue that the menu shouldn't be accessible anymore during this
> 'shutdown' procedure...

Yes, that's what the fix does. It was discussed to remove the systray icon (the "source" of the event) early when shutting down, but I voted against that because part of its context menu remains functional and valid (and useful, as the last "visual handle" allowing to quit the app if it gets stuck too long in the cleanup code).


René