Special-casing banners of resident notifications was really a
thinly veiled special case for chat notifications, as those were
still using the old notification actor which coupled the life-time
of the notification to its actor. This is no longer the case, so
we can do the sane thing and destroy banners once they are no
longer needed.
Passing null as body always meant clearing the existing one. While this
mattered less with the old message tray which used the expanded actor,
the new message list in the calendar uses the unexpanded body. We clearly
don't want that to disappear on icon changes, so pass the existing one.
We currently use the setActiveSession method to both mark a menu item as
selected, and also tell gdm about the current session the user selected.
Since gdm is ultimately in charge of the state, we should decouple this
and simply ask gdm to set the session, and have the menu item reflect
what gdm thinks is the current session.
This prevents state getting mismatched and oscillations from happening,
where we get in a loop of constantly telling gdm what the session is.
https://bugzilla.gnome.org/show_bug.cgi?id=740142
If a smartcard is missing from the reader when we start up,
and the system is configured to disable password authentication,
then we need to ask the user to insert their smartcard.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=740143
It makes sense for the gesture to reflect the position of the
activities button / dash. In RTL locales, those are located on
the right rather than the left, so make the gesture apply to
the opposite edge in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=737502
Instead of listening to a dbus property exported by g-s-d, listen to the
MetaBackend signal telling the last interacted device, and make sure we
only show the keyboard for touchscreens.
https://bugzilla.gnome.org/show_bug.cgi?id=745977
While legacy status icons are notoriously bad with regard to
accessibility (well, among many other things), we should still
make them available via ctrl-alt-tab ...
https://bugzilla.gnome.org/show_bug.cgi?id=746022
Currently dismissed events will simply reappear when browsing
back and forth between dates, which is clearly broken. Instead,
hide events that have been dismissed permanently. For now, we
simply store a list of ignored IDs ourselves, until we get API
in evolution-data-server to reliably store custom per-event
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
Each event returned by GetEvents includes the (currently unused)
UID, which is not always enough to unambiguously identify an event
(different calendar sources, recurring events, ...).
As we will start using the property to record events that have been
dismissed and should be persistently hidden from the calendar, change
it to a truly unique ID.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
If the action was initiated by the user, we want to show the
modal dialog immediately, while if the action was initiated by
NM autoconnection policy we first show a notification and then
show the dialog when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=660293
The design calls for differentiating between dismissable reminders
and permanent events, based on whether the selected date is "today"
or some other day.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
While messages in the EventsSection are currently simple enough to
use the generic Message baseclass, the design calls for events to
only be dismissable on the current day. We will need a subclass to
implement this behavior cleanly, so add one.
https://bugzilla.gnome.org/show_bug.cgi?id=744927
