Hotplug notifications use custom notification banners to include
application icons in buttons. Bring those back by providing an
appropriate createBanner() implementation.
Nothing except for the chat notification is really custom, so stop
specifying the flag for anything else - it will soon become a bit
harder to create non-standard notifications, so don't do it for no
good reason (discouraging this is of course the reason for making it
harder in the first place) ...
The message tray is now empty and about to be removed, so an indication
at the bottom edge of the overview becomes an odd location to convey the
status of the summary. We will eventually display an indication in the
top bar that unseen messages are available, for now just remove the
existing indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Since the summary area was removed from the message tray, Source are not
longer represented in the UI, so right-click menus and summary icons are
no longer a thing.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
When we will start to show notifications in the date drop-down, we
will not use the actual notification actor, but construct our own UI
based on Calendar.Message. This is similar to what we already do in
the lock screen, except that in this case clicking the notification
should activate the default action.
So rename the existing _onClicked() method to activate() to make it
clear that such use is acceptable. While not strictly necessary, also
rename the corresponding signal to match.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
According to the design, hotplug notifications should no longer offer
an eject action and use regular notification buttons (but using icon
and text), the default action when clicking the notification itself
is to launch the file browser.
Also as the corresponding resident notification is gone, it no
longer makes sense to make the notification transient.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
The new notification system will no longer give access to actions
from the notifications list, so a notification that is never
displayed as banner does not make sense here.
https://bugzilla.gnome.org/show_bug.cgi?id=744815
Ouch, classy - we are telling translators to use a '24h' time
format for the '12h' time format string.
Luckily, only a handful of translations actually followed the
comment (de,hu,id,is,kk,nb,nl), and most of the corresponding
locales do not support 12-hour format anyway (only is_IS, at
least on Fedora).
We commonly mark strftime format strings for translation to account
for date/time representations without an existing strftime shortcut
("Yesterday %H%p"). As those translations are looked up according to
the locale defined by LC_MESSAGES, while the conversion characters
themselves are resolved according to LC_TIME, the result can be
rather odd when mixing locales ("Den 27. January"). The correct
solution would be to install translations for format strings in
the LC_TIME catalogue and look them up with dcgettext(), but we
don't have the infrastructure to do that easily. Work around this
by adding a helper method that looks up a string in LC_MESSAGES
using the locale defined by LC_TIME and use that to translate
format strings, which has the same result.
https://bugzilla.gnome.org/show_bug.cgi?id=738640
Indicate to NetworkManager that the Shell's agent supports VPN
hints, and pass those hints to VPN auth dialogs that also indicate
that they support hints.
VPN plugins can request new secrets, for example if the previous
ones are incorrect (eg, user mis-typed the password) or some other
reason (next token code required to re-sync a hardware token).
The specific secret that the VPN wants, and a VPN-specific message,
are passed in hints from the plugin, to NetworkManager, to the
agent (GNOME Shell) and then to the auth dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=737592
We need to put the actual actors in the history, not just the labels,
otherwise all emptyLine (which are not messages but are not empty
either) and all lines with a timestamp will get stuck in the scrollback.
https://bugzilla.gnome.org/show_bug.cgi?id=733899
It is a bit odd to request AM/PM format when the locale selected
by LC_TIME lacks the concept. We ignore the format setting in that
case elsewhere and assume 24-hour format, let's do the same for
chat timestamps for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=728271
Until now the timestamps were using 24h format.
Check gsetting clock-format to know when
the user is using 12h format or 24h format and
make the timestamp acordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=715158
When set to fill, the label will always end up left-aligned, which
is only correct in LTR locales. Set the alignment explicitly to
work in both RTL and LTR locales.
https://bugzilla.gnome.org/show_bug.cgi?id=712596
Some consumers may want to construct their buttons specially, so allow them
to do that by adding a new API that takes a button instead of a label.
https://bugzilla.gnome.org/show_bug.cgi?id=710137
Since commit 1242a16265, we will use a fake prompt which
cancels alls requests without dialog when the keyring component
is disabled. However this does only apply to new requests, dialogs
that are already active when the session mode changes are kept
open. This is not quite as expected, so cancel the prompt in that
case.
https://bugzilla.gnome.org/show_bug.cgi?id=708910
gnome-keyring provides a fallback in case our builtin prompt fails
to register, so keyring dialogs may still pop up even when they
are supposed to be disabled.
Instead, keep the prompt registered but cancel requests immediately
while disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=708187
We don't want password entries to grow when entering more characters
that fit the available width; as labels' ClutterText ellipsizes by
default, the password labels allow entries to grow by shrinking.
Setting the appropriate ellipsize mode fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=708324
We don't want the password entry to grow when entering more characters
that fit the available width; as labels' ClutterText ellipsizes by
default, the password label allows the entry to grow by shrinking.
Setting the appropriate ellipsize mode fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=708324
