For menus, it makes more sense to pick a width that fits a reasonable amount
of content rather than a fixed amount of screen estate, so use font-relative
sizes instead of pixel values.
https://bugzilla.gnome.org/show_bug.cgi?id=754581
Some labels in the system status menu - namely network names - are out
of our control, and may thus grow the width "infinitively" unless we
restrict the menu width. So far we have been doing this by setting a
fixed width or max-width, but any value we put there might end up
being too restrictive in some locales. Instead, request a width that
fits all the labels we want to show unellipsized and use that instead
of an arbitrary limit.
https://bugzilla.gnome.org/show_bug.cgi?id=708472
The code previously tried to stop spinner after it was hidden, but
due to an incorrect check was only stoppig it after it was shown.
Also, it was only stopping after hiding due to an animation, and
failing to stop it in the non-animated case.
This left the spinner hidden and running while VT switched away
from the login screen, only stopping when the auth prompt was
reset when switching back.
https://bugzilla.gnome.org/show_bug.cgi?id=753891
* switch to a one-column layout (and adjust strings/widths
accordingly
* remove separator before system menu
* add link to account settings to user submenu for consistency
https://bugzilla.gnome.org/show_bug.cgi?id=751377
Follow the design we have in gtk+ for buttons dialogs,
which are at the bottom and they expand full width, having
the same amount of space for each one.
Also, since this removes any space for non-button widgets
in the button area, move the spinner present in the auth prompt
dialog next to the password entry.
https://bugzilla.gnome.org/show_bug.cgi?id=746108
We now stopped using notification actors directly for anything, so
we can simplify the Notification class significantly by turning it
into a purely informational object others can use to built their UI
representation from.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
Since we stopped special-casing chat notifications to use the old
notification actor, we need to provide a notification banner to
maintain the inline chat functionality, so split out the UI from
the existing ChatNotification class.
https://bugzilla.gnome.org/show_bug.cgi?id=746343
The .selected style class indicates the "active" menu item, which
is generally the last hovered or focused one (whichever happened
last). Styling that instead of :focus and :hover directly guarantees
that only a single item will be selected at a time, which removes
ambiguity and matches the behavior of GTK+ menus.
https://bugzilla.gnome.org/show_bug.cgi?id=745246
Commit 5a8923ef95 removed support for legacy status icons from
the notification system, as we no longer want them to appear as
notifications. As we are unfortunately not quite at a point where
we can remove all support for them for good, so we now need an
alternative place to put them. Add a small dedicated tray at the
bottom which appears when any legacy status icons are active. By
default it is almost completely hidden to not interfere with the
user's windows, but can be expanded on demand to interact with
the icons.
https://bugzilla.gnome.org/show_bug.cgi?id=745162
