GNOME Bugzilla – Bug 710945
GNotification: document restrictions of what kind of applications can use the API
Last modified: 2018-05-24 15:46:15 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.
Created attachment 258192 [details] [review] GNotification: document restrictions of what kind of applications can use the API
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".
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.
> - 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/
-- 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.