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

[Andreas Pakulat]

Hi,

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

> On Friday November 07 2014 14:16:07 Andreas Pakulat wrote:
> > 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?
>

Let me clarify something since you're always talking about UI  events, but
thats not what the processEvents call does. UI events at least in my books
are any events related to the user interface. This includes interaction
events like clicks, keyboard input etc. but also includes redraw, resize or
move events. The latter can afaik not be stopped from being delivered. What
can be 'delayed' is the delivery of keyboard or mouse events by using
ExcludeUserInput. However this only affects events in the Qt application
that you're looking at, but due to the usage of libdbusmenu-qt some 'parts'
of your application (in particular the application menu bar and apparently
also the systray and its menu) are not living in your application process
but are in another process. So you can't block the user input events
triggering menu items in that separate process. You can of course ensure
that your menu actions are disconnected before cleaning up, or at least
most of them are disconnected in case there are some still working. Since
the separate process needs a way to trigger the original action's connected
slots when the menu in the separate process is being triggered it uses Qt's
metaobject system to call the slots directly when the corresponding IPC
call is received in your application. Stopping that IPC call from happening
would require ExcluseSocketNotifiers I guess in QApplication::processEvents
and would shut down all sockets the app may use. Might be not a good idea
for KMail if it talks to IMAP...

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

Yes, the libdbusmenu-qt  devs should probably consider to emulate userinput
events instead of invoking code directly to avoid breaking assumptions such
as 'my menu bar runs in the same process as my main application'.

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

Oh, systray is using that too? Ok, wasn't aware of that. Another option for
solving the 'useful' part you mention would be to let a timer fire after a
'reasonable timeout' and ask the user wether KMail should be killed since
it seems to be hanging in its cleanup phase.

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