Commit c6f22826cf added a call to update() to refresh the notification
time for sent and received messages. However as it omits the bannerMarkup
parameter, escaped text like ''' now makes it through verbatim.
Rather than adding the parameter, we can just refresh the timestamp in
the existing update() call to fix the issue - it means the notification
timestamp is only refreshed for received messages, but that reflects
the text shown in the notification, which isn't updated for sent
messages either.
https://bugzilla.gnome.org/show_bug.cgi?id=779435
Media notifications currently always show the forward and backward
buttons as clickable, regardless of whether the corresponding action
is available or not. Media players usually address this by rendering
controls insensitive in this case, so do the same here.
https://bugzilla.gnome.org/show_bug.cgi?id=773884
Without the boxy background, event messages look a bit plain and
unaligned with other messages. Adding an icon addresses this,
however as repeating the same icon over and over again in case of
many events would be rather noisy, only show it for the top event
as in the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Update the notification style according to the latest mockups:
- make notification icons smaller and prefer symbolic variants
- remove background box when not hovered/focused
- increase spacing between elements
- use normal text sizes
https://bugzilla.gnome.org/show_bug.cgi?id=775763
For notifications in the message list, it is usually less relevant
when exactly it occurred, but how long ago. So rather than showing
the exact time and expecting the user to figuring out the timespan
themselves, change the format to something human readable.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Currently the secondary actor (if set) and the close button are
exclusive, that is the latter replaces the former on hover. As
the swapping feels rather busy and there's no real reason both
cannot be shown at the same time, keep the secondary actor always
visible.
A welcome side effect is that it no longer needs to be placed at
the end, so we can move the notification timestamp right next to
the corresponding title.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
The section titles usually don't provide a lot of value - messages
themselves are usually pretty unambiguous about their type, and
having a hidden shortcut to some settings panel or application isn't
essential either - except when showing the selected date when browsing
other days, as it adds context to the listed events. Based on that,
remove the section title as a general MessageListSection feature and
move it into the EventsSection, where we only show it when it is useful.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
We will eventually remove section titles from the message list to
reduce visual noise and give the actual information provided by
the messages more space. So in order to not lose the ability to
mass-dismiss messages, the latest mockups spot a "Clear All" button
at the bottom - implement that.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
The latest mockups contain a button to clear all sections at once.
As some elements cannot be cleared, we need to provide that information
to avoid offering an action that has no effect.
https://bugzilla.gnome.org/show_bug.cgi?id=775763
Weather conditions - at least as far as online services are
concerned - don't usually change in a couple of minutes.
So when updating shortly after a previous update, assume
the current conditions are still valid and trigger an
update without showing a loading indication. This should
help a bit with not getting stuck permanently in loading
state when on a shitty network.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
Similar to the Clocks integration we've had in the date+time drop-down for
a while, the designs have called for a similar section that integrates
GNOME weather as well. Use the WeatherClient added in the previous commit
to implement that section and add it to the popover.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
In preparation of integrating GNOME Weather, add a helper class that
retrieves weather information according to Weather's configuration
if the application is installed.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
In order to avoid distracting popup size changes while browsing
other dates, we freeze the size to the last size request. However
in case of more complex size negotiations - wrapping or ellipsizing
labels, scrollable elements etc. - there's a chance of stray calls
to get_preferred_width/height() that are not used for the actual
allocation. If such a call happens to be the last size request
before the layout is frozen, the saved size will be wrong. To fix
this, save the allocated size rather than the requested one.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
We want the width of the calendar column to be determined by the
calendar, other elements should adjust their allocation accordingly.
However neither ellipsization nor wrapping will kick in unless the
parent's width is restricted, so use a small custom layout manager
that enforces the desired behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=754031
As the telepathy integration picks up existing channels on startup,
ChatNotifications are another case where the real time the message
was received may be before the time it is picked up by the shell.
While this is less of an annoyance than restored GNotifications, as
it generally only affects restarts from the run dialog, it's an
easy fix now ...
https://bugzilla.gnome.org/show_bug.cgi?id=775799
GNotifications are persistent until dismissed or withdrawn, including
across restarts. As we show the time a notification was received in the
calendar, we need to include that information when serializing the
notification in order to be correct.
https://bugzilla.gnome.org/show_bug.cgi?id=775799
Since the last notification redesign, we've been showing the time a
notification was received in the calendar drop-down. However as the
time is in fact added by the NotificationSection, it is actually the
time a notification was added to the list. Usually that difference is
not significant, except when previously received notifications are
restored on startup.
In order to be able to address those cases, we need a time that is
associated with the notification itself, so add a datetime property
that defaults to the current time, but may be set from an optional
parameter as well.
https://bugzilla.gnome.org/show_bug.cgi?id=775799
When gnome-clocks is installed, there is currently a race between the
GSettings schema being added to the database and the world clocks
session trying to use it. The prize if we win that race is an abort
in GIO, so use the newly added AppSettingsMonitor skip the race
altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=766410
When integrating with optional components like Clocks, it is not safe
to access their GSettings right after the application became visible
to the AppSystem:
Installation is usually not atomic, so the .desktop file may appear
before the settings schema, in which case Gio will abort due to an
"invalid" schema ID.
To address this, add a small helper class that wraps the settings
access in a safe way.
https://bugzilla.gnome.org/show_bug.cgi?id=766410
