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
