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
* 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
GNOME Shell throws the following warning message:
'St-WARNING **: Too many values for border-radius property.'
Was fixed with just remove the last '0' on the 'border-radius'
property in the '.tile-preview-left.on-primary' class on both files:
gnome-shell.css and gnome-shell-high-contrast.css.
https://bugzilla.gnome.org/show_bug.cgi?id=744900
We no longer have a single notification actor that is either displayed
as banner or reparented to the summary depending on state - both the
lock screen and the notification section of the message list create
their own UI based on the information attached to the notification
object. Adding to this that different representations of a notification
may now exist simultaneously (as they are included in the message list
immediately rather than after the banner has been displayed), it no
longer makes sense to keep the banner actor in the notification itself.
Add a new NotificationBanner class that provides a separate banner
implementation based on the message list's NotificationMessage that will
soon replace the existing notification banners.
The notification list in the calendar drop-down now functions as summary
area, so we can drop it from the message tray and remove a lot of complexity
from the state machine.
https://bugzilla.gnome.org/show_bug.cgi?id=744850
Turn the existing EventsList into a MessageListSection and add the
message list to the calendar drop-down. The new events list only
displays events for the currently selected day, but in a more
structured and friendlier way than the old one.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The message list is a scrollable list that will hold sections of
different types of time-related messages like notifications,
calendar events or birthday reminders. When no section displays
any content for the selected date, a placeholder is shown instead.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
The new design has the events list on the left and the calendar on the
right, so swap them around and remove the vertical separator between
them in favor of some additional whitespace as in the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
This used to be the style-class for status icons (i.e. icon-only
top bar items). It got unused a while ago when the class used
by status icons stopped using it - except for the keyboard indicator,
which set the class manually to appear as status icon despite not
being a real icon.
Now that the button highlight is provided by the .panel-button class
on a parent, the obsolete class results in a double border on the
keyboard indicator when active - just drop it from there as well
to fix.
- the goal is to have the items activate even on the edge
sadly this Fitzsiness is only working on the app vault icon
at the bottom, not the regular icons so far.
So we can style it differently than :hover.
We already have a active state for the menu items which includes
more than hover. For example, when the keyboard focus moves to a item
or we select programatically a item.
For this reason we need a style class named active for the meaning we
give to it in menu items, and a pseudo class active with the meaning
CSS has.
https://bugzilla.gnome.org/show_bug.cgi?id=744680
Since widnows decorations with round corners has a special shape,
which when scaled we can't match with a simple border-radius.
So to prevent to show a gap between the caption border and the
caption itself, apply a shadow.
