Enter/shift/layout/hide buttons have been made to use our own assets, key
labels have been made slightly bigger, and incorrect padding has been
removed from the extended keys popovers.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/46
The previous implementation of the CSS generation logic considered sassc
an optional dependency and made sure for that reason that the result CSS
files ended up in the source directory, so that they could be checked
in and kept in sync with the source sass files.
As we are making sassc a required dependency, we can now stop doing that
extra work and simply rely on the CSS files being automatically generated
each time the sass sources change. By doing this, we can now effectively
get rid of the CSS files checked in the repo as well as of the parse_sass.sh
script, since the CSS files will now live on the build directory only.
https://bugzilla.gnome.org/show_bug.cgi?id=792822
As the style has grown bigger and more complex, generating the different
variants from a common source has been a good decision. However given how
intertwined the theme is with gnome-shell itself, relying on a submodule
has proven to be quite painful. And as things stand right now, it is going
to get worse:
- using either pre-generated CSS or generating it at build time is
odd, and violates meson's strict separation between source- and
build directories; we are therefore considering dropping the CSS
and depending on sassc to always generate it at build time
- with the migration to gitlab, our workflow shifts decisively towards
branches; however there is no support in either git or gitlab for
handling two brances of separate repositories consecutively, which
gets particularly awkward for branches in a private namespace
With those pain points in mind, we will adjust our setup as follows:
- remove the submodule from gnome-shell and instead import the
sass as subtree
- after that, the sass sources can be changed like any other files
in the repository, and regular contributors can forget that there
was ever anything special about them
- whenever we want to update the classic style, we can push the subtree
changes and bump gnome-shell-extension's sass submodule
In other words: Updating the classic styling will become slightly more
painful, but not much and only for me; in return, everyone else can
stop fiddling with submodules (and buy me a beer).
All section titles use an icon, while all corresponding submenu items
are plain-text. As a result, labels in submenus aren't aligned with
the labels in the parent, which makes them harder to read and look
unbalanced. Address this by adding additional whitespace to submenu
items to account for the additional elements in the title.
https://bugzilla.gnome.org/show_bug.cgi?id=706191
When dragging a window between two workspaces a light effect used
to be present. The effect was lost probably during the theme revamp
in version 3.16.
https://bugzilla.gnome.org/show_bug.cgi?id=789103
As notification icons now align with the title, it makes sense for
them to follow the text size in case a text-scaling-factor other
than 1 is applied.
https://bugzilla.gnome.org/show_bug.cgi?id=788265
Using a unicode character here means it may look quite different
from the intended style (for instance with emoji fonts). Avoid
this by providing a custom icon and use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=766368
The legacy tray introduced as part of the notification redesign in
3.16 was meant as a stop-gap solution to encourage applications to
move away from the concept of status icons, but it hasn't really
done anything except of getting in the way. Given that the large
majority of apps that still make use of status icons work perfectly
fine without them, we decided that it is time to drop this unloved
bit of UI altogether. Users who still want them (or use one of the
odd cases where an app really depends on the icon) can install one of
various extensions that are available, either based on the XEmbed
support that is still kept around or implementing the DBus-based
StatusNotifier spec.
https://bugzilla.gnome.org/show_bug.cgi?id=785956
While the new title position gives the previews more space, they now
overlay the content which may hide valuable information. Address this
by only revealing the title as additional information on hover, like
we do for other auxiliary elements.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
With the window titles no longer being shown as part of the previews
grid, we can reduce the spacing to have more space available to the
window previews themselves.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
We consider the window previews the primary way to identify a window,
so it makes sense to give them as much space as possible. So in order
to not have title captions take up too much vertical space, overlay
them on top of the preview borders.
https://bugzilla.gnome.org/show_bug.cgi?id=783953
Meson is on track to replace autotools as the build system of choice,
so support it in addition to autotools. If all goes well, we'll
eventually be able to drop the latter ...
https://bugzilla.gnome.org/show_bug.cgi?id=783229
Those will go away when we port authentication prompts to the new
MessageDialogContent widget, so pick the style classes from there
and adjust individual properties with more specific rules to re-
produce the existing style.
https://bugzilla.gnome.org/show_bug.cgi?id=784985
A lot of our modal dialogs share a similar structure:
[Icon] Some title
Maybe a subtitle
And sometimes even a body for stuff like
longer descriptions.
A dedicated widget with a common style will allow us to significantly
reduce duplication of both code and CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=784985
There is a clear difference between the file name and its associated
description which the mockups clearly highlight. Consequently,
make the description label semitransparent, in order to emphasize
the file name, not the description itself.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
The current size of the text is way bigger than what
we want now. The default front size is what we are
looking after, therefore no explicit value is needed
to specify the font size.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
The current separator uses a gradient effect as a separator
between search results. As the mockups suggest, the gradient
separator is no longer needed, in favor of a more simple one,
which is a thin semitransparent line.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
In order to match the current mockups, the providerIcon
class needed to include both the name of the provider
and the label that informs the user about how many more
search results are available for that specific provider.
The latter replaces the plus sign icon that has been
used so far.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
In order to make gnome-shell search functionality fit on
smaller screens, like those of devices, search results
need to take advantage of more horizontal space so that
any extra space can be used efficiently.
In order to do so, change the layout of the ListSearchResult
class from a vertical one, to a horizontal one and also
decrease the padding of the list-search-result-content css
class.
https://bugzilla.gnome.org/show_bug.cgi?id=749957
The user list uses the same indication for hover and focus, so it
is possible for two items to be highlighted at the same time. Using
different styling would improve the situation, but only to some
extent - the user would still need to figure out which highlight
corresponds to which activation method. So instead, copy the
approach we use in popup menus and use a single property for
highlights that is updated by both focus- and hover changes.
https://bugzilla.gnome.org/show_bug.cgi?id=772284
GTK+ switched from ruby-based sass to c-based sassc for performance
reasons. It makes sense to follow suit, if not to not require two
tools for the same job ...
https://bugzilla.gnome.org/show_bug.cgi?id=783210
The solid black top bar we currently use works well for maximized
or tiled windows, as it puts focus on the application content by
blending into the monitor bezel. However it also visually reduces
the screen space, which is particularly noticeable when no window
is located nearby. Having the top bar blend with the background is
a better option in that case, so track window positions and add
some transparency when the top bar is free-floating.
https://bugzilla.gnome.org/show_bug.cgi?id=747163
The usual expectation when selecting large fonts is for content to
be bigger, not that less content is displayed. While not always
possible, there's no reason not to scale modal dialogues with the
font size.
https://bugzilla.gnome.org/show_bug.cgi?id=782000
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
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
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
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
Update according to the latest mockups:
- don't use a border around the list as specified
by the latest HIG version
- use more generous spacing between controls
- allow extension descriptions to take up two lines
- drop GNOME branding from the window title
- make the app name consistent with the window title
https://bugzilla.gnome.org/show_bug.cgi?id=778672
When gnome-shell fails to start on login, gnome-session tries to
re-launch it again with all extensions disabled. This is currently
implemented by clearing the list of enabled extensions, which means
the user needs to re-enable their extensions manually again.
To make this process less annoying, add a single 'kill-switch' setting
gnome-session can use without interfering with the user setting.
https://bugzilla.gnome.org/show_bug.cgi?id=778664
This is an implementation of the pad OSD that's been previously
present in gnome-settings-daemon. Since things are moving closer
to the compositor, it makes sense to have this implemented as shell
UI.
https://bugzilla.gnome.org/show_bug.cgi?id=771067
Nowadays, the user interface has mostly stabilized with most changes
happening under the hood. As a result, extensions written for previous
versions of GNOME Shell are very much expected to keep working on
updates, if it wasn't for the version check that requires a version
bump in the extension metadata. There has been a setting to disable
that check for a while, but it's existence isn't widely known (hence
the common perception that "everything breaks on updates"). While
there is still some risk that an out-of-date extension can be enabled
without error, but fails spectacularly later (where we cannot catch
the exception), it is reasonably small by now when compared to the
~95% of extensions that can be "unbroken", so swap the default value
to disable version checks by default.
https://bugzilla.gnome.org/show_bug.cgi?id=770887
Commit bd6e7f14d1 reimplemented the cycle keybindings to
fix cycling between more than two windows, but the approach
of highlighting cycled windows by actually focusing them has
the drawback that cycling messes up the MRU order of windows.
To fix this, only change the window focus when the operation
finishes, and use a dedicated actor that draws a border around
a window clone for highlighting.
https://bugzilla.gnome.org/show_bug.cgi?id=771063
intltool is unmaintained nowadays while upstream gettext gained
support for formats like GSettings schemas and .desktop files,
and offers a mechanism to teach it about other XML formats not
yet supported out of the box which we can use for the rest.
So there's nothing stopping us, just make the switch ...
https://bugzilla.gnome.org/show_bug.cgi?id=769074
If a sandboxed app requests access to some system resource (camera,
microphone, location), the portal frontend needs to ask the user
for permission. In GNOME, we want this to be a system modal dialog,
so provide an org.freedesktop.impl.portal.access implementation
that exposes a generic system modal permission dialog on the bus.
https://bugzilla.gnome.org/show_bug.cgi?id=768669
We currently use the :active pseudo class to mark the selected day
in the calendar. Whenever the selected date changes, the class is
added to the corresponding button and removed from all others.
However when the selected date doesn't change (i.e. when clicking
the already selected date), the buttons are not updated and the
use of the :active class conflicts with StButton's builtin handling
of the class - the class is removed on the button up event and the
button is deselected.
Fix this by simply using a different pseudo class.
https://bugzilla.gnome.org/show_bug.cgi?id=746867
Add a dialog that is used in a following patch, to ask user if they want
a requesting application to gain access to their location.
Co-author: Florian Müllner <fmuellner@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=762119
We lost media controls outside of notification banners when
implementing the new notification designs. Reimplement this
functionality as a dedicated "Media" section in the message
list based on MPRIS.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
It is not always possible to determine the type of audio device that
got plugged in. Add a system modal dialog to query the user in that
case and export in on the bus to gnome-settings-daemon.
https://bugzilla.gnome.org/show_bug.cgi?id=760284
We can autodetect what to do based on the user's session, so drop
the separate desktop files.
This, along with some future changes, will enable us to be bus
activatable.
https://bugzilla.gnome.org/show_bug.cgi?id=741666
If we detected that Bluetooth devices were setup, show the Bluetooth
menu so that users can easily turn Bluetooth back on.
This is a bit of a hack, as we cannot detect whether there is a
Bluetooth adapter at all when it's disabled, so we cannot tell whether
there were any Bluetooth devices setup, at some point. This state is
saved in the gnome-shell GSettings in the had-bluetooth-devices-setup
key.
Checking whether we saw Bluetooth devices at one point is a good
enough guess of whether there will be some in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=723848
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
With the message tray no longer being a distinctive UI element,
the existing <super>m shortcut for viewing the notification list
is no longer mnemonic. It is also less convenient as it requires
both hands with most keyboards. So make <super>v the new default
to _view_ notifications, which matches the corresponding Windows
default.
The previous default is kept as secondary shortcut to ease the
transition.
https://bugzilla.gnome.org/show_bug.cgi?id=687986
