Optional QtGui dependency for KDBusAddons?

[David Faure]

On Wednesday 13 November 2013 11:16:24 Alex Merry wrote:
> On 13/11/13 05:38, Martin Gräßlin wrote:
> > On Tuesday 12 November 2013 23:42:36 Alex Merry wrote:
> >> > The latter is my personal preference (and I don't see any real issue
> >> > with KDBusAddons optionally using something from Qt Essentials), but
> >> > what are other people's thoughts?

The issue is that dbus-only services should be usable by core-only apps, e.g. 
daemons that don't want to require QtGui / QGuiApplication.
For instance we're still dreaming of a core-only kded, one day...
or more importantly for server-side stuff which doesn't have an X server at 
all.

> > Could you explain why KDBusService has to care about the
> > startupnotification at all? What would be the negative result if
> > KDBusService doesn't handle it?
> > 
> > Because I would say "let's ignore it, transit to DBus and call it a day".
> 
> Well, it's important for any application that specifies in its desktop
> file that it deals with startup notifications.
> 
> Suppose you start a second instance of a Unique application.  The DE
> running it doesn't necessarily know that it's the second instance or
> that it's unique, so it does the startup notification thing.  *Someone*
> should remove it; the Qt xcb plugin won't because the temporary second
> instance never shows a window and the main instance doesn't get the
> startup notification id.

Right.

So the negative result for the user, to make things clear to other readers, is 
a never-ending (well there's a timeout) startup notification animation when 
clicking on the kmail icon and kmail is already running.

> Alternatively, if the app implements D-Bus Activation, the client can
> pass the desktop startup notification ID via the D-Bus call.  The
> application still has to remove it.

I think most developer would rather not have to deal with startup 
notification. I know I considered it a black box for years (even though now 
that I know more about it, I realize it's quite simple).

> The other option, I guess, would be to put this in the API of
> KDBusService: allow the application to set the startup notification ID
> in the constructor, and send it out with the signals.

I'm not sure what this would look like exactly?

> Or just ignore it and have no support for startup notifications in
> Unique applications.

Let's postpone the issue for 4 or 5 months. There's rumours of another 
freedesktop meeting, I can get a spec for DBus-based startup notification 
sorted out there. I know the glib/gnome people are very much in favour of it, 
the Qt/KDE developers looking at wayland are too, so we can move this forward 
rather than adding API or dependencies to kdbusaddons that we'll regret later 
on.
If we release KF5 and some apps using it before that (which I kind of doubt), 
then the workaround is indeed to disable startup notifications for unique apps 
meanwhile (one line in the .desktop file).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5