After the recent notification changes, the title may still be null
when the source is originally added. Handle that case and make sure
we pick up later title changes by setting up a property binding.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3308>
Adding a notification clearly constitutes a count change, but
the notify call was accidentally dropped during the overhaul
of the notification API.
Fixes: 34f05b075b ("messageTray: Let the tray decide whether to show a
banner")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3308>
The fallback path broke when we removed support for window icons.
Nowadays we track all windows, and as a result should always have an
associated app (although not necessarily backed by a .desktop file),
so this shouldn't make a difference in practice. Not to mention that
external docks (like cairo-dock) are extremely rare themselves now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3295>
Override redirect windows manage their own positioning and size alone
and are always sticky, so we're not covering them either with the
animation MonitorsGroup, and thus there's no need to clone them or we'd
end up having two windows painted.
This was causing the shell tray icon window actors (that have no opacity
by default but that are override redirect) to show up during the
animation as their clone animation is not 0.
The other option would be hide them during the animation phase, but
there's no need for this.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3285>
'icon-missing' is not an actual icon name. It somewhat works
because an invalid icon name will fallback to the correct
'image-missing', however for apps the generic app icon is
a better fallback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3248>
Setting `useBodyMarkup` to `true` fails with:
JS ERROR: TypeError: this.setBody is not a function
set useBodyMarkup@resource:///org/gnome/shell/ui/messageList.js:585:14
Fixes: f0e863f529 "messageList: Use GObject properties for Message"
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3232>
The fallback for creating models is to try the next one in case the current
one can not be created, until we fall all the way back to the US layout.
Obviously we shouldn't fall back in case creating the model actually worked,
so break out of the loop and then use the new model.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3230>
Using two actor to display collapsed and expanded body creates a small
flicker when switching between the actors, since we can resize the actor
we can just use one actor and resize it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
Setting the `datetime` property whenever a notification is updated is
tedious and error-prone. Therefore, whenever properties, other then
`acknowledged` and `datetime`, of a notification change update the
`datetime` property to the current time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
This removes the `createBanner()` method on `Notification` and `Source`.
Since we want to use the same widget for the calendar and the banner,
let's not allow to create custom widgets just for the banner.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
Stop using custom buttons for notification actions. The only reason to
use custom buttons was so that we could add icons next to the button
label, if we really need the icons next to the label we can add icons to
the notification API.
By using the actions API we can ensure that buttons always look the
same without additional work.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
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>
