After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 710945 - GNotification: document restrictions of what kind of applications can use the API
GNotification: document restrictions of what kind of applications can use the...
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-10-26 23:06 UTC by Giovanni Campagna
Modified: 2018-05-24 15:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GNotification: document restrictions of what kind of applications can use the API (1.52 KB, patch)
2013-10-26 23:06 UTC, Giovanni Campagna
none Details | Review

Description Giovanni Campagna 2013-10-26 23:06:14 UTC
Unfortunately, there is no way to make the app-id based API and
grouping work without DBus activation (which prevents all non-unique
apps from using it), and there is some change involved in a tradional
non-dbus-activated app before it can switch to it.
Comment 1 Giovanni Campagna 2013-10-26 23:06:17 UTC
Created attachment 258192 [details] [review]
GNotification: document restrictions of what kind of applications can use the API
Comment 2 Lars Karlitski 2013-10-28 16:58:14 UTC
Thanks for clarifying this in the docs, but saying that an application _must_ be activatable not quite true. I think the shell should remove notifications from applications that are not activatable when they quit.

Also, persistent notifications won't work at all on desktop environments other than the shell right now. The libnotify backend doesn't support persistence.

I think we should include something like "this will only work if the application is activatable and the shell supports persistent notifications".
Comment 3 Giovanni Campagna 2013-10-28 17:10:11 UTC
No, that's the thing: the GtkNotification backend will not work at all if the application does not own a DBus name and does not use a .desktop file named after it.
I tried to make them work, but:
 - There is no way for the shell to know if the application is DBus activatable or not (other than calling ListActivatableNames)
 - There is no way for the shell to know if the application is exporting the DBus name it claims as app_id, other than trying to use it and falling back on the sender for the invocation
 - There is no way for the shell to associate an app_id with a legacy desktop file name, in case the application is not converted.

Additionally, there is no way to use the gtk API with applications that are split across multiple process (eg epiphany/webkitgtk), but I believe this restriction is acceptable and they just need to have their own internal marshalling.
Comment 4 Lars Karlitski 2013-10-28 17:58:52 UTC
> - There is no way for the shell to know if the application is DBus activatable
or not (other than calling ListActivatableNames)

Applications that are activatable have to have DBusActivatable=True in their desktop files. The shell can check if that key is present.

> - There is no way for the shell to know if the application is exporting the
DBus name it claims as app_id, other than trying to use it and falling back on
the sender for the invocation

It has to if it wants to support activation.

> - There is no way for the shell to associate an app_id with a legacy desktop
file name, in case the application is not converted.

An application has to be converted to use this API. Converting is not a big deal and something we want all apps to do anyway.

All of this is in the latest revision of the desktop entry spec:

  http://standards.freedesktop.org/desktop-entry-spec/latest/
Comment 5 GNOME Infrastructure Team 2018-05-24 15:46:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/769.