After the latest texture cache changes, loading the icon at its preferred
size and scaling it via the actor size no longer works. Instead, use the
icon-size property which is applied when loading the icon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/452
If a result is displayed at the end of the search results, there should
obviously not be a line separating it from the next result underneath
it. To fix this, always hide the separator for the last result visible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/311
Window titles aren't restricted in length, so the menu may end up unwieldily
width. Commit 0bec76b6ee therefore limited the app context menus, but that
got accidentally dropped in commit 0ded0dbfd5. Add back the limitation and
extend it to the new app menu as well.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
This keyboard works similar to GTK+'s emoji chooser (actually, both pull
from the same JSON file). Emojis are categorized in sections and variants
and kept in a "model".
The EmojiPager actor then uses this model to generate pages on-the-fly as
the user swipes around. This is an important optimization since the amount
of actors would rival with the rest of the shell otherwise.
The EmojiSelection object puts the EmojiPager, the page indicators and
a KeyContainer with the bottom row of emoji section shortcuts together to
implement the emoji panel as a whole.
The Keyboard object hooked this to an "emoji" key, which is just visible
on the Clutter.InputContentPurpose where showing an emoji would be
meaningful. Otherwise the surrounding buttons are made a bit wider to
cover up for it (i.e. as it was before).
The OSK panel uses 1/3rd of the monitor height, plus we specify a minimum
size for the keys. This doesn't play along if contents won't fit (short
monitor, big fonts, ...) pushing contents offscreen. Reduce the minimum
size a bit so there's better chances to fit.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/675
Since commit 447bf55e45 we turn the top bar translucent when
free-floating. While this looks fancy and reduces the appearance
of cutting into the available screen space, it has also had a
negative effect on legibility.
Nobody stepped up to address those issues in two years, so revert
back to the fully opaque top bar.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/408
While the current textual forecast is non-intrusive, it may be too
much so, making it less effective to spot the current conditions
at a glance.
Refresh the section to use a more conventional graphical representation,
similar to the one used by gnome-weather itself.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/262
Implement for barLevel an overdrive area. This is a zone represented via a
different styling to indicate that you are bypassing the normal zone of
a given level, without reaching yet the maximum limit.
https://bugzilla.gnome.org/show_bug.cgi?id=790280.
Reuse the BarLevel class to get similar drawing behavior as Slider.
Rename theme css impacted properties and ensure that the osdWindow
remains accessible.
Ensure we don't force setting a custom border color like on the OSD.
https://bugzilla.gnome.org/show_bug.cgi?id=790280.
We can simply request the symbolic variant from CSS so that we don't
have to append '-symbolic' to all the names. This will always make
it easier to pick up that information from external sources (like
.desktop files).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/433
Make the indicator for active remote access use the warning color, to
indicate the severity of allowing remote access.
This only makes the indicator icon orange; the icon in the system menu
is still white.
In places where numbers appear in columns (like the calendar widget) or
where changing numbers would result in labels jiggling around due to
small width changes (like the clock), use the newly added
font-feature-settings support to request tabular figures.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/34
After the move to Gitlab, the gnome-shell-sass repository is more
exposed than it used to; clarify that it is not the place where
style changes should happen, but rather the corresponding subtree
in the gnome-shell repository.
* Remove tiny padding of user-list
* Less space between avatar and username
* Apply the 1em padding only to the user-widget, not the timed-login-indicator
Adjust the previous commit which applied the alignment to :first-child
descendants, instead of only immediate children. This fixes alignment
issues for a number of Shell extensions by making it easier to override
with a .popup-menu-item style-subclass.
find_program() defaults to require the program in question, and as
failing to locate it is now fatal, there's no longer a need for
checking whether it was found later.
Spotted by Michael Catanzaro.
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
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
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
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
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
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 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
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
Display notifications that have not been dismissed in the message
list - eventually this will replace the existing message tray summary.
Notification messages show icon, title and one line of the body and
can be clicked to activate the default action. However they cannot be
expanded, so other actions or the full body text are not accessible
in this mode.
https://bugzilla.gnome.org/show_bug.cgi?id=744817
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
The sass sources now live in a project in GNOME, so they can
be used in multiple projects like gnome-shell-extensions.
Because of that, add gnome-shell-sass as a submodule of gnome-shell
and remove the sass sources from the theme directory.
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.
- separator seems to have a semi-opaque top that interfers
with the bottom row of teh calendar
- current day can't have a blue brder on the bottom,
but $borders_color on the sides. Apparently cannot
use non-uniform border colors.
- month pager missing
Currently we animate in both sides, hover on and hover off, and with
200ms. The downside of that it that it feels sluggish when passing with
the mouse hovering few items because the on transition is slow.
Match what gtk did for fix this for list rows hover state at
commit 52e91f1f74ecb943d, animating only on off hover. However,
gnome-shell doesn't support different kind of transitions for its css,
that will be lovely to have a easeOutQuad as well here.
