Actually link a notification source with an app instead of just to
its app name and PID, which in many cases don't really identify an
app. E.g. for portal applications the PID points to the
xdg-desktop-portal.
Use the app when ever possible but keep using the app name and PID
as a fallback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
A notification can have two ways to specify a sound, via a name of a
sound in the sound theme and/or a file. Therefore introduce an object
that can hold both properties and creates an abstraction over the
different source. This reduces the number of properties for a
notification, which will make it simpler to port it to GObject
properties.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
We auto-close FDO notifications when the sender leaves the bus,
given that the protocol was created without persistency in mind
and any action will become invalid.
However that broke when moving the public-facing implementation
into a separate service, as we now track the (always running)
service instead of the original sender.
Fix that by forwarding the sender to the internal implementation
via a private hint, just like we already do for the PID.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3204>
The hint is a private implementation detail between the public
and internal services, not something anybody else should set
(*cough* libnotify *cough*).
Prefix the name to hopefully make that clearer.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3204>
Commit 932ccac1 changed Source to use a regular constructor
instead of `_init()`.
Unfortunately that results in ordering issues for subclasses
that override `_createPolicy()`, if that method needs to access
any properties that are set in the constructor (as `this` is
only available after chaining up to the parent).
We can fix that by simply setting the policy from the constructor,
instead of relying on some overriden method being called.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3170>
Even though the comment in the code says that sources are reused even
thought the app title has changed this is actually not the case. Therefore
when ever the app title of a notification changes a new `Source` is
created. Therefore there is no point in setting the app title again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103>
As the notification redesign affects the API anyway, we can just
as well use the opportunity to modernize the code.
Turning the icon into a GObject property means we no longer need
a custom signal for change notifications, and the icon becomes
usable in bindings.
Since setting an `GThemedIcon` is common this also adds a convenience
property to set the icon name directly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103>
Our telepathy component has been optional for years, and it is
disabled by default on major distros, so we cannot assume that
it handles any particular notifications.
Plus Empathy itself is mostly dead, so it's unlikely to be used
much anymore anyway.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3110>
The Config module is shared between the main process, D-Bus
services and tests, which previously prevented it from being
ported to ESM.
The previous commit removed the last outstanding blocker, so
we can now port the last remaining module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2880>
Out of the members of the notification daemon(s), these are the most
necessary and flexible to override. The daemons are used as singletons
and notifications are rather temporary, while the sources are more
flexible and make the most sense to override (and revert).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2869>
We have been using type-safe comparisons in new code for quite a while
now, however old code has only been adapted slowly.
Change all the remaining bits to get rid of another legacy style
difference.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
After porting the more complex cases - in particular those that
affect a module's API - we are left with straight-forward D-Bus
method calls that can be moved to promise-based wrappers in one
go.
For consistency, this also switches from Remote to Async where
the call result is ignored.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
This behavior dates back all the way to the original gnome-shell
release, and it did make sense at the time:
- we were first to make notifications persistent instead of
closing them after a timeout; apps were therefore used to
treat notifications as fire-and-forget instead of closing
them when no longer relevant
- neither web notifications not portals did exist yet, so the
D-Bus API was only used directly, instead of as a backend
for other APIs; as a result, focusing the app was more likely
than not to put the source of the event that the user was
notified about into view
Nowadays both persistent notifications and web notifications
are wide-spread, so the original reasons no longer apply.
This change helps web notifications in particular, as it reduces
the differences between XDG and portal-based implementations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2332>
We have made good progress on object literals as well, although there
are still a lot that use the old style, given how ubiquitous object
literals are.
But the needed reindentation isn't overly intrusive, as changes are
limited to the object literals themselves (i.e. they don't affect
surrounding code).
And given that object literals account for quite a bit of the remaining
differences between regular and legacy rules, doing the transition now
is still worthwhile.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2200>
It's unfortunate that we cannot fully embrace template strings, but
we aren't limited to "legacy" formatting either; replace the last
remaining places where we still use string concatenation to reduce
the difference between regular and legacy style a bit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2200>
Unlike the desktop-entry hint, the app name is not optional. That
doesn't mean that we'll be able to match it to a .desktop file,
but we can at least try if we fail to match on PID or desktop-entry.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1291
For fd.o notifications, we are taking the sender's PID into
account when associating notifications with sources (mainly
to deal with notify-send).
This broke when the implementation under the well-known name
was moved into a separate service, as the implementation in
gnome-shell will now always see the public notification-daemon
as sender.
Restore the old behavior by resolving the sender PID in the
separate service, and pass it as hint to the implementation
in gnome-shell.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2592
xgettext gained some support for template strings, and no longer
fails when encountering '/' somewhere between backticks.
Unfortunately its support is still buggy as hell, and it is now
silently dropping translatable strings, yay. I hate making the
code worse, but until xgettext really gets its shit together,
the only viable way forward seems to be to not use template
strings in any files listed in POTFILES.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1014
Since ES5, trailing commas in arrays and object literals are valid.
We generally haven't used them so far, but they are actually a good
idea, as they make additions and removals in diffs much cleaner.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
ES6 allows to omit property names where they match the name of the
assigned variable, which makes code less redunant and thus cleaner.
We will soon enforce that in our eslint rules, so make sure we use
the shorthand wherever possible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/805
