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

[Andreas Pakulat]

Hi,

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

> On Friday November 07 2014 16:49:21 Andreas Pakulat wrote:
>
> Hi
>
> >Let me clarify something since you're always talking about UI  events, but
>
> I should clarify something too: the 1st crash report I linked to was not
> due to me accessing a menu IIRC, at least not *after* having used the Quit
> menu item.


The crash you mentioned in your first mail was a QTimer firing, no menu
involved but still not a UserInput event either. Its a programatic event
and the application author has full control over when and if it fires.


> >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
>
> Well, those redraw, resize or move events are also the result of user
> input (with the possible exception of the screensaver kicking in).


Not necessarily, or at least not necessarily user input events in the same
process/application. For example think about a user moving a window over
the kmail one when kmail is shutting down. Or the window manager
re-arranging windows, those events may be received by the kmail event loop
if there's still an X11 window handle connected to the X11 server and
passing the X11 events to the qt event loop.


> The whole problem here is that as soon as it becomes possible to send
> events programmatically it becomes a lot more complicated to make
> assumptions on the origin of those events.


Well, Qt events differ between spontaneous events and non-spontaneous ones.
Where the former are usually generated by the user clicking into your
window and the latter are those that may be generated programatically.


> >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
>
> I'm not sure they aren't, however it's possible that they have a public
> DBus interface, and that the application itself also makes use of that.


I have no clue about libdbusmenu-qt or how it works. kdeui seems to link it
in, so any KDE app will use it too. Plasma links against it as well, so I
guess this really is for the menus in the systray or something like that.


> >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
>
> Erm, no you can't, but OTOH that other process isn't the one shutting
> down. If you're right that an external process is involved (KDEPIM has
> loads of them), then whatever it does "comes back" to the main application
> for treatment.


Well, the second backtrace is pretty clear, the application received a dbus
call through its dbus connection. This is not a userinput event in the
application itself, but it may be trigger by user input in another
application. This dbus call is handled by libdbusmenu-qt and then this
library triggers some slot in your application code again. And that code
that is triggered is not prepared to be executed during the shutdown
procedure. So I'd argue the slot should be disconnected at that point
already or the code should be made so it can be triggered during the
shutdown procedure.


> >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'.
>
> Again, I don't think that's what's going on here... I know KDE has an
> option to use a Mac-style global menu but I don't use it.
>

Yeah, all the dbusmenu library and protocol do is exporting menu
information over dbus. How this is used then by another application also
connected to dbus is a different story. I guess in your case its the
systray app then, which makes sense since plasma uses the library
explicitly as well - like to import the menu's of all systray-enabled
applications.


> And I've seen the same crashes happen on OS X, which does have the global
> menubar.


Then there's likely a difference between the backtrace on OS X and the two
you posted from Ubuntu.


> >Oh, systray is using that too? Ok, wasn't aware of that. Another option
> for
>
> Sorry, using what? If you mean DBus, I don't think a separate application
> is used to manage the systray.


Sure there's a separate application managing the systray in a KDE session:
Plasma (can't say which of the plasma processes exactly don't have an
in-depth overview of the architecture there). Thats a separate process that
gathers the icon and context menu and other things like notifications shown
in the systray from the various applications. And as a separate process its
not affected by eventloop filters in KMail and it has a way to tell kmail
when an action in the context menu of KMail's systray entry has been
clicked. That way is afaiu libdbusmenu-qt and its dbus communication and
thats hitting you in that second backtrace.

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