This drops all subclasses of `MessageTray.Source` that were used to
display system notifications. Now the `Source` returned from
`MessageTray.getSystemSource()` is used.
Ensure also that properties and methods that where set on the `Source`
are moved to the `Notification` object itself.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3156>
Enables the use of a new `xkb-model` dconf key to let user configure
their desired keyboard model.
Also included is additional glue for respecting X11Model set at the
system level (ie. via `localectl`).
For simplicity, this assumes the use of one global keyboard model.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2583>
The values of the two control widgets are syncronized, meaning
that both emit signals when the local value changes, regardless
which one is visible and is actually used by the user.
This is not ideal because it leads to two dbus calls
per local change. To alleviate this, only consider
changes from the widget that is visible.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3086>
The logic could enter an infinite loop because it tried to
propagate local changes to g-s-d that were caused by signals sent
by g-s-d. For example:
1. slider is set to 50
2. Set(50) dbus call is sent
3. slider is set to 51
4. Set(51) dbus call is sent
5. PropertiesChanged arrives due to Set(50)
6. this._sliderItem.value is set to 50
7. notify::value is emitted from this._sliderItem
8. Set(50) dbus call is sent
9. PropertiesChanged arrives due to Set(51)
10. this._sliderItem.value is set to 51
11. notify::value is emitted from this._sliderItem
12. Set(51) dbus call is sent
To alleviate this issue, block signal handlers when the local state is
changed due to a remote event.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7111
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3086>
These have been long deprecated over in clutter, and (via several
vtables) simply forward the call to the equivalent ClutterActor methods
Save ourselves the hassle and just use ClutterActor methods directly
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3010>
Since commit 6a23e8ee0f4, we use the adapter state (that includes
transitional state) to indicate progress when a state change takes
a long time.
However on many systems, the delay happens on the rfkill side,
before a change request even reaches the adapter.
Address this by temporarily overriding the adapter-state with the
expected transitional state, until an actual adapter state change
occurs.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5773
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2815>
We currently show the bluetooth toggle when Bluetooth can be
toggled via rfkill, or when there is a powered adapter.
While the latter condition is obvious - if there is a working
Bluetooth adapter, then Bluetooth is available - it does impose
a problem: We rely on rfkill for turning Bluetooth off, so if
rfkill is missing, the toggle is stuck.
We could handle that case and power off the adapter ourselves
when necessary, but then the toggle would just disappear when
turned off.
Instead, only show the toggle when rfkill is available, so we
can assume that turning Bluetooth on and off will work.
This is also consistent with Settings, which shows Bluetooth
as unavailable in this case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2815>
We have been using type-safe comparisons in new code for quite a while
now, however old code has only been adapted slowly.
Change all the remaining bits to get rid of another legacy style
difference.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
We have made good progress with transitioning to the new style,
to the point where we can complete it with a final push.
Start with changing the remaining places that still use double
quotes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
The module is shared between the various D-Bus services and the
main gnome-shell process, so it was originally left out to allow
porting different bits at their own speed.
Now that everything has been ported to ESM, there is no reason
to not move that particular module as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2868>
The custom setter used by the slider item isn't emitting change
notifications, so the property binding that uses it as source
never propagates the new value.
Fix this by emitting proper change notifications.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2856>
We have always defaults to an empty ornament, so that menu items
are always aligned, even when radio items are used.
However radio items are fairly rare, so most of the time we end
up with an extra margin with no purpose. The design team now
prefers radio items to only align with each other, so that regular
items get the expected margin.
Change the defaults accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2843>
Soon only radio items should use a visible ornament, to avoid
unnecessary extra margins in regular items.
Network items can act as both radio- and regular items, so
update the ornament accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2843>
Layout items use the ornament to indicate the active layout, so
their ornament should always be NONE or DOT.
The default is about to change to HIDDEN, so explicitly initialize
the ornament to NONE to keep the current radio item appearance.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2843>
Settings no longer exposes a slider for the keyboard brightness,
leaving keyboard shortcuts as the only way of adjusting it.
This is good enough in most cases, because devices with keyboard
backlight usually include corresponding keys on their keyboard.
However for devices without those keys, it would be good for the
settings to be exposed somewhere again. Quick settings seems like
a more appropriate place than "proper" Settings, since it gives
quick access that doesn't require a major focus change.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6765
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2820>
Use the new privacy indicator class for the input one and move it next
to the other privacy indicators.
While on it move all privacy indicators to the front, following the
system-status-indicators mockup.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2840>
- spin out all the panel button styling into a drawing mixin
- clean up the styles generally
- make special cases for the clock and non-flat buttons
- contrast fixes for non-flat buttons, fixes#6768
- new stop icon for the screen recording/cast indicators
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2804>
Now that we track apps instead of instances, we can make the menu
items activatable, because the corresponding action is no longer
app specific (like activating a particular tab): We can simply
activate the app, which hopefully will bring it to the foreground
again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2790>
The background apps menu currently tracks instances rather than
apps. That matches the behavior of `flatpak ps` and can be useful,
for example when one particular instance runs out of control.
But as we don't include any information that allows to actually
distinguish between instances, multiple instances appear simply
as duplicated app entries.
Given that a menu is too limited for detailed information, stop
representing individual instances, and track apps instead.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6654
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2790>
When we can't detect a headphone by form factor, we do a string
match on the port name. A match on 'Headphone' isn't less likely
to be valid than a match on 'headphone', so make sure we ignore
capitalization.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2691>
Commit 9d75d777c72e introduced code to hide the subtitle of the
quick setting toggle when it matches the title of the toggle.
That's because NetworkManager tries to make the network names
more palatable on its own, and reports that the name of single
wired networks is "Wired" even if it may have another name.
What that commit failed to account for, however, is that there are
other circumstances where we end up with a subtitle is exactly the
same of the title. For example, when turning off Wi-Fi or mobile
broadband connections.
The behaviour of commit 9d75d777c72e is safe enough to be applied
on other device-backed connections, so do it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2682>
In GNOME OS, due to a misconfiguration, geoclue was configured without
systemd support. In that configuration, geoclue does not install its
systemd .service file (geoclue.service) but it (incorrectly) includes
the following line in its D-Bus service file:
SystemdService=geoclue.service
As a result, when dbus-daemon tried to activate it at gnome-shell's
request, it would fail with:
Unit geoclue.service not found
Then, GeoclueAgent._onGeoclueVanished() would be called, as the
name_vanished_handler passed to Gio.bus_watch_name(). This is consistent
with Gio.bus_watch_name()'s documentation:
> You are guaranteed that one of the handlers will be invoked after
> calling this function.
But that function assumed that this._managerProxy is defined, leading
to:
JS ERROR: TypeError: this._managerProxy is undefined
_onGeoclueVanished@resource:///org/gnome/shell/ui/status/location.js:163:9
Fix this by checking for nullishness of this._managerProxy. (Strictly
speaking, it's undefined rather than being null, but other code in this
file already uses the vaguer '!= null' test, which considers undefined
to be null.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2689>
