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, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
