With the porting of gnome-bluetooth to the new GListModel API the
behavior regarding removing adapters changed: It now no longer
guarantees to emit "device-removed" signals for the paired devices when
the adapter gets removed.
This means we need to do that ourselves now, so clear the list of
connected signals when the default adapter changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2214>
Turns out this broke showing the bluetooth menu entry for adapters which
rely on the had-devices-setup property being set while turned off. These
adapters are completely removed from the system by the firmware after
powering them off, so in that case there is no default adapter anymore,
although we still want to show the menu.
This reverts commit aaf47167b5.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2214>
We actually don't get a time from the xdndHandler when it emits
drag-end, so we fail right now when calling
workspaceManager.get_workspace_by_index(time).
Fix it by getting the time ourselves instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2211>
Only workspace groups that are associated with a workspace have a
background. As a result, when restacking window previews we end up
passing `undefined` to clutter_actor_set_child_above_sibling()
instead of null, triggering a warning.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2209>
We have made good progress on object literals as well, although there
are still a lot that use the old style, given how ubiquitous object
literals are.
But the needed reindentation isn't overly intrusive, as changes are
limited to the object literals themselves (i.e. they don't affect
surrounding code).
And given that object literals account for quite a bit of the remaining
differences between regular and legacy rules, doing the transition now
is still worthwhile.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2200>
It's unfortunate that we cannot fully embrace template strings, but
we aren't limited to "legacy" formatting either; replace the last
remaining places where we still use string concatenation to reduce
the difference between regular and legacy style a bit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2200>
This commit adds support for Home and End keys to move
to the first and last workspace respectively.
Previously only Page_Up and Page_Down were recognized
to move one workspace at a time in overview mode.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2201>
The event passed to formatEventTime() is reused at a later point.
Therefore, we are not allowed to manipulate the event directly.
This fixes an issue where the user clicks on a multi-day all-day event
the second time before the event gets garbage collected and the event
then is one day shorter.
Fixes 528ee01fef
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2184>
WorkspacesDisplay connects to key-press-event on the stage to switch
workspaces when page up or down is pressed and nothing else intercepts
these keys. This means that it is still possible to switch workspaces
while they are hidden behind the search.
So only allow these keybinding while the WorkspacesDisplay is reactive
which gets updated by ControlsManager depending on whether there is an
active search or not. Also set it as initially reactive, because
otherwise the keybindings would only work after performing an initial
search.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2204>
There's a few things that are really unncessary to log without any
debugging enabled, for example "Getting parental controls for user", so
remove that.
Other things can be useful, so use console.debug() to log those.
Especially the warning in showAppInfo() we don't want log by default as
it spills tons of messages during shell startup (the async
initialization of the malcontent manager takes some time).
While at it, also make the !HAVE_MALCONTENT message a bit more accurate.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2196>
We're calling get_interval on tzA right now for both the tzA and tzB,
this causes a critical error during shell startup:
g_time_zone_get_offset: assertion 'interval_valid (tz, (guint)interval)' failed
Fix this and use tzB to get the offset for timezone b.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2195>
While _sync() does already handle the case where there's no adapter just
fine (hiding the item and the indicator), let's make the handling a bit
more obvious and add an explicit check for !this._adapter where we bail
out and hide the UI.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2188>
There's two ways bluetooth can be powered off/on for us: One way is to
go via airplane mode (which uses rfkill), and the second way is to tell
BlueZ to turn off the device. Now rfkill always has the final say on
whether bluetooth is off, BlueZ OTOH has the final say on whether
bluetooth is on.
This means when we want to know whether bluetooth is turned on, we only
have to ask BlueZ, so simply read this._client.default_adapter_powered
for that.
For turning bluetooth on or off we use rfkill, but when turning it on,
make sure it's turned on in Bluez, too.
FTR, this is exactly the same way the Bluetooth panel in Settings
handles this.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2188>
We currently use get_color(), which assumes the color exists in the
stylesheet (and prints a warning if it doesn't).
Switch to lookup_color() and skip filling the background if no
such colors exits.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2172>
The original popup included arrows that indicated the direction of
the switch. We stopped doing that a long time ago, and ever since
the popup has only indicated active vs. non-active workspaces.
Simplify both the API and style to reflect that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2127>
The indicator shows the recording duration and lets the user stop it on
click. It is more discoverable than the stop entry in the aggregate
menu.
The class extends ButtonBox directly rather than Button because Button
does nothing that it uses, and actually causes issues with its dummy
menu (its vfunc_hide() throws an "open-state-changed: Error: incorrect
pop").
The menu-set signal declaration is required by the panel.
The screencast is stopped upon button press in vfunc_event(), which
matches PanelMenu.Button's input handling.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2163>
In a subsequent commit we will add a function to open the screenshot UI
in the screencast mode. This argument will allow us to do that without
resorting to accessing private fields from the outside.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2107>
This way we don't need to uncheck the other button manually, and it also
allows switching the mode by setting the other button's checked to
false, and not just by setting the target mode's button to true. An
example clean-up can be seen in the "V" key handler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2107>
These two are moving into gnome-shell to unify screenshot handling and
allow for same-frame capturing.
While we're at it, move the keybindings .xml file from g-c-c here
because it belongs to gnome-shell.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2107>
We will re-use the same modes for more bindings in subsequent commits.
Also, while we're at it, invert the modes, to emphasize where the
screenshot UI cannot be used, rather than where it can be used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2107>
It will be used for the window right-click menu and for handling keys
that are moving here from g-s-d.
Lockdown settings are also moving into the split _storeScreenshot() as
that is the only place where they are used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2105>
- drop card style from calendar
- remove focus ability from non-interactive calendar elements
- flesh out the styles for the calendar grid
- fix margin and padding issue with login screen calendar
- update no-notifications icon
- add padding to media player buttons
- catch a couple other minor style papercuts
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2161>
This reverts commit fdac0602db.
The commit was fixing a crash, which cannot longer be reproduced, but also
introduced a noticeable white flash when switching wallpapers. This will
become even more noticeable when we try to uniformly transition the whole
screen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2070>
If the finish function isn't specified, promisify will now try
to use the async name without '_async'/'_begin' suffix (if any)
and '_finish' appended.
Everything except IBus uses a variation of that pattern, so there's
quite a bit of boilerplate we get to remove…
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2174>
As users can have different primary mouse buttons (left vs right) it
might happen, that a user with a different
preference wants to switch. Currently they need
to use the mouse button, that the current
user prefers.
This change enables users to use either the left or right button.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1972>
Currently when switching from a popup menu to another in the same
manager, we first show the new menu, then hide the old menu and
remove its grab, then create a new grab for the just shown menu.
This briefly ungrabbed moment will still trigger keyboard focus
changes, that might have other visible effects. In order to fix
this, change the grabbing order so first the new grab is created
then the old one is dismissed. This ensures focus moves from the
old menu to the new menu without gaps in between.
Since a grab is tied to an active menu, but close/grab are now
slightly decoupled, also ensure closing a menu only tears down its
own grab. This is necessary for correct accounting while doing the
grab shuffling.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5039
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2166>
The current preference API - buildPrefsWidget() - predates client-side
decorations. While extension authors have been finding ways around
the limitation of not having access to the window/titlebar, the change
to the new Adwaita API seems like a good time for an updated API that
officially provides that access (as far as allowed by libadwaita).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2012>
Adapt the new GNOME platform API for the upcoming 42. This makes
sure that we get the latest version of the stylesheet, as well as
support for the new dark mode.
Using the dedicated preference API also gives extensions with more
complex preferences an easier and standardized way for implementing
multi-page preferences.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2012>
The error UI comprises the bits that are actually custom. Splitting them
out from the off-the-shelf window makes it easier to replace the dialog
with libadwaita's dedicated preference window.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2012>
Use GLib's spawn_async() instead of Gio.SubprocessLauncher() which does
not support the child setup function to start ibus-daemon.
This way we can restore the NOFILE limit prior to run the ibus-daemon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2117>
The REPLACE flag we currently pass is useless, as replacing the service
is disallowed when not started with the ALLOW_REPLACEMENT flag.
Fix this by adopting a more standard pattern where replacement is always
allowed, but only actually requested when `--replace` is passed on the
command line.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2152>
All fd.o Notifications signals are emitted for a particular notification,
so debugging aside, only the owner of said notification has a legitimate
reason to act on it.
So far we (and other implementations like the old notification-daemon)
have relied on the client-side to properly filter the signals (like
libnotify), but at least the QT implementation is known to not do
that.
Enforce correct client behavior by only emitting the signal to the
original sender.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5008
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2153>
- move all icons to the icons directory
- rename some icons to be more meaningful
- put all icons on a resource sheet
- update references to icon name changes
- deprecate icons for those in standard set
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2141>
CSS and JS adapted from the Overview window close buttons, but with some
style tweaks requested by the designers.
Since the screenshot UI is long-lived (it's created once at startup,
rather than every time it's opened), we need to refresh the close button
position, as it can change at runtime. Subscribing to preference changes
seems to be skipped for bindings generation in Mutter, but simply
refreshing upon opening the UI should do the job.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4997
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2147>
This was here exclusively to silence out events from other pointing
devices in the stage. Since ClutterGrab being used now is global to
all devices and events are coerced to an invisible actor, there is
no need to explicitly do this.
Also, this event handler was set on the stage, while the grab happened
on a child, so it was fairly uneffective already.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2146>
Since the grab no longer lets events bubble up to the stage unstopped,
we should be forwarding the key events that bubbled up to the dialog
to maybe cycle focus.
Fixes broken keyboard navigation in several context menus around the
shell, other than the panel ones.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2140>
Since the grab no longer lets events bubble up to the stage unstopped,
we should be forwarding the key events that bubbled up to the dialog
to maybe cycle focus.
Fixes focus cycling on keyboard navigation inside dialogs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2140>
