You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
notificationDaemon.js: Cleanup notification app_icon and icon-path
handling.
- (Readability) Use appIcon instead of icon everywhere to refer to
what should be a url or icon-name for the application that sent
the notificataion.
- Sanitize app_icon and icon-path values when the notificatioin is
first received. Per the fdo spec, only file uris and icon-names
are valid.
- Fully support icon-path in _notifyForSource() (icon names weren't
being handled).
- Catch and return _notifyForSource() errors to the dbus
invocation.
- Only show an additional image (based on icon-data or -path) if
the uri or icon is different from app_icon. Otherwise, both a
normal smaller icon and duplicate large one will be shown,
which doesn't look nice.
The last change is based on an issue with Thunar (as of 4.18.8 at
least) when using libnotify 0.86:
- thunar_notify_show() creates a new notification using
notify_notification_new() providing a device icon. This is set
as the 'app-icon' property internally to libnotify.
- later, thunar_notify_progress calls notify_notification_update()
with that same icon, only now it's set as the 'image-path' hint
(as well as icon_name internally). (I think in previous libnotify
versions, this argument would be more or less ignored internally),
and the only way to use image-path was to set the hint directly).
Fixes#13026
Thunar was freezing in Cinnamon because of item 3 above -
_notifyForsource() was assuming icon-path would be a path or uri,
when only a uri or icon name was supported. The g_filename_to_uri()
error wasn't being caught, and the dbus invocation was never
returning.
ref:
https://gitlab.gnome.org/GNOME/libnotify/-/commit/f5842adeffdbb8675484b89867938249a65485d9https://bugzilla.redhat.com/show_bug.cgi?id=2372896
0 commit comments