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

[Andreas Pakulat]

Hi,

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

> On Friday November 07 2014 23:09:16 Andreas Pakulat wrote:
> > 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.
> > 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.
>
> > 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.
>
> Right. Now I'm pretty sure that the actual drawing (etc) of the systray
> menu happens in KMail, but apparently as a result of DBus messages. Seems
> awfully complicated, but also about the only way to make the thing optional
> and compatible with launch the application when there's nothing to leave
> the systray icon, or something that's not KDE (e.g. running KMail under a
> Gnome session).
> If things really work that way they could perfectly well work the same way
> on OS X - at least if OS X had the Plasma applications :)
>
> Still, if under Qt/X11 the Systray icon and menu are managed by plasma
> over the DBus, and KMail is thus coded to "work that way", how can the same
> code function without those incoming DBus messages that aren't being sent
> because there is no Plasma on OS X?


On MacOSX there's other code that integrates into MacOSX equivalent of a
systray. As I said this is likely done through libkdeui, i.e. kdelibs has
an abstraction layer for 'Systray Icons & Notifications'. And using
libdbusmenu-qt is just one way of communicating with the 'native'
systray/notification system used on Linux platforms running Plasma (and
possibly Gnome (3?)). On other platforms the communication may be done
without libdbusmenu-qt, via direct native API calls or maybe there's a
fallback to plain QSystray API.

Maybe KMail uses only QSystray for its systray stuff and the abstraction is
done by Qt's QPA architecture and in a KDE session this loads the KDE
platform plugin which uses libkdeui which uses libdbusmenu-qt to talk to
Plasma's systray. Same way that plain Qt apps usually use KDE's file dialog
when opening a file in a KDE session.

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