This allows extensions to override `_addNotification()` to create
custom `NotificationMessage` subclasses, which is already possible
for `MessageTray.MessageTray._showNotification()`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3672>
The job that lints code snippets in the style guide only runs
when either the documentation or the linting rules are changed.
Because of that it went unnoticed that the awk tool it uses to
extract the snippets is no longer available since the CI image
was rebased to F42.
Given that awk is awkward anyway, use the opportunity to rewrite the
snippet extraction in python instead of adding awk back to the image.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3694>
This doesn’t introduce any functional changes, as
`this._manager.currentBreakType` is set to the value returned by
`this._manager.getNextBreakDue()` when entering `BreakState.BREAK_DUE`.
However, it should make the code a little clearer as now the code refers
to the ’next’ break type rather than the ‘current’ one in the context of
an upcoming break.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3687>
When ClutterImage got merged into StImageContent with commit 64d5d01360
("st: Merge ClutterImage with ImageContent"), a small error slipped in when
copying over the update_image_size() function.
Within ClutterImage, update_image_size() served a simple purpose: To call
clutter_content_invalidate_size() in case the texture size would change.
To check that, ClutterImage was storing the existing texture size in the
priv->width and priv->height fields.
When merging into StImageContent, those priv->width/height fields happened
to overlap with priv->width/height of StImageContent, but there they are
storing the preferred size, rather than the texture size. Copying
update_image_size() as-is into StImageContent meant we now set the
preferred size to the texture size, subtly breaking resource-scaled StIcons
(where texture size is a multiple of the preferred size).
The breakage isn't very apparent because StIcons manually set the size
of their internal ClutterActor child to the requested icon-size via
clutter_actor_set_size() in st_texture_cache_load_gicon(), and that makes
the child actor report the correct size in get_preferred_width/height(). The
child actor gets allocated via clutter_actor_allocate_align_fill() from
ClutterBinLayouts vfunc_allocate(), and clutter_actor_allocate_align_fill()
honors both the available size from the parent and the CONTENT_SIZE
request-mode on the child. So when the StIcon has a larger allocation (aka
extra available size), clutter_actor_allocate_align_fill() will fill that
available space with the (too large) content size.
To reproduce the issue, on a resource-scaled monitor, simply create an
StIcon with a fixed width and height that's larger than the icon-size. The
icon will be painted too large and blurry.
Fix this fallout by avoiding to touch the priv->width/height properties on
StImageContent, and instead simply comparing old texture size to new texture
size, we have both textures around after all!
Fixes: 64d5d01360 ("st: Merge ClutterImage with ImageContent")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8287
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3680>
The DBus PreparingForSleep property on org.freedesktop.login1.Manager
does not trigger PropertyChanged signals, leading to wrong values due to
gdbus caching. In most cases it would have always been false.
Additionally it was not included in the XML interface description file
included in gnome-shell. So it was actually undefined.
Since this property is used in _calculateUserStateFromLogind() to
determine that a user is not active when closing the lid on a laptop,
the user was considered still active.
Fix this by storing the "start" argument from the PrepareForSleep signal
instead of trying to read from the property.
Fixes: 6a43b6f55 ("timeLimitsManager: Store screen time state on suspend/resume")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3679>
Since the handle radius is used to calculate the width and height of the
slider, having the calculated size be a non-integer value can cause the
following widgets in a box-like container to be unaligned with the pixel
grid, which can lead to blurriness or other visual issues.
This for example could be observed with the interface font set to
"Cantarell 12", which results in a handle radius of 8.278. In quick
settings when showing two consecutive sliders, the second slider then
gets rendered at a non-integer vertical offset.
Further having a non-integer size for a StDrawingArea can cause the
texture to get slightly squished or stretched as the size of the cairo
surface is rounded to the nearest pixel, but rendered using the
unrounded actor size.
This commit changes the border radius rather than ceiling the preferred
width/height so that the handle size always matches the width or height
of the widget and there are no visual gaps caused by a partially filled
pixel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3648>
Using the ceiled radius for calculating the rightmost position the
handle can take on the slider was resulting in a small gap when the size
was not an integer value since the radius used when drawing the handle
is not ceiled.
This effectively reverts 38da479e which seems to have been the wrong fix
for the problem it was trying to solve. The problem presumably had been
caused by not considering the border that the handle still had at that
time.
The border issue was then later fixed by 3ddae9d8, without reverting
38da479e. Then in 6fd0aac8 support for drawing borders on the slider got
dropped, including the changes from 3ddae9d8, leaving us with just the
changes from 38da479e but now without borders on the handle.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8187
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3648>
There is always at least one workspace context which is the context
that is currently being used by the GNOME desktop. If no running realm
is associated with this context then we consider this context to be
'detached' and store it so that the next time a context is needed to
attach to a running realm, this 'detached' context will be used rather
than asking mutter to create a new fresh context.
From some testing on a full session with break reminders enabled, it
seems that it’s possible to break the stacking order of the lightbox
actor if the user continues to interact with the session while it’s
visible (for example, while they’re supposed to be taking a movement
break).
Rather than try and work out what’s going on with the lightbox here, it
seems more robust to switch to using a Clutter effect, like we did with
the screen time UI (in `timeLimitsManager`). Then the effect can be
applied to the main UI group, and doesn’t depend on a separate actor
being placed in the right place in the scene graph.
So, remove the lightbox, and instead add a
`ClutterBrightnessSaturationEffect`, and use its brightness property to
fade the screen slightly while in breaks.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3655>
This makes the buttons on the ‘break overdue’ notification match those
on the ‘time to take a break’ notification. This makes more sense than
showing no buttons on the former, because it leads on from the ‘time to
take a break’ notification after a short wait.
By adding a ‘Take’ button it gives the user a path to acknowledge that
they are starting to take their break, rather than having to let the
session idle.
The ‘break overdue’ notification wasn’t on the original design[1], which is
probably why its buttons got overlooked.
[1]: https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/wellbeing/wellbeing.png
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3656>
This avoids the race between systemd emitting the `prepare-for-sleep`
signal, gnome-shell then starting to write the screen time data to disk,
and systemd suspending the hardware.
The race isn’t so much of an issue if the suspend succeeds (if
gnome-shell loses, the data will still get written out when the machine
resumes), but it’s slightly problematic if the machine loses power while
suspended, as that means the latest screen time data is lost.
Includes significant suggestions from Florian Müllner.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3643>
There are two main changes in this commit:
* Listen to the `prepare-for-sleep` signal from `LoginManager`, which
is emitted just before suspending and just after resuming. When the
signal is received, update the user’s screen time state (active or
inactive), add a transition if necessary, and save the screen time
history if necessary.
* Factor the `preparingForSleep` property of `LoginManager` into the
user’s screen time state, meaning that the user will be considered
inactive between the system going for suspend and coming back from
resume.
The rest of the changes in the commit are boilerplate to allow for this
functionality to be unit tested.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3643>
When trying to connect to a network from gdm, it doesn't make sense to query
secrets from the gdm user since it's a system user.
Furthermore, gdm runs an isolated dbus-session per gnome-shell instance
(for multi-seat setups). Instead, gnome-keyring-daemon is started by systemd
and so it registers on the _main_ dbus session of the gdm user session.
Then, gnome-shell tries to dbus-activate another gnome-keyring-daemon on its
isolated bus, but gnome-keyring-daemon refuses to start as it sees another
instance already running, exposed at $XDG_RUNTIME_DIR/keyring/control.
After a 25s timeout, gnome-shell aborts the request without ever prompting
for a new password.
Because it is both problematic and pointless to query secrets in this case,
let's avoid it altogether and just prompt the user for the network password.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3646>
* Remove obsolete apps
* Add new core apps
* Deduplicate apps which were in both the grid and a folder
* Split system tools out of the utilities folder
* Rearrange the dash a little
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3642>
We currently create the default folder with the corresponding
app list, regardless of whether the apps are actually part of
the default install or not.
This matters when a user explicitly install such an app later,
as it will be hidden away in the folder rather than appended
to the app grid as expected.
To avoid that, only add currently-installed apps to the folder
when creating it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3632>
Defining default apps as serialized GVariants isn't very human-friendly,
which likely contributes to the fact that the lists are in parts horribly
outdated (Books! Cheese! Screenshot! gedit!).
Instead, generate the lists at build time from simple text files, which
should be much easier to update.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3632>
When there are 3 or more windows in WorkspaceLayout, showing or hiding
window preview overlay in some certain orders could cause
inconsistencies in windows' vertical arrangement.
Let's take window A, B, C as an example. Initially, A is above B and B
is above C in workspace layout like this: A -> B -> C.
After opening activities, user could:
1. Move cursor to B preview, which would move B above all in layout:
B -> A -> C
2. Move cursor from B to C preview. When C's showOverlay() is called
before B's hideOverlay(), _restack() would move C above all and don't
change B's arrangement:
C -> B -> A
3. Finally, move cursor away from C's preview:
B -> A -> C
In this case, when user closes Activities, they would see window
stacking wrong for a while.
This commit adds some extra logic in _restack, checking the
_stackAbove's _stackAbove when this._stackAbove._overlayShown is true.
Though it's still not guaranteed to be always consistent as there could
be several WindowPreview with _overlayShown as true if pointer moves
really fast, this helps avoid glitches in many cases.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4638.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3460>
Using the user object at `/org/freedesktop/login1/User/self` is
convenient, but has the caveat that login1 does not emit the
`PropertiesChanged` signal for the object.
That is indeed logical, as for signal emissions there is no
sender that can be used to resolve `self`.
The new TimeLimitsManager depends on change notifications for
user properties, so stop using the `self` shorthand and instead
create the User proxy for the user's UID.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8185
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3636>
Most of the function is already asynchronous, except for the
initialization of the returned proxy. gjs' D-Bus wrapper gained
some convenience API a while ago that makes this trivial enough,
so use it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3636>
Traditionally, getter/setter functions have been considered a
C convenience, and we therefore didn't bother to add them for
many properties that are only consumed from JS.
However now that gjs optimizes property accesses by calling the
appropriate getter/setter instead, it makes sense to add them.
Leave out ScrollView's [vh]scrollbar-policy properties, as they
have a combined `set_policy()` setter that is consistent with
GTK's ScrolledWindow.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3620>
Some properties have getters and setters that don't follow the
usual naming scheme, and they are therefore not recognized
automatically. Annotate the properties so that g-ir-scanner
picks up the methods.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3620>
Traditionally, getter/setter functions have been considered a
C convenience, and we therefore didn't bother to add them for
many properties that are only consumed from JS.
However now that gjs optimizes property accesses by calling the
appropriate getter/setter instead, it makes sense to add them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3620>
gjs now optimizes property accesses if possible, by calling the
corresponding getter/setter method. For this to work, the method
not only has to exist (obviously), but also match the type of
the corresponding property.
Both `Label` and `Entry` currently define their `clutter-text`
property as `Clutter.Text`, while the corresponding getter
returns the more generic `Clutter.Actor`.
Fix that so that both property and getter use the more specific type.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3620>
gjs now optimizes property accesses if possible, by calling the
corresponding getter/setter method. For this to work, the method
not only has to exist (obviously), but also match the type of
the corresponding property.
For some reason the `Global.stage` property is defined as
`Clutter.Actor` instead of `Clutter.Stage`, which is returned
by the getter.
Fix that so that both property and getter use the more specific type.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3620>
The new design requires that other messages and groups are faded when the user
has a group expanded. This introduces a new GLSL shader to provide the
desired effect. The new shader is used for the already existing scroll
fade and the previous one is removed. The two fades need to work together to
ensure that resulting fade looks good.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
We need to track message order separate from the widget children order,
because of how notification groups will add a cover over other messages
when a notification group is expanded that will prevent interaction with
any message other then the expanded notification group.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
For message grouping by source we need more control over the list of
messages to reflect this change rename the MessageSection to
MessageView. Message from different sources will be added to the
MessageView directly in a future commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
For message/notification grouping by source we need more control over
each single message therefore in a future commit the
MessageListSection will contain all messages directly instead of having
a separate section for different source (notifications and media).
The lost NotificationSection and MediaSection will be readded in a
future commit as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3012>
Support the new `banner-message-path` and `banner-message-source`
settings, which allows loading the banner message from a path
instead of GSettings. This is mainly useful for `/etc/motd` and
similar mechanisms, to show the same message for both graphical
and non-graphical logins.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3558>
Our D-Bus services don't make sense outside a GNOME session, so
they shut down automatically when gnome-shell is not on the bus.
However this does not only apply when activating a service from
a non-GNOME session, but also when restarting gnome-shell on Xorg.
This is particularly problematic for services that shut down
automatically, as they lose all tracking state, even when
re-activated.
Address this by queuing a shutdown check instead of shutting down
immediately, so that the service can pick up the new shell name
provided it appears before the timeout (i.e. two seconds).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7843
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3463>
The service implementation already has to resolve the shell's
unique name to exclude it from sender tracking.
It can just as well take care of watching the shell D-Bus name,
which simplifies the code and will allow for more flexibility
when handling the shell disappearing from the bus.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3463>
Section visibility has become less complex when moving events
out of the message list. We no longer need different behavior
in different sections, so we can instead control the visibility
of the entire list in a single place.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3429>
The `Notification` object is destroyed before the `Message` widget so
during the removal animation the user still could click on the `Message`
and activate the notification. This ensures we don't warn about it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3429>
And change the `close` signal on `Message` to run the default handler
last, which allows other signal handers to stop the signal emission
chain.
This change shouldn't have much effect on existing code but will be
needed for by-source notification grouping.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3429>
Since we have now the `notification-removed` signal on
`MessageTray.Source` we can use it instead of connecting to the
`destroy()` signal for each single notification in the
`MessageListSection`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3429>
The widgets `NotificationMessage` and `NotificationSection` in `calendar.js`
aren't used only by the calendar.
Move the two widget to messageList.js since once we add by-source grouping for
messages (which will happen in a future commit) we need a much tighter
coupling between them and the rest of the MessageList. In future the
`NotificationSection` will need to be removed to make expanding of
groups work.
This also removes a circular import of files: `calender.js` imports
`messageTray.js` and it imports `calender.js`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3429>
The following happens when processing an `@import()` rule:
1. `_st_theme_resolve_url()` to resolve file
2. `insert_stylesheet()` to track file/sheet
a. take ownership of file/sheet (ref)
b. use file as key in `stylesheets_by_file` hash table
c. use file as value in `files_by_stylesheet` hash table
3. release reference to file
This leads to a refcount error when importing a file that
was already parsed before:
1. file start with refcount 1
2. `insert_stylesheet()`
a. increases refcount to 2
b. inserting into `stylesheets_by_file` *decreases* the
passed-in key if the key already exists
c. `files_by_stylesheet` now tracks a file with recount 1
3. releases the last reference to file
The file object tracked in `files_by_stylesheet` is now invalid,
and accessing it results in a crash.
Avoid this issue by reusing existing stylesheets, so we don't insert
a stylesheet that's already tracked.
As a side-effect, this also saves us from re-parsing the same file
unnecessarily.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7306
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3619>
There are two instances where we set the deprecated `vertical`
property with a `{vertical}` shorthand that escaped previous
greps; move those to the new `orientation` property too.
Fixes: b75b4abaf0 ("js: Set BoxLayout orientation")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3618>
Since `Spinner` is no longer a subclass of `Animation`/`AnimatedIcon`,
the latter are now unused. Apparently that's not only true for
gnome-shell itself, but also extensions, so there's little reason
for keeping the former base classes around.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3612>
gjs_context_eval_module_file() is a convenience method for
- register the module (load and parse)
- evaluate the module (run)
The first can fail, but has no notion of status code; the
second will always set a valid code if provided (either as
returned by the module, or set by gjs itself).
Doing those two steps separately allows us to explicitly
handle failures to register the module, so that we can then
return the original status code from evaluating the module.
That means that if evaluating the module "fails" with a
`GJS_ERROR_SYSTEM_EXIT` error (because it was terminated
with `System.exit()`), we now return the correct status
code instead of `EXIT_FAILURE`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3599>
The gjs API is slightly odd, in that explicit calls to `System.exit()`
are treated as errors, regardless of the passed status code.
Before addressing this, split out the module evaluation code into
a separate function to separate it from the main logic.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3599>
Unlike `StBoxLayout` which is ubiquious, `StScrollBar` is hightly unlikely
to be used outside of `StScrollView`. It therefore seems unnecessary to
deprecate the `vertical` property before removing it, so do just that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3614>
BoxLayout is extremely common, so removing the old `vertical` property
in favor of `orientation` would be very disruptive. Instead, deprecate
it to indicate our intention of removing it eventually.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3614>
Using "vertical: false" to express "horizontal" has always been a
bit awkward. While we have stuck to the existing property for a long
time, transitioning to an `orientation` property like in GTK and
Clutter seems better.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3614>
It is tightly coupled to the preview, and not meant to be unset
or replaced during the lifetime of the object; size requests
and allocation assume that it exists.
Make that explicit by marking the property as construct-only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3615>
The container is tightly coupled with the preview, and there is
never a need to replace it at a later point. Set it directly
during construction, so the underlying base class can make
this explicit by marking the property as construct-only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3615>
We currently only specify the library to link with when declaring
a dependency, which means that satisfying other requirements like
dependencies or includes is left to the targets.
Move everything required by libshell/libst to the declared dependency,
so other targets only need to care about their own requirements.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3615>
Our code to "forward" `notify` signals from the underlying layout
manager for the `vertical` property broke when ClutterLayoutManager
removed its own `vertical` property.
Property changes via the underlying layout manager should be rare,
but still worth fixing, so explicitly connect to `notify::orientation`
now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3613>
This adds a comment to make clear that the Utilities category is
intended to be organized alphabetically by the display name of
the apps (*not* by the desktop file names), and adds comments
with the current display name of each app.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3609>
These have (Logs) or previously had (Characters) the
X-GNOME-Utilities category in their .desktop file and so showed
up in the Utilities folder (despite 152faae claiming that the
category was "completely unused"). Characters had the category
removed in
https://gitlab.gnome.org/GNOME/gnome-characters/-/commit/210eb09
in apparent expectation that it would be added to the list, but
it seems it was not.
We could restore consideration of the category, but I guess let's
just list the apps instead? I don't know if any others are
missing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3607>
In order to keep the test code brief, all expected times and dates are
written as ISO 8601 strings in the test code, and use `Z` to specify UTC
(again, to keep things brief).
If the test is run under a significantly different timezone, the
end-of-day timestamp changes significantly, as it’s calculated by the
code-under-test using the local timezone.
Avoid that issue by requiring the `timeLimitsManager` tests to always be
run in UTC.
The previous failure could be reproduced by running `TZ=Europe/Madrid
meson test -C /opt/gnome/build/gnome-shell timeLimitsManager --verbose`
— the test for “tracks a single day’s usage early in the morning” would
fail.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3605>
To prevent sporadic shutdown failures:
```
** Message: 17:08:37.707: Shutting down GNOME Shell
(gnome-shell:91892): Gjs-CRITICAL **: 17:08:37.728: Object .Gjs_ui_panel_Panel (0x5b53524fb030), has been already disposed — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3601>
This fixes a bug which happens if screen time limits are *disabled* and
the history file
(`~/.local/share/gnome-shell/session-active-history.json`) is missing
when gnome-shell is started.
If so, the code would previously have incorrectly called
`this._stopStateMachine()` on startup, even though the state machine
wasn’t running. This adds a fake transition from ACTIVE to INACTIVE to
the history file.
If the user later (that day) enables time limits, the code assumes that
they were active from the start of the day through to that fake
transition, which is possibly sufficient time to reach the user’s limit
already. This results in the screen immediately being made greyscale as
the limit has apparently been reached.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8155
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3597>
This is mostly for use when testing a nested gnome-shell in a terminal:
terminating it with Ctrl+C from that terminal should give the process an
opportunity to save state on shutdown (such as the screen time limits
history file).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3397>
This implements wellbeing screen time limits in gnome-shell. It depends
on a few changes in other modules:
- New settings schemas in gsettings-desktop-schemas
- A settings UI in gnome-control-center
- User documentation in gnome-user-docs
It implements the design from
https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/wellbeing/wellbeing.png.
The core of the implementation is `TimeLimitsManager`, which is a state
machine which uses the user’s session state from logind to track how long
the user has been in an active session, in aggregate, during the day. If
this total exceeds their limit for the day, the state machine changes
state.
The user’s session activity history (basically, when they logged in and
out for the past 14 weeks) is kept in a state file in their home
directory. This is used by gnome-shell to count usage across reboots in
a single day, and in the future it will also be used to provide usage
history in gnome-control-center, so the user can visualise their
historic computer usage at a high level, for the past several weeks.
The `TimeLimitsDispatcher` is based on top of this, and controls showing
notifications and screen fades to make the user aware of whether they’ve
used the computer for too long today, as per their preferences.
Unit tests are included to check that `TimeLimitsManager` works, in
particular with its loading and storing of the history file. The unit
tests provide mock implementations of basic GLib clock functions, the
logind D-Bus proxy and `Gio.Settings` in order to test the state machine in
faster-than-real-time.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: https://gitlab.gnome.org/Teams/Design/initiatives/-/issues/130
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3397>
This is a `GSource` which is dispatched when the offset of the system
real/wall clock changes with respect to the system monotonic clock. This
can happen when the user explicitly changes the system clock, or when
there’s an NTP sync after a prolonged period offline.
The source can’t tell you *what* the offset change was, just that there
was one.
This will be used in an upcoming commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3397>
Unlike for plain JS Errors, the `message` property of GLib.Errors
is read-only, so the intent to replace it with a nicer message
triggers an Error itself.
We could create a new GLib.Error with the changed message instead,
but as it turns out, none of the parse errors contain the technical
prefix we want to strip out, so we can simply drop the special-casing
altogether.
This is also consistent with `spawnCommandLine()`, which never
had special treatment of parse errors.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8146
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3593>
- remove the highlighting js in favour of color definitions, to fix it not really working in light theme or high contrast
- add a bunch of color definitions to set the color of the menu button in the different styles
- drop the border drawing for a separator, to fix visual issues with the high border radius, in favour of a separator element
- change the class names of some things to make it understandable
- bit of overall css tidying
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3554>
- renamed all assets to start with osk- disambiguate them from other keyboard status icons
- updated the design of hide, enter and keyboard layout icons to be more rounded
- new symbolic assets for emoji and delete actions to move away from using 16x16
- updated keyboard scss to use the scalable icon definition
- updated the zwnj asset to align with GNOME icon style
- changed all references to icons in layouts
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3555>
When the 'text-scaling-factor' key changes and it's set bigger than 1.0,
the corresponding switch is activated in the a11y menu. However, since
commit 946ee93692, setting the state using
`setToggleState()` also fires the 'toggled' signal, which is I think
correct and intended.
However, that means the GSettings handler for 'text-scaling-factor'
should block that 'toggled' handler when it sets the switch active, as
otherwise the 'text-scaling-factor' is always set to 1.25 when it is
first made bigger than 1.0.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3574>
Almost all switches represent boolean settings, which means we can
use bindings instead of fiddling with signal handlers.
As menu items have a `:sensitive` property, this also deals with
handling keys' writability.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3576>
Updating the accessible state is an internal business of the
class, so making it private is more appropriate.
Besides, it was never called from outside the class since it
was added in 2012, so it's unlikely we'll ever have a use case
for it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3576>
Both popover menus and dialogs can be dismissed with the Escape key,
however the former triggers on key press, while the latter triggers
on key release. As a result, the same key press+release can dismiss
both the command entry's context menu and the run dialog itself.
Fix this by only triggering a key shortcut when a matching key press
was recorded before, which matches how Dialog handles button shortcuts.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8132
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3585>
Last cycle, libadwaita added a new Spinner widget whose visuals
we should adapt. It loops extremely slowly though (a framerate
of 60fps would require 3180(!) frames), which means our current
asset-based implementation isn't well-suited for the job.
Instead, reimplement the underlying GdkPaintable as ClutterContent.
This does not only ensure consistency with libadwaita, but also
gives us more flexibility by picking up style information from
the widget the content is attached to.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3565>
The magnitude of the noise in the final output scales with:
1.0 - cogl_color_out.a
A fixed value for the magnitude relative to cogl_color_out.a might be
too small for large cogl_color_out.a or too large for small
cogl_color_out.a (or possibly even both).
Compensate for this to achieve constant magnitude in the final output.
The coefficients were determined experimentally as a compromise between
preventing colour banding with dark background content and tolerable
noise with bright background content.
This helps for the issue described in
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7795 .
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3572>
ClutterImage as is, is very basic and doesn't really serve any purposes
other than being inherited by StImageContent. As we cannot easily push
ImageContent to Mutter by merging it with ClutterImage because it will
bring more GdkPixbuf usages and also because Clutter doesn't really deal
with theming bits.
Instead, merge it with StImageContent and let GNOME Shell take over from
here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3547>
The new command will take an extension directory set up
with `meson-build --sysext` inside a toolbox, and turn
it into a merged system extension on the host.
Namely it will
1. copy the extension directory from the container to the host
2. set up the extension-release file expected by systemd-sysext
3. compile gsettings schemas if necessary (using the merged
schemas directory)
4. install the extension to either runtime or system
5. merge the extension
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3498>
While the toolbox image itself has all necessary dependencies to
build and run the shell, we still need them in the destdir when
building a system extension.
Achieve this by running .gitlab-ci/install-common-dependencies.sh
if it exists, which is the script that is used both for gnome-os
system extensions and mutter's CI image.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3498>
When specified, the project is installed to a separate destdir
inside the container instead of the container's root filesystem.
This can be used to install several projects into a common extension
directory:
```
$ (cd mutter; meson-build.sh --sysext) &&
(cd gnome-shell; meson-build.sh --sysext)
```
We will later add a separate command to extract the directory
from the container and turn it into a system extension suitable
for use with systemd-sysext.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3498>
Out development toolbox contains an `update-mutter` command to
make it easier to keep mutter up-to-date for people who only
want to deal with gnome-shell.
To allow them to make use of the new sysext tooling, change the
command to install both to the toolbox root and the sysext
directory.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3498>
When building a system extension for GNOME OS, any extra
dependencies are needed both in the container (for building)
and the extension's destdir (for running).
Because of that, the --destdir flag that was added in commit
8aeb6dc86 does not only install to the specified directory
as expected, but also runs a second install step without
destdir (i.e. to the system).
However that behavior is not a good fit when we extend our
existing toolbox tooling to build system extensions for
Fedora instead of GNOME OS.
To account for that, make the --destdir option cumulative
and install the project to all provided destdirs (or /
if omitted).
This gives us the flexibility to install to the system, a
different destdir, or both:
```
$ ./install-meson-project.sh # install to system
$ ./install-meson-project.sh --destdir /new/dest # install to destdir
$ ./install-meson-project.sh --destdir /new/dest --destdir / # both
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3498>
Commit 730fcf34e9 was meant to strip the .desktop suffix from the
desktop directory file, but failed to actually do so: The replace()
method is called on the string parameter before it is passed to
the meson command which substitutes `@BASENAME@`, so it doesn't
have any effect at all.
Really fix the issue by providing the full output name.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3567>
GitLab is currently timing out a lot, and the number of consecutive `git
clone` operations which the `build-sysext` job does is basically
guaranteed to fail at some point. I’ve tried one CI run 30 times in a
row without success.
Temporarily allow this job to fail until GitLab is fixed.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3251>
This implements health break reminder support in gnome-shell. It depends
on a
few bits and bobs from other modules:
- New settings schemas in gsettings-desktop-schemas (released in
47.beta, which Mutter already depends on)
- A settings UI in gnome-control-center
- User documentation in gnome-user-docs
It implements the design from
https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/wellbeing/wellbeing.png.
The core of the implementation is `BreakManager`, which is a state
machine which uses the Mutter `IdleMonitor` to track whether the user
is, or should be, in a screen time break.
The `BreakDispatcher` is based on top of this, and controls showing
notifications, countdown timers, screen fades, the lock shield, etc. to
make the user aware of upcoming or due breaks, as per their notification
preferences.
Unit tests are included to check that `BreakManager` works. These
provide mock implementations of basic GLib clock functions, the
`IdleMonitor` and `Gio.Settings` in order to test the state machine in
faster-than-real-time.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: https://gitlab.gnome.org/Teams/Design/initiatives/-/issues/130
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3251>
Internally in gnome-shell it may be useful to modify the actions
available on a notification while it’s still visible, but without
clearing them all and re-creating them.
Allow that by returning the action object when adding it, and adding a
`removeAction()` method which takes that object and removes it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3251>
If the shift key was pressed, we should switch back to the default level
after the next commit. It seems that this only worked due to a superfluous
signal emission so far (see https://gitlab.gnome.org/GNOME/mutter/-/issues/3448).
When the keyboard is in this "shift" level (note: only "shift", not
"opt+shift" level) without being latched, there are certain events that
should put it back into the default level:
- A normal character key on the OSK being pressed
- A keyval on the extended OSK (eg. TAB key or an arrow key) being pressed
- The backspace key being pressed
- The OSK being hidden
- The user moving focus in the entry
The `_updateLevelFromHints()` function already takes care of updating the
active level after certain kinds of events, we can achieve the desired
behavior by adding a fallback case to that function where it moves the level
back from "shift" to "default".
Since we only want this switch back to the "default" layer as a response to
actual user input, add a `userInputHappened` boolean to
`_updateLevelFromHints()` and don't set that when the application simply
changes its content hints.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3286>
Looks like we currently do the press-and-release dance for keys that specify
both a keyval and the "modifier" action. So when pressing CTRL in the
extended OSK, not only is the CTRL modifier set together with the next key
pressed, but the actual CTRL keyval quickly gets pressed and released,
similar to how we'd do it for the TAB key.
This seems unintentional, as the press-and-release behavior should probably
be specific to keys like TAB, and not apply to modifier keys, so limit that
behavior to only keys without an action specified.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3286>
A lot of keys have no action set. In that case key.action is `undefined`,
but the strict equality check of `action !== null` here will return true and
we'll enter the if-case anyway.
That's quite confusing and was not intended like that, so change the
comparison to a less-strict operator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3286>
The extended-us layout is currently using actions/keyvals inconsistently for
its backspace keys, use the "delete" action consistently, just like we do in
all other OSK layouts (including the newly added za-extended layout).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3549>
When representing the keyboard backlight levels as discrete items,
it is currently not possible to keynav past the first button.
Fix this by bypassing the usual event bubbling and passing key press
events directly to the focus manager, similar to what we do for
popup menu items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3545>
Desktop directories use .directory as suffix, not .directory.desktop.
The suffix is still needed for the source file, so xgettext and
damned lies can correctly infer the type, but strip it from the
output file.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3541>
Quoting Ebassi https://www.bassi.io/articles/2023/02/20/bindable-api-2023/:
Whenever you’re describing a function that takes a callback, you
should always annotate the callback argument with the argument that
contains the user data using the (closure argument) annotation
You should not annotate the data argument with a unary (closure).
The unary (closure) is meant to be used when annotating the callback
type
Recently gobject-introspection became a bit more strict with this and
that generated some warnings:
Warning: St: invalid "closure" annotation: only valid on callback
parameters
This commit fix all the closure annotations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3535>
Instead of having the name of the directory be X-GNOME-Utilities. This
also allows translating the name to the user's language. The name is
chose to be different to X-GNOME-Utilities from GNOME Menus.
In the process, also remove the categories. The menu definition from
gnome-menus is not used, and it's not a category that apps list
themselves, so it's completely unused anyway.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3526>
The hook would be optional if anything called `meta_plugin_get_info()`,
except that nothing has done so for the last ten years.
It seems a bit pointless to export information that is completely
unused, in particular as we never updated it ("version 0.1"?!),
so just stop doing that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3524>
When the inner radius of the top left corner is 0, the corresponding arc
does not get drawn, resulting in a path going from the bottom left
corner to the top right corner when the path is closed.
Fix this by always including a line_to from the bottom left to the top
left corner.
Fixes: dde13b30c ("st/theme-node-drawing: Trace the correct path for inset box shadows")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7996
The name is a bit cleaner, and has been the preferred option(!)
since meson 1.1.
Mutter recently updated the name, so follow suite.
The meson version bump shouldn't be an issue, given that several
hard dependencies like mutter and glib already require higher
versions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3515>
Commit ee0538807 restored the fixed password entry width, but only
for entries nested under .prompt-dialog-password-layout. That
does not include the network secret dialog, so go back to the
original styling prior to commit 8d065b558e where the width
is set for all password entries, and the mount operation overrides
it with a more specific rule.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3514>
Commit removed the fixed width that is used by polkit/keyring
prompts, with the result that the entries now start at their
natural size, and grow as text is entered.
Restore the original behavior, but nest the style under
.prompt-dialog-password-layout (polkit/keyring) to better
differentiate it from entries under ..prompt-dialog-password-grid
(mount operations).
Fixes: 8d065b558e ("style: Clean up dialogs stylesheet to fix layout issues")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3511>
- remove unnecessary dialog type-specific padding, spacing and margin definitions that led to layout to problems
- bump the size of user avatar in authentication dialog
- nest css classes in the sass to better reflect the structure of dialog elements
- sync style of audio device selector with switcher-popup style
- sync text and padding styles with other elements
- fix incorrect button order in audio selection dialog
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7876
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3473>
The Meta keybinding API now exposes the Clutter event to GJS, which was
previously hidden due to it being a gpointer. Since this moves the
binding argument one argument to the right on the GJS side, any code
that was using the binding argument needs to be updated.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3502>
As the keyboard is released asynchronously after setting the ibus
engine, there's a possibility that the `this._reloading` property
changed in the meantime.
To ensure that `holdKeyboard()` and `releaseKeyboard()` are correctly
paired, record the condition in a local variable so that it maintains
its value in the callback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3476>
When commit ce89b15bb1 made the code async, it did not only
delay releasing the keyboard until after the engine has been
updated, but also the following code that updates the current
input source.
One result is that the current source is now initialized later,
which breaks any code that relies on the source being set.
This affects the login screen in particular (which uses different
`InputSourceSettings` than the regular session): It fails to come
up entirely if the OSK is enabled.
To fix the issue, use a .then() callback to release the keyboard,
instead of blocking all following code with await.
Fixes: ce89b15bb1 ("ibusManager: Use async await instead of callbacks")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7912
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3476>
The dist command only needs an up-to-date build directory, it
does not require the project to be installed first.
While the install step is generally quick, leaving the container
file system alone can save a rebuild after the dist is done
(for instance when testing a branch, then temporarily switching
to the release branch for dist).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3497>
Handing the various options to different meson commands in meson-build
gets a bit tedious. Instead of handling them all on the toplevel,
split out *_command() functions that generate the commandline for
the corresponding meson command.
That way, options are handled locally where they matter, which
makes future changes and additions a bit easier.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3497>
For non-debug and non-plain cases - i.e. mainly release builds - in
order to mirror Mutter.
One advantage of doing this is that it allows us to use non-trivial
asserts more generously, such as calling `g_list_length()`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3099>
Previously we just copied the outer path and scaled it down, but that
resulted in an inconsistent thickness at the corners because the pivot
points for the arcs also moved inward.
So now we trace the inset path explicitly to maintain the correct
thickness (spread) around all the corners.
The spec actually mentions you need to do it in section 6.1 [1]:
> Note that for inner shadows, expanding the shadow (creating more
> shadow area) means contracting the shadow’s perimeter shape.
Despite the fact the example diagram gets it wrong in section 6.1.1 [2],
it does then follow with more confirmation that the shadow radius should
be reduced:
> To preserve the box’s shape when spread is applied, the corner radii
> of the shadow are also increased (decreased, for inner shadows) from
> the border-box (padding-box) radii by adding (subtracting) the spread
> distance (and flooring at zero).
[1] https://www.w3.org/TR/css-backgrounds-3/#box-shadow
[2] https://www.w3.org/TR/css-backgrounds-3/#shadow-shape
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7913
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3488>
The ripples are used both for the "Hot Corner" animation and for the
"Locate Pointer" animation. The latter one is an accessibility feature
and should always work, even when animations are disabled. Take this
into account.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2986>
There are cases when we want to mark an animation as required. For
example, we want the "Locate Pointer" animation to work even when
the animation as marked as disabled. Take this into account when
easing an actor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2986>
There are cases when we want to mark an animation as required. For
example, we want the "Locate Pointer" animation to work even when
the animation is marked as disabled. Take this into account when
adjusting the animation time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2986>
The return value currently indicates whether the request was
successful, namely `setCompletionEnabled(false)` will return
`true` if completions were successfully disabled.
However the only caller that uses the value uses it to indicate
whether completions were enabled.
Given that nothing else uses the value, change the meaning to
match the caller, and indicate whether completions are enabled
after the call returns.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3439>
When creating a new NM connection they are by default system connections. A
user cannot create them if they don't have the correct polkit permissions
(org.freedesktop.NetworkManager.settings.modify.system).
If a user tried to add a new connection in the drop down menu, then they got
no password prompt and NM logged the following:
[...] audit: op="connection-add-activate" pid=1872 uid=1000 result="fail" \
reason="Insufficient privileges"
This change adds the current user to the user permissions for the new
connection, if the user has no permissions to modify the system connections,
which copies the behavior of GNOME Settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3462>
The coordinates are effectively in the windowing system coordinate
space, which when scaling Xwayland, we need to scale these. Do this with
the Meta.Window.protocol_to_stage() function on the focused window,
which handles it correctly for the corresponding windowing system and
configuration.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3458>
After the old tool transformed into the extensions app, we added
a wrapper for compatibility with extensions that spawned the
command to open their preferences.
This was a long time ago.
As the ESM port happened since, we *know* that all extensions
are newer than that change. And as spawning the old prefs tool
is no longer accepted in review, no extension that is compatible
with current shell versions still does it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3456>
It's more common to use the dedicated .rst suffix for reStructuredText
files, so now that the files were ported,
use that.
(Renaming the files separately from changing it is less likely
to confuse git, thus the separate commit)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3454>
It's as human-readable as asciidoc and produces the same results,
but the tooling is more widely supported. Also both GLib and GTK
switched to it for their man pages, so rst2man is already a
dependency of the platform.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3454>
The original asciidoc project is still stuck on python2, so on
distros that didn't switch to a fork (like Fedora), it pulls
in over 100M of legacy dependencies.
However we are about to move our man pages to reStructuredText
which doesn't have that issue, and which is already used for
GLib's and GTK's man pages.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3454>
There are cases where this._user might be null when a session
is opened. This is because the user is not selected via GDM but
it is set through PAM. This happens when logging with smart card
or with credential managers, for example.
Given the session-id of the opened session, look for the owner.
This fixes the following error:
```
gnome-shell[153293]: TypeError: this._user is null
Stack trace:
_findConflictingSession@resource:///org/gnome/shell/gdm/loginDialog.js:1219:26
_onSessionOpened@resource:///org/gnome/shell/gdm/loginDialog.js:1254:51
@resource:///org/gnome/shell/ui/init.js:21:20
```
Fixes: df84854d9 ("loginDialog: On login, allow logout a conflicting session")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7526
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3448>
The conflicting session is owned by the same user per definition.
Use the Name property of the conflicting session to get the
username instead of assuming that `this._user` is defined and
passing the username around.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3448>
Since commit df84854d90 the function
_onSessionOpened() is now async. This means that if an error occurs
we get the following warning:
```
gnome-shell[1014]: Unhandled promise rejection. To suppress this
warning, add an error handler to your promise chain with .catch()
or a try-catch block around your await expression. Stack trace of
the failed promise:
_onSessionOpened@resource:///org/gnome/shell/gdm/loginDialog.js:1166:27 @resource:///org/gnome/shell/ui/init.js:21:20
```
Follow the suggestion and add a try-catch block in order to reveal
what the error is. In the catch phase, reset the faded AuthPrompt
otherwise we can't retry with another user.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3448>
The corner pipelines state theme node paint state was not necessarily
free of existing pipelines, so make sure to free them before looking up
new ones.
This avoids leaking thousands of CoglPipeline instances after toggling
the overview a bunch of times.
Fixes: e1868cab1a ("st/theme-node-drawing: Factor in border radius in update_resources()")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3421>
During session startup, we have the following chain:
LayoutManager._prepareStartupAnimation()
`- LayoutManager._startupAnimation()
`- LayoutManager._startupAnimationComplete() (a)
| or
`- LayoutManager._startupAnimationGreeter() (b)
| or
`- LayoutManager._startupAnimationSession() (c)
`- Overview.runStartupAnimation() (d)
`- OverviewActor.runStartupAnimation() (e)
`- ControlsManager.runStartupAnimation() (f)
Branch (b) calls LayoutManager._startupAnimationComplete() once the
animation is complete. Branch (c) does the same, except that
ControlsManager.runStartupAnimation() is an async function that awaits
LayoutManager.ensureAllocation().
LayoutManager._prepareStartupAnimation() is an `async` function, and its
caller catches & logs any error it raises.
Previously, ControlsManager.runStartupAnimation() – (f) in the above
diagram – was declared `async`, because it uses `await` internally, but
also accepted a callback, which was called on successful completion of
the function and the animation it triggers.
If an exception is raised during execution of the function, its callback
would never be called, and because the promise it implicitly returns is
discarded, the exception would never be logged either. And, stepping a
few levels up the call stack, the callback that
LayoutManager._startupAnimationSession() (c) provided would never be
called, and so LayoutManager._startupAnimationComplete() would never be
called, meaning the cover pane that prevents input would never be
removed and the session would be unusable.
Remove the callback parameter from ControlsManager.runStartupAnimation()
(f), and instead make it resolve in the case where the callback would
previously have been called.
Remove the callback parameter from OverviewActor.runStartupAnimation()
(e) – it is just a wrapper around ControlsManager.runStartupAnimation().
Adjust Overview.runStartupAnimation() (d) accordingly: rather than
passing a callback to OverviewActor.runStartupAnimation(), await its
return and then proceed. There is a slight behaviour change here:
previously, in the branch where this._syncGrab() is false, the callback
would be called before calling this.hide(), whereas now this.hide() is
called before the async function returns.
Adjust LayoutManager._startupAnimationSession() and its siblings to be
async, rather than each calling _startupAnimationComplete() directly.
Finally, in _prepareStartupAnimation() await _startupAnimation() either
succeeding or failing, and in either case call
_startupAnimationComplete(), removing the cover pane that prevents all
input.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3428>
The portal login window uses WebKit, which is a security-sensitive
component that not all vendors want to support.
Support that case with a build option, and update the captive
portal handler to use the user's default browser if the portal-helper
is disabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3408>
When NetworkManager detects limited connectivity, we currently
pop up the portal helper window immediately. This can both be
disruptive when it happens unexpectedly, and unnoticeable
when it happens during screen lock.
In any case, it seems better to not pop up a window without
explicit user action, so instead show a notification that
launches the portal window when activated.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7688
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3408>
Mutter has a new tool for interacting with mutter with features we don't
expose to users yet. It can be exported as a dbus service but it is not
done so by default. This adds an easy way to do so without having to
remember some JS snippet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3425>
When an app folder is opened it would do so without grabbing the
keyboard focus, so one could not navigate with the arrow keys without
pressing Tab. This adds the focus parameter to popup()'s grab, which
sets the key focus to the elements of the folder when it is opened.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3338>
The AppFolderDialog would lose keyboard focus after editing the title
(likely due to the folder entry grabbing key focus). This commit adds
navigate_focus() to _showFolderLabel() to send key focus back to the
dialog's elements after editing the title.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3338>
In commit e69da36095, Florian Müllner
wrote:
> We currently complete the animation using an onComplete handler,
> which only runs if the corresponding transition was stopped when
> finished.
>
> While it is unexpected that the transition is interrupted, it can
> apparently happen under some circumstances (like VMs with qlx).
> The consequences of that are pretty bad, mainly due to the cover
> pane that prevents input during the animation not getting removed.
>
> Address this by always completing the animation when the transition
> is stopped, regardless of whether it completed or not.
There are effectively four branches of the startup animation:
1. if Meta.is_restart() is true, no animation is run on startup; I
believe this is the X11-only case of restarting the shell
mid-session.
2. if Main.sessionMode.isGreeter is true, just the panel is eased onto
the screen; this is the GDM case.
3. if Main.sessionMode.hasOverview is true, then a whole sequence of
animations are run; this is the normal session case.
4. otherwise, the whole UI zooms in to full size, and from full
transparency to full opacity; this is the Initial Setup case.
The fix above handles cases 2 and 4, but not 3. This patch applies the
same fix to case 3, so that the callback is always called on session
startup even if the transition is interrupted.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3422>
All styling currently happens on the ScrollView child, which
means that instead of a scrollbar inside the dialog to move
the content, we have a scrollbar next to the dialog that moves
the dialog as a whole.
Fix this by simply moving the style classes to the up-most parent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3414>
Now that we no longer provide a portal implementation ourselves,
the only expected callers are the GNOME portal implementation
and (since recently) the remote desktop daemon.
Make that explicit and restrict callers to these senders, like
we do for other D-Bus APIs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3411>
Try h264 on intel and AMD hardware using VA-API, using vapostproc
to do the color conversion using specialized hardware. We're not adding
a vaapi pipeline using the color conversion GL shader here, as vapostproc
color conversion should be better suited for anything needed by vaapi
based encoders/decoders.
A capsfilter is used to enforce the use of DMAbuf (memory:DMABuf) with
the new explicit modifier API (format=DMA_DRM).
Also, we're using the new va* gst elements instead of the vaapi* ones
here, as the vaapi* elements are deprecated, while the va* elements are
actively maintained.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2080>
Not until we've waited for leisure can we make precise assumptions about
otherwise animated actors sizes and positions, so do that before
checking fittsiness.
This should fix the flakyness of the fittsy test case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3398>
If `params` is floating when provided by the caller, and if one of the
early return paths is taken from this function, the call into GIO never
sinks and takes ownership of the `GVariant`, and hence it’s leaked.
Always explicitly sink the input variant as soon as the function is
called, then it can’t be leaked.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3396>
Currently overview windows added in workspace constructor lack monitoring
the skip-taskbar property. All other windows added after this have
this monitoring.
This uses existing code to correctly add the signal and removes all redundant
code.
It also insures all transients are handled correctly on initialization using
the existing code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3386>
If there's a window flowing over the left edge in a workspace, the
animation of showing or hiding overview in the left adjacent workspace
would glitch, as the window would appear or disappear suddenly.
This commits tries to fix it by making sure the active workspace are
above other workspaces when updating workspaces or active workspace
changed in workspacesView.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7364
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3378>
The reduced border radius from st_theme_node_reduce_border_radius() depends
on the allocation size, and when it changes, has_large_corners can change.
has_large_corners is used to determine whether to pre-render using cairo,
so that means a change to the allocation size can influence whether the
pre-render using cairo should happen or not.
On changes to the allocation size we don't want to call render_resources()
though, but just update_resources() instead. And since we know now that
changes to the allocation size might cause pre-rendering to get enabled
or disabled, we need to do the "should pre-render" checks in
update_resources(), too.
So factor out those "should pre-render" checks into a new function
st_theme_node_maybe_prerender_background(), and then call that function from
both render_resources() and update_resources().
This fixes rendering artifacts with borders or rounded corners after changes
to the actor size.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6567
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3354>
If the new CSS functions added in commit c593aecbde
are used wrongly, an expected argument may be missing.
The code checks for that, but only after dereferencing
it to assign the next argument. Fix that by splitting
up the checks.
Spotted by coverity.
CID: #462818
Fixes: c593aecbde ("st/theme-node: Implement extensions for accent
color")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3380>
When not logged in, the New Issue URL only redirects to an unhelpful
login page while the Issues page allows you to search for existing
issues and still offers a "New Issue" button.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3377>
Add -st-accent-color and -st-fg-accent-color so that these colors can be
accessed from CSS.
Since they are often transformed in SCSS atm, add st-transparentize(),
st-mix(), st-lighten(), st-darken() that work in runtime.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2715>
Switch to render nodes. Most of the changes follow the pattern of
replacing a cogl_framebuffer_draw_*() call by (1) creating a paint
node, and (2) calling the corresponding clutter_paint_node_add_*()
API.
StWidget now overrides ClutterActor.paint_node(), instead of paint.
All subclasses that overrided the paint vfunc also are changed to
override paint_node.
The entry point for CSS rendering, st_widget_paint_background(), now
receives a root ClutterPaintNode, and propagates it to the rendering
machinery.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1538>
CredentialManagers emit a user-authenticated signal with a token
upon a successful authentication. This marks the service as preempting
and will be used for the next login/unlock request. However, the
preempting service is not cleaned after a successful verification.
As a consequence, it will be picked on a second unlock request.
This doesn't happen after a succesful login request because there
is a transition from the gnome-shell process owened by GDM to the
one owned by the user.
Clean the preempting service on a successful verification, like we
do when the PAM conversation stops.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3291>
`g_desktop_app_info_launch_uris_as_manager_with_fds()` was added
in GIO 2.57.2. We now depend on at least 2.79.2, so we no longer
need a fallback path for the case the function isn't available.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3361>
After the subproject moved to a meson wrap, its checkout is no
longer managed by gitlab.
While meson will take care of checking out required submodules
during setup, this will not happen for `test` or `dist`, so store
the checked out code in artifacts.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3370>
We set the expand-fraction property of the workspace thumbnails on changes
to their should-show property. The should-show property defaults to true, and
the expand-fraction property defaults to 1. The should-show property gets
updated in the constructor of the ThumbnailsBox though, and it might become
false (that is the case when starting up the shell) during construction.
In this case we're not yet listening to "notify::should-show" in the
ControlsManager, and therefore forget to update the expand-fraction
accordingly. Fix that and ensure the expandFraction is always set to the value
we expect after hiding or showing the thumbnails (we call _updateThumbnailsBox()
from _update(), which we call in the constructor).
This should be the proper fix for the problem that 9bf550da8 (which caused
the workspace thumbnails to never show) originally tried to fix.
Fixes: 9bf550da88 ("overviewControls: Set expandFraction for ws thumbnails to 0 when hidden")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7668
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3323>
GtkWidget.set_size_request() enforces a minimum size, while
GtkWidget.set_default_size() simply sets the default size.
The docs of set_size_request() say "In most cases,
gtk_window_set_default_size() is a better choice for toplevel windows", and
in our case it doesn't seem necessary to prohibit the window from having a
smaller size, so switch to using the default_width and default_height
properties.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3307>
The template currently fails with the deployed gitlab/podman.
Let's not block all merge requests on a job that is only relevant
to the Extensions app, so disable it temporarily until the issue
is sorted.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3358>
This was the type the function expected, but we were actually passing
the global context to it.
This didn't crash for some reason, but indeed it was wrong and we didn't
catch it because mutter side had not type-checks either
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3355>
There are cases where it makes sense to have fillPreferencesWindow be
async, so await it. One such case is when using .ui files from resources
with (GTK) templates. When extension developers load the resource in
`fillPreferencesWindow` and then import the js file that registers the
classes, there will be an error at the moment that there is no UI
provided. Similarly, make getPreferencesWidget async optionally.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3348>
Changing type when casting a double pointer is not strictly allowed in
C. In order to fix compilation with `-fstrict-aliasing`, don’t use
`g_clear_pointer()` for clearing this pointer where the type expected by
the destroy notify function does not match the type stored in the
`ShellCameraMonitor` struct.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3351>
If no child setup is provided then all the shell extensions that use
GLib.spawn_async should actually use the shell spawning utils since we
are supposed to always restore the default nofile rlimit on launched
children.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
Using child setup functions is unsafe in gjs code so let's warn if this
happens so that extensions using a similar codepath are warned.
This could be also part of gjs, but we provide a shell override since we
have alternatives to log about.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
In the shell code we often use GLib.spawn_async to launch processes
with a GSpawnChildSetupFunc implementation in JavaScript to reset the
mutter nofile rlimit in the new child process.
However, this is highly unsafe to do because this implies that the child
setup function code is executed in gjs where a lot of allocations are
done and even more not-async-signal-safe code is executed, in fact
leading to dead-locks as reported in the past.
To prevent this, declare a new functions that do the same of the GLib
counterpart but without providing a GSpawnChildSetupFunc that is instead
implemented in the C-side doing the cleanup that mutter requires without
allocations or async-signal-unsafe code.
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6698
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
The child context setup function used as launch GSpawnChildSetupFunc
uses g_object_get that internally potentially allocates memory, making
it not async-signal-safe and so not something that is safe to use in
between fork and exec, so just use the simpler getter here.
Note that the current implementation of app_child_setup() is safe
already as sd_journal_stream_fd, dup2 and close are so.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
In the future, the module will automate uploading the release
tarball. We already use the CI pipeline to generate the tarball,
so it's easy to hook up the module and provide some testing
before the module goes into production.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3340>
We currently assume that the `CI_COMMIT_TAG` variable matches the
version component of the generated dist tarball.
That is usually correct, but sometimes errors happen and a wrong
tag is pushed, and the real release uses something like "46.0-real".
Account for that by building the artifact path from `meson introspect`
and exporting it as environment variable.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3340>
A feature that works for server side decorated windows only that
only adds slightly more convenience over the regular "move" action that
is still there.
Keeping it around would complicate some cleanups in upstream Mutter
so just drop it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3332>
The offset in high contrast mode was moving the dot too close to the
text making the spacing between the text, dot and hover highlight appear
visually unbalanced. Also it was making it more likely to overlap
descenders in the text.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
With the dot now being placed correctly at the bottom of the hover
highlight it is now also overlapping the 1px inset shadow used as
outline in high contrast mode. To avoid this, shift the dot up
accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
The offset was given as a hardcoded (physical) pixel value and did not
take scaling into account. This lead to it being shifted closer towards
the icon as the scale increased.
This now replaces the hardcoded value with a CSS property which
automatically includes the scale factor.
Further this allows simplifying some calculations that previously were
trying to counteract the hardcoded offset using margins by using the
intended offset directly.
With this the dot in the dash is also now placed at exactly the bottom
of the hover highlight, while previously there was an unintentional 1px
space.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7488
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
We currently compute the target scale from the allocated height,
which means that it only becomes available after thumbnails have
been allocated at least once at their expanded height.
As the minimap is initially hidden, this only happens after it is
expanded for the first time, which means the corresponding transition
is not animated.
In order to allow for a fix, compute the target height ourselves
to allow the scale computation to work independently from the
expand factor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3331>
The auth prompt currently propagates all key presses, even the
Escape press that is used to cancel it.
On the lock screen that means that the same event that cancels
the prompt (and switches back to the clock) is *also* propagated
to the handler that activates the prompt on key press.
That handler doesn't do anything when the prompt is already visible,
which is the case when the transition to the clock is animated.
However when animations are disabled, canceling the prompt will
result in a new prompt getting created immediately, and the login
screen is stuck on the prompt.
Fix this by not propagating key events that are used to cancel
the prompt.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3317>
The prompt itself may get destroyed when canceled, in which
case it is no longer possible to chain up in the vfunc.
This is usually not an issue as the prompt is only destroyed
at the end of a transition, but it results in a warning if
animations are disabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3317>
The main use of the --dist flag is as a fallback when the CI
dist job doesn't work for some reason. The gnome-shell tarball
now needs the --include-subprojects flag, and it doesn't hurt
for mutter/gnome-shell-extensions, so just add it when --dist
is specified.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3164>
jasmine-gjs isn't widely available in distributions, so instead
of adding an obscure build dependency, include the subproject
in the tarball.
The --include-subprojects flag only applies to subprojects that
are used in the build, so we do not bundle gi-docgen that is
provided in the mutter image.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3164>
Jasmine[0] is a popular testing framework for javascript, which
gjs itself has used in a heavily customized form for its own
unit tests for years.
It's far superior to the very rudimentary `jsUnit` module that
is still included with gjs, and the jasmine-gjs project provides
a general-purpose wrapper for gjs apps.
Set up the necessary build infrastructure to run unit tests
through jasmine. That allows for existing unit tests to be
ported one-by-one.
[0] https://jasmine.github.io/index.html
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3164>
We build a small run-js-test executable so tests run in a
similar environment as gnome-shell, and then wrap it with
a generated script that provides environment variables like
GI_TYPELIB_PATH.
This is more complicated than it needs to be, we can just as
well set up the typelib search path from the runner and pass
in the environment via meson.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3164>
gsettings overrides can be in affect when XDG_CURRENT_DESKTOP is set. We
need predictable default values for predictable tests in mutter and thus
mutter will start asserting that GSETTINGS_BACKEND='memory' and
XDG_CURRENT_DESKTOP=''.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3329>
The fingerprint device fetching code has a generic error handler,
that assumes the passed in error is GError. If it's not a
GError it will fail trying to use GError specific methods.
This commit adds some validation checking.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3319>
We no longer provide a portal implementation, so there's no need
for owning the name. Right now only the gnome portal consumes
the API, and that accesses it under "org.gnome.Shell".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3326>
The dash currently doesn't enforce any spacing when it comes to the left and
right edges of the monitor. With the right amount of icons, it will come
very close to or even touch the edge.
Make sure this "edge case" also looks good by adding a padding to the left
and right of the container.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
We use the pagePadding to adjust for the large indicators that we add on the
left and right of the appGrid.
While the original padding needs to be applied to the padding for the
indicators (as it was in super.vfunc_style_changed already), there's no
reason to add an extra row and column spacing to the pagePadding on all
sides, so remove that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
We multiply the spacing around the workspace thumbnails with the
expandFraction so that it grows with the animation to show/hide them. We
shouldn't factor in the extra spacing to accomodate for the thumbnails in
case they're hidden though, so make sure expandFraction is set to 0 after
the thumbnails got hidden.
This fixes the spacing when a user never uses workspaces (and the workspace
thumbnails are never shown), and also the first transition from
hidden->shown for the thumbnails, which currently starts at 100% scale (ie.
pops into existence).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
With a previous commit we've made the overall dynamic spacing dynamic, but
the spacing is now a bit much when it comes to the space between search and
workspaces minimap, just as workspaces minimap and large workspaces.
The minimap should somewhat "squeeze into the empty space" here, so
reduce the spacings above and below it a bit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
The naming of the appGridBox is quite confusing, as it actually
describes the box of the workspaces strip, but in the appGrid state of
the overview. Change that name and call it workspacesBox instead, which
seems to make more sense here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
With the addition of notification headers, we no longer include
an icon with every notification, but only when the notification
explicitly specifies an icon (other than the app icon).
After those changes, it makes more sense to use the icon as
provided by the app than forcing the symbolic style (which
only works for themed icons anyway).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7620
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3296>
It can be useful to know whether an icon displays a symbolic (rather
than just requesting it). Add a new :is-symbolic property for that
purpose, backed by private API on StImageContent that allows the
texture cache to shuffle that information through to the icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3296>
After the recent notification changes, the title may still be null
when the source is originally added. Handle that case and make sure
we pick up later title changes by setting up a property binding.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3308>
Adding a notification clearly constitutes a count change, but
the notify call was accidentally dropped during the overhaul
of the notification API.
Fixes: 34f05b075b ("messageTray: Let the tray decide whether to show a
banner")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3308>
Sometimes the test runners are saturated with other work. Bump the test
timeouts by a multiplier of 5 with the hope that they now will be much
more likely to have time to finish in time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3299>
The fallback path broke when we removed support for window icons.
Nowadays we track all windows, and as a result should always have an
associated app (although not necessarily backed by a .desktop file),
so this shouldn't make a difference in practice. Not to mention that
external docks (like cairo-dock) are extremely rare themselves now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3295>
Currently we're using relative positioning when sending click events to
tray icon clients, and this leads to some apps (especially Qt ones) to
try to open the menus at such absolute coordinate under X11.
To prevent this to happen, let's get the root coordinate from the xembed
and let's use it to compute the synthetic event root x/y.
We could have even used the actual event position for this, but getting
it from the xembed makes this more consistent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3283>
The format of the .desktop file names and their StartupWMClass of
Chromium and Chrome shortcuts has changed, so update the docs to match
the most recent versions of these web browsers.
The user interface to create shortcuts has also changed. They are no
longer created through a "Tools" menu (which doesn't exist anymore), but
rather through a "Save and share" menu. So add that to the docs as well.
Finally, replace the examples using the GNOME Wiki with examples using
the new GNOME Developer Handbook.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7482
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3289>
Override redirect windows manage their own positioning and size alone
and are always sticky, so we're not covering them either with the
animation MonitorsGroup, and thus there's no need to clone them or we'd
end up having two windows painted.
This was causing the shell tray icon window actors (that have no opacity
by default but that are override redirect) to show up during the
animation as their clone animation is not 0.
The other option would be hide them during the animation phase, but
there's no need for this.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3285>
'icon-missing' is not an actual icon name. It somewhat works
because an invalid icon name will fallback to the correct
'image-missing', however for apps the generic app icon is
a better fallback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3248>
Simply looking at the return value of sd_pid_get_user_unit can be used
to determine if the process is in a systemd unit, but it doesn't say if
gnome-shell is managed by systemd.
For example, running toolbx on a host with systemd creates a libpod
unit, even if the gnome-shell that gets started in the toolbx is itself
not managed by systemd.
We can make sure that gnome-shell is managed by systemd simply by
checking if the unit we're running starts with org.gnome.Shell.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3267>
meta_selection_source_memory_new previously had some precondition checks
which would return NULL if the mimetype is NULL but now that it returns
an error we can't do that anymore.
Move the precondition checks to the caller instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3260>
Without this flag, changes resulting in invalid gschemas are ignored and
easily lost within the compilation input. In CI and some development
workflows this may let bad builds through.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3262>
Setting `useBodyMarkup` to `true` fails with:
JS ERROR: TypeError: this.setBody is not a function
set useBodyMarkup@resource:///org/gnome/shell/ui/messageList.js:585:14
Fixes: f0e863f529 "messageList: Use GObject properties for Message"
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3232>
The fallback for creating models is to try the next one in case the current
one can not be created, until we fall all the way back to the US layout.
Obviously we shouldn't fall back in case creating the model actually worked,
so break out of the loop and then use the new model.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3230>
Using two actor to display collapsed and expanded body creates a small
flicker when switching between the actors, since we can resize the actor
we can just use one actor and resize it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
Setting the `datetime` property whenever a notification is updated is
tedious and error-prone. Therefore, whenever properties, other then
`acknowledged` and `datetime`, of a notification change update the
`datetime` property to the current time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
This removes the `createBanner()` method on `Notification` and `Source`.
Since we want to use the same widget for the calendar and the banner,
let's not allow to create custom widgets just for the banner.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
Stop using custom buttons for notification actions. The only reason to
use custom buttons was so that we could add icons next to the button
label, if we really need the icons next to the label we can add icons to
the notification API.
By using the actions API we can ensure that buttons always look the
same without additional work.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
Actually link a notification source with an app instead of just to
its app name and PID, which in many cases don't really identify an
app. E.g. for portal applications the PID points to the
xdg-desktop-portal.
Use the app when ever possible but keep using the app name and PID
as a fallback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
A notification can have two ways to specify a sound, via a name of a
sound in the sound theme and/or a file. Therefore introduce an object
that can hold both properties and creates an abstraction over the
different source. This reduces the number of properties for a
notification, which will make it simpler to port it to GObject
properties.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3173>
Since commit 9c2da01a9, the avatar's child is expanded to account
for the new St.Bin behavior. However as expand flags are propagated
up, this now results in avatar actor getting unintentionally expanded
in places like the end-session dialog.
Stop this by explicitly setting the avatar actor to not expand.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3221>
NetworkManagers NmClient has a bug for wireguard connections where the
notify::active-connections and connection-added are emitted in the wrong order:
When a wireguard connection gets activated, notify::active-connections is
emitted first, then connection-added happens.
We currently expect these signals to emitted in the correct order, so our VPN
toggle is not actually updated when a wireguard connection is established.
Until this bug is fixed in NetworkManager, work it around by calling
_syncActiveConnections() manually after we see ::connection-added.
NM issue: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1483
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6656
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3219>
Some extensions try to destroy the provided dialog, so they can
instead show the preferences in an alternative way.
Unfortunately that is undetectable from the Extensions service,
which still thinks the dialog is open, and will therefore block
other prefs dialogs.
Try to steer extensions away from that anti-pattern (or at the
very least switch to `close()` which doesn't break) by overriding
the window's destroy() method and show an extension error instead.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7435
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3209>
Add pipelinea for h264 software encoding using openh264. This is the least
problematic (from a patent perspective) software encoder for h264, Fedora
ships it in a pre-installed repo and it can be enabled very easily. Most
people should have it enabled already to allow for decoding of h264 content.
Unlike vp8enc, this encoder is optimized for realtime and is really fast, it
outperforms the vp8 encoder by an order of magnitude and should allow for
smooth recordings even on older hardware.
The reason why mp4 was chosen as a container format over mkv is that mp4
can be played inside firefox and chromium, whereas mkv can't be played.
It's ensured that the mp4 file is still playable in case the recording
got cancelled by using the "first-moov-then-finalise" fragment-mode on
mp4mux.
Even though h264 is problematic from a patent perspective and often can't
be shipped by default, it still the best supported and most popular codec
out there. The software encoders and decoders are really fast, it's used
everywhere on the web, and it can be hardware decoded on almost any device
out there.
See also: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2080https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7335
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3211>
Depending on the encoder we want to use a different container format and
therefore a different file extension. Right now this file extension is
forced to be webm, so shuffle things around a bit to make that more
dynamic.
Note that this also introduces removing for the old file created by the
recorder, otherwise it would create an empty "mp4" file every time it
falls back from "mp4" to "webm".
To be nice to external (ie. not gnome-shell) consumers of the
screencastService, let's not break the API completely, and detect the
".webm" suffix a little longer to not end up with weird file.webm.webm
filenames.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3211>
When the stop conflicting session dialog is opened, use a timeout of 60
seconds to close it.
This is an attempt to keep security in the situation where the user leaves,
the system is left unsupervised and the dialog is opened; allowing anyone
to stop the old session and start a new session.
When the dialog is closed by the timeout, a notification apperars informing
about that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3134>
When opening a session, find if there's already a session opened for the
same user with the help of Loginmanager.
When it's found, display the conflicting session dialog.
The logout dialog allows shutting down the conflicting session using the
greeter dbus method "StopConflictingSession".
If the dialog is already opened and the conflicting session has been
closed on its side, the new session will start.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3134>
These changes will be used by the next commit when displaying a
conflicting session dialog.
session-removed signal will be used to close the conflicting session dialog
if it's not needed anymore.
getSession method will be used when a session is opened, to check if
there's already a conflicting opened session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3134>
Forward these from the IM, and handle the ones involving
the OSK state: lowercase/uppercase/auto_capitalization/titlecase.
The latter two involve peeking at the surrounding text, to figure
out if it makes sense to toggle keyboard level.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
The ibus-typing-booster IM module is already meant to do the "right"
thing when the IBus.Capabilite.OSK hint is passed to the IM. We do
already honor that hint (commit 23bfd08b3c), and ibus-typing-booster
has been doing this for a reasonably long time (first release seems
to be 2.19.9 dated 2 years ago, current is 2.24.12).
Drop this mangling of foreign settings, and let ibus-typing-booster
figure out the optimal configuration given the presence of an OSK.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Move the complex parts of this mechanism from the Keyboard object
to the KeyboardController object, replaced by code that is easier to
follow.
Also, keyval guessing is deferred to a later point in the commit
procedure so so it does not happen for a single character only,
this way we can send multi-character input through the IM, which
is necessary for some OSK layouts.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7190
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
We only support "latched" which stays toggled on for a single
character unless long-pressed. Support "default" mode explicitly
to switch back to the default level, leaving "locked" implicitly
supported as the way to stay in the same level.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
This is already covered by a timeout to handle focus transitions between
windows at the Clutter.InputMethod implementation, we can react immediately
and avoid chaining up timeouts.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Since we now just store the current group, we do not need to track
closely source changes vs selection changes in the available sources.
We just re-generate the current OSK keymap for all, so coalesce both
signals into a more generic "group-changed".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
And fix it so it is effective again. This is a small piece of
smarts the code needs to earn, so that keys with the "emoji"
action are hidden, and their width assigned to the next key.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
And drop some more guesswork in the code, since some layouts have
less than 4 levels. This also allows for having OSK maps with more
than 4 levels. Let us hope that the sanity of our future kin will
remain below that threshold.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Drop some code, in favor of a numeric keypad that is driven through
the same JSON-based maps. This is also a first use of the "height"
key property in the JSON files, for the Enter key.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Do not hardcode the us-terminal OSK keymap, and append '-extended'
to the current group name, accounting with the existing 'us' fallback.
This allows for concerned individuals to propose language-specific
terminal layouts.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
This will allow OSK descriptions to declare "tall" keys. May be
used in combination with the "start" property added in previous
commits, in case a gap needs to be explicitly left.
No OSK description uses this yet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
This optional property defines the offset the a key should have
relative to the previous key (on its left) or the start of the
column if it is the first key. If this property is not
present, the key will be placed with no relative offset.
This for example allows keymaps to explicitly define the padding
of the rows that are not "full" relative to other rows, without
guesswork in the code. It is used for this purpose in the
keymaps/levels/rows that needed it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3162>
Previously backspace would only ever remove a single character left of
the cursor, regardless of selection.
This requires the application to correctly set the anchor position in
text_input::set_surrounding_text(), which currently only gtk4 seems to
do. When there is no selection or on other applications that always set
cursor = anchor, like gtk3 does, the behavior is not changed and still
only deletes one character.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2746>
Since mutter@33088d59 the cursor we receive from mutter already is a
character index while the code here still treated it like a byte offset.
Further the code to detect the previous word position was treating the
cursor parameter already like a character index, while passing the
cursor that was prior to that commit a byte offset.
The function also had some unreachable and redundant code paths. The
pos < 0 case can never be reached due to the max(). Also the regex
already ensures that all whitespace is considered, so the code to remove
spaces not actually do anything except when deleting the first word in
the text, in which it would cause the first character to not get
deleted.
Also it was not handling characters with more than 2 bytes correctly. In
the presence of these JS string functions, such as search(), can not be
considered to operate on character indices anymore but rather the number
of UTF-16 byte pairs. Issues with this can be avoided by using
iterators, which unlike anything else iterate on characters, not byte
pairs and by not using the results returned by JS string functions for
anything but JS strings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2746>
Given that this may lead to the shell to hang on gdm startup, and that
we expect the service to be up and running quickly, we can safely set a
5 seconds timeout instead of using the longer GLib proxy defaults.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
Since fingerprint service can now be started also if a conversation has
already began, we can also initialize the proxy asynchronously, without
the risk that the service won't be started early enough.
As per this, remove the usage of FprintDeviceProxy wrapper completely
since it's just not giving us anything here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
On ShellUserVerifier construction we used to start fprintd in a sync
fashion all the times, however in case the daemon had startup failures
or was hanging for whatever reason (like due to devices probing, given
that fprintd synchronously wait for them all to be initialized) we used
to just fail, leaving gdm or the lockscreen in a not usable state.
While this could be prevented with a try/catch statement, there's no
much point to wait for fprintd if that's not the default authentication
service, and so:
- If we use gdm-fingerprint as default auth method, use a sync call to
initialize it and in case of failures, just continue with fallback
authentication mechanism (password)
- Otherwise, asynchronously initialize fprintd and continue with the
ShellUserVerifier without fingerprint support until we got a reply.
In case the service fails to deliver us a result, we don't give up
but we will try doing that at each authentication via
_checkForFingerprintReader().
In case all works properly, as per the previous commit, once the
initialization is done, we'll start the fingerprint PAM gdm service.
Fixes#5168
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
If fingerprint service is not replying fast enough to our async request,
authentication is started but the fingerprint service is never started.
So, in case the fingerprint type information is received after that the
authentication has been started, let's start the service.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
There's no point to initialize the fprint proxy and the smartcard
manager if they are disabled in authentication settings, so just avoid
initializing them, but at the same time this implies tracking of user
changes and so:
- If a new service has been enabled, we initialize it
- If a service has been disabled we destroy it and reset the
authentication if such service was currently active
In both cases we do update the default service.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
If we have a late activation of a service backend we may need to check
whether it has been already started, and in case it has not, we can try
loading it.
So rely on gdm to see what service has been started, instead of handling
it manually on our side only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2267>
Its parent `lockDialogGroup` has exactly the same background-color
set in the same file. Giving them both the same wasted render time on
overdraw, and caused multi-layer blending artifacts (slight flickering
of the grey background) when the login dialog fades in/out.
While the flicker can also be fixed using `set_offscreen_redirect`,
there's no point adding that overhead when the extra layer doesn't need
to be painted. Removing it halves the average render time of the login
animation.
Closes: https://bugs.launchpad.net/bugs/2036388
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3207>
Since the launch context may also be used to activate an action on an
running application with an already existing window, which we don't
necessarily want to move to a different workspace, don't set a workspace
for the launch context. If no active window exists for an application
then it will be place on the currently active workspace anyways.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3198>
There are multiple different places where we activate an app action,
but none set the correct activation token. Therefore this adds an async
method to to call `ActivateAction` on `org.freedesktop.Appliaction`
with the correct activation token/startup id as platform data.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3198>
We auto-close FDO notifications when the sender leaves the bus,
given that the protocol was created without persistency in mind
and any action will become invalid.
However that broke when moving the public-facing implementation
into a separate service, as we now track the (always running)
service instead of the original sender.
Fix that by forwarding the sender to the internal implementation
via a private hint, just like we already do for the PID.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3204>
The hint is a private implementation detail between the public
and internal services, not something anybody else should set
(*cough* libnotify *cough*).
Prefix the name to hopefully make that clearer.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3204>
commit c8bb45b41c introduced a new
verification state, VERIFICATION_IN_PROGRESS, to detect when the user
has already interacted with the authentication prompt, so the
prompt can rate limit the number of times the user can cancel
authentication attempts with the escape key (without also rate limiting
the number of times they can hit escape to go back to the clock without
interacting with the prompt).
That means there are now two states that represent the user actively
undergoing verification: VERIFYING and VERIFICATION_IN_PROGRESS.
It's inappropriate to reset the smartcard service if the user is
actively conversing with it. We try to check for that by looking at the
original verification state, VERIFYING, but we unfortunately, neglect
to account for the new VERIFICATION_IN_PROGRESS state.
The result is that if a user types their smartcard pin at the clock,
and then inserts their smartcard, the pin will get cleared instead of
used, and they have to retype it again.
This commit fixes the oversight, and allows users to again pre-type
their smartcard pin at the clock before inserting their smartcard.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2765>
Both timestamp and options parameters have been unused since
the switch to Clutter.grab(), so remove them.
Stop using Params.parse(), so that code that still passes the
parameters doesn't throw an error.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3195>
Currently extensions can only be locked down completely by
restricting the `enabled-extensions` key via dconf.
This is too restrictive for environments that want to allow users
to customize their system with extensions, while still limiting
the set of possible extensions.
To fill that gap, add a new `allow-extension-installation` setting,
which restricts extensions to system extensions when disabled.
As the setting is mainly intended for locking down by system
administrators, there is no attempt to load/unload extensions
on settings changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3180>
Since the last commit, we have infrastructure in place in the ScreencastService
to blocklist pipelines which crashed the recorder.
If such a crash happens a few minutes into a screencast, we can't do any better
than telling the user about the problem and encouraging them to try again (with
the faulty pipeline now blocklisted).
If the crash happens while starting the recording though, we can actually do
better: We can try to auto-restart the ScreencastService ourselves, and the
recording might still succeed without the user noticing anything. So retry
that start of the recorder for two more times, and then finally give up.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
When gstreamer crashes during recording, it pulls the whole screencastService
down with it.
These crashes are typically caused by the gstreamer pipeline that's in use,
so to avoid running into them again and again, we can blocklist the last
used pipeline in case the recorder didn't shut down (aka crashed) last time.
To store this state, create a file (gnome-shell-screencast-pipeline-blocklist)
in the XDG runtime dir and store the ID of the current pipeline in that file
before we try to start.
Now when we crash while running the pipeline, the entry in that file will stay
around and we'll pick it up on the next start of the screencastService as a
blocklist.
When the recording was successful on the other hand, we'll call
`this._updateServiceCrashBlocklist([...this._blocklistFromPreviousCrashes])`
and remove the new entry from the file again before shutting down the recorder.
In addition to that, we can now encourage the user to try recording again
after a crash happened. Adjust the failure notification a bit to say
"please try again".
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6747
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
Since we now propagate error types back to gnome-shell now, let's start
with showing a special error message in case the disk ran out of space,
which is probably the most typical error.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
When the screencast fails to start, we currently don't really inform the
user, other than the red screencasting indicator in the panel going away.
Re-use the failure handling paths to also show a notification when the
screencast fails to start. The notification in this case obviously should
not have an action to open a file (there is no file), so make that depend
on whether this._screencastPath is set and unset the path.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
We'll be using hardware encoding for screencasts soon, so we'll likely see
more things go wrong in the future, including crashes of the whole
screencastService. To deal with this, we'll introduce logic to blocklist
certain recording pipelines in case of failure and also add some logic
to retry the recording automatically.
To allow for better messaging to the user in those failure cases, we want
to be aware in gnome-shell, what exactly the error in the recorder was.
So propagate the most common types of errors that can happen in the
ScreencastService to gnome-shell using the new DBusError module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2976>
Commit 932ccac1 changed Source to use a regular constructor
instead of `_init()`.
Unfortunately that results in ordering issues for subclasses
that override `_createPolicy()`, if that method needs to access
any properties that are set in the constructor (as `this` is
only available after chaining up to the parent).
We can fix that by simply setting the policy from the constructor,
instead of relying on some overriden method being called.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3170>
We have several places where we create an application policy
from an app if possible, and fall back to a generic policy
otherwise.
Make that more convenient by adding a small helper method.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3170>
Since commit 932ccac1c2, the Source constructor takes a
properties object instead of individual arguments.
That means that the policy may now be set through a construct
property, and we shouldn't override it if that was the case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3170>
This is to make it generally more in line with the stylesheet as well
as to resolve the blue and white bleeding together in dark mode.
It's also consistent with switches in recent mockups.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3077>
Ideally, the use case we have for MetaGroup would be removed but that
requires investigation that could be done as a future step
The function also expects a MetaWindowX11, so add a check to ensure
we don't crash at runtime if the function gets called on a wayland
client
Also removes an unused header import
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3157>
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>
Generating the enums from a list of names means that developers
have to deduce the names of enum members themselves. That's more
important than a bit more convenience when adding a new enum, so
instead spell out the exported enums, and use the enums directly
when registering a domain.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3160>
Extensions like dash-to-dock use set_icon_geometry() to window.
This changes the dest and scale of ease animation of minimize and
makes it looks very strange. By setting dest opacity to 0 the animation
could be more natural.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2968>
Screencasts can be disabled for various reasons:
1. the service is not available (missing plugin etc.)
2. screencasts are not allowed by the session mode
(lock screen etc.)
3. the UI is invoked in screenshot-only mode (portal)
Currently each of those conditions is handled in a different
code path, which means that later conditions can re-enable
the button.
There's also an inconsistency whether disabling the button
is done via visibility or reactivity, which still allows
toggling the hidden button via shortcuts (although a hidden
button means that screencasts aren't supported at all, so
nothing will be recorded in that case).
Address this by updating the button from a dedicated function.
Fixes: 671df28a50 ("screenshot: Only handle mode-switch shortcut when
supported")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7358
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3155>
The ID is currently hard-coded to the non-development one, with
the result that the .Devel app effectively doesn't have any
metainfo.
Fix that by configuring the file with the correct ID.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3158>
We sometimes return custom D-Bus errors. Right now those errors
are ad-hoc, which means receivers don't have a proper way of
checking whether a thrown GLib.Error corresponds to a particular
remote error.
In order to change that, we should define proper error enums and
domains, and register them with GDBus, so that there is an automatic
mapping between D-Bus errors and GLib.Errors.
The new module doesn't export any domains or enums yet, but provides
internal tooling to make these exports more convenient.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3159>
Returning a GLib.Error from a method invocation will encode the
error when sent over the wire. In case the error itself is already
an encoded remote error, just passing it on will result in double
wrapping.
Avoid that by stripping any remote error information before
returning it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3159>
Pipelines for non-protected branches are set to 'manual', and
thus cheap. However they may still get picked by `@marge-bot`,
meaning that the bot waits for the completion of a pipeline that
never starts.
Avoid that by not creating pipelines for branches with open
merge requests.
Credit to Jordan, who came up with this for gst.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3153>
This object contains only the `title` and `icon` of a
`MessageTray.Source` which allows using it for sources
that aren't notification sources like mpris.
The old `MessageTray.Source` isn't renamed to something
less generic to not break API. Once we have a good reason
we should rename it to something more specific.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103>
Even though the comment in the code says that sources are reused even
thought the app title has changed this is actually not the case. Therefore
when ever the app title of a notification changes a new `Source` is
created. Therefore there is no point in setting the app title again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103>
As the notification redesign affects the API anyway, we can just
as well use the opportunity to modernize the code.
Turning the icon into a GObject property means we no longer need
a custom signal for change notifications, and the icon becomes
usable in bindings.
Since setting an `GThemedIcon` is common this also adds a convenience
property to set the icon name directly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3103>
They use API from Clutter.Rectangle which hasn't been used in the
magnifier since commit c815979f, and has since been removed from
Clutter altogether.
Since the methods are unused, remove them instead of fixing them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2037>
If something grabs the key focus while a modal is pushed, keeping
key-focus on that actor seems like the smarter thing to do than setting
it back to the last focus after the modal gets popped again. So check if
the key focus actor that we set when pushing the modal got changed when
popping that modal, and if it got changed, simply don't touch key focus.
This fixes a bug with the close dialog, where key focus isn't correctly
set to the dialog after alt-tabbing to a window showing a close dialog.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/786>
When setting the key focus to `this._dialog`, the default button is not
automatically focused and no button has key focus.
Use the `initialKeyFocus` property of the dialog instead, and set focus
to the default button if the dialog is not already focused.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/786>
It sounds strange that buttons would admit Pango markup
in their label text. It sounds better to default to plain
text, and let users wanting markup to access the child
directly.
This also makes the first label being set consistent
with later text being assigned wrt markup usage, since
the non-markup ClutterText API is used if the child is
already present and of the expected type.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3149>
Small and well-defined feature requests can be very useful, but
unfortunately too many are neither small nor well-defined.
Try to improve on that by adding another README section that
explains that changes need design approval, and points to
appropriate places to have broader design discussions,
hopefully without being too off-putting.
While this is unlikely to stop all "bad" feature requests, it
at least gives us something to point to when closing requests.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
We currently just link to the issue tracker without providing
any further guidance.
Improve on that by pointing to the appropriate handbook chapter,
point out extensions as a possible source of issues, and direct
users towards discourse/matrix for support/discussions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
The link to the GNOME schedule was added because of some confusion
of which versions are supported upstream. Briefly outline the
policy of "last two stable + current main", so that the information
can also be deduced from tags etc. without scrolling through the
schedule calendar.
While at it, update the link to the schedule to point to the
future release.gnome.org page.
Death to the wiki!
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
The current debugging page on the wiki is fairly outdated and
very X11-centric, so base the new page on the recently added
mutter documentation instead, but with a bigger focus on
Javascript debugging.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
While we use the standard meson build steps, our dependencies
are non-trivial and running the shell can be tricky; it's
certainly worth documenting.
This is also a good opportunity for plugging out toolbox tooling.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
We have a fair bit of C code, yet don't document the expected
coding style. This is not much of an issue for regular GNOME
contributors as we are following the conventions of the wider
project (glib, gtk, clutter, ...), but it's still better to
spell it out.
Do that by adapting the corresponding documentation from mutter.
Even if much of our C code doesn't match all the new guidelines,
it's good to consolidate the coding style between both projects.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
Start consolidating project-wide documentation in the docs/ folder.
While at it, change the name `js-coding-style`, which is both less
ominous and allows for an accompanying `c-coding-style`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
Mutter's documentation was extended recently, with files using a
pattern of `some-stuff.md`. There is no strong argument for using
camel case, so switch to the same pattern as mutter to remove some
unnecessary friction for people who contribute to both projects.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3122>
To avoid having the coding style get out of sync with the actual
coding style in the future, run eslint on the individual snippets
when either the guide or the linter config change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3146>
Now that StIcon updates its texture automatically on icon theme
changes, we only have to recreate icon actors that aren't StIcons.
(This probably only applies to the folder icon in the app grid
where the sub-icons do use St.Icon, but making that assumption
feels dodgy with an API as generic as `createIcon()`)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3141>
St.Icon is very commonly used for displaying themed icons, yet so
far updating the icon on icon theme changes is left to the caller.
Unsurprisingly, very few actually do that, with the result that
for most icons, icon theme changes only take effect after a delay
(say, a color change on hover) or not at all.
This is also inconsistent with GTK, where Gtk.Image will automatically
pick up icon theme changes.
Address this by tracking whether the current icon corresponds to
a themed icon, and update it automatically on theme changes if
it does.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3141>
Since commit c570011 dropped the `with` statement, this bit of
the test has only checked for writes to a specific variable
in the file.
There is no direct replacement for `with` here, the best we can
do (I think) is comparing property names on the global objects
before and after the `eval()` call.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3132>
Since commit a466029374, the activities button uses the standard
`:checked` pseudo class in the overview instead of the custom
`:overview`.
As a side effect, the generic handling of the `CHECKED` Atk state
in StWidget now covers the case, and we no longer need to manage
the state explicitly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3126>
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>
On wayland, transient windows don't use the DIALOG window type,
so any effects that special-case dialogs currently pick the
wrong animation.
Fix that with an "animation window type" that is used instead
of the real type.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3125>
This produced the following warning:
```
DEPRECATION: Project uses feature that was always broken, and is now
deprecated since '1.3.0': str.format: Value other than strings,
integers, bools, options, dictionaries and lists thereof..
```
The resulting value of `SHELL_BACKGROUND_IMAGE` was indeed bogus, not
containing a proper file path.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3123>
Since StDrawingArea is the only user of ClutterCanvas, it is possible
to move ClutterCanvas completely out of Mutter to gnome-shell. This
allows to remove another Cairo dependency from Mutter.
This patch merges ClutterCanvas code extracted from Mutter to
StDrawingArea.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3098>
The indicators are currently part of the background image in the
high contrast theme. Using symbolic icons instead allows separating
the switch shapes from the high-contrast setting in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3107>
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>
It's useful when the existing build directory became invalid,
for instance after a meson update, and exposing it directly
from the wrapper script is more convenient than removing the
directory or entering the toolbox manually to invoke meson.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3113>
Unlike the other scripts, meson-build currently doesn't set
the `-e` option. The script is mainly a wrapper around a single
toolbox call, but it means that any errors during option parsing
print a warning, but are otherwise ignored.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3113>
Our telepathy component has been optional for years, and it is
disabled by default on major distros, so we cannot assume that
it handles any particular notifications.
Plus Empathy itself is mostly dead, so it's unlikely to be used
much anymore anyway.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3110>
- use a single button mixin for all buttons with a saner 'style' parameter
- rework the entry mixins to be similar to the buttons'
- clear out all unused or deprecated mixins
- create some drawing functions for focus ring and high contrast inset
- replace instances of old mixins with the new
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3109>
Now that xdg-desktop-portal-gnome implements the Access portal
interface, GNOME Shell doesn't have to be the portal backend for
that anymore.
The D-Bus implementation is still preserved, because internally,
xdg-desktop-portal-gnome may still proxy the Access call to GNOME
Shell when the parent window is not available. That's a private
exchange between xdg-desktop-portal-gnome and GNOME Shell though,
and doesn't require GNOME Shell to be a full portal backend.
See https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/140
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3106>
All the ControlsManagerLayout uses from BoxLayout is the spacing
property, both size requests and allocation are completely custom.
That makes subclassing really questionable, so stop doing that
and just hook up to the `spacing` style property manually.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3104>
- drop extraneous calendar-day style_class on week headings
- fix wrong variable in insensitive button mixin
- add some missing focus styles to calendar month header
- fix the asset for today with-events in light theme
- adjust HighContrast visuals for other month days
- make pager buttons circular
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3102>
- clean out unused colors; add desaturated light color
- remove long unused drawing functions; add high contrast color mixin
- de-duplicate and move common colors to a default-colors stylesheet
- rework how HighContrast is defined; clean up HC cruft
- bring over named color defines and other colors from libadwaita
- change how panel colors are defined
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3097>
To mirror Mutter.
This is useful for local installations with e.g. the `release`
buildtype.
Further more, Fedora has been doing the same system wide and it
apparently was helpful in various ways.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2982>
The `state-set` signal is emitted to change the underlying state,
which can have two reasons:
1. the user toggled the switch
2. the extension's `enabled` state changed externally
In the second case, calling enable/disable is pointless at best,
and can mess up the expected state by permanently disabling an
extension that was disabled because of the global kill switch.
Address this by only calling enable/disable if the new state does
not already match the current value of the `enabled` property.
Close https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7305
Fixes: fec523f83f ("extensions-app: Use new 'enabled' property")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3090>
Instead of manually formatting the error message and stack, use the same
formatting mechanism as we do when displaying errors to the user that
occur while opening extension preferences. This should correctly
indicate where syntax errors from imported modules occur.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3041>
Previously, when we formatted SyntaxErrors with toString(), they
wouldn't display the file/line/column where the syntax error occurred.
This adds a utility function that performs a more comprehensive
formatting that displays location information for SyntaxErrors, as well
as the .cause property of the error if it is present. This formatting is
equivalent to what we do in gjs-console when logging an error.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3041>
The switch for enabling/disabling extensions currently bases its
state on the extension's ACTIVE state.
This is problematic in the enabled-but-inactive case, because
activating the switch tries to change the state from off to on,
which leads to enabling an already enabled extension (an obvious
no-op).
The new `enabled` property allows us to do better, and use delayed
state changes where the switch position represents the `enabled`
state, and the trough color whether the extension is ACTIVE.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7004
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3073>
The ENABLED state means that an extension's `enable()` method
was called successfully.
This usually matches whether an extension *should* be enabled
according to the enabled-extensions/disabled-extensions settings,
but not necessarily: If an extension had an error or does not
support the currently active mode, its actual state is different.
We currently only expose the actual state to external tooling,
but whether an extension should be enabled is relevant as well,
for example to disable a lock-screen only extension from the
regular session.
For that purpose we will expose a separate `enabled` property.
To avoid confusion with the existing states, change the exposed
names to (IN)ACTIVE.
This does not affect the D-Bus API, as the numeric values of
the states remain unchanged.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7004
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3073>
Ideally we would replace the sliced-image based animation with a
themed `process-working-symbolic` icon and rotate it, so the spinner
simply picks up the current foreground color.
Unfortunately the `repeat-count` property does not work for rotations,
so to fix the broken spinner in the light variant
in the meantime, include assets for both variants and swap them
out at runtime.
Not everything in the light variant is actually light (overview,
OSDs, ...), so use a simple heuristic on the text color to decide
which asset to use.
Close https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6783
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3080>
The properties passed to the constructor are currently used
directly in anonymous functions. Store them in properties
instead, so they become accessible outside the constructor,
including for changing them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3080>
The newly added developer name syntax appears not implemented
across related platforms: GNOME Software, Flathub, etc.
There is no harm in using both deprecated and newly introduced
tags together, and neither appstream-glib nor appstreamcli
fails to validate this usage.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3079>
- Use the `<developer><name>` tag instead of the deprecated `<developer_name>`
- Implement appstreamcli for extra appdata validation
- Fix a release description
- Update the donation URL
- Add the translation tag
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3071>
logError() prints an exception with an optional prefix, and is
used fairly commonly through-out the code base.
The problem is that by being defined in gjs, it uses "Gjs" as the
GLib log domain, not our own as expected.
Address this by adding a small override that implements the function
with console.error().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3072>
The new InteractiveScreenshot() D-Bus method is implemented using
the signals introduced by the previous commit, and is fundamentally
very simple: take the screenshot, and return the GFile URI.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2999>
These signals will let the yet to be introduced D-Bus method to
be notified of when either a screenshot has been taken, or if
the screenshot UI has been closed without taking a screenshot.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2999>
Add a screenshot-exclusive mode that makes the screencast button
unreactive, and therefore disables screencasting. It doesn't change
the visibility of the button though, as that's done by the codepath
that checks if screencasting is supported.
This will be used by the D-Bus callback to take interactive
screenshots.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2999>
Make the captureScreenshot() auxiliary function return the GFile at
which the texture was saved. This file will be used to return the
screenshot URI to the new D-Bus method to take interactive
screenshots.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2999>
After the last rounds of redesign, it's time to update
the appdata accordingly:
- update screenshots
- add screenshot captions
- point homepage to apps.gnome.org
- mark as mobile adaptive
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3067>
Manually adding and removing rows to dynamic lists is rather
old-fashioned, GTK 4 strongly encourages the use of models.
Modernize the code by exposing extensions as ListModel, and
bind it to the two lists with appropriate filters.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3067>
Most properties that determine the availability of an action are
not expected to change, but now that extensions are represented
as a GObject, we can just generically set up bindings for all
actions instead of explicitly tracking the properties that we
expect to change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3067>
Now that we can use console.debug() to log messages that aren't
shown by default, we can be a lot more verbose without spamming
the system log.
Use that to all extension state changes, which can be useful for
debugging.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3058>
Both icons are not immediately obvious, and the context provided
by the tooltip can be hard to discover.
Address this by making the icons interactive, and provide further
information in a popover.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3051>
We use our own lists so we can do filtering, but that means we
lose the built-in relation with the group's title.
Set the relation ourselves, so the two lists are described correctly
in screen readers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3051>
When an extension is disabled, we "rebase" all extensions that
were enabled afterwards, in case they override the same method.
This can be fairly expensive, in particular when disabling many
extensions at once, for instance when locking the screen.
Help with that by sorting extensions by the number of session-modes,
as extensions that support multiple modes are less likely to be
disabled on session mode changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2851>
Since commit ed3b8d093e, the actor's single-child policy is
enforced even when using the generic add/remove_child() methods.
This makes it possible to follow GTK/AdwBin's lead and replace
out custom child allocation with a BinLayout, without changing
the actor's semantics in a fundamental way.
However this does change slightly how the child is allocated, as
it now only expands according to its expand properties, not when
the alignment is set to FILL.
Even after the preparations in the previous commit, some fallout
is still likely, but it will be easy to address, and the cleanup
is significant enough to justify it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3046>
Right now, St.Bin ignores the child's expand properties, and
instead expands the child if its alignment is set to FILL.
This will change when we replace the custom allocation code
with a layout manager, so to prepare for that, set the expand
property where needed to keep the expected behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3046>
We have considered .desktop files a required app component for
more than 10 years now. It also has been several years that the
default session switched to wayland, which doesn't have protocol
for window icons.
So stop using an elaborate fallback path just for legacy clients,
and just fall back to the same generic icon we use for wayland
clients.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3056>
- updated mixin for tile_button
- dropped the overview_button mixin
- minor changes to dash, appDisplay and switcherPopup JS to accommodate new stylesheet
- new focus style for all tile buttons
- improved high contrast style support for app grid and dash
- renamed some style-classes
- tidied up dash stylesheet
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3017>
Requires mutter!1908 first.
So now consumers of the clutter blur code don't have to know the
implementation is Gaussian and no longer need to convert the intended
blur radius to a sigma value.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1905>
- The "user menu" was replaced with "system menu" years ago, so
update the terminology in the summary and description
- Remove the full stop from the end of the summary for consistency
- More verbosely describe the behavior that's being overridden to
reduce confusion
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3050>
If an interface has any signals, we don't want to auto-shutdown
while a caller is still connected to a signal.
Unfortunately we can't tell whether there are any signal connections,
so we track all callers instead, and keep the service alive while
any of them is still on the bus.
For services that we call from gnome-shell itself - like screencasts
or extensions - this has the unintended side effect of effectively
disabling auto-shutdown.
Address this by exempting the org.gnome.Shell name from sender
tracking.
Services that we expect to keep running for the lifetime of the
shell already disable auto-shutdown, so the only downside is a
small startup delay to resolve the well-known shell name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7250
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3052>
strstr() in find_class_name() will always consider "" a match so the
loop was not stopping at the end of the class_list. None of the matches
within the class_list would satisfy the return conditions, unless the
class_list was either an empty string as well or has a trailing space.
So this ends up with a match outside of the allocated string that
happens to satisfy these conditions by chance which then leads to the
class string containing some of this unrelated memory. Or it might lead
to a segfault.
This adds checks to the public API that uses find_class_name() to
prevent extensions from accidentally triggering a crash this way or
having some otherwise unexpected results.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7152
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3006>
- new drawing function to convert px to em, for select instances
- updated fontsize function to convert fonts in pt to em
- replace instances of discrete sizes with defined values
- fix instances where assets or icons did not scale along with text
- rework panel buttons to accommodate the scaling padding and icons
- new 'scalable' definitions for elements that follow text scaling
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3033>
Now that we have a collection of scripts around the toolbox
workflow, it makes sense to add a brief overview over the
available tools.
For now it's just located in the corresponding tools folder,
but it gives us something to point to once we overhaul the
toplevel documentation as part of the wiki migration.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3040>
As useful as the custom jhbuild setup was at the time, it has been
superseded by jhbuild proper (which gained the ability to install
system dependencies since) or alternatives like containers.
Given that the script hasn't been meaningfully updated for almost
10 years, its list of dependencies is hopelessly outdated, and it's
therefore more likely to confuse newcomers than being of actual
help.
As much as I have fond memories of the script when starting out,
it's finally time to retire.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3040>
Since GNOME 44, extension schemas are compiled at install time.
At the time GNOME 46 is released, this will be all supported versions,
so start relying on it and drop the old compatibility
code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3042>
Wrapping the gnome-shell call with `dbus-run-session` is *mostly*
enough for testing, but not quite.
When running without gnome-session, the wayland display is not
propagated to the D-Bus daemon, so any app that is D-Bus activated
still opens in the host session.
This can be worked around by using a specific wayland-display name
and exporting it to the `dbus-run-session` environment up-front.
At this point the invocation is finicky enough to justify another
convenience script. This also gives us a place to expose some
useful features for testing, like forcing a right-to-left layout
or simulating the greeter.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2935>
We don't require any build steps other than the standard meson
commands, but entering a toolbox and running 2-3 meson commands
still adds some friction.
Add a small convencience script that
- finds the toplevel source directory (similar to `jhbuild make`)
- enters the speficied toolbox (or the configured default)
- automatically picks a build directory based on the toolbox name
- builds and installs the project to /usr (inside the toolbox)
It also allows specifying meson -D options to change the build
configuration, and to optionally run `meson dist`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2935>
Setting up more than one gnome-shell toolbox is uncommon, and users
shouldn't have to specify --set-default for other tools to pick the
right default.
It would be possible to detect the number of containers that were
created from the shell toolbox image, but the far easier option is
to just set up the first container as default.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2935>
In the absence of a fade-out it doesn't make sense to clip them sooner
than that.
So now we make the left and right padding equal to the border
("box-shadow") width and leave the top/bottom padding unchanged.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3031>
Now that both the website and the Extension app support the custom
"version-name" field, we should expose it in the CLI tool as well.
As a more developer-oriented tool, keep showing the automatic
version along-side the new field when both are set.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3034>
The extensions site recently added support for a custom
"version-name" string in metadata:
gitlab.gnome.org/Infrastructure/extensions-web/-/merge_requests/154
This allows developers to control the version that is exposed to
users. As the version according to the developer is almost always
more relevant than the automatic version assigned by the website,
use it instead of the "version" field if set.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2995>
After the port to ESM, an extension's `prefs.js` file is imported
asynchronously. An unintended side effect of that is that we now
show the dialog before anything can be added to the window (either
by the extension, or the fallback error UI).
The delay almost always won't be noticeable to users, but it's
bad practice and prevents extensions from using some API that
only works before the window is realized.
To address the issue, add a `loaded` signal to the dialog that allows
the caller to postpone showing the window until the UI is ready.
Close: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7201
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3025>
Using an exported `init()` function to create the object is an odd
pattern, and not having the object referenced anywhere makes it harder
to access for debugging or extensions.
Just export the `EndSessionDialog` class and instantiate it like we
do for other objects.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2997>
Custom properties are not cached by the theme node itself, so
looking them up repeatedly at every repaint is relatively
expensive.
Avoid this by caching the values ourselves at style changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2994>
Custom properties are not cached by the theme node itself, so
looking them up repeatedly at every repaint is relatively
expensive.
Avoid this by caching the values ourselves at style changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2994>
I can't think of a reason why limiting the border to a maximum
would make any sense.
The original intention was probably to set a minimum border width
to avoid having to deal with border/no-border complexity in the code,
but as cairo accepts a line width of 0, it just works.
However limiting the size to the overall height seems reasonable,
as at that size a bigger height and different fill color can
achieve the same effect without requires special handling of
other values like the radius.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2994>
The docs say that `st_adjustment_set_values()` emits the `changed`
signal only once but it's actually emitted for each changed property,
this uses the `dispatch_properties_changed` vfunc to emit the `changed`
signal only per call to `st_adjustment_set_values()`. As a positive
side effect this also makes it possible to use `g_object_freeze/thaw_notify`
to compress the `changed` signal emission when using the setters for
properties.
This also fixes the wrong emission of the `changed` signal in
`st_adjustment_set_values()` when only the `value` property is changed.
Side note: the code is heavily inspired by GtkAdjustment
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3023>
The Eval() method currently evaluates the provided string, and
returns the result immediately. This isn't useful when a promise
is returned, which has become much more likely now that accessing
any module requires import().
Simply await the result, to handle both sync and async code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3021>
It is a bit odd to have different default values for the vertical
and horizontal policy, but then that's what we almost always want in
practice: Automatic scrolling vertically, and no scrolling horizontally.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3020>
The scroll fade effect is the only component that accesses the
{v,h}scroll properties for anything other than getting access
to the corresponding adjustments.
Allow the effect to get what it needs via new private API instead,
so we can deprecate and eventually remove the scroll bar properties.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3020>
The adjustments are currently only accessible indirectly via
the scroll bars. It is a bit odd to expose internal children,
and as nearly all users only access them for the adjustments,
it makes sense to expose those instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3020>
We hide scrollbars with POLICY_AUTOMATIC when the content of the scroll
view fits completely inside the view without having to scroll. In this case
it seems like a good idea to give the content the full available size
without subtracting scroll bars from that size.
So subtract the scroll bar from the size we give to the child only when
the scroll bar is actually visible, when it's invisible subtract 0 instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2190>
StScrollView applies the policy of whether to show or hide the scroll
bar,
and with the AUTOMATIC policy the scroll bar should be hidden as soon as
the
content of the scroll view is small enough to fit without scrolling.
Now we only know about the final size of the content when we're inside
st_scroll_view_allocate(), so that's where we can decide whether the
scroll
bar should be visible or not. Clutter really doesn't like calling
clutter_actor_show/hide() in the middle of an allocation cycle though,
so
what we do instead is saving the state into priv->vscrollbar_visible,
and
then just not painting the scroll bar based on that in a paint() vfunc
override.
This approach is not great for several reasons, it means we also have to
override pick() and finally it means the paint volume of the scroll bar
is
incorrect.
While the greatest solution to this would be to just hide/show the
scroll
bar inside the allocate() function as it is possible in gtk, we have an
established pattern for this kind of case too: We usually allocate a
0-sized
rect for the thing we want to hide, so let's do that instead.
A nice side effect is that we can conveniently drop another paint() and
pick() vfunc override.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2190>
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>
As per the warning emitted when destroying without closing first
GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed.
You must explicitly end the data stream to the loader before dropping the last reference.
closing it is necessary.
Create the GdkPixbufLoader after loading the file contents so that
the loader is guaranteed to be closed before it is destroyed.
(`gdk_pixbuf_loader_write()` closes it on failure.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3008>
When GridSearchResults::_getMaxDisplayedResults() is called after the
first character has been entered in the search, GridSearchResults has
no children yet. _getMaxDisplayedResults() tries to determine the
maximum number of search results based on how often the largest child
would fit into the allocated size or -1 (i.e. no limit) if there are no
children. So for the initial search there is no limit and in the app
search all matching apps get added as possible results, which due to the
search term being only a single character is almost all installed apps.
This now causes allocation to be run for all these results, despite the
vast majority of them never being visible, which on slower machines can
cause noticeable delays before the search results are displayed.
This now adds the ability for search providers to specify a maximum
number of results that gets used instead of -1 when specified. By being
provider specific this means extensions implementing their own providers
will not be affected by this.
Further this sets the maximum for the app search provider to 6 as per
the current designs.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7155
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3004>
PopupMenuManager was connecting to notify::key-focus on the stage on
construction, but only ever reacting to it when one of its menus was
open. Given that every single app icon and text entry creates a
PopupMenuManager this was causing a lot of these handlers to be created.
Every single handler meant calling into JS code only for the vast
majority of them to determine that they would not do anything.
Additionally these handlers were leaked for the whole lifetime of the
stage due to never getting disconnected.
This now only connects the handler when a menu is open and disconnects
again when it is closed, significantly reducing the number of active
handlers at a time.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7143
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3001>
This reverts commit 575ba13b9b.
That commit did not actually prevent the "Unknown" application from
showing up in the dash or app switcher when the recorder was running,
but it introduced a problem with Proton which also uses gstreamer OpenGL
elements in its transcoder. This was causing the overview to get stuck
while the transcoder was running due to the app for the
"OpenGL Renderer" window being null.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7042
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3000>
If the cursor was placed on one of the widgets that get removed when
rebuilding the calendar due to a month change, destroying the hovered
widget will trigger a repick. This repick can then trigger an allocation
while not all buttons of the calendar are present.
If the last allocation before selected-date-changed is emitted was from
such an incomplete state, DateMenuButton will still freeze the layout in
this state in its signal handler.
What freezing the layout in DateMenuButton is supposed to do is to
prevent size changes of the menu when changing days, but for this the
layout needs to be frozen before potentially rebuilding calendar. This
change ensures that by emitting the signal earlier.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5411
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5469
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2989>
Instead of using a special branch for the not animate case, just use
the same path with duration 0.
Since commit ee09c5c853 we are sure that
duration 0 is always preserved.
In the not animate case, we now call this._updateState(). This was not
happening before.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2987>
Instead of using a special branch for the not animate case, just use
the same path with duration 0.
Since commit ee09c5c853 we are sure that
duration 0 is always preserved.
In the not animate case, we now call this._actionBin.hide(). This was not
happening before.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2987>
Windows of type DESKTOP are currently handled like all other sticky
windows, and stick to the monitor while the animation happens in the
background.
This behavior is odd for desktop windows, which are otherwise always
kept underneath regular windows.
Instead, make them part of the background, so they keep the expected
stacking position and animate together with the workspace.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2865>
Storing the pointer to the fade effect only works as long as we control
all the code that can modify the effects of an actor, but this is not
the case in the presence of extensions. Apparently some extension
manages to remove the effect, which leads to fade_effect pointing to
some invalid address by the time dispose is called, leading to a crash.
This instead uses clutter_actor_get_effect() to get the effect when it
is needed to avoid crashing in these situations.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6521
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2974>
Under certain unknown circumstances currently not every
`disable_unredirect_for_display()` gets matched with an
`enable_unredirect_for_display()` when closing the overview.
As we only want to not disable unredirection when hidden and we nowadays
have a state machine that ensures we transition to and from one state to
another only once, handle unredirection en-/disablement as part of the
state transition.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2970>
Both of these ended up with a "undefined" delta, which turned
the final value into 0 no matter the previous state.
While this was already fixed for touchpads in the previous commit
(by not forwarding emulated discrete events), this looks somewhat
out of place even for the mice that have left/right discrete scroll
actions (e.g. tilting the scroll wheel left or right).
Let these unhandled directions have a delta of 0, and focus on
vertical scroll for both smooth and discrete events.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2967>
The pipeline contains a GST plugin that pops up an unclosable
zero-sized window.
Unfortunately we did not manage to come up with a proper fix
in time, so for now explicitly exclude it from app tracking.
This does not address all issues (it still prevents the
window's workspace from getting removed, even when it appears
empty), but at least it avoids the most confusing effect by
preventing the "app" from showing up in dash, alt-tab etc.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6763
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2956>
Currently we periodically check for updated extensions, prepare
an update and perform it at the next login.
This is largely due to the fact that once an extension has been
loaded, its code is cached and reloading it would only make it
*appear* as updated, while in reality still running the old code.
Of course this only applies *once* we have loaded extensions.
Before that, it's possible to download and install updates, and
only then initialize extensions with their latest version.
The trade-off is that network requests, data download and extraction may
introduce a significant delay before extensions
are enabled. Most extensions modify the UI one way or another,
so that delay would likely be noticeable by the user.
Assuming that users are usually happy enough with the current
extension version, that trade-off doesn't seem worthwhile.
However there is an exception: After a major version update,
extensions are likely disabled as out-of-date, or at least
more likely to break (when the version check is disabled).
In that case delaying extension initialization to download
and install updates looks like the better trade-off, so do
that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2951>
When commit 4d963c432b introduced the global workspace adjustment,
it mostly copied the adjustment handling from the overview that it
set out to replace.
That includes cancelling ongoing transitions when the number of
workspaces changed. However that missed that transitions don't
happen on the main adjustment, but on the "child" adjustments
returned from `createWorkspacesAdjustment()`.
Address this by tracking all child adjustments, and cancel transitions
there as well when necessary. Use weak refs to not
interfere with garbage collection, in case an extension creates
its own child adjustment.
Fixes: 4d963c432b ("main: Introduce global workspaces adjustment")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7000
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2949>
Reportedly, non-alphanumeric key levels were able to stick by
happenstance, and let the user press multiple keys until explicitly
switching to a different mode. Reportedly, this broke, switching to
the default level after the first key press on the additional levels.
Since we have this information in the OSK key models (each level has
a "mode" field to either default/latched/locked), retrieve this
information for them for each level, and only reset to the default
level if on one of those latched levels, and the relevant key was not
locked through long-press.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5763
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2945>
The _commitAction() paths have early returns, which made resetting the
latched mode inconsistent depending on the paths taken to commit the
string. This made latched modes not return to normal on e.g. Shell
entries.
Make this happen outside the function, and after the only calling
point, so that the level is correctly reset on all situations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2945>
The window button is disabled when
- there are no windows
- we are in screen-recording mode
- the session mode doesn't allow windows
However the last condition is only taken into account when
opening the dialog, but not when switching from recording-
to screenshot mode.
Address this by updating the button's sensitivity in a separate
function, so the different conditions are considered consistently.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6990
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2944>
Some extensions want to modify the value of the MAX_THUMBNAIL_SCALE
constant. That is no longer possible, as exports are always read-only
from the outside.
Make this possible again by exposing the scale as a property on the
object itself, so extensions can override it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2939>
Looking glass is not just helpful for development, but also when
asking users to provide relevant information.
Having it in-tree makes it easy to reference, and ensures that
the documentation is still in a maintained place when plans to
retire the wiki go head.
The content is based on the [wiki-page] with updated code samples,
small sections on added features, and outdated references removed
(anyone remember project looking glass?).
[wiki-page]: https://wiki.gnome.org/Projects/GnomeShell/LookingGlass
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2932>
Since commit 6a23e8ee0f, 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>
Meta.Rectangle was replaced by Mtk.Rectangle. Mutter defines a
typedef for compatibility, but it turns out that gjs fails to
pick it up.
Work around that by adding a small compatibility function
that prints a deprecation warning and returns the expected
Mtk.Rectangle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2930>
We now hide ornaments by default. As some of the items in the
window menu can be checked, that means that they will now shift
horizontally, and no longer align with other menu items when
checked.
That's quite bad, and as the items in question don't form a
distinctive group/section, adding back the spacing only to
those two items would still look fairly awkward.
So revert back to the previous behavior for this particular menu,
and default to the NONE ornament.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6962
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2926>
Nowadays, Clutter knows what an implicit grab is, which gives
us already the feel that we are after with buttons (e.g. press
and drag on the button will not enter other actors meanwhile).
ClutterGrab was only added to provide that feel meanwhile, and
it's also slightly more intense (e.g. altering keyboard focus,
or triggering leave events on all parents of the button) which
may trigger side effects.
An example is the IBus candidates popup, where the pagination
buttons may indirectly trigger dismissing of the entire popup
when interacted, by stealing the keyboard focus to the
client/actor doing IM.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2497
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2244
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2924>
Nowadays we can set up translations automatically, but only when
the domain is provided with the metadata.
This can be a problem, for example our extension templates use
the automatic translation handling that we recommend, but as a
result the code will throw an error unless `gettext-domain` is
added to the metadata.
Binding a text domain is cheap enough to not care about unnecessary
or duplicated calls, so add a final fallback to the UUID when no
domain was provided as parameter or in the metadata.
There is already a precedent with the `gnome-extensions pack` command
that falls back to the UUID when no explicit gettext domain was
included in the metadata.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2888>
Commit a72c95de changed the focus style for all system entries
to a more neutral color, as the stronger focus often clashes
with the wallpaper background on the lock screen.
However that is not a concern for entries that appear over the
neutral system background. Worse, the neutral focus indication
provides so little contrast with the background there that is
not much of an indication anymore.
Address this by restoring the old focus indication for the
generic system_entry mix-in, but override it specifically on
the lock screen to avoid the clash with the wallpaper background.
Fixes a72c95de
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6945
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6880
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2922>
The WorkspacesView may be scheduled to be destroyed during
relayout, and despite that go through the allocate() vfunc.
When that happens, the ::destroy handler is called early,
so the WorkspacesView clears this._workspaces in result.
When vfunc_allocate() is called, various paths rely on the
workspaces array being still populated, which is not the
case.
The existing check at vfunc_allocate() for the WorkspacesView
having no children is insufficient, since children are destroyed
as a result, not beforehand.
This results in the following warnings when going out of
overview:
JS ERROR: TypeError: workspace is undefined
_getSpacing@resource:///org/gnome/shell/ui/workspacesView.js:218:13
vfunc_allocate@resource:///org/gnome/shell/ui/workspacesView.js:344:18
vfunc_allocate@resource:///org/gnome/shell/ui/overviewControls.js:223:33
removeWindow@resource:///org/gnome/shell/ui/workspace.js:856:29
addWindow/<.destroyId<@resource:///org/gnome/shell/ui/workspace.js:808:22
_updateWorkspacesViews@resource:///org/gnome/shell/ui/workspacesView.js:1023:38
prepareToEnterOverview@resource:///org/gnome/shell/ui/workspacesView.js:990:14
prepareToEnterOverview@resource:///org/gnome/shell/ui/overviewControls.js:740:33
gestureBegin@resource:///org/gnome/shell/ui/overviewControls.js:802:14
_gestureBegin@resource:///org/gnome/shell/ui/overview.js:409:33
_beginGesture@resource:///org/gnome/shell/ui/swipeTracker.js:601:14
_handleEvent@resource:///org/gnome/shell/ui/swipeTracker.js:173:26
@resource:///org/gnome/shell/ui/init.js:21:20
This always happens through the _updateWorkspacesViews() paths, so there
is a new WorkspacesView taking over and the one being destroyed should
silently go away.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6935
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2918>
Allow passing 'null' to setLevel and setLabel, so 'null' and 'undefined'
behave the same way.
Fixes a regression introduced by a42f7c23, which caused parts of old
notifications to persist into new notifications, or elements being
incorrectly made visible
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2917>
We currently only create boilerplate code for the actual
extension. Now that libadwaita has largely standardized
preference UIs, it makes sense to allow creating the
prefs.js boilerplate as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2889>
This gesture to switch the focused app was already a bit of a
compromise solution at the time it was added, its clunky way to
work (3fg long press, then taps with a 4th finger to switch
application) was pretty much picking up the remains of our
limited wiggle room (sticking to 3fg/4fg global gestures, since
2fg are application domain).
But then directional 3fg gestures took prevalence, and made it
easier to switch between applications. This small gesture remained
a bit of an easter egg, largely unused and unknown.
Fast forward to today, and it's being noticed in a bad way. The
changes to event handling and delivery to actions has made this
gesture take prevalence over the wee-bit-more-popular 3fg swipe
gestures, making those never become active and never trigger.
While a gesture framework is being investigated that might
help handle these situations (or, in a less undefined manner),
this doesn't seem like a case worth going out of our way to
hack around until that is in place. We can remove this, and make
all WM interactions go through the 3fg directional gestures.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2729
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2910>
We include a .desktop file for the Extensions D-Bus
service, to provide name and icon to the preference
dialog when used without a parent window.
However we missed adding it to POTFILES.in, so it is
currently untranslated, whoops.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2904>
This is a small helper function that is used by the DND handling
in the dash and its items.
It turns out that some extensions used to override it, which is
no longer possible: We don't export it, and if we did, it would
be read-only.
To make the function available again, expose it as static method
on the dash itself.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2903>
Quick Settings has become a popular extension point, but adding
items anywhere but the end has become harder since the indicator
setup was made async.
Address this with an addExternalIndicator() method that adds
indicator and quick settings items at reasonable positions.
At the same time, adjust the indicator setup to take eventually
added external items into account.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2894>
We will need some more access to the menu's underlying grid to
provide extension API for adding additional quick items.
Expose a new getFirstItem() method that (surprise!) returns the
first item.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2894>
The QuickSettings menu currently only support appending items
at the end. Extensions can get around that limitation by accessing
the private grid property to move the item afterwards, but we don't
allow this in our own code.
Expose a new insertItemBefore() method that allows adding an item
before an existing one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2894>
After removing the app name and icon, the next natural step that
was requested from the design team is to add workspaces indicators
to the top bar, where currently the Activities button is placed.
In addition to that, this is desired because there are known issues
with using "Activities" as a label for the overview. A more
comprehensive rationale for that can be found at [1].
Add an workspaces indicator replacing the Activities label in the
activities button.
The WorkspaceIndicators class controls how many workspaces dots
exists, their expansion, and the width multiplier. The WorkspaceDot
class takes the expansion and the multiplier, and applies it
internally so that we can get perfectly rounded dots at all
times without using CSS hacks.
The width multipliers are hardcoded, and defined by the design
team. We can revisit them later if necessary. Special care is
taken to not let these width multipliers result in fractional
widths.
When the number of workspaces changes, WorkspaceIndicators adds
new dot to the end, and animate them. When removing, scale the dot
out, then destroy it.
This does not work with workspace grids, but that's not supported
by GNOME Shell anyway, so no effort is made to cover this use case.
The button continues to have "Activities" as its accessible name,
but the label actor is removed.
Also adjust the padding of the activities pill, so it better wraps
the new indicators.
[1] https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/227
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2902>
If a failure happened during initialization the shell does not provide
any debug information, and so only the error is shown without a stack
trace.
Since this information is provided, pass it as the error message.
Do not log this directly from JS so that we just use one termination
path.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2899>
Meson stopped using polkit for automatic privilege elevation, and
will no longer attempt any priviledge elevation when not running
interactively.
Running the entire install command as root used to be problematic
in the past, as it could result in ownership changes of files in
the build directory that would result in build failures later,
but the aforementioned change leaves us with little choice.
Apparently `meson install` will spawn `ninja` with dropped
privileges when a rebuild is needed, so hopefully this will
no longer be an issue.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2892>
Prior to Geoclue v2.7, the location description did not seem to ever be
set. Now, the source used to determine the location is set as the
description. This can result in the location name in dateMenu to be set
as "WiFi", "GeoIP", etc., since we relay the description as the location
name to GWeather. Instead, pass an empty string so GWeather continues
to set the location name itself.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2729>
The translation functions we export from extension utils must
work with all extensions, not only the first that calls one
of the functions.
That means that we are back to examining a backtrace for every
function call unless an extension defined its own translation
functions with `import.meta.url`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2887>
Create a derived workspaces adjustment using the new API, and
bind it to the 'progress' property. This is only done by the
MonitorGroup representing the primary monitor.
The progress value that WorkspaceAnimation operates on
represents the percentage within the workspaceIndices array
we are, so make sure to transform the percentage to the
correct workspace index.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
The getter of the MonitorGroup's 'progress' property sets
some values based on it, but doesn't notify the property
change.
Fix that by calling this.notify('progress') when the setter
is called.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
Derive the workspaces adjustment used by OverviewControls (and
shared with WorkspacesView) from the main workspaces adjustment
using the new Main.createWorkspacesAdjustment() method.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
And a way to derive "sub"-adjustments from the main one.
The main and private StAdjustment properly represents
workspaces, and has all relevant properties (lower, upper,
and value) set by the workspace manager.
The main adjustment is not bound to any particular actor,
which means we cannot call the 'ease' method directly.
Consumers of this API should create adjustments using
Main.createWorkspacesAdjustment(), and this new adjustment
is bound to the actor that the consumer passed. Consumers
must not change any property of the derived adjustment other
than the 'value' property.
The 'value' property is synchronized between all adjustments
created, which guarantees that all elements that represent
workspaces can have a shared and up-to-date understanding of
where in the workspace layout we are.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2881>
The Config module is shared between the main process, D-Bus
services and tests, which previously prevented it from being
ported to ESM.
The previous commit removed the last outstanding blocker, so
we can now port the last remaining module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2880>
Unit tests currently load shell sources directly from the
filesystem.
This is currently blocking generated sources - namely config.js - to
ESM, because a relative import from the source dir will fail to
locate the file in the build dir.
Address this by using the same GResource as gnome-shell instead of
direct filesystem access, as the resource will always include all
sources files at the expected location.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2880>
Out of the members of the notification daemon(s), these are the most
necessary and flexible to override. The daemons are used as singletons
and notifications are rather temporary, while the sources are more
flexible and make the most sense to override (and revert).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2869>
Now that all code conforms with the new style, we can remove all
the tricky bits that compare errors from regular- and legacy
config or limit checks to changed lines from a git diff.
All that is left over the eslint CLI tool is the ability to output
results both as junit for gitlab and plain text for logs without
duplicating the linting, but that's well worth preserving.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
There is no longer a difference between regular- and legacy config.
That means that all code now follows the regular configuration, and
we no longer need a separate check that enforces this for new code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
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>
We sometimes obtained the current event through the general machinery
just so we could pass it along as a ClutterEvent instead of a specialized
subtype.
We now get that out of the box, so may avoid getting the current event
which is just a cast of the same current event we already have.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2872>
These traditionally got the various ClutterEvent subtype structs as their
argument, so it was not allowed to use ClutterEvent generic getter methods
in these vfuncs. These methods used direct access to struct fields instead.
This got spoiled with the move to make ClutterEvent opaque types, since
these are no longer public structs so GNOME Shell most silently failed to
fetch the expected values from event fields. But since they are not
ClutterEvents either, the getters could not be used on them.
Mutter is changing so that these vmethods all contain an alias to the
one and only Clutter.Event type, thus lifting those barriers, and making
it possible to use the ClutterEvent methods in these vfuncs.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2950
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2872>
Commit 17d9ec5788 made the input method call update() more eagerly,
but also at times that it does not have a cursor position yet. Make
it bail out correctly in that situation.
Fixes: 17d9ec5788 ("inputMethod: Keep Capabilite.FOCUS before context.focus_in/focus_out")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2876>
If context.focus_out() is called *after* context.set_capabilities(0),
The FocusOut D-Bus method is ignored because of no FOCUS capability.
If context.focus_out() is called *before* context.set_capabilities(0),
The 0 capability is set to the next focused context and the
FocusIn D-Bus method is ignored because of no FOCUS capability.
So context.set_capabilities(0) should not be called.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6415
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2666>
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>
Glibc defines `d_ptr`/`d_val` to be a relocated address on most
architectures, except for riscv and mips where it is just an offset from
the binary load address. So we need to convert `strtab` from an offset
into a pointer for riscv and mips.
Internally within glibc there is the `D_PTR` macro for doing this, which
relies on private data hidden in an ABI-unstable part of `link_map`. So
we can't use the same conditional logic as glibc does internally.
Our solution is to detect when `strtab` is unreasonably low (below the
address of our binary) and so it must be an unrelocated offset. In that
case we just do the relocation manually.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6528
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2718>
Overriding vfuncs can be useful, in particular when we convert
to ES modules, and exported symbols cannot easily be swapped out.
Adapt overrideMethod() to work correctly in that case as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2809>
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>
We currently consider idle nodes as in use to avoid too fast state
changes and thus flickering of the indicator icon. However, the current
idle timeout is rather long and arguably confusing for users.
Thus switch to only consider running nodes as in use, but delay
disabling of the indicator by 500ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2854>
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>
Extensions must now export a class with a fillPreferencesWindow()
method in their prefs. That is less convenient for extensions
with simple preferences than the old buildPrefsWidget() hook, as
they must wrap their widget in page/group widgets.
Address this by adding a default fillPreferencesWindow() implementation
that calls a getPreferencesWidget() method and wraps it as necessary.
This is flexible enough to support different cases fairly conveniently,
from simple single-widget prefs over tweaking the window to complex
multi-page prefs:
```js
class SimplePreferences extends ExtensionPreferences {
getPreferencesWidget() {
return new SimplePrefsWidget();
}
}
class TinkerPreferences extends ExtensionPreferences {
getPreferencesWidget() {
return new SimplePrefsWidget();
}
fillPreferencesWindow(window) {
super.fillPreferencesWindow(window);
window.set_default_size(123, 456);
}
}
class FullPreferences extends ExtensionPreferences {
fillPreferencesWindow(window) {
const page1 = new GeneralPage();
window.add(page1);
const page2 = new FoobarPage();
window.add(page2);
}
}
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
Use the new defineTranslationFunctions() method from the previous
commit to create gettext functions for the module, instead of
re-exporting from the shared module.
It is now up to extension developers to use the more effective
```js
import {Extension} from 'etensions/extension.js';
const {gettext: _} =
Extension.defineTranslationFunctions(import.meta.url);
```
or the more convenient
```js
import {Extension, gettext} from 'extensions/extension.js';
const _ = gettext;
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
The method can be used to define a set of gettext functions that
call the corresponding method of an extension.
Those functions are very similar to the gettext functions we are
exporting, except that:
- looking up the extension is delegated to the
Extension/Preferences class
- it is possible to avoid examining the stack
when called with `import.meta.url`
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
With convenience API like getSettings() now being provided by
the ExtensionObject subclass, extensions will need to access
their entry point more often.
Having to pass a pointer through the hierarchy can be annoying,
so add a static method that allows them to look it up:
```js
const ext = Extension.lookupByURL(import.meta.url);
this._settings = ext.getSettings();
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
The Extension/Preferences classes are where we will focus for
future extension convenience API, so developers should be
encouraged to use them as entry points.
Adjust the existing templates to do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
Extensions now must export a class that conforms to a particular
interface both for the actual extension as well as for prefs:
enable()/disable() methods for the former, fillPreferencesWindow()
for the latter.
This is quite similar to the previous method-based entry points,
but it also gives us a more structured way of providing convenience
API in form of base classes.
Do that in form of Extension and ExtensionPreferences classes on
top of a common ExtensionBase base class.
getSettings(), initTranslations() and the gettext wrappers are
now methods of the common base, while openPreferences() moves
to the Extension class.
Based on an original suggestion from Evan Welsh.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
Extensions often need to set up additional resources from their
directory, like settings, translations or image assets.
So far extensions have used getCurrentExtension() to access the
shell's internal extension object which contains path and dir
properties. That's far from ideal, first because it requires
generating a stack to figure out the current extension, and
second because the internal object also contains state that
extensions shouldn't meddle with.
Just include those properties in the metadata we pass to the
extension constructor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2838>
Pipewire allows us to easily track whether any cameras are in used by
checking the state of camera nodes. Add a simple camera monitor to the
shell, allowing us to show e.g. a status indicator.
Naturally the monitor is limited to apps using Pipewire for camera
access and thus subject to the same chicken-egg problem like the camera
portal - it could confuse users that apps may use the camera without
being noticed by the monitor. The hope and assumption here is that a
better shell integration might speed up adoption of the new camera APIs
Pipewire 0.3.49 is required for refcounted `pw_init()`/`pw_deinit()`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2840>
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>
The Config variable that was removed in the previous commit was
actually wrong (PACKAGE_VERSION vs. GETTEXT_VERSION), so the
substituation didn't work.
Meson warns about this, let's make these warnings fatal to catch
similar issues during CI.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2844>
Ever since the mutter image started to set up a non-root user for
running tests, the toolbox image built on top of it has been broken.
The issue has now been addressed, so update the image to pull in
the fix.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2850>
We unified most code paths earlier, but the common code will still
import Main locally if no extension manager was injected before.
Now that the old extensionUtils was split between extension and
preferences, each of those modules can simply import the manager
from its corresponding environment, and then inject it into the
shared module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
For the time being this mostly means re-exporting functions
from the shared module. However openPrefs() is now only
available to extensions, and we stop exporting both
getCurrentExtension() and setExtensionManager() to either
extensions or prefs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
We got rid of all uses of extension utils code in the gnome-shell
process itself, and everything that is now using it - including
extensions - is already loaded as module.
We can therefore quickly move the file to ESM, which will help
a bit with upcoming changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
ExtensionUtils was originally used for shared functions between
the extension system and the (old) prefs-tool, but then gained
useful API meant for extensions themselves.
It's a bit weird to mix the two, so split out the extension convenience
API into a separate module.
We will soon split up the module further, and add specific "flavors"
for extensions and preferences, with the current code providing a
shared base for both.
That should explain both the new location and the odd module name. :-)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2837>
Now that we always have an extension manager object, we can use
the same code path for use from extensions and prefs.
For that, inject the D-Bus service's extensionManager instead
of the current extension.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2832>
ExtensionUtils' getCurrentExtension() method currently either
returns the extension that was injected with setCurrentExtension(),
or imports Main locally to access the extensionManager.
But local imports won't work anymore when we convert to ESM,
and setCurrentExtension() is only an option for prefs.
Instead of diverging the code paths even further, we'll unify
the two cases as much as possible.
As a first step, add a basic extension manager in the Extensions
D-Bus service that exposes the same lookup() API as the "real"
extension manager.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2832>
When looking for a directory name that matches the extension UUID,
we can just as well use GLib's dirname()/basename() functions
instead of wrapping the path in a GFile.
We also know that the original path corresponds to a regular file
and not a directory, so rearrange the loop to avoid a lookup that
is guaranteed to fail.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2832>
We currently use a regular expression to extract the exact file path
from a stack line. That RE is no longer accurate:
- we assume a line number at the end, but at one point the column
number was added as well
- stacks from ES modules use file:// URIs instead of plain paths
Luckily that doesn't matter: We don't want to access any actual
files, so all we need is a path that can be traversed and that
contains the UUID.
We can get that with simple string manipulation, so avoid the regex
overhead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2832>
gi modules are always loaded (there is no API for "set version without
loading"), so
we need to break dependencies.js into three sections:
- Required
- Compile-time optional
- Runtime optional
Required dependencies are always imported, compile-time optional
dependencies
are loaded if gnome-shell is compiled with support for them, and for
runtime optional dependencies we catch any errors when attempting to
load them.
If runtime optional dependencies fail to load we log a debug-level
message.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
Removes the init() function in favor of executing all environment
changes when the file is imported.
Additionally ports all unit tests using imports.gi.environment.init() to
use the updated module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
GJS provides utilities to run scripts given a filename, using those
utilities we can remove most of the logic implementing file loading.
Additionally the REPL logic does not make much sense for a test
runner and is unused, so remove it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
We started to version them last cycle, so docs can be differentiated
between versions. It is not *expected* that two versions show up
on the same system, but then it also doesn't hurt handling it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
Once environment.js is an ES module we need to ensure we can dynamically
specify the version for required GI dependencies such as Clutter.
Moving dependency version setup to dependencies.js ensures gi.require
calls are done before environment.js imports any utilities.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
The environment module is used to initialize the environment, yet it
currently also defines the adjustAnimationTime() function.
Ideally it should not export any utility functions, in particular
once converted to ESM.
The function cannot be moved to the existing Utils module, as that
depends on an initialized environment, and can therefore not be
imported from environment.js, so use that opportunity to group
together several animation helpers in a new animationUtils module.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
This allows using await in the command (or the header we
add to it), for example when handling Promises or importing
a module dynamically.
The latter will be crucial when porting to ESM.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2842>
Part of the possible completions involves evaluating the part
of the passed in text that looks like an object, so that we
can query it for properties.
Using a Function or eval() for that means that we can only
complete text that does not use `await`. To get over that
limitation, evaluate the text in an AsyncFunction instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2842>
We currently throw an error when encountering a result that cannot
be represented as string, with the prompt appearing somewhat stuck
(the input cannot be committed).
Showing a lame fallback instead at least avoids that issue. When
the object has a typeof 'object' but is not an instanceof Object,
we are likely dealing with an ES module, and can show a slightly
less lame fallback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2842>
We currently include a fake config.js file to satisfy the indirect
import from ExtensionUtils. However we're about to need to pass
build-time information into the program ourselves, so generate
a proper file.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2841>
GThemedIcon considers the "-symbolic" suffix when generating
fallback names (i.e. "foo-bar-symbolic", "foo-symbolic", "foo-bar",
"foo").
That means now that we prefer more accurate name matches from any
theme over fallback matches from higher-priority themes, we no
longer need to special-case symbolic names for preferring symbolic
matches over full-color fallbacks.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2824>
When resolving an icon name, we currently look in all themes in
order whether one of the requested names matches.
That means, a "keyboard" icon from the configured theme will
trump over any of "keyboard-shift", "keyboard-brightness" and
"keyboard-preferences" from lower-ranked themes (like "Adwaita"
and "hicolor").
That applies to custom icons we include in the resource, which
are added to the fallback ("hicolor") theme.
We are less bound by the named-icons spec than GTK, so we can
adapt the lookup to prefer the most accurate match to matches
from the highest priority theme.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2824>
The eslint jobs report their results as artifacts in junit format,
so that gitlab can present them in its UI.
However many people miss that, and unsuccessfully check the logs
instead.
Account for that by also printing the results to stdout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2829>
console.log() is implemented with structured logging, and as we
set an appropriate log domain, it's identical to the custom function
bar the custom fields with extension data.
Few people know about those custom fields, and adding them comes
at a cost, as we end up producing and parsing a stacktrace on
every log() call.
It therefore seems appropriate to drop the custom function, and
turn the global log() symbol into a simple convenience alias for
console.log().
If it turns out that people do miss the custom fields, we can add
an alternative to ExtensionUtils.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2830>
`toLocaleFormat` is now `formatDateWithCFormatString` and formatTime and
formatTimeSpan are moved into dateUtils.
Instead of overriding system.clearDateCaches, add a helper in dateUtils.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2827>
Now that scripts are loaded as external modules, there's no reason
anymore for bundling them with the gnome-shell executable. Just
move the scripts into a dedicated folder in tests/ and run them
from there.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
The purpose of the tool has shifted from running a limited set
of performance tests repeatedly to collect performance data
and catch regressions, to a wrapper that drives gnome-shell via
scripts for tests.
With that, the concept of a "default" script doesn't really make
sense anymore.
Instead, turn the argument from an optional flag into a required
parameter. This will allow us to stop bundling the existing tests
in a follow-up commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
The original purpose of the tool was to collect performance data
that would optionally be uploaded to a server in Owen's living
room. While the corresponding scripts are still included (although
the server was probably dismantled years ago), the tool is mainly
used for running gnome-shell with scripted tests nowadays.
Rename the tool to reflect that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
Environment variables aren't the best option to pass parameters
to a process (wouldn't it be "fun" if SHELL_PERF_MODULE appeared
in a regular user session?).
Instead, use a (hidden) --automation-script command line flag to
specify a script file that should be used to drive an automated
session.
As a side effect, the script no longer has to be relative to the
main module itself, so it will be possible to run scripts that
aren't bundled with the shell sources.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
The perf scripts that can be used to script the gnome-shell UI
for testing are sufficiently separate from the rest of the code
base to allow porting them to ESM modules before the rest of
the code base.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
We currently only find a matching ref on the same remote in
a merge request pipeline, but not in branch pipelines.
It can occasionally be useful to run a pipeline without opening
a merge request, so try the same remote here as well instead of
just assuming origin.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2814>
The file indicates to the systemd shutdown scripts that extensions
should be disabled, so that extensions that crash the shell on
startup cannot lock out the user indefinitely.
For that purpose, we create the file before initializing extensions,
and remove it after 60 seconds. That generally works, because it's
highly unlikely that a session genuinely ends within the first minute.
It's possible though (for example during developments or when running
tests), so also remove the file when shutting down cleanly before
the timeout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2807>
Now that extensions themselves are imported as modules, do the
same for their preference dialogs.
Extensions must now export a class with a `fillPreferencesWindow()`
method as default.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2795>
Continue the move to ESM by loading modules dynamically with
the standard import() expression, rather than by installing a
custom (legacy) importer.
This is a breaking change that affects all extensions, as they
now need to explicitly export the expected symbols.
As we are already breaking all extensions, take that opportunity
and remove support for the individual entry points: Using a
class with enable()/disable() methods has been the recommended
pattern for a long time, it is now the only entry point.
Instead of instantiating the class from an `init()` function,
the class must now be exported as default to be recognized.
Additionally, we no longer install an importer on the extension
object, so extensions that consist of more than one file MUST
import those files as modules now.
There will be a second breaking change for extensions when
gnome-shell's own code is ported to ESM, so most extension
developers will likely want to wait until the port is complete
before starting to port their extensions.
Based on a commit from Evan Welsh.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2795>
When using fractional scaling, the size of the loaded image with
applied scaling may still differ from the displayed size. This
is currently addressed by syncing the size of all slice actors
in the (probably only) caller.
Instead, set the actors to fill their parent automatically.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2798>
The tests rely on the ability to run Clutter as stand-alone app,
which hasn't been possible for quite a while now. Event handling
was broken long before that, plus tests that need a human to run
them and evaluate the result aren't that useful to begin with.
It would be neat to test our CSS rendering by setting up a stage,
capturing it and comparing it to a reference image. But writing
some code that exercises backgrounds, borders etc. is hardly the
obstacle to make that happen, and not worth carrying around dead
code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2811>
This was necessary after mutter configured a non-root user
for the image, although as it turned out not sufficient.
The latest image no longer sets up a special user, so building
the toolbox image should work again as before.
This reverts commit ee384d85da.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2813>
The keybinding is a direct, less commonly used alternative to
stand-alone 'super'. While it can be useful to have a regular
keybinding alternative - although 'super+alt+up' also provides
that to some extent - most users probably don't even know about
it's existence.
It is therefore less justified to take away a valuable shortcut
slot, so stop assigning a default shortcut to free 'super+s' for
other actions.
Users who do use the keybinding can still use Settings to assign
a shortcut.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5670
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2716>
If gjs itself defines ARGV, it only holds the arguments that are
passed on to the script, and javascript code should combine the
programName and ARGV (or the newer programArgs) when it needs a
C-style argv array.
Do the same in the portal-helper process instead of passing along
the original C argv, to avoid confusion when accessing the arguments
from javascript.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2786>
We want to replace gjs' custom (and now legacy) imports system
with standard EcmaScript modules: JS developers are already
familiar with them, they have better tooling support and using
standard features over non-standard ones is generally the right
thing to do.
Our D-Bus services are separate from the main process, and thus
can be ported separately (except for the few imports that are
shared with the main process' code base).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2786>
- 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>
GTK 4.12 deprecates gdk_wayland_toplevel_unexport_handle() in favor
of the new gdk_wayland_toplevel_drop_exported_handle(). We are not
bound by API stability, so we can just expose the additional argument
that the replacement requires instead of tracking the handle
internally.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2778>
We currently special-case the DISABLED error when initializing
filtering, but not on app filter changes.
While it seems reasonable that Malcontent.Manager wouldn't emit
the signal while disabled, that's not actually true: It is emitted
when any user account information tracked by AccountsServices
changes.
Even if the signal were limited to changes of the ParentalControls
extension, it would still get emitted when app filtering *becomes*
disabled.
So regardless of potential improvements in libmalcontent itself,
we should filter out the DISABLED consistently, both when creating
the initial filter and when updating it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6749
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2796>
Commit c449058d44 changed the pointer clone to use a single
actor. However that broke applying the hotspot translation to the
position, so the magnified cursor is now displayed with a shift.
Undo the change to restore the old behavior.
This reverts commit c449058d44.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2780>
gjs now has an internal mainloop that it can spin to resolve
module imports. That loop uses the thread default context,
so its possible that other sources, namely from mutter, get
dispatched when iterating the context. If that happens before
mutter is properly initialized, this will lead to a crash.
GjsContext needs to iterate its internal mainloop when initializing
to resolve internal modules, to avoid iterating Meta's mainloop and
triggering events before Meta is ready we will initialize the Shell
global and thus the GjsContext (js_context) before Meta.
Once GjsContext is initialized, we can call meta_context_setup().
Once Meta is setup and started, we'll run init.js which uses GJS'
internal promises API to set a "mainloop hook". The mainloop hook
is run immediately after the module returns so GJS will not attempt
to iterate the main loop again before exiting.
Also adjust the 'headlessStart' test to not wait for the
MetaContext::started signal, as that signal has now already
been emitted when the code is executed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6691
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2781>
get_size() in _syncAnimationSize() can't be called until the actor
has a parent, otherwise we'll get an error for calling
st_get_theme_node() prior to the actor being on a stage.
_syncAnimationSize() is called asynchronously via
textureCache.load_sliced_image() and there is currently no guarantee
the actor will actually be "loaded" prior to calling it.
This becomes a more obvious error/issue when refactoring parts of the
Shell loading to also be asynchronous.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2563>
The windows we create use a simple pattern as content, as that's
easier to follow than completely empty windows. GTK4 no longer
allows hooking into the drawing of arbitrary widgets, so prepare
for that by using a dedicated subclass instead of a signal handler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
We are about to port the helper proxy to GApplication, which means
that it will establish a display connection before exporting its
D-Bus name. That means that the compositor must be able to respond
to a roundtrip request to avoid locking, so don't block on the proxy
becoming available.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
There's another remaining bit of Gtk3 code in a small test program
that changes a window title to a random character sequence every
five seconds. While the value of that test is a bit questionable,
it doesn't hurt either and a port is trivial.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
Its only purpose is to provide a test case for the remote app menu,
but that support was removed in gnome-shell years ago. We don't
need a test case for GTK's fallback app menu support, so remove
the whole thing.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
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>
Provide a reasonably public way to register and unregister search
providers, without adding too much API.
`Main.overview.searchController` provides access that may be generally
useful, while `SearchController.addProvider()` and
`SearchController.removeProvider()` provide a simple interface for
extensions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2783>
We started to support Soup3 in GNOME 41, and used it by default
since GNOME 43. This should be enough time for distros to adapt,
so GNOME 45 looks like a good moment to drop the old Soup2 support.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2776>
Since we started to support the color-scheme preference, extensions
should be able to provide appropriate variants (if they deal with
colors).
So look for a variant with -dark/-light suffix before using the
plain stylesheet.css, and reload extension stylesheets on
color scheme changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2324>
The IBusCandidatePopup can get 'stuck' in an active, visible state if
it is on-screen at the point when the input method is changed to a method
that doesn't use such popup (e.g. regular English).
Force the candidate popup to close when the engine is changed.
It will reappear (via regular lookup table update signal) if/when it is
next required.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6717
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2774>
Out of the box, the container images only support US English. It
can sometimes be necessary to use a different locale, so add
a convenience flag to enable support for additional locales.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
The container is useless for building or running gnome-shell unless
it includes the correct mutter version, so building it by default
makes sense.
However a manual build can be significantly faster when there's an
existing build dir, so add an option to skip the automatic build.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
A toolbox created by the script can be used as the base of a pet
container that is manually updated with new dependencies over time
and accumalates additional packages; or it can be used as a deposable
container that is recreated each time the dependencies change.
To make the latter case more convenient, add a --replace option
that deletes an existing toolbox before creating the new one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
The script is a thin wrapper around `toolbox create`, mainly to
avoid the tedious image names. In addition, it allows us to
ensure that the container includes a matching mutter version.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
Toolbox is a convenient option for development, but setting up
the image with all dependencies is annoying at best, in particular
later in the cycle when `dnf builddep` is likely insufficient.
To address that, produce toolbox images for main and stable branches
that are based on the regular CI image, and update them whenever
the image version is updated. This guarantees that all build- and
runtime dependencies are included.
Unsurprisingly, the script that produces the image draws heavily
from freedesktop's ci-templates. The most notable difference
(other than being neither distro-agnostic nor generic) is that
tag names are fixed (toolbox:main, toolbox:43 etc.) to make them
easier to consume.
Instead, whether an image needs rebuilding is based on a custom
label that records the base image that was used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2713>
The callback would schedule a clutter_actor_destroy() on the first
argument. Unless told otherwise, this is the same actor that is
already being destroyed, so this is a no-op.
Instead, the intent is to make the clone follow up destruction of
the window actor so that it results in correct removal of this
window from the ShellWindowPreviewLayout. Use a swapped connection
to pass the clone actor as the first argument of the signal callback.
Fixes: 04c781674c ("Move WindowPreviewLayout from JS to C")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6570
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2756>
Calling _teardownPipeline() before _tryNextPipeline() was actually not a
good idea, it sets the pipelineState to STOPPED, which means we can't try
any of the following pipelines anymore.
Instead what we want to do is set the pipeline state of the old pipeline to
NULL when trying a new one, without calling _teardownPipeline() for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2754>
Now that the app menu indicator is no longer shown, it shouldn't be possible
to toggle the popup menu via keyboard shortcut anymore, so remove the code
and gsettings definitions for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2610>
This pipeline imports dmabufs and does format conversion using GL.
The `video/x-raw(memory:DMABuf)` filter ensures format negotiation
between `pipewiresrc` and Mutter will only succeed if Mutter advertises
dmabuf support as well, falling back to the next pipeline otherwise.
Using this pipeline frees Mutter from downloading buffer content on the
main thread which can have a big impact on compositor performance.
Doing format conversion on the GPU should further improve the overall
performance on most hardware.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2597>
When the screencast dbus service crashes due to gstreamer, we should also
handle that and not pretend to continue recording.
Let's listen to g-name-owner changes for that and then also send a
notification about it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2752>
Make sure gnome-shell gets notified of errors that happen during screen
recording using the screencastService, so that it can properly notify the
user about the error and tear down its state, too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2752>
Pipewire versions < 0.3.67 may not fail immediatly on negotiation
errors, thus use the last/fallback pipeline directly.
Technically, a similar recent version of Wireplumber is required
as well, but we can't check that easily and the combination of old
Wireplumber and new Pipewire is quite unlikely.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
Introduce a fallback mechanism for gstreamer pipelines that allows to
define multiple pipelines and prefer them over each other.
The way this works is that we introduce a new STARTING PipelineState.
While the Recorder is in that state, it is allowed to tear down the
current pipeline and start another one whenever an error happens, this is
used to try multiple pipelines in a fixed order until a working one is
found.
Right now there's just a single pipeline using the existing vp8 encoder, the
actual new encoders and pipelines will be added in a separate commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
The check for the Pipewire version was originally introduced in
d32c0348 which states:
> Since it is not clear yet when a proper solution will arrive,
> this makes use of `always-copy` as a workaround for now and
> should be reverted once it is no longer needed.
The check for a stable Gstreamer version with the mention proper fix was
introduced in d7b44319 and carried for the 43 cycle.
By the time Gnome 44 will be released all distros should have had enough
time to update their Gstreamer version - or backport the patches, in
case of not ustream-supported versions.
Thus lets drop it now.
Note: `always-copy` is not suitable for dmabuf buffers as it copies via
mmap.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2609>
Right now when we tell gstreamer to move the pipeline to the state
PLAYING, we pretend that happens immediately and set our PipelineState
to PLAYING right afterwards.
In reality though it's more complicated than that: Gstreamer changes
states asynchronously and set_state() returns a Gst.StateChangeReturn.ASYNC.
In that case we should wait until the according STATE_CHANGED event happens
on the bus, and only then set our PipelineState to PLAYING.
Since the STATE_CHANGED event will also happen when set_state() returns
SUCCESS, we can use the same async logic for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
Gstreamer can produce various errors, we shouldn't pretend those don't
exist and go on as usual when one happens. Instead, when an error
happens, tear down the pipeline, set our PipelineState to the new ERROR
state and bail out with a proper error message.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
We're tracking three different state-machines in the Recorder object:
The state of the gstreamer pipeline, the state of the screencast
session, and the sender of our dbus invocation that might vanish.
Properly handling errors that might appear in any of those three "black
boxes" is not easy, especially tearing down the other two when one of
them breaks.
So refactor the error handling here: Add a single error path for each of
those three states we're tracking, and make them all subsequently call
the _bailOutOnError() method. From there we tear down the other states and
call the error callbacks.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2197>
The pattern has become a lot less common, not least indicated
by the removal of the HeaderBar:subtitle property. And in this
case we are including an icon in the subtitle, which looks
completely out of place.
Address this by moving the URL/security information into a
popover menu, inspired by the similar drop-down in GNOME Web.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2690>
Years ago, the function used to clean up the cache when the
window was closed. But now that an ephemeral data manager is
used, nothing is cached anymore and the function is left as
a mere wrapper around this.destroy().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2690>
The events that the draggable uses to initiate a drag operation
are the same as the ones a click action consumes for clicks.
It is still possible to combine the two, but it's finicky and far
from being straight-forward. To make this easier, add a dedicated
addClickAction() method to draggables that takes care of the
setup before adding the action to the draggable actor.
In the longer term, we'll want to turn DND into an action, and
have something like GTK's gesture group to allow combining actions
that would otherwise step on each other's toes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2742>
Actions provide a higher-level API than event handlers, not unlike
GTK's event controllers (albeit less complete). Allowing them to
take care of the low-level bits where possible is generally a good
idea.
Menu items are a very straight-forward case, with a good amount
of code saving, so port them over.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2742>
The handler dates back to commit 50f248ec5b in 2011, and is
part of the original hack of making the activities button a
PanelMenu.Button while suppressing its menu.
By now, panel buttons without a menu have been properly supported
for years, but somehow that bit of the hack stuck around, even though
it is no longer actually needed (probably since the introduction of
DummyMenu.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2741>
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>
Provided we use the correct version of the SpiderMonkey shell, we
can perform checks using the same engine that is used by gjs.
However some engine features are opt-in, so the set of features enabled
by gjs and js102 may differ. The obvious option for avoiding this is
replacing js102 with gjs for tests.
For that reason the check-potfiles.js script has been ported to gjs
and a second (simpler) script to replace `js102 --compileonly` was
added. This work happened in a separate repository to make sharing
between different JS-based projects easier.
Update the CI image to pull in those scripts and include gjs.
This will also address the issue that `js102 --compileonly` does not
handle modules.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2193>
Both the subdir and prepare arguments are very specific to
building the extensions-tool subproject stand-alone. In order
to make the script more generic, turn those required arguments
into optional --subdir and --prepare ones.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712>
We currently remove the directory at the end of the script, but
that code is only reached when all previous operations were
successful.
Address this by first using an absolute directory path in /tmp
instead of a "random" location based on the CWD, then set a trap
to remove it on exit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712>
The script has four mandatory arguments, and also accepts optional
build options that are passed on to meson. Checking for the number
of arguments *before* filtering out the optional ones means that
`./install-meson-project.sh -Done=1 -Dtwo=2 -Dthree=3 -Dfour=4`
is considered valid, even though not a single required argument
is passed.
Fix this by filtering out the arguments before doing the usage
check. As it is a nice touch to have usage information at the
top of the script, move the message into a usage() function at
the top.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712>
If we have multiple desktop ID's that share the same startup-wm class
and none of them is actually matching the desktop-id, then we should
exclude the ones that should not be shown in the current desktop.
This will help preventing cases such as the previous one in case no
desktop file ID would match the startup-wm-class exactly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721>
When fetching the desktop ids into a map of startup-wm classes we meant
to give the ones that match the desktop ID more priority, however
this did not happen because we were always comparing a desktop
file id, including the `.desktop` suffix, with a wm-class that generally
does not include that.
This is the case of gnome-system-monitor, that provides two desktop
files, one of which is OnlyShowIn=KDE but both have the same
StartupWMClass and thus the first parsed is preferred, even though its
desktop-id is gnome-system-monitor-kde.
As per this, remove the .desktop suffix when comparing it with the
startup-wm-class, keeping the old check just in case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721>
After the introduction of implicit grabs in Clutter, a release
event will now always be delivered to the actor that received
the corresponding press event.
This results in surprising behavior when moving the pointer
while pressed, as a button release will always activate the
original item, even when the pointer moved to a different item
or outside the menu altogether.
Address this by checking the hover state (that is, whether
the item contains the pointer actor) before activating it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6606
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2740>
When a WindowPreview is being destroyed, the class default handler for
the `destroy` signal is responsible for destroying its child actors.
This happens after the emission of the `destroy` signal, i.e. after
`WindowPreview::_onDestroy()` has been run.
The destruction of the WindowPreview's child actors now triggers a
re-pick, but due to WindowPreview having already being marked as
`CLUTTER_IN_DESTRUCTION`, it will not be picked, resulting in a `leave`
event if the cursor was on top of the WindowPreview at the time
`destroy()` was called on it.
So this leads to `WindowPreview::vfunc_leave_event()` being run after
`WindowPreview::_onDestroy()`, which means the idle started by the leave
event handler will not be removed and ends up accessing actors after
they have already been destroyed.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5512
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6065
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2738>
Dash labels are children of the main uiGroup and so could be destroyed
before their logical-owner DashItemContainer during shutdown.
This implies that we could destroy them twice. To avoid this, unset them
when destroyed.
This is mostly visible when using dash-to-dock, but it's still
technically possible with upstream code:
** Message: 19:57:49.847: Shutting down GNOME Shell
(gnome-shell:2788214): Gjs-CRITICAL **: 19:57:49.933: Object St.Label
(0x55b33668eab0), has been already disposed — impossible to access it.
This might be caused by the object having been destroyed from C code using
something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x55b3345fd3d0 ==
#0 7ffeabd810d0 b /data/GNOME/gnome-shell/js/ui/dash.js:86
#1 55b335b62f88 i /data/GNOME/JHBUILD_HOME/.local/share/gnome-shell/extensions/dash-to-dock@micxgx.gmail.com/docking.js:487
#2 7ffeabd838f0 b self-hosted:1121
#3 55b335b62ec8 i /data/GNOME/gnome-shell/js/ui/layout.js:240
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2739>
The left/right navigation between top bar buttons is usually
handled by a key-press handler on the button's menu.
However when a DummyMenu is used, the button itself serves as
fake menu actor and will get grabbed when "opening" the menu.
Due to that grab, the event is not propagated to the stage,
and regular keynav does not work.
To avoid the focus getting stuck in that case, add an explicit
key-press handler that bypasses the grab.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2734>
When the user clears all notifications from the notification menu UI, it's
possible for a queued notification to be destroyed after the currently displayed
notification. The removal of the currently displayed notification is not
processed until the notification menu is closed (due to `this._bannerBlocked`).
By then, it's possible that `_notificationRemoved` has already been overwritten
when `_onNotificationDestroy` is invoked with another (queued) notification.
This eventually results in a notification banner that cannot be removed by the
user as the notification object needed to do so has already been destroyed.
Fix this by only assigning to `_notificationRemoved` if `this._notification ==
notification`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2736>
This is a small one time leak if there is more than one entry in the
search path due to multiple iterations overwriting the old pointer
before finally going out of scope.
Fixes: 934faaace ("st/icon-theme: Start using g_autofree")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2737>
When loading a symbolic SVG, the original file is wrapped in
a header that includes a generated stylesheet with the
appropriate colors, plus an overall opacity.
The opacity value is clamped to values between 0 and 1, which
directly matched the alpha field of the GdkRGBA type. However
since we moved to StIconColors/ClutterColor, the alpha field
is now in the range [0..255], any alpha value other than 0 now
results in full opacity.
To fix, translate the [0..255] integer into a [0..1] double
before using it as opacity.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2731>
Emitting this signal is broken right now: We check for a length of 0 on
this._objects[objectPath], but the
`this._objects[objectPath][interfaceName] = null` we do before the
check doesn't actually remove the key, it only sets the value to null,
leaving the key around and thus the amount of entries in the object doesn't
change.
Fix that by using the delete statement instead, "delete" properly removes
the key and thus affects the amount of entries in the object, making our
length === 0 check effective.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2730>
- Fixing things where the wrong colors bleed through or the colors are inconsistent.
- expand colors definitions for system colours
- add overrides to styles for overview and lockscreen
- update drawing functions to better use new colours
- rework entry drawing css
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2515>
When checking for an extension schemadir, an error will be thrown if
`query_info()` is used and the directory is missing.
Catch the case of a missing directory, but throw an error if the
path exists as a non-directory type.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2727>
Both :icon-name and :gicon are propagated to the internal QuickToggle
with property bindings. However the bindings are set up in the wrong
order:
:icon-name is a convenience property to set :gicon to a ThemedIcon
of the given name. That means binding :icon-name first will correctly
set the underlying StIcon's :gicon, but then the :gicon binding will
set it again to null.
Fix this by swapping the order in which the bindings are set up,
so that it works for both properties.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6542
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2726>
Commit 9d75d777c7 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 9d75d777c7 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>
When a window is in the background and should not have the cursor on top
of it, its _cursor will be null. By getting the texture through it, we
add this extra check, which was missing before, leading to a cursor
drawn at 0, 0 on windows where it should not have been drawn.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2702>
909616b208 seems to have wrapped window actors in a container, so the actor.has_pointer check started failing. Instead, switch to meta_window_has_pointer () which doesn't rely on window actor implementation details.
We check for existence of has_pointer first just in case someone attempts to run gnome-shell 44.1 with mutter 44.0 which does not have the function exported publicly yet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2710>
Add common test environment variables to a default test setup so that they
don't need to be repeated everywhere.
Also ensures that we're always using the gsettings memory backend to never
interfere with local environment.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2661>
GSettings schemas are now compiled at install time, so it is no
longer necessary to include the compiled schema in the archive.
However the `gnome-extensions pack` command hasn't been adjusted,
so that it can still be used to produce valid archives for all
supported versions.
To not let that code linger forever, error out when building
a version where GNOME 44 is the oldest supported release.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2639>
Whether or not animations should be enabled depends on various
factors, some of which may change at runtime. We therefore
track changes, and sync the setting by calling inhibit/uninhibit
as necessary.
Except that we never actually record the new state, so when animations
are disabled, we end up inhibiting them every time
the setting is synced, whoops.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2698>
Even though commit b89d90eb8 talked about the GLib.BookmarkFile
type, this didn't stop the code from sneaking a silly typo and
refer to this GLib.BookmarksFile (i.e. extra 's').
Fix the code to refer to the right type name and constructor.
Fixes: b89d90eb8 ("screenshot: Use GLib.BookmarkFile to save recent screenshots")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2692>
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>
We created the socket window using the same coordinates that mutter uses
for its own off-screen windows created via
meta_x11_display_create_offscreen_window() and that are filtered out in
MetaWindowX11's is_our_xwindow().
This caused these windows to be never tracked by mutter and then we
never received a "::window-created" signal that should lead a ShellTrayIcon
to associate itself as the clone of the created MetaWindow.
So, still keep it offscreen, but at different location.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2684>
At least for the time being, the background portal's app monitor
only supports flatpak apps, which are the only apps where we can
reliably match processes to .desktop files and assume that they
belong to graphical apps.
To indicate that there may well be apps that don't appear in the
list despite running in the background, add a clarifying section
title.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6400
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2681>
There is only a very limited subset of GTK that is usable from
within the compositor, and by now we should have replacements
for all of them in place.
On the other hands there is plenty that can go catastrophically
wrong in the rest. In particular on wayland, GTK must never open
a wayland display connection.
Make sure that extensions don't do anything silly, by disallowing
all GDK backends.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2680>
Prior to commit 7bd98f3f5f animation
onComplete handlers always occured at least after one main loop
iteration.
Now, if animations are disabled, they can get invoked immediately.
That breaks the endSessionDialog button handler, which calls
close before setting up the "closed" signal handler.
This commit fixes the handler to get set up first.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2677>
Shell has been stuck at version 0.1, which makes it difficult to
version API documentation.
Configure it to build with the same namespace version as
Mutter, so documentation and API changes can be tracked.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2674>
St has been stuck at version 1.0, which makes it difficult to
version API documentation.
Configure it to build with the same namespace version as
Mutter, so documentation and API changes can be tracked.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2674>
StIconTheme was added as a private implementation detail of
StTextureCache, but it turns out that some extensions do
make heavy use of GtkIconTheme.
Allow them to port away from GTK by exposing StIconTheme to
introspection.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2671>
At least for the time being, the background portal's app monitor
only supports flatpak apps, which are the only apps where we can
reliably match processes to .desktop files and assume that they
belong to graphical apps.
To indicate that there may well be apps that don't appear in the
list despite running in the background, add a clarifying section
title.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6400
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2660>
There's a few things going on here, that unfortunately must
happen in lockstep:
- The gnome-desktop-3.0 dependency gets replaced by gnome-desktop-4
and gnome-bg-4. The code in ui/background.js required minor updates.
- The libnma dependency gets replaced by a libnma4 dependency. The
code in misc/modemManager.js required minor updates.
- The gtk3 dependency is torn down everywhere but tests. Some
missing GdkPixbuf dependencies had to be added to compensate for
its lack.
- gtk_init_check() is no longer called
As a result, we replace a hard gtk3 dependency with a soft gtk4
run-time linking one, only added indirectly through gnome-bg-4
and libnma4.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2655>
Avoid using it by... guess it... yes! Copying the function
into an utility. This helper function to convert between
pixel formats is quite self-contained and unrelated to the
rest of GTK, so may be copied in place.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2655>
Reimplement tray icon support on top of NaXembed. NaTrayIcon now
becomes a subclass of this type, replacing GtkSocket. The
ShellTrayIcon wrapper now embeds directly a NaTrayIcon, the
ShellEmbeddedWindow GTK widget and ShellGtkEmbed ClutterClone
objects are no longer necessary to wrap a NaXembed socket window.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2590>
When the `QuickMenuToggle` was a discrete button, it could be set to
toggle mode, but the inner buttons no longer reacts as expected.
Bind the `toggle-mode` property between the `QuickMenuToggle` and its
contents so they behave as single toggle when enabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2664>
Avoid the GTK dependency, and use the common GLib API to store
screenshots in recent files. While at it, give it a better
exec hint than the implicit "gnome-shell %u" GTK added for us,
nobody seems to pay attention to that, but if they ever did
it's better to provide sensible information.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2656>
Meson enforces a separate build dir, so we no longer have to care
about build artifects in the source tree. Same applies for all
the generated crap autotools like to spread around.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2642>
gnome-bluetooth clears the list of devices when the adapter goes
away, but we cannot assume that that'll happen when powered down.
We don't want to show a (potentially outdated) list of devices
that cannot be interacted with in that case, so explicitly check
for the active state when returning devices.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2658>
The FolderView is a subclass of BaseAppView, which already has a
full-blown SwipeTracker attached to it. So no need to add another
PanGesture on top, the SwipeTracker will handle it for us.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2318>
NetworkManager frequently refreshes the list of available access points.
For some reason this often ends up removing some or all access points
only to add them back in a later refresh later. With the exception of
the currently connected access point, which is never removed.
When all access points of a WirelessNetwork have been removed, it gets
destroyed by NMWirelessDeviceItem::_removeAccessPoint(). This however
does not happen for the currently connected network due to the always
present access point. If this network now happens to consist of multiple
access points, the "unused" NMAccessPoints will get removed and added
in these refreshes, without the WirelessNetwork getting destroyed.
Whenever such an unused access point is added, due to the use of signal
tracking this leaks the NMAccessPoint and SignalTracker until the
WirelessNetwork is destroyed.
However when the NMWirelessDeviceItem is destroyed, for example due to
suspending, it stops tracking access point changes, ensuring that the
condition for the WirelessNetwork being destroyed can not occur anymore.
Even with just two access points, such as can be found in 2.4GHz+5GHz
home routers this issue leaks hundreds of NMAccessPoints and
SignalTrackers per day. As well as a small number of WirelessNetworks
which are also kept alive by the SignalTrackers.
To fix this disconnect from the access point when it gets removed and
destroy all remaining networks when the NMWirelessDeviceItem is
destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2652>
After an extension is installed, run `glib-compile-schemas` on its
`schemas` directory, if it exists.
This should avoid any endianess-related issues for extensions when
running GNOME Shell on varying architectures.
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2638>
We include a private hidden .desktop file for evolution's calendar
component, so that we can explicitly open that component when
evolution is configured as the default calendar application.
That's because the evolution developers didn't want to ship
additional .desktop files at the time, but they have since
then included a desktop action that can be used for the same
purpose.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2479>
Switching between the app grid and the window picker in the overview via
gestures results in _gestureEnd() getting called with endProgress !== 0
in both cases, which leads to it calling _showDone(). This then
unconditionally changes the state to SHOWN, which in this situation is
already the current state. Since the previous commit this results in a
warning, so check if we are already in the SHOWN state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514>
There have been several bugs in the past that caused invalid transitions
of the `shown` state, such as going from `showing` to `showing`. These
cause consecutive emissions of the `showing` signal, which can confuse
other classes such as the search controller which connects to the stage
`key-press-event` on showing and disconnects again on `hiding`. Having
two consecutive `showing` signals will cause it to connect twice, and
only disconnect once when hiding the overview again. This will lead to
key presses getting repeated in the search until the session is
restarted. Because there is no obvious connection to how and when this
issue got triggered, this now adds some validation code that only allows
valid transitions and throws an error otherwise so we get a backtrace of
the code actually causing the problem.
This does not fix the issue(s) causing the invalid state transitions, it
only adds a way of tracking them down.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4651
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514>
Sandboxed apps that run without a window are detected by the new
background monitoring service, introduced by xdg-desktop-portal.
We have an opportunity to improve the predictability of the desktop
and ensure that application state in transparently reported to users
by showing these apps, and allowing them to closed.
Add a new background apps menu to the quick settings, that is always
added at the bottom of the popover, and has a slightly custom, flat
style applied to it.
Show background-running apps in this menu, and allow closing them
by first attempting to execute the 'quit' action through D-Bus, and
if that fails, sending SIGKILL to the process.
See https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/191
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2624>
Since commit a1d650ce27, window title changes are listened for in the
ShellWindowTracker in order to emit ::tracked-windows-changed when
there are window title changes.
The rest of the things that happen in between (removing the window
from a ShellApp, possibly have it destroyed, and possibly creating a
new ShellApp to re-insert the window) are superfluous and even result
in the altTab switcher popup ending up confused about the applications
available.
Only emit the signal so changes can be followed on D-Bus, but avoid
the ShellApp fiddling otherwise.
Fixes: a1d650ce27 - window-tracker: Emit 'tracked-windows-changed' on title changes
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6385
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2634>
Menu toggles are currently regular toggles with an additional
arrow button. This allows for a simpler implementation, but
has downsides with regards to keyboard navigation and hover
feedback.
To make it more obvious that the two parts of the menu toggle
perform different actions, change the overall structure of the
toggle to *contain* a regular toggle and the menu button.
That way each element uses its own hover effect, and shows up
in the keynav focus chain.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5964
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2632>
Testing the greeter UI in nested has been broken for a long time
now, because the backend isn't ready yet when we try to push a
modal (via the screen shield).
As running nested is only relevant for development and testing,
working around the issue rather than fixing it properly seems
fine, so do just that and slightly delay startup when testing
the greeter UI.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2573>
The ClutterFrame argument was added to several signals with mutter commit
08b0e563d4d0088e19d24f3199626a2d27349d09. We have a bunch of after-paint
handlers in gnome-shell too, and updating those was apparently forgotten,
introducing subtle memory corruption that was luckily easy to track down by
running gnome-shell with ASAN enabled. Let's fix that and add the additional
argument to all the signal handlers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2629>
The --hotplug option works together with --headless and makes the perf
tool not add a persistant virtual monitor, allowing the perf test
themselves able to handle monitors.
This is needed for hotplug tests.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
This is meant to let perf tests initialize themselves earlier than they
would otherwise run.
This allows them to setup the necessary dependencies, e.g. create
test monitors or similar actions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
When we unmap, the child widgets have already been destroyed, so we
shouldn't try to. To detect this, delete the references we keep to them
on destroy, and null-check the hide call.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
The cached work area, which is the work area of the primary monitor,
effectively depends on two properties - the (global) work area and the
primary monitor - and we are only tracking changes to one of them. Also
track monitor changes to also cover the second case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
Doing it ourselves in the shutdown handler in layout.js means we won't
risk reacting to monitor changes that happen after gnome-shell prepares
to shutdown and the signal handler would disconnect itself in case we
used `connectObject(..)`.
This will currently never happen, but in the future perf tests will be
able to create virtual monitors for testing purposes, and they might get
destroyed during the shutdown procedures, causing us to react to them
when we shouldn't.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2623>
Thanks to NetworkManager's connection name disambiguation, it's
pretty common for single wired connections to be named "Wired". This
is fine and what we want almost all times, but in the specific case
of quick settings, we already have a "Wired" string set as title of
the quick settings toggle, so having that as subtitle is reduntant.
Hide the subtitle label (by returning null) when the subtitle of
a wired network matches the title.
Fixes ab10b95d2d
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6369
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2627>
If there is a single connection for a given NMToggle subclass,
use the connection name; otherwise, transform that into '%d
connected'. This is better than the current "Device (counter)"
template, e.g. "VPN (2)", which would give us a quick toggle
with:
VPN
VPN (2)
Change that to e.g.:
VPN
2 connected
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2619>
Following the previous commits where we left the quick toggle title
open for the new title scheme, set the titles for all network pills
to what currently is the "default" name.
That means, we pull the device name from Network Manager for devices,
through the disambiguate function, and hardcode 'VPN' for VPN
connections.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2619>
Instead of map the currently active items - for whatever they are -
into the quick toggle title, bind it to the subtitle.
This leaves room for setting static titles for device-backed
networks, such as Wi-Fi, Wired, Bluetooth, etc.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2619>
Add a subtitle label to QuickToggle, with a less prominent font.
Make the subtitle invisible when no text is present.
This new property will be used by next commits to implement quick
settings with a static title, and a changing subtitle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2619>
We already have ClutterColor to represent a color, and StIconColors
to hold color information for symbolics from CSS. Now that we moved
GtkIconTheme in-tree, we can make use of those types instead of
translating back and forth from GdkRGBA.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
We are still linking to GTK, and extensions may import GTK for
whatever reason, so avoid conflicts by moving the copied GTK
code into our namespace.
With that and the previous adjustments, the new code is now
finally buildable.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
Its use has been discouraged for years, and glib recently deprecated
it officially (while turning it around a small wrapper around malloc).
Don't let it sneak back in through some old GTK3 code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
The GTK code predates the G_DECLARE_*() macros, so it's under- standable
that it still does all the boilerplate manually. We
don't have that excuse in 2023, so move the the standard macros.
There is no reason for GtkIconTheme to be derivable, and as that
means that the instance struct itself is private, stop adding
separate private instance data.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
GTK uses its own private i18n header, which most notably defines
an I_() macro for interning static strings. That may be a worthwhile
idea for the entire codebase, but as it's out of scope for this
change set, just use the standard i18n support from glib for now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
Those are GTK internals that don't apply to us. Without the distinct
"screen's default icon theme", we also don't need custom theme support,
and can just always track the theme from StSettings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
The GTK code dates back to a time when "gchar" and friends were
still considered a good idea. Replace them with standard types
except for "guint" (I'm lazy) and GtkIconCache code that relies
on glib's byte order macros.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
GtkIconTheme's headers are split between a public and a private
one. We won't expose the icon theme API at all, nor do we need
to access anything beyond what the texture cache is currently
using, so merge the private header into the implementation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
GTK4 changed icon loading significantly, it is now closely tied
to snapshots and paintables. This makes a port highly unrealistic,
so to avoid staying stuck on GTK3 forever, copy the relevant code
into the tree.
The code is unmodified except for the include names and replacing
some stray tab indentation. It is still full of GTK internals, so
it will take a while before we can actually build it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
This behavior makes more sense to have in the iconGrid itself: When a
page is filled up with items, the new item should never go to the start
of the next page, but always to next empty slot.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
Folders reflow across pages because they don't set
allow_incomplete_pages to true. This means we want the nudging of items
to happen slightly differently when dragging an item across pages:
- When dragging from lower page index to a higher one, always reflow
towards the start of the grid (because there's now an empty slot on the
old page and items on the new page will force-reflow towards that)
- When dragging from a higher page index to a lower one, we can reflow to
the end as we usually do
To archive this, factor out the selection of "reflow direction" into a
separate variable that always defaults to "end" (because empty space is
always at the end of the grid). Set it to "start" when the item created an
empty slot on the current page or (and this is new:) on a previous page in
the folder case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
The iconGrid's getDropTarget() API supports dropping items to adjacent
pages just fine, but in the AppDisplay, we clip the grid and don't show
those adjacent pages. That doesn't stop getDropTarget() from picking
drop targets which are on adjacent pages though, so we need to filter
those out in the layer above.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
Returning a page and a position for the drop target seems more
straightforward than returning an actual grid item in getDropTarget().
With the next commit, this will allow us to throw away drop targets that
are not on the current page.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
_getLinearPosition() is a function that converts a page and position
index to the "accumulated" index that includes all pages before the
page. The function is used by _addItem() and _moveItem() for getting the
new index of an item inside the _orderedItems array.
Now when passing -1 as position to _addItem() or _moveItem(), this means
the item should be appended to the page. Right now _getLinearPosition()
returns the last item index on the page when passed -1, inserting the
item into _orderedItems at this index will actually not append it, but
insert it between the second last and last item.
To fix it, let's make the whole thing more robust by explicitly passing
an item to _getLinearPosition(). This means we simply no longer have to
assume what "-1" means. Moving the call to _getLinearPosition() to
happen after addItem() and moveItem() ensures that the new item position
is used and not the old one.
This fixes issues where the _orderedItems array gets out of order when
moving or adding items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
This is done just to "reset" the gesture when a grab operation
begins. With grab ops being based on ClutterGrab now, the gesture
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This is done just to "reset" the gesture when a grab operation
begins. With grab ops being based on ClutterGrab now, the gesture
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This is done just to "reset" the gesture when a grab operation
begins. With grab ops being based on ClutterGrab now, the gesture
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This is done just to "reset" the click action when a grab operation
begins. With grab ops being based on ClutterGrab now, the action
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This reverts commit 2b3ab3ecec.
Since the window menu no longer uses a MetaDisplay grab, but directly
a ClutterGrab, this is ineffective. But also, grabs are stackable, so
it's fine to push the window operation grab first and then dismiss the
window menu grab, even when MetaDisplay grabs get ported to using
ClutterGrab underneath. We now can just grab right away, so do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
Currently only the org.gnome.shell.keybindings schema is marked
as child schema. There's no harm with that, it's just nice to be
consistent, and having schemas show up in `gsettings list-children`
is a nice, touch.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2617>
Device additions/removals are tracked by GvcMixerControl, which
doesn't change when unsetting the stream. So clearing the menu
manually was a workaround, not a fix.
It's also worth noting that I failed to reproduce the original
issue again, so it's possible that we were working around a
pipewire bug that has since been fixed.
This reverts commit 1b62b7ea0a.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2616>
The on-screen keyboard only handles a single keyval per key, so the
current upper-case version of the German "ß" ends up as "S" instead
of the expected "SS".
It is possible to change the keyboard code to emulate multiple key
presses/releases for that particular case, but then luckily a proper
upper-case form exists nowadays: "ẞ".
That seems more appropriate for a single key than a dedicated "SS"
key, so replace it in all layouts that include it. Anybody who prefers
the traditional "SS" can easily tap "S" twice.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2612>
The tool was added in 2018 to migrate to per-desktop overrides from the
old overrides system.
5 years later, everyone who’s going to migrate probably has migrated, so
we can delete the script and remove a process running on every login.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2611>
Since commit 7bd98f3f5f animateOutAndDestroy() destroys
the placeholder right away when animations are disabled. Connect to the destroy signal
before calling the function.
This fixes the following error:
Gjs-CRITICAL **: 16:51:35.195: Object .Gjs_ui_dash_DragPlaceholderItem (0x55b9a946da20),
has been already disposed — impossible to connect to any signal on it. This might be
caused by the object having been destroyed from C code using something such as destroy(),
dispose(), or remove() vfuncs.
== Stack trace for context 0x55b9a70d08f0 ==
#0 7ffe161bd070 b resource:///org/gnome/shell/ui/dash.js:835 (df3d61d32e0 @ 98)
#1 7ffe161bd170 b resource:///org/gnome/shell/ui/dash.js:901 (df3d61d33d0 @ 779)
#2 7ffe161bd290 b resource:///org/gnome/shell/ui/dnd.js:562 (3d4da0cfd420 @ 909)
#3 7ffe161bd360 b self-hosted:1115 (3d4da0c7ef10 @ 407)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2604>
Dropping a icon from the dash to the application grid will set this._placeholder
to null. However the AppIcon is still used to represent the application in the
application grid. If we click on it we emit a pressed event. Stop assuming
that this._placeholder is still valid in the callback, use the icon parameter
instead.
This fixes the following error:
```
Gjs-CRITICAL **: 18:22:39.003: JS ERROR: TypeError: this._placeholder is null
_ensurePlaceholder/<@resource:///org/gnome/shell/ui/appDisplay.js:1477:17
vfunc_button_press_event@resource:///org/gnome/shell/ui/appDisplay.js:3121:27
```
Fixes: 6fc93b78bc
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6317
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2606>
The videos directory doesn't necessarily have to exist, users are free to
delete it. Right now we don't handle this case and screencasting fails.
Let's handle it and fall back to the users home directory instead when
xdg-videos doesn't exist.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2594>
- increase the font size of clock elements
- increase the size of user avatars
- combines lock and login scss into one file
- clean up the css for avatars
- adjust the blur parameters of the screen shield
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2564>
In addition to the "overshoot/bumping into monitor edge" behavior we already
have, we also want to switch pages when simply hovering above the prev/next
page indicators.
This page switch shouldn't happen immediately though, it needs to be kicked
off using a timeout instead. The reason for that is that the next/prev page
indicators are large areas, and simply dragging there isn't enough of a
gesture to really interpret as "the user wants to switch pages".
After this page switch has been toggled once, it can be repeated using the
same "repeat" timeout we introduced with the last commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2581>
Right now we have a behavior in the appGrid where "bumping" the cursor
against the monitor edge during DND switches the page immediately, and
holding it there (at the monitor edge) switches pages again after a timeout.
With the next commit we'll introduce another way of switching pages during
DND, that is hovering over the next/prev page indicator to switch pages. To
allow those two methods to play well together, refactor the "overshoot" page
switching to make the timeout into a more generic "repeat" timeout. This
means we can now divide page switching can be roughly divided into two
different steps:
- Switch page immediately when bumping cursor against screen edge, also
works when repeatedly "bumping"
- Switch page automatically again after a second when keeping the cursor at
the screen edge without moving
We'll reuse the "repeat" timeout that's introduced here in the next commit,
where we'll introduce page switching by hovering the next/prev indicators.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2581>
With MR https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335,
the page navigation in the app grid was redone and prominent, always visible
navigation arrows were added. This larger change in the navigation of the
app grid also involved changes to the drag and drop behavior.
Before those changes (in GNOME 42), switching pages during DND in the app
grid worked like this: By "bumping" the cursor against the monitor/appGrid
edge, an immediate page switch would be triggered. Leaving the cursor in
that edge area would then trigger repeated page switches every second. By
repeating the "bump" gesture (moving cursor back into the grid, then
"bumping" against the edge again), it was possible to switch pages even
faster than every second.
When adding the always visible navigation arrows, we briefly tried out a
different way of page-switching during DND with commit 09b975fa: The "bump
against monitor edge" gesture (or "overshoot" behavior as it's called in the
code) was replaced with a hover timeout on the navigation arrows. The idea
behind that was to allow hovering the navigation arrow during DND to
eventually trigger a page switch, which also makes sense.
The replacement of the "overshoot" behavior made some people unhappy though,
so it was decided to bring back the old "overshoot" behavior with commit
4dcae8dd. Due to time pressure before the release that didn't go very well
and we ended up with a mixup of both approaches that doesn't feel too
polished.
So let's try to fix that by first going back to the working "overshoot"
implementation as it was in 42, then slightly refactoring that
implementation, to finally incorporate the new "page indicator hover"
behavior that https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335
originally intended to use.
This reverts commit 4dcae8ddd2.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2581>
When GNOME shell runs on a less memory system (for example 3 GB RAM), it
is usually killed by the kernel OOM-killer easily. Because, it has a
higher OOM score. However, GNOME desktop environment cannot do anything
when the GNOME shell is killed.
This commit adjusts and lowers down gnome-shell process' OOM score to
avoid being killed by the kernel OOM-killer too early. In other words,
sacrifices other processes first.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2582>
This means the screen share window view gets updated also when the title
of a window changes. This is important since it often changes shortly
after mapping, which would otherwise go unnoticed by
xdg-desktop-portal-gnome.
An example is launching Files and it showing up as 'Loading..', or
launching a terminal, and it not showing the proper title (current
directory), but some place holder that is never visible on the
application window.
Adding it to the window tracker instead of in introspect.js itself is
for convenience - there is no per window signal tracking there, and it
already listens to the signal emissions about changed windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2578>
We no longer *require* a merge request URL in commit messages, we
ban them (since Marge is kind enough to add them for us).
While at it, add a small section on prefixes (~~stolen from~~
inspired by mutter).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2572>
If we are getting purpose hint changes while the language switcher is popped
up, this likely means the purpose hint was actually triggered by the key
focus change induced by the language switcher popping up.
In this case, we on one hand would like to preserve the state that applied
before thise focus change, and on the other we very much want to avoid the
keymap change that would forget about the keys being pressed.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6066
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2534>
Extensions can export asynchronous enable() and disable()
functions. To guard against re-entrancy when enabling or
disabling an extension, this commit adds two new states:
ENABLING and DISABLING which are set immediately prior
to calling enable() and disable() respectively.
This commit updates the extensions CLI and Extensions app
with new strings for these states.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2364>
When we're running in e.g. CI, or in a virtual machine without hardware
acceleration, and we actually want to enable animations despite the
potential performance implications, change the AnimationsSettings to
only inhibit if we're a XVNC instance or not hardware accelerated if
--force-animations wasn't passed.
Still inhibit animations if there is a remote desktop session that
explicitly disables animations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2560>
If we want to run with the welcome screen showing, it should be done so
explicitly. Hide it if there is a perf test running for now, so that
what we test is what is expected to be tested.
We also don't want to show the root user warning, since we'll be running
as root in the CI containers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2560>
This allows neat tricks like first arranging the script `fakegdb`:
```sh
function ignore_gdb_arg() {
if [[ "$1" == "--quiet" ]] || [[ "$1" == "--args" ]]; then
return 1
else
return 0
fi
}
ignore_gdb_arg "$1" || shift
ignore_gdb_arg "$1" || shift
echo exec "$@"
```
then running
```sh
meson test -C build -v perf-basic --test-args '--wrap "gdb --args"' --gdb --gdb-path `which fakegdb`
```
To make it possible to run the perf test case with gdb running the
actual gnome-shell.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
This test runs all of GNOME Shell using the headless backend inside a
mocked D-Bus environment. The basic test tests, well, basic things, like
the panel menu, the overview, showing the app grid view, as well as
going back to the session view.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
If one wants to run tests the non-installed gnome-shell, that currently
fails as gnome-shell the executable attempts to link against
./build/src/libgnome-shell.so, but when GObject introspection tries to
find what library to link to for Shell, it goes to the installed
libgnome-shell.so, causing two different versions of libgnome-shell.so
to be loaded.
This, however, can be avoided thanks to meson adding $ORIGIN paths to
relevant libraries before installing an executable. What this means in
practice is that we can inspect ourself upon startup, discover whether
the RPATH/RUNPATH header contains $ORIGIN, and if so, expand it to the
directory containing the executable, and prepend the introspection
search paths with said directory.
This effectively means that the introspection machinery now finds the
same library that the linker linked the gnome-shell executable with,
making it run successfully.
It's not possible to use $GI_TYPELIB_PATH since
g_irepository_prepend_library_path() takes precedence. There is no
"append" variant of that API.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
Tearing down gjs means that we won't have any dangling references kept
alive by GC or otherwise alive Javascript objects, when we finally tear
down the mutter context. This allows for a clean shutdown of GNOME
Shell.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
Move back actors that were adopted from mutter (window_group,
top_window_group, the feedback group) from the uiGroup to the stage, and
then destroy the uiGroup. This will tear down more or less all of GNOME
Shells actors gracefully.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
The nPages property can be 0, which is the case in a stripped down CI
image without a single app to be listed, which means we can't clamp to
`nPages - 1`, since that'll give us a negative index and the following
error:
(gnome-shell:266): Gjs-CRITICAL **: 16:48:56.633: JS ERROR: Error: Page -2 does not exist at IconGrid
getItemsAtPage@resource:///org/gnome/shell/ui/iconGrid.js:1383:19
_translatePreviousPageIcons@resource:///org/gnome/shell/ui/appDisplay.js:323:34
_syncPageIndicators@resource:///org/gnome/shell/ui/appDisplay.js:396:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:445:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1236:29
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1582:15
_init/<@resource:///org/gnome/shell/ui/appDisplay.js:499:18
_init/pagesChangedId<@resource:///org/gnome/shell/ui/iconGrid.js:1137:24
_removePage@resource:///org/gnome/shell/ui/iconGrid.js:454:14
_removeItemData@resource:///org/gnome/shell/ui/iconGrid.js:495:18
moveItem@resource:///org/gnome/shell/ui/iconGrid.js:854:14
moveItem@resource:///org/gnome/shell/ui/iconGrid.js:1277:29
_moveItem@resource:///org/gnome/shell/ui/appDisplay.js:1194:20
_redisplay/<@resource:///org/gnome/shell/ui/appDisplay.js:1085:22
_redisplay@resource:///org/gnome/shell/ui/appDisplay.js:1080:17
_redisplay@resource:///org/gnome/shell/ui/appDisplay.js:1370:15
_init/<@resource:///org/gnome/shell/ui/appDisplay.js:633:24
_initializeManager@resource:///org/gnome/shell/misc/parentalControlsManager.js:95:14
async*_init@resource:///org/gnome/shell/misc/parentalControlsManager.js:63:14
ParentalControlsManager@resource:///org/gnome/shell/misc/parentalControlsManager.js:55:4
getDefault@resource:///org/gnome/shell/misc/parentalControlsManager.js:42:22
start@resource:///org/gnome/shell/ui/main.js:184:29
@resource:///org/gnome/shell/ui/init.js:6:17
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
Running dispose on the setting causes issues when we're being destroyed,
as the signal handler in the GSettings binding will be cleared by the
GObject itself before it has the chance, resulting in warnings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
With meta_exit() we bypass the tear down procedures, making the test
case excercising much less code paths. Use meta_context_terminate()
instead, as that exits the main loop and goes through proper shutdown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
Since commit 7bd98f3f5f the onComplete callback
is called right away when animations are disabled. As side effect, now
this._coverPane gets shown/hidden in the wrong order. Start the animation after
setting this._coverPane initial state, so that the animation callback can set the
this._coverPane final state without it being overwritten later.
Move the animation also after emitting the showing and hiding signals. So that the
order showing -> shown and hiding -> hidden is still preserved when animations are
disabled.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6096
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2532>
- rework the entry style to work in both hc and normal
- rework drawing functions to accommodate hc
- buttons all get borders under hc now
- window picker titles are more legible
- alt+tab switcher tiles are visible
- dash is made more visible under hc
- popover menus are all more visible under hc
- search results borders are improved
- calendar days have a different look under hc
- overview bg is completely black in hc
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2527>
The old custom overrides mechanism was superseded by
session-specific defaults back in 2018. By now any
potential consumers (like gnome-tweaks) should have
adjusted, so time to remove it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2517>
We currently initialize regions in all code paths except for the
greeter. But while there are no windows on the login screen, the
work area can still be used for positioning, for example for
notifications.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2546>
We assign (disambiguated) device names every time a device is added
or removed, and store the name on the corresponding menu item.
However menu items are only created when the device should be shown,
not necessarily when it is added (unplugged ethernet cable, ongoing
initialization, ...).
Fix this by tracking device names separately from device items, and
set the name on newly created items.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6040
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2529>
If the OSK is destroyed while visible without being close()'d first,
the completion mode might remain turned on. Ensure it is turned off
on OSK destruction so that typing-booster has no chance to remain
turned on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2543>
Even though the emoji panel may be destroyed with the OSK, the swipeTracker
that is set up to navigate between pages is left lingering, and handling
events for some gestures in the stage. This results in warnings like:
JS ERROR: TypeError: this._panel is null
set delta@resource:///org/gnome/shell/ui/keyboard.js:720:9
_onSwipeUpdate@resource:///org/gnome/shell/ui/keyboard.js:750:22
_updateGesture@resource:///org/gnome/shell/ui/swipeTracker.js:670:14
vfunc_gesture_progress@resource:///org/gnome/shell/ui/swipeTracker.js:288>
on touch interaction after the OSK was shown and dismissed. In order to fix
this, issue explicit destruction of the swipeTracker when the emoji pager
actor is destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2543>
When the overview is hidden just after starting GNOME Shell the app
grid is not populated yet. Thus, this._grid.nPages is 0. When the
overview is about to be hidden, we call goToPage(0) on the AppGrid.
This results in pageNumber being clamped to -1 and leads to the
following exception:
```
JS ERROR: Exception in callback for signal: hidden: Error: Page -2 does not exist at IconGrid
getItemsAtPage@resource:///org/gnome/shell/ui/iconGrid.js:1383:19
_translatePreviousPageIcons@resource:///org/gnome/shell/ui/appDisplay.js:323:34
_syncPageIndicators@resource:///org/gnome/shell/ui/appDisplay.js:396:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:445:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1237:29
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1584:15
_init/<@resource:///org/gnome/shell/ui/appDisplay.js:1328:52
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:89:42
_hideDone@resource:///org/gnome/shell/ui/overview.js:589:18
_animateNotVisible/<@resource:///org/gnome/shell/ui/overview.js:566:55
onStopped@resource:///org/gnome/shell/ui/overviewControls.js:753:21
_makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:150:22
_easeActorProperty/<@resource:///org/gnome/shell/ui/environment.js:316:60
```
Connect to the overview hidden signal only after initializing the
AppDisplay content, so that goToPage(0) is not called when there
is no page yet.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5837
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2536>
The quick settings menu is child of an actor at 0,0 coordinates,
simply transformed to look in place. However the parent actor stays
at 0,0, and gets a width/height that is able to contain the child
menu (even though the transform will push it outside the parent
actor).
This makes the parent actor (not meant to handle pointer/touch
input) to cover parts of the shell. Since this actor is also where
the Clutter grab happens, the menu is not dismissed either.
Make this parent actor have a 0x0 size, so that it can still act
as the parent for the quick settings menu, but does not actually
cover any area. This makes clicks around the top left corner work
again while the quick settings menu is opened.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5887
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2535>
The screencast service shuts down when not in use, so it is almost
certainly not running when handling the screencast shortcut.
Instead of making sure the service is restarted, just cache the
property when initializing the proxy.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2533>
Some gstreamer plugins require a connection to the display server,
so they block until the server is up and running. That's why we
moved the check into the D-Bus service, so that the blocking would
not lock up the compositor itself.
However the block can still delay the service initialization so
much that auto-shutdown hits immediately when returning from the
constructor. If that happens, the proxy on the shell side is no
longer backed by a remote object when the init callback runs, and
all properties therefore resolve as `null`.
As a result, gnome-shell thinks that screencasts aren't supported
and hides the screencast button.
Fix this by holding the service during the gstreamer checks, so
that the auto-shutdown timeout only starts after the service is
ready.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6051
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2533>
In commit ee09c5c853 we chose to pick
the minimum value in order to preserve 0 instead of replacing it with
1. While returning 0 unconditionally when animations are disabled
seems the more logic thing to do, we were unsure about possible side
effects. Do the change now. Since we are early in the development cycle
we should be able to deal with side effects (if any) on time for the
next release.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2528>
The IBusInputContext currently seems to be a bit sloppy wrt propagating
the current state to engines after those are changed, this results in
engines possibly ending with purpose/hint/etc that do not actually
correspond to the current state.
Ensure this state is cleared on unfocus of our IBusInputContext, so
that the next time the input method receives an input focus, the new
state makes it all the way to the currently active engine.
Fixes situations in the GDM/lock screen password entry that IBus
would miss the PASSWORD hint set on the StEntry, and let passwords
be fed to engines.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5966
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2512>
Besides user interaction, there's two users of IBusManager.setEngine():
- The code that toggles all IBus engines off on entries with PASSWORD
purpose.
- The code that toggles completion support on OSK presence.
These are currently pretty oblivious to each other. Make this
interaction more resilient by making all external IBusManager changes
more cautious about directly changing the engine, and revoke properly
the completion mode if it needs be (e.g. changing to a non-XKB engine).
But another notable change is that ibus-typing-booster is now preferred
always, over PASSWORD purpose hints. This is done to avoid possible
doubled attempts to change the current engine (and ensuing IBusInputContext
confusion).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2512>
GDBusProxy transparently handles the remote object appearing and
vanishing. It is therefore not an error if the service is not
running at the time the proxy is initialized, so we proceed and
try to read the list of profiles which is null in that case,
resulting in (harmless but annoying) warnings.
Avoid this by only reading the initial list of profiles if the
service has a name owner.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5992
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2518>
When propagating keys from the OSK, we usually feed these directly to
the IBusInputContext and let the IM handle the effects of this virtual
key event (which may also include feeding a key event back to us).
But these functions may also return a FALSE value if the key was "let
through" by the IM, which means the ball is in our yard again, and
we are responsible of letting this event get to its destination.
If that happens, just fall through, so the string is committed to
the client as an UTF-8 string, or propagated through keyboard events.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5930
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2508>
Consider the existing input sources MRU only valid if it contained
more than one element to pick from. Fixes the following situation
with initial-setup sessions:
- Initial setup Session starts, with several input sources already
configured ("us" between them)
- InputSourceManager initializes, only the default "us" keymap is
available
- MRU list is constructed, "us" is picked
- InputSourceManager catches up with session configuration, the
other extra sources are added
- MRU list is reconstructed, "us" is already the most recent
- Session ends up with "us" picked, regardless of its position in
the list, and no MRU existing prior to startup
If we consider the intermediate single-element MRU list invalid,
it is still possible to pick the best default source between all
the configured ones (the one that was put first in the list,
basically), after initialization is complete.
But also, it is unnecessary to have if there is a single source to
pick from. After the sources list has two elements or more, the
MRU list will become effective and preserved during changes to
the available sources.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5873
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2495>
There are cases where the animation time is set to 0 on purpose
in order to not animate. When animations are disabled via
/org/gnome/desktop/interface/enable-animations those animation
times are increased from 0 to 1. This makes the "Caps lock is on."
message appear unconditionally in the lockscreen for a brief moment.
Select the minimum between the two values. So that an animation time
0 is preserved instead of being replaced by 1.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2471>
In older versions of GNOME, when a menu was used for Bluetooth devices,
we tried to avoid showing the Bluetooth menu to folks who didn't use
Bluetooth.
This kept causing problems as the menu would disappear if no
devices were setup and the platform "airplane mode" removed the
Bluetooth device from the USB bus, making it impossible to detect
whether a Bluetooth device existed, compared to a user unplugging a
removable Bluetooth device.
Closes: #5749
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2488>
When updating the MRU sources if there was no prior MRU, we want
to go with the unmodified list of sources in visibility order.
However iterating over object properties happens in an undetermined
order, so the initial MRU list ends up picking a value at random.
In order to prefer the sources list in the same order than they
appear in the menu if there was no prior MRU, order the keys
when accessing it and building the initial list of sources.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5873
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2487>
Use Meta.LaterType.BEFORE_REDRAW to queue setting the bind constraint
offset in an idle callback. This is needed since the signals that
trigger updating the offset may be emitted during allocation, at which
point queuing new relayouts isn't ideal, since it could result in
relayout cycles. In this case, we really do want to relayout as a side
effect of another actors allocation, so make this explicit.
This fixes a few warnings such as:
The actor '<unnamed>[<StBoxLayout>:0x3138d70]' is currently inside an
allocation cycle; calling clutter_actor_queue_relayout() is not recommended
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2476>
When a `PanelMenu.Button` is added to the `statusArea`, its menu is
added to the `PopupMenuManager` if it has one at the time. If a menu is
added later or a new one set, the new menu is never added.
Move the call to `PopupMenuManager.addMenu()` from `_addToPanelBox()`
to `_onMenuSet()`, which is called when the `PanelMenu.Button` is added
and whenever it emits the `menu-set` signal.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2470>
Pipewire 0.3.52 via commit a1f33a99 introduced a change that affects how
long pipewiresrc holds onto the pw_buffers it dequeued. Before that
change the pw_buffer was held until the end of the videoconvert element
at the beginning of the pipeline. After that change the pw_buffer was
held onto until the filesink at the end of the pipeline. This was
starving MetaScreenCastStreamSrc of pw_buffers to record new frames
into, resulting in the majority of frames being missed, especially in
situations in which the encoder was taking longer.
Pipewire 0.3.57 via commit 1ea1d525 will allow queuing the pw_buffer
early again via the `always-copy` option. This however is only a
workaround until a proper solution is found in either pipewire or
gstreamer that does not depend on copying the buffer contents and
instead queues the pw_buffer again after videoconvert as prior to
a1f33a99.
Since it is not clear yet when a proper solution will arrive, this makes
use of `always-copy` as a workaround for now and should be reverted once
it is no longer needed.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5585
Related: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2461
Related: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/283
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2436>
The object the SignalTracker belongs to is stored in a map managed by
the SignalManager which keeps a reference to that object. This map is
never destroyed nor is any entry ever removed. This leads to all objects
that ever had SignalTrackers used on them being kept alive even after
all references outside of the SignalTracker are long gone. This then
also extends to other objects which are leaked indirectly through
reference chains from these objects.
And if some of those objects are GObjects, this will prevent them from
being finalized, leaking further resources. A StWidget for example will
not release its shadow textures.
Fix this by destroying the SignalTracker and removing it from the
SignalManager once the last signal it was tracking has been untracked.
A WeakMap could have been used as well, but we need the Map to be
iterable in some of the following changes.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5807
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5796
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2466>
After the next commit, when some classes, such as PopupMenuManager try
to disconnect via a destroy handler, the SignalTracker might have
already been destroyed, so trying to get it from the SignalManager will
cause it to create a new one, which will then try to connect to the
destroy signal of the already destroyed object.
This could for example be triggered by changing backgrounds.
Fix this by not doing anything in disconnectObject if there is no
SignalTracker for that object.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2466>
This reverts commit 085102be74.
We need the SignalManager map top be iterable at shutdown for some of
the following changes. A WeakMap is not iterable. This revert changes it
back to a regular Map, which re-introduces the leaks caused by this.
Those will be fixed differently by the two followup commits.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2466>
Commit 9168f6055e marked the parameter as nullable, which is in
conflict with the precondition check. But given that NULL is
valid for the underlying ClutterText (and GtkLabel accepts it
as well), there's no strong argument for disallowing NULL, so
remove the precondition check.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2465>
Due to !2056 the monitor config is 2 instead of 4 on the desktop.
However, the constant `Meta.MonitorSwitchConfigType.UNKNOWN` is fixed to
4, and may cause the initial selection to be out of index thus fail to
display the switcher. This replaces the above constant to the actual
length of the switcher items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2451>
If a device has multiple connections set up, then at most one of
those can be active at a time, which is why they are presented
as radio items.
In contrast, VPN connections are not mutually exclusive, each can
be turned on or off independently. Setting :radio-mode on them
currently means that VPN connections can be activated, but never
disabled.
So instead of abusing the :radio-mode property to give VPN items
the UI we want, use regular items that reflect the desired behavior
and explicitly set up the UI the way we want.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2426>
The object the SignalTracker belongs to is stored in a map managed by
the SignalManager which keeps a reference to that object. This map is
never destroyed nor is any entry ever removed. This leads to all objects
that ever had SignalTrackers used on them being kept alive even after
all references outside of the SignalTracker are long gone. This then
also extends to other objects which are leaked indirectly through
reference chains from these objects.
And if some of those objects are GObjects, this will prevent them from
being finalized, leaking further resources. A StWidget for example will
not release its shadow textures.
Fix this by using a WeakMap in SignalManager.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5807
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5796
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2450>
We got a shiny new screenshot UI last cycle, but only relatively
obscure ways of launching it: Keyboard shortcut or overview search.
The new quick settings provides us with a natural place to expose
the functionality more prominently, and at the same time reduce
the emptiness of the top row, in particular on systems without a
battery and when locked.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
We will expose the screenshot UI from quick settings, including
on the lock screen. It would be odd to restrict keyboard shortcuts
more than the more accessible UI, so relax the modes for the
screenshot-ui and screen-screenshot shortcuts.
We still disable all screenshot shortcuts on the login screen, as
users don't have an obvious way to retrieve the screenshot files.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
We currently don't take the session mode's `hasWindows` property
into account when deciding whether window screenshots should be
allowed. Right now that doesn't matter in practice, because all
the ways to bring up the screenshot UI are blocked in those modes
anyway. This is about to change though, so take the property into
account to prevent an information leak.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
It is currently not possible to bring up the screenshot UI while
locked, but that is about to change.
We still don't want screencasts in that case, because they are
much easier to abuse for filling up someone else's disk.
That restriction is enforced by inhibiting remote access in the
backend, so trying to create a screencast session will fail anyway.
Still, not offering an action that is unavailable is better than
having it fail silently, so do exactly that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
When we aren't showing the power toggle (read: on systems without
a battery), all items in the top are located on one side. Address
this by "moving" the spacer between "Settings" and "Screen Lock"
in that case to balance items a bit better.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
The quick settings code was first developed in an extension, which
meant it made sense to maintain compatibility with GNOME 42 and not
use the new :icon-name convenience property.
There is no good for sticking with that for GNOME 43 as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2439>
Since we put the actual slider into a bin to get a proper focus
indication, the slider isn't focused anymore and its accessible object
is therefore invisible to the screen reader.
Fix this by passing the slider's accessible object to the actor
that takes the focus.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2431>
NetworkManager can check if a network interface has "internet access" by
invoking a HTTP request.
The URI used for connectivity checking in NetworkManager can be configured
manually in NetworkManager.conf:
[connectivity]
uri=http://portal-check.exmaple.com/nm-check.txt
Portal Helper provides an argument to pass the URI that should be opened.
If this argument is empty it uses http://nmcheck.gnome.org as a fallback.
Pass the URI configured in NetworkManager to Portal Helper instead of
an empty string.
Fixes#1313
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2228>
This prevents _sync() being called after actor destruction (since actor
destruction became more reliable in mutter@3d94c7cc2) and so eliminates
this shutdown error:
```
(gnome-shell:35197): Gjs-CRITICAL **: 16:31:02.769: Object .Gjs_ui_calendar_Placeholder (0x559ed6e547e0), has been already disposed — impossible to set any property on it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x559ed6022310 ==
#0 559ed783c5a8 i resource:///org/gnome/shell/ui/calendar.js:1012 (31955be5fc90 @ 148)
#1 7ffef8f38230 b self-hosted:1178 (32af8f6b0c40 @ 454)
#2 559ed783c518 i resource:///org/gnome/shell/ui/popupMenu.js:806 (31955be18ce0 @ 52)
#3 559ed783c488 i resource:///org/gnome/shell/ui/popupMenu.js:954 (31955be190b0 @ 168)
#4 559ed783c3f8 i resource:///org/gnome/shell/ui/panelMenu.js:189 (31955be88150 @ 41)
#5 7ffef8f3de60 b self-hosted:1178 (32af8f6b0c40 @ 423)
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2429>
It is generally not possible to differentiate between systems
without bluetooth support, and systems where a bluetooth adapter
is powered down.
We work around that by tracking whether there are any set up devices,
and keep the bluetooth visible in that case, even when no adapter
is present.
However commit eeabdd150c moved updating the setting into the code
that handles adapter changes, which is exactly the place where we
carefully avoid changing the setting because it would be too
unreliable (devices may have already disappeared, or not yet
appeared).
Fix this by changing _setHadSetupDevices() to _syncHadSetupDevices()
and call that everywhere _sync() used to be called, *except* on
adapter changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5714
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2409>
We do set the full OSK as LTR since keymaps are defined in that
direction. Other actors inside the OSK might want differently so
move this piece of setup to init(), so child actors can set their
own without the OSK overwriting the value.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
This should be handled in the capture phase so containers setting
up the drag gesture have an opportunity to handle events from children.
This also follows what the 3fg swipe gesture does.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Update the emoji panel so it can handle ratio changes dynamically,
and propagate the ratio from the Keyboard itself, so that the
emoji panel has a size that fits the OSK panel it was launched
from.
This is more important now with widely varying ratios, like
extended keyboards.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
This keymap requires the corresponding input method for Hangul
input, and the hangul mode to be enabled. Look up for the right
state, and use a corresponding 'us' keymap for english input
otherwise, in order to follow hangul IM behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Add latched keys a distinct color again (mainly for alt/ctrl being
notoriously active), and tweak the suggestions box sizes so there are
no size jumps between an empty and a populated suggestions box.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Make these closer to the mockups, on most locales at least.
Unclear/remaining are:
am, ara, il, in+mal, ir, kg, mk, mn, rs, ru, th, ua
Since the extended OSK keymap is short on space, it coalesced
both keys together (i.e. extending the extra keys popup) so it
takes less room.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Like OSK key buttons, we must avoid the default grabbing behavior
of StButton here. Hook to button-press-event to commit the selected
words, so we get a chance to prevent focus changes on the current
key focus.
Likewise, connect to ::touch-event to handle touch input.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
This mode changes the current IBus engine to ibus-typing-booster
under the rug (i.e. no changes in keyboard status menu) for any
XKB engine selected.
In order to make it useful for the currently selected language,
the typing-booster dictionary is changed to the current XKB
layout language. And since the OSK has its own emoji panel,
typing-boosters own emoji completion is disabled.
These changes only apply as long as the OSK panel is shown,
reverting to the original engine and typing-booster configuration
after it is hidden. This in theory also caters for users that
do have ibus-typing-booster enabled as an input source.
The final effect is text prediction for the language that is
being typed, according to the OSK layout, given that
ibus-typing-booster and the relevant hunspell dictionaries are
used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
This action will replace CLUTTER_KEY_Backspace emission for
the OSK backspace key. Following the available mockups, implement
different modes of operation:
- Single tap deletes a single character
- Long tap starts deleting characters one by one
- Longer tap switches to word-by-word deletion
This is made possible via the input method surrounding text,
inspecting the string to look the previous char/word position
backwards, and relies on IM focus providing enough context.
Since deleting text and getting surrounding text are both
async operations, we make one happen after the other, until
the button is released.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Keep it consistent with the rest of the actions. For long press
handling (i.e. shift turning to caps lock), this also means the
release action should be cancelled after any long press, to prevent
both from taking effect at the same time.
Prior to this commit, we used to switch level (and hide the button
being pressed) on button press, which made its long press handler
never get a paired release and end up triggering caps lock.
Performing the action on release ensures the shift key button does
not fall into this situation, making this issue moot.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Have these defined in the JSON files themselves, instead of trying
to add them from JS while minding the differences in number of levels
and rows.
This means more redundant data in the JSON files, but simplifies
OSK layout creation significantly, and allows finer control over the
appearance without quirks.
As a result, importing data from CLDR is no longer as straightforward
as running an script. After initial import, manual editions will be
required to add missing keys, assign key widths, and so on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
These actions are defined in the JSON files themselves, allowing
us to migrate away from the sets of pre/post default keys, and fold
them into the JSON files for fuller control on layout and appearance.
As a first migration step, handle the relevant actions in the buttons
created from the JSON files, so we can port these.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Instead of having callers handle pressed+released, emit string
commits on a distinct signal that is emitted all at once during
release.
This also unifies the behavior of keys that have an extended keys
popup and not wrt press/release behavior and key repeat.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
Add distinct properties for label/icon, and commit string/keyval
actions. This makes keys figure less things on their own, allows
disociating aspect and behavior (e.g. label '↲' and keyval 0x13),
and makes the fallbacks clearer (keyval and label resorting to
commit string).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
We want to extend the data model with additional keys, actions,
and properties. We need keys to be a map instead of a plain array
of strings.
Adapt the script to dump data in this new format, so it generates
a decent base to manually complete the work.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2278>
We want the list to keep updating, so periodically request scans
from NetworkManager. The code follows what Settings does in its
wifi panel, including the used interval.
There's a cute little spinner in the menu header now, to indicate
an ongoing scan.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Unlike the old menu that restricted almost everything on the lock
screen, we went into the completely opposite direction with quick
settings and kept everything that does not launch windows available.
Extend that line to the network items, but still respect the
`network-control` permission.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
When moving to quick settings, we will no longer have a single
parent we can hide instead.
This is only really needed for VPN - devices go away when networking
is disabled, connections (as in: configuration) do not - but it's
simpler to just handle this in the base class than adding a
_shouldBeVisible() method the VPN section can override.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
If any device is in hotspot mode, use the corresponding item as
primary. Disable the (future QuickMenuToggle) menu in that case,
and turn off the hotspot when activated rather than toggling the
global wireless switch.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Wireless items represent a single adapter, but wireless connectivity
is controlled globally under NetworkManager.
So instead of delegating activation to items, bind the :checked
property to the global :wireless-enabled property and toggle it
on activate.
As any wireless devices will change their state to UNAVAILABLE
when wireless is disabled, don't remove corresponding items in
that case to keep the section visible.
We don't want to hide the button to turn Wi-Fi back on when toggled
off :-)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Whether the device is used as a hotspot is currently only
used internally for the name and icon-name properties.
But hotspots need special treatment in the toggle as well,
so turn the method into a GObject property.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
As the sections are about to turn into quick toggles, they need
to be able to perform an action on click.
Add an activate() method for that purpose, which either disconnects
all active items, or connects the primary item.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
DeviceItems are sections, and therefore not actually activatable.
However when we port to quick settings, those toggles will need
to do *something*.
For that reason, provide an activate() implementation that
1. deactivates the device if currently connected
2. delegates the action to the most-recently used item,
the first visible item or the auto-connect item (in that
order)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
The primary indicator is a bit tricker than the VPN one: The source
of the binding can change depending on the connection, and we still
want to show it when there is a network connection we don't know
about (either because we don't handle the device type, or the
device isn't managed by NetworkManager).
Bindings still make the whole thing a lot nicer though.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
This is the last property that will be needed by the future
betwork quick toggles.
It maps to the same item as :icon-name, except when more than one
item is active. In that case, we overrule the binding and return
a generic name and count (like "VPN (2)").
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Again no big surprise, a property that will soon correspond to the
quick toggle's icon.
It is more involved than the :checked property though, which is just
a simple boolean.
To keep it as simple as possible, we set up a binding group and use
that to bind the :icon-name property.
As state changes, we then update the group's source with the item
we deem to best represent the section as a whole at the given
moment.
That is (in that order):
- the first active item
- the most recently used item
- the top-most visible item
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
Instead of subclassing PopupMenuSection, it is now a plain GObject
that has a `menu` JS property.
That brings it a tad bit closer to QuickMenuToggle, which is another
GObject with a `menu` property.
We are on the final stretch now. Over the next couple of commits,
we'll add some (fake) properties so we can hook everything up,
and then it's finally time for the big switch.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2408>
We treat wake up requests the same as user activity, as in general
the two behave the same: Turn on the screen and reset the idle watch
until the system becomes idle again.
The big exception is when the screen isn't locked yet. In that case
user activity should interrupt the automatic screen lock, but a
request to wake-up the screen (like showing a notification) should
not.
Address this by ignoring wake-up requests while the screen shield
isn't active, as we can expect the screen to still be turned on at
that point.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5719
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2413>
Now that console.debug() makes it easy to log message with DEBUG
priority, we can be a lot more generous with logging without
spamming logs (by default).
Those turned out useful in figuring out the issue in the next
commit, so let's keep them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2413>
This is a region where, if hovered while dragging, immediately goes
to the previous or next page. This behavior was lost during the
transition to the new app grid layout manager.
Bring back the drag overshoot region.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
As per feedback, remove the visible styling of the page indicators.
They're still used to layout and detect drag hovering, so the actors
are still in place, but they're completely transparent now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
This brings back the ability to drop an icon beyong the last page.
Because the acceptDrop() method does not have access to the target
drop actor, to avoid an extra pick or manually calculating it from
allocations, simply store it during DragMonitor.dragDrop(), and
use the target actor in acceptDrop().
This commit also removes the last usage of SidePages, so drop the
enum too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
This simplified the _handleDragOvershoot() callback quite a lot.
Instead of transforming point positions and checking them against
grid coordinates, merely check if the drop target is one of the
page indicators.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
Make the next and previous page arrows be StButtons, with their
'icon-name' property matching the current StIcon icon name, and
use the 'clicked' signal to switch pages.
Remove the 'button-press' callback the scroll view, since the
buttons take over this functionality.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
This was lost 2 commits ago, but now we reimplement this in a
different way. There is some jesting with allocations, since
we cannot use transformed positions while changing translation
of the icons. This new implementation works regardless of the
screen resolution.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
This is a major departure to how page previews used to work. Add
a new layout manager that handles showing and hiding page previews
and navigation arrows. Move most of the code handling page previews
to this new layout manager.
The layout manager allocates at most 20% of the screen width for
the previews, and at least the width of the arrow.
The next and previous page peeking effect is temporarily lost with
this commit, but will be reintroduced in later commits.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
AppDisplay will require an extra padding applied on top of CSS
page padding. This is specific to AppDisplay and FolderView.
Add a new AppGrid class which subclasses IconGrid and adds this
extra padding - here called 'indicators-padding'.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
The API surface of IconGrid was originally meant to be only
setGridModes(), however findBestModeForSize() ended up being
called by AppDisplay code. Now that FolderGrid sets the modes
correctly, we don't need to skip calling findBestModeForSize()
anymore.
Always call findBestModeForSize() during IconGrid's allocation.
Add an underscore to findBestModeForSize() since it's now back
to be a private method of IconGrid.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
Back in the day, adaptToSize() contained mad maths to figure out
icon sizes. Over time, its scope was reduced, to the point where
we are today where it mostly just redoes some quick maths to
predict the grid size based on the CSS box model.
Remove adaptToSize() from BaseAppView and child classes. It still
is an internal detail of the IconGrid class, but it's not exposed
as a "public" method anymore.
This removal is not perfect, as it doesn't move or compensate for
any of page indicators and arrows code. This will be done in follow
up commits introducing a new layout manager for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
Another step in dismantling AppDisplay before reintroducing some
of the elements there. Instead of adding a certain amount of
padding, capped at 200px, always give the grid all available size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
The stack widget once was a ShellStack and had a prominent role
in layouting AppDisplay, but after a series of reworks it's now
effectively unused, and can be safely removed.
Remove the '_stack' widget from AppDisplay.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
We'll have to dismantle parts of AppDisplay and BaseAppView in
order to introduce navigation arrows in a way that won't drive
people insane.
Start this dismantling by removing the fade effect. It looks odd
for now, since we still set padding to the app grid, but that
will change soon too.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2335>
Space will be less of a concern when each sections becomes its own
menu, but it's still not infinite. To address this, enable MRU
tracking and limit the list to the eight most recently used items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Devices do not have an associated timestamp, but as we can now
track the MRU order of their connections, it makes sense to consider
the time of the most recent succesful connection the timestamp
of the device item.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We always display items sorted by name, but there are cases where a
second order by recency is interesting. Add an option to ItemSorter
to keep such a list and allow accessing it with another generator
function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Connections have a timestamp property, which records the last time
it was succesfully activated. This is useful information to us, as
more recently used connections are likely more relevant than ones
that haven't been used for a long time (or not at all).
To make use of it in the future, expose that timestamp as a property.
Only connections support it, but we will soon provide a reasonable
value for devices as well, so add the property to the base class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Eventually each section will turn into its own menu, which should
include a single settings item.
This also removes the odd duplication of items, now that we avoid
using submenus where possible.
In general this is straight-forward, except for modems: Some
models are now supported by a dedicated wwan panel, while others
still use the generic network one.
Address this by adding items for either panel, but only show one
at a time. The new panel is used if *any* modem is supported,
only when all modems require it, the legacy panel is used.
Hopefully that shouldn't be an issue for many users, as using many
different modems with different capabilities should be fairly rare
(except for Aleksander Morgado, but I think he can handle it)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We currently stopped using submenus altogether, but that only works
- if there is a single connection that represents
the device as a whole
- if there is just one device, so it is unambiguous
what device items belong to
To implement that behavior, add a 'single-device-mode' property that
NMDeviceSection can set on its items, and have items update their
'use-submenu' property based on that.
For wireless devices it's a straight mapping, as its items represent
wireless networks that can appear and disappear by just walking around
(multiple wifi adapters also sounds rather fringey).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Now that device sections manage a list of items, and the VPN section
manages a list of items, it's time to split out a shared base.
The class will get more involved over time, and eventually become
the base of all network quick items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We got the indicator out of the business of tracking connections,
now it's time to do the same for devices.
Let sections track device additions and removals, and create device
items for them as it sees fit.
It also allows the sections to handle the ::activation-failed signal
by themselves, instead of passing it on from device items.
With this, the indicator is now solely responsible for global state:
Manage the top bar indicators, notify on connection failures, and run
the portal helper when NetworkManager detects a captive portal.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
As mentioned when doing the same for VPN connections, it is currently
the indicator itself that keeps track of added and removed connections.
It then has to figure out the correct section, and iterate through all
its device items so each item can check whether the connection
corresponds to its device.
Stop that mess, and let each device item keep its connections updated
by itself. That is actually way easier, as NM.Device already exposes
available connections through a property, so we can get rid of all
the checkConnection() shenanigans.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
We currently wait until we got a connection to NetworkManager.
That's possible because the old PanelMenu indicator API takes
a menu, so it is possible to add or remove items dynamically
later.
That won't be the case with quick settings, where `quickSettingsItems`
is a plain array that is only read once when adding the indicator.
Prepare for that by moving section initialization into the constructor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Now that wi-fi devices will be handled by a separate menu toggle
instead of as part of a combined system menu, there is no longer
a need of delegating network selection to a separate dialog.
To keep the menu from growing too much, the (sorted) list of
displayed networks is kept at a limit of eight. There is always
Settings for a complete list…
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
In terms of UI, this means that in the common case where we have
a single (or no) connection, the device can be represented as a
single menu item rather than a submenu.
But more importantly, all our menu items inherit from the same
GObject class now, so we can use bindings where appropriate.
This will later extend to quick toggles as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
The class implements a menu item that contains a section which
can be collapsed into a submenu.
It is very common for network devices to only have one associated
connection, so hiding away a single item in a submenu is fairly
inconvenient.
This class will address this, by only using a submenu when it is
actually needed.
Although the main issue it addresses is that menus (including
sections) aren't GObjects. This gives us a GObject that can
be added to a menu, and that can itself contain other menu
items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
The class only provides the GObject properties that are currently
defined by NMConnectionItem, plus a way to set the active connection
that should be used for the item's :is-active state.
Its sole purpose is to provide a shared base for both device- and
connection items, and to have that base be a GObject so we can
start linking properties via bindings rather than manual fiddling.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Let's keep things simple and use the same appearance regardless
of the number of configured VPNs. Also unlike for device items,
every connection item in the VPN section is a toplevel item, so
there isn't a real need for different presentations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
The NMConnectionSection class is used - surprise - to manage a
list of related connections. And while the presentation of VPN
items is slightly different from connections associated with
devices (switches vs. ornaments), it makes perfect sense for
the VPN section to share the nitty-gritty with the base class.
But…
Right now it is perfectly fine for NMConnectionSection to be
used both as a child element in a device section, and as toplevel
item of the VPN section. Any nesting of sections is entirely
transparent to the user, and all connection sections appear as
submenu items in the toplevel menu.
That won't work for quick settings.
There's no PopoverMenuSection that allows invisible grouping, so
adding items dynamically would either need to happen at the end,
or require some tricky cross-component code to impose a particular
order.
And last but not least, quick toggles are very much unsuited for
a potentially large number of items. The whole point is to provide
quick direct access to system features, not to compete with menus
over the number of items they can hold.
That is, we need to get from the current state where each device
appears as a toplevel item, to a state where we have one quick
toggle for each device type plus one for VPN.
The decoupled VPN section still behaves largely as it did as a
subclass, with the notable difference that it no longer uses
a submenu item, so all VPN connections now appear at the toplevel.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Right now the indicator itself tracks all devices and connections,
creates and destroys the corresponding menu items, matches them
to a section and updates the connection/device arrays that are
attached to the section.
Sounds messy?
It is slightly less effective to connect multiple handlers to the
same NMClient, but let's assume that devices and connections aren't
added/removed at 60 frames/s, and we can add some readabilty by
moving the code into different classes that only have to care about
the bits that are relevant to them.
The VPN section is a good starting point, because its handling is
already quite different from device sections.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
At its core, it's the sort order tracking from NMConnectionItem
with a bit of sugar on top to provide access to the ordered items
and the ability to provide a custom sort function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
You could argue that the item name is closer to what is displayed
to the user, but it doesn't really matter: Connection items will
always use the connection ID when there is more than one, which
is the only case where sorting matters.
However sorting by items will allow us to generalize the code, and
use it for items that do not represent a connection.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
When not in radio-mode - that is, when the connection is the only
connection for its device - we want the item to represent the
device as a whole.
Achieve this with a small ConnectionItem subclass that adds a
:device-name property for that purpose.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
When not in radio-mode - that is, in the single-connection
case - the item currently uses a plain 'Connect' label.
That is OK while the item is inside a submenu that describes
the device, but we will soon stop using a submenu when a single
item can describe the device as a whole.
Prepare for that by adding an icon that is shown when in non-radio
mode, and include the device name in the label in that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2407>
Newer versions of IBus (> 1.5.26) have the IBUS_CAP_OSK capability
which can be used to hint the active IM about an OSK driving input as
opposed to a physical keyboard. This may be used by IMs to tweak their
behavior to suit OSKs better.
Add the GNOME Shell side handling for this capability, and toggle it
on whenever the OSK is visible.
Since this is a far too new enum value and we don't want such new
IBus dependency, this change plays fast and loose with JS guarantees,
since a logical OR with an undefined value results in the other operand
unmodified it will work for older versions where the capability does not
exist and thus we want nothing extra enabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2415>
We are calling _loginScreenSessionActivated() even in cases where this is
not required. For example, there are cases where the Active property is
already `true` and properties like `IdleHint`, `IdleSinceHint` and
`IdleSinceHintMonotonic` change. In this cases _loginScreenSessionActivated()
is called and will reset the authPrompt when not necessary.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2411>
We do want to update the best AP on strength change, in case we
can switch to a better one.
But even if we can't and the AP is unchanged, the icon should
be updated to reflect the change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2414>
Only when part of it is actually visible.
Because the central rectangle is generally the largest part, this
eliminates most of the shadow's render time. For example, animating
`.workspace-background` by tapping Super, the shell's overall render
time is reduced about 15%.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1915>
There's no visible change here since we're just moving from the
default transparent black to transparent other. But the latter can
be used as a special value to indicate to the rendering code when a
background is expected to be always occluded.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1915>
Right now DeviceCategory is a small section wrapper that shows
a summary instead of its content if it contains too many items.
It will eventually eventually turn into the base class for
network device quick toggles. Who would have thought that
when it was added for the "there's a computer with 32 ethernet
cards" fringe case?!
For now, give it a more appropriate name and use device types
instead of our made-up categories, now that the two map neatly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
It's odd to swap out a switch with a status label, and the
information isn't that helpful to begin with: It's either
transient (connecting, deactivating, ...), or too little to
be meaningful (unknown, failed, ...).
We're also perfectly happy to not show it in "label mode"
(i.e. when there's just one VPN).
Just get rid of it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Stop providing detailed state descriptions, instead use a name
that best represents the device at the moment (like a wifi SSID,
the carrier name, or the device name as determined by network manager).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
The _devices property is another case of overloading the
"device" term.
Fun fact:
this._devices[device._delegate.category].devices
uses three different meanings of "device" (section, NM.Device, item).
The devices array in sections won't be around for much longer,
but the property that tracks the sections is worth renaming.
While at it, use a map instead of a plain object, which has a
guaranteed order when iterating (which will come in handy later).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Different access points can belong to the same wireless network. As
NetworkManager doesn't handle this for us, we need to track networks
ourselves, and we currently do this using ad-hoc object literals and
monkey-patching.
Clean this up by factoring out a proper WirelessNetwork class, and
associate them to items with a map.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Interpreting the different flags is better left to the domain
experts at NetworkManager. It is also much more likely that
NM's own functions will handle newly added flags than our own
code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
There is a straight mapping between running/enabled and visibility,
so bind them instead of using a signal handler.
_syncConnectivity() is called both from _syncMainConnection() and
on connectivity changes, which should cover any running/enabled
changes.
That just leaves updating the icon on state changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
We would want the signals to be disconnected if we ever happened to
destroy the indicator. Even if we don't, connectObject() is simply
nicer when connecting half a dozen handlers at once.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
There is only one case where we show a notification: When activating
a connection failed.
There is therefore no reason for a generic wrapper around the
notification API. Likewise, tracking the source is a bit pointless,
given that the notification is transient. In fact, as we destroy
an existing notification *before* checking for the source, any
previous source will be gone by that point.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
The function is a handler for the `notify::state` handler, so
the state and reason parameters used in the checks are always
undefined.
In addition, `DEACTIVATED` is not (just) a failure state. We
clearly don't want to complain about a failed connection when
the change happened on request of the user.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
We never used it, so after more than ten years, it seems safe to
assume that we never will.
Plus different items pass different types, which makes it pretty
much impossible to use, even if we wanted to (which apparently
we don't 🤷️)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
When deciding on whether to show the 'no-route' icon, we check
for the client's connectivity *and* whether the devices's active
connection is used as primary connection.
This is currently masked by the indicator updating the icon on
connection changes anyway, but items should still notify the
change themselves.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
The wireless device item tracks the active access point in order
to update its icon on signal strength changes.
However we currently don't synchronize the initial state, so we
miss strength changes until the first access-point change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
Otherwise any unrelated errors in that function are hidden,
because exceptions in async functions are turned into promise
rejections (and JS cannot know that we won't handle it at a later
point).
It wouldn't happen to me of course 😉
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
I wasn't genuiously going to touch those lines, but I ran into
a limitation of the run-eslint script:
It currently bases changed lines on a diff between HEAD and main
instead of the commit-by-commit log.
The two can vary quite a bit when shuffling code around, and those
are the lines the tool kept complaining about.
I'll look into improving the script, but for now it's quicker to
just shut it up by fixing up the complaints.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2406>
There isn't always a serviceName when we set a message. Furthermore we
are passing the serviceName only to decide if we want to wiggle or not.
Pass the wiggle parameters instead. If they are missing, we don't want
to wiggle.
This fixes the following error:
JS ERROR: Exception in callback for signal: login-format-changed: Error: Wrong type number; string expected
setMessage@resource:///org/gnome/shell/gdm/authPrompt.js:542:13
_showRealmLoginHint@resource:///org/gnome/shell/gdm/loginDialog.js:931:26
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:114:47
_updateLoginFormat@resource:///org/gnome/shell/gdm/realmd.js:85:18
_reloadRealm@resource:///org/gnome/shell/gdm/realmd.js:57:14
_onRealmLoaded@resource:///org/gnome/shell/gdm/realmd.js:64:14
_makeProxyWrapper/</<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:245:34
Fallout from 526f0711f1.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5547
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2404>
Now that the old system menu has been ported over, we can move
the power toggle to its intended place. The main difference to
the stand-alone toggle is that the button now uses its natural
size rather than the fixed size of regular quick items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
This port is a bit messier than the previous ones, because the
existing menu section translates less directly to the new UI,
which uses a row of individual toggles for settings, lock and
shutdown.
In order to not complicate the grid layout further by supporting
rows with a different number of columns than the overall grid and
children at their natural size, create a custom, non-reactive
SystemItem item that spans an entire row, and contains the individual
toggles.
This works quite well, even with the shutdown item that uses a menu
for the various actions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
With menu support in place, this is now a straight-forward port:
Just add the existing profiles section to a QuickToggleMenu instead
of a submenu item.
The toggle itself now switches between 'balanced' and the last used
non-default profile.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
Now that the QuickSettingsMenu supports child menus, it is time
to add menu support to quick toggles.
Do that by introducing a QuickSettingsItem parent class with a
construct-only :has-menu property, as that will allow including
menus in items that aren't following the standard icon+label
pattern of QuickToggle (yes, we'll have some of those).
A common parent class also allows us to control the type of
menu that is created. That's important, as we need another
custom menu type to
- constrain the menu's y position to place it underneath
the source actor
- use open/close animations taylored for this use case
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
This is where it gets hairy.
Some quick settings items will have an associated menu. When
opened, the main menu should grow to make room for the child
menu, as it would do if it contained the child.
At the same time, the child menu will attach to its parent, and
block all input there while it is open.
Menu-modal menus so to speak.
Implement this as follows:
- change the QuickSettingsMenu actor to a stack that holds
- the boxpointer (a.k.a. the actual menu)
- an overlay actor to hold child menus
- use constraints to bind the overlay's position and width
to the boxpointer; the y position is offset to align the
overlay with the grid inside the actual menu
- add a placeholder actor to the main grid, whose height is
bound to the overlay height; using a "clone" instead of
the actual overlay means that layout changes are not triggered
from outside the grid hierarchy, which would be prone to
allocation warnings
- update the layout manager to not allocate the placeholder as
a regular grid child, but instead include its height in the
space underneath the row with an open menu
- apply a dim effect to the boxpointer when a child menu is
open, to indicate that input is blocked
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2393>
WorkspaceBackground's allocate is a hot function called every frame
during overview animations. Port it to C.
While we're at it, cache the work area and the monitor geometry, which
do not need to be re-fetched on every allocation.
This reduces the average WorkspaceBackground allocation time from
0.134 ms to 0.017 ms. With four workspaces, scrolling the overview sees
an average WorkspacesView allocation time improvement from
1.104 ms to 0.678 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2394>
The aggregate menu with its submenus isn't well-suited for simple
on-off actions, so we didn't expose the global color-scheme support
that was introduced last cycle.
Quick settings on the other hand are a natural fit for actions like
this, so add a corresponding toggle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
The power indicator should not be a regular quick toggle, but
instead be part of a "system area" row at the top of the menu.
But as in the end it is still a simple button, we can do the
port to quick settings now, and move it later when the system
row is implemented.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
For now, this is another simple toggle. The icon, state and
visibility reflect what the old menu did, and the top bar
icon is still only shown when devices are currently connected.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
Another simple toggle. Unlike the old menu, it is always shown
if airplane mode is supported, not just while airplane mode is
active.
We still only show the top bar icon while airplane mode is on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
Night-light is now a simple, always visible toggle that directly
controls the underlying setting. No change to the top bar icon,
which is still only shown while night-light is active (read: at night).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
Like the aggregate menu currently, the quick settings menu will
eventually contain some items that should dismiss the menu. And
as those items may appear in child menus or otherwise be nested,
a public method on a global object is more convenient than handing
the main menu down the hierarchy.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
The new indicator will eventually expose all the system status
items that are currently provided by the aggregate menu, but in
a more accessible form than the current submenu-heavy menu.
Right now this just adds the new empty indicator to the top bar,
alongside the existing aggregate menu.
We can then move items over one-by-one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
The quick settings menu is a popover that arranges items in a
reflowing, homogeneous grid. Grid children may span multiple
columns, but not rows.
For now the QuickSettingsMenu that contains the grid is just a
convenience wrapper around the layout manager that does the heavy
lifting. The two will become more intertwined when we add support
for menu toggles though, so the custom menu type is unfortunately
needed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2392>
Multiple booleans - both in arguments and return values - are almost
always problematic API, because people have to memorize (or more likely
look up) the meaning of each position.
Instead, return a JS object so each value has a name attached to it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2370>
After porting the more complex cases - in particular those that
affect a module's API - we are left with straight-forward D-Bus
method calls that can be moved to promise-based wrappers in one
go.
For consistency, this also switches from Remote to Async where
the call result is ignored.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
The LoginManager abstraction is still mostly callback-based, not
least because the methods are thin wrappers around logind D-Bus
calls.
However as gjs' dbus wrapper now generates promised-based wrappers
as well, we can implement a proper async API just as naturally.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
Thanks to recent gjs changes - namely the ability to promisify
interface prototypes and promise-based D-Bus wrappers - we can
modernize the ContentTypeDiscoverer API to use an async function
instead of a callback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
Our search provider API has to be asynchronous to support remote
providers. It doesn't have to be based on callbacks though, now
that async functions provide a nicer alternative.
That is particularly true after gjs's D-Bus wrapper started to
generate promise-based method variants.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
Provider loading has been synchronous since 2013, so we can
just as well return the results directly instead of passing
them to a callback.
Even if we returned to asynchronous loading in the future,
we wouldn't want to use a callback, but make the function
itself async.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
There are a couple of places left where we still use the old
indentation style, update them before making code changes.
After that, there are only a couple of non-type-safe comparisons
left of legacy style, so change those as well while we're at it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2344>
The latest mockups move the screen sharing indicator into a
separate control, similar to the existing indicator for built-in
screen recordings.
As this removes the submenu and only keeps the top bar icon (for
external screen recordings), this will smooth the transition to
quick settings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
Location services aren't expected to change frequently: They are
either disabled globally, or permissions are granted on a per-app
basis.
This is less of a concern while the setting is exposed in a small
submenu, but as we moving to quick settings, it does not deserve
the prominence of a quick toggle. Just the top bar icon and Settings'
privacy panel should be enough.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
Other than connecting stream when necessary, the volume menu
only forwards slider events to the indicator, and method calls
from the indicator to the appropriate slider.
Just cut our the middle-man and let the indicator handle the
slider items directly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
On error, we currently print a warning and bail out early. That
means we don't hide the slider, despite it being non-functional
without the proxy.
Fix this by making sure _sync() is called in any case. While at
it, use an appropriate log level for the warning message.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
Properties are null while a proxy has no owner. Javascript helpfully
coerces that into `Number(null)` (a.k.a. 0), so we end up with a
broken slider.
Explicitly check that the value is an integer before doing the
comparison to catch that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
The new class abstracts away the nitty-gritty of bluetooth- and
airplane-mode handling, and exposes just what the UI needs.
This will become more important with quick settings, where there's
a stronger separation between top bar icon and quick toggle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
There's no good reason for waiting for the proxy to be initialized
to connect signals. In fact, connecting the signal beforehand
ensures that the handler is in place when the proxy fetches the
properties, so we don't have to call the handler explicitly.
That in turn allows us to rely on the signal parameters to only process
changed properties.
To achieve that, construct the proxy manually, and then initialize
it asynchronously in a Promise.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
There's no good reason for waiting for the proxy to be initialized
to connect signals. In fact, connecting the signal beforehand
ensures that the handler is in place when the proxy fetches the
properties, so we don't have to call the handler explicitly.
That in turn will allow us in a follow-up to rely on the signal
parameters to only process changed properties.
To achieve that, construct the proxy manually, and then initialize
it asynchronously in a Promise.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2391>
By default, gitlab skips checking out of submodules. So far this
didn't matter to us, as meson will initialize submodules as part
of setup.
It no longer does for the dist command however, and as we run it
from a separate job where the submodule checkout isn't preserved,
the job breaks with recent meson versions.
Fix this by instructing gitlab to checkout the submodule for all
jobs that need it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2371>
Don't try to initialize and then enable an extension if it is not supported
in the current mode. Otherwise the extension will not be initialized, and the
initial ERROR state is not cleared. Once it is in ERROR state we can't enable
it anymore when we switch mode. Instead, leave the extension in INITIALIZED
state, so that it will be initialized when appropriate. This happens for
extensions that support the unlock-dialog mode but not the user mode.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2378>
Screenshots use `%Y-%m-%d %H-%M-%S` for the timestamp, which has the
advantage of allowing proper lexicographical sorting.
The screencast file name pattern, on the other hand, uses
locale-dependent expansions, which break sorting based on file name, and
introduces the chance of potentially invalid characters on different
file systems.
Fixes: #5115
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2300>
`ShouldShowAirplaneMode` only considers whether airplane mode
should be shown for the form factor, not whether there are
any actual kill switches available.
That's tracked in a separate property, `HasAirplaneMode`.
Take that into account for our `:show-airplane-mode` property,
so that it reflects when airplane mode should and *can* be shown.
Right now we only show airplane mode when it is enabled (and
therefore available), but this will change in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2385>
There's no good reason for waiting for the proxy to be initialized
to connect signals. In fact, connecting the signal beforehand
ensures that the handler is in place when the proxy fetches the
properties, so we don't have to call the handler explicitly.
That in turn will allow us in a follow-up to rely on the signal
parameters to only process changed properties.
To achieve that by constructing the proxy manually, and then
initialize it asynchronously in a Promise.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2385>
In case where there are multiple in- or output devices, pulseaudio
or pipewire can pick the "wrong" one by default.
Allow users to change devices without opening sound settings by
adding a submenu to the sliders when there is more than one device.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2380>
Since IBus does not provide this information right away, we
so far cannot do much about providing a truthful anchor position
for the preedit text. But with the Mutter API in place it will
be up to this object to do so in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2384>
When gjs overhauled its coding style, it opted for disallowing
spaces around braces in object literals: `{foo: 42}`.
We opted out of that particular rule in commit 09b8e8f, primarily
because it would have been a very intrusive change with the old
style of object literals:
```js
let oldStyle = { foo: 42,
bar: 23 };
```
Alas, all multi-line object literals have been transitioned to
the new style where braces go on separate lines, so they are no
longer subject to the rule one way or the other.
Nowadays the rule mostly affects destructuring, and there it
is a bit odd to apply different spacing rules to arrays and
objects:
```js
const [foo, bar] = someArray;
const { baz, quz } = someObject;
```
This is now the main divergence from the canonical gnome style,
and the only one where we directly contradict it.
It would be good to transition away from that, and as the rule
now only affect destructuring and single-line object literals,
we can do that on a case-by-case bases by moving the override
to the legacy configuration.
As desctructuring imports makes up a fair share of the affected
code, and those will change when moving to ES6 modules, this
seems like a good moment to start that transition.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2375>
This behavior dates back all the way to the original gnome-shell
release, and it did make sense at the time:
- we were first to make notifications persistent instead of
closing them after a timeout; apps were therefore used to
treat notifications as fire-and-forget instead of closing
them when no longer relevant
- neither web notifications not portals did exist yet, so the
D-Bus API was only used directly, instead of as a backend
for other APIs; as a result, focusing the app was more likely
than not to put the source of the event that the user was
notified about into view
Nowadays both persistent notifications and web notifications
are wide-spread, so the original reasons no longer apply.
This change helps web notifications in particular, as it reduces
the differences between XDG and portal-based implementations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2332>
libadwaita has a new About window, and GNOME apps are expected
to use it going forward instead of GtkAboutDialog.
Comments are meant to be detailed, and are no longer shown in the
main view. So we remove the old comments.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2373>
GNOME Shell will only update extensions if the org.gnome.Extensions
app is present. This commit adds alternative support for
com.mattjakeman.ExtensionManager to the extension updating mechanism.
It enables updates to occur when extension-manager is the sole installed
tool on the system. When both applications are installed,
org.gnome.Extensions is preferred at all times.
Fixes#5564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2358>
The iterator was pointing to NULL when going out of scope, leading to
autofree not clearing the list.
==300183== 32 bytes in 2 blocks are definitely lost in loss record 14,798 of 38,939
==300183== at 0x484586F: malloc (vg_replace_malloc.c:381)
==300183== by 0x4D7D980: g_malloc (gmem.c:127)
==300183== by 0x4D95AB3: g_slice_alloc (gslice.c:1074)
==300183== by 0x4D96D96: g_slist_prepend (gslist.c:282)
==300183== by 0x487854F: shell_app_get_windows (shell-app.c:794)
==300183== by 0x48791A1: shell_app_get_pids (shell-app.c:1201)
==300183== by 0x488B293: shell_window_tracker_get_app_from_pid (shell-window-tracker.c:702)
==300183== by 0x488B632: get_app_from_window_pid (shell-window-tracker.c:370)
==300183== by 0x488B632: get_app_for_window (shell-window-tracker.c:436)
==300183== by 0x488B632: track_window (shell-window-tracker.c:549)
==300183== by 0x4CDBB75: g_cclosure_marshal_VOID__OBJECTv (gmarshal.c:1910)
==300183== by 0x4CD8BE9: _g_closure_invoke_va (gclosure.c:893)
==300183== by 0x4CF2A28: g_signal_emit_valist (gsignal.c:3406)
==300183== by 0x4CF2C2C: g_signal_emit (gsignal.c:3553)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2367>
The logging function cannot be asynchronous, so move the override
into main.js where ExtensionUtils can be imported at the top level.
Importing ExtensionUtils in environment.js at the top level is not
possible because it would import Main prematurely.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2363>
ES modules do not allow exports to be overriden, in anticipation
of the ESM port add a `setCurrentExtension` utility which will
throw if used in the shell. This is tested using a conditional
import of Main.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2363>
Even though GNOME Shell is not explicitly using structured logging via
G_LOG_USE_STRUCTURED, GLib uses it as default since 2016 [1], and so
we're de facto using it.
As per this, if backtrace on warnings is enabled, it is ignored since the
log handler isn't used anymore, and no dump is printed.
Thus, replace the default log handlers with writer functions instead, honoring
backtrace-warnings debug string.
[1] https://gitlab.gnome.org/GNOME/glib/-/commit/fce7cfaf40b6e1e50c9140aa0397f5
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/697>
We considered any ConnectFlag value major than SWAPPED as invalid, while
it's technically not fully true as we need to ensure that the passed
value is respecting the whole flags mask.
In fact, per se SWAPPED|AFTER (> SWAPPED) is a valid value (even if we
don't support the AFTER value).
But this makes the check more future-proof.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
While untracking an object we used to compute it's proto for each signal
we were disconnecting from, while this is not needed when we're just
iterating over all the same owner signals, so let's add few more
functions to compute an object prototype, and repeat the disconnections
in the simplest way we can.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
We used to create a temporary array of signal tracker keys and then to
iterate through them in order to untrack the objects, but the Map's can
be iterated directly so let's just use their native forEach.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2366>
Introduce a new class, EventEmitter, which implements signal
handling for pure JavaScript classes. EventEmitter still
utilizes GJS' addSignalMethods internally.
EventEmitter allows static typechecking to understand the
structure of event-emitting JS classes and makes creating
child classes simpler.
The name 'EventEmitter' mirrors a common name for this pattern
in Node and in JS libraries.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2043>
For non-MR pipelines, we check for a matching branch or tag name
in mutter. As we use the same naming policy for stable branches
and branch at about the same time, this works generally fine for
branches.
However for tags, it is less unlikely that there is no matching
tag in mutter, in particularly late in a stable cycle when most
changes are translation updates (which are much rare in mutter
than gnome-shell).
Before falling back to main (which is doomed to fail in that case),
try to guess the correct stable branch based on the tag name.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2293>
If we only raise screenshot UI to top, ibusCandidatePopup can still
cover screenshot UI because each time ibusCandidatePopup updates it's
visibility it will raise it to top and this also happens if we open
screenshot UI via keybinding. This commit fixes it by only raising it
above keyboardBox, because keyboardBox is above all entries in modal
dialogs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2331>
ibusCandidatePopup actually works as a top chrome because it always
raises itself above top_window_group when updating visibility, so just
initing it as a top chrome instead of initing it below top_window_group.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2331>
The overviewGroup's size is currently determined by the coverPane
actor. That actor is only shown during transitions, so we rely on
ClutterFixedLayout including hidden children in its size request.
That odd behavior is about to change, so we need to make sure the
overview still requests the correct size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2351>
When a window with a modal dialog gets minimized and at the same time
the dialog is closed, the WindowDimmer undim animation starts and gets
cancelled when the minimize animation is done, because that unmaps the
window actor.
In this case we want ensure the dimming effect still goes into a
proper state instead of being stuck mid-animation, so listen to
onStopped instead of onComplete for syncing state of the window dimmer.
While at it, clean things up a little and move the check for the
attach-modal-dialogs pref inside the _syncEnabled() function.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5581
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2349>
Right now, we don't pay much attention to visibility hints from IBus
about the candidates list for the OSK suggestions bar. Since some
IMs rely on this visibility being honored, do that.
To fix this, the visibility hints for the lookup table are now
propagated to the keyboard, so the Suggestions actor hides its
internal candidate buttons. Since the Suggestions actor gets its
minimum height from CSS, this does not result in OSK size jumps.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5601
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2347>
There is no hint about the currently selected language, but this exists
in the mockups. Add a dot ornament on the language that is currently
selected at the time of showing the OSK languages popup.
Since this popup is created from scratch every time it is shown, and
the popup is torn down with the OSK during replacement. This also
works for further times the languages popup is shown.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5598
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2346>
Applications launched using D-Bus activation will have a returned PID of
0, which systemd interprets as moving the requesting process to a new
scope, causing GNOME Shell to be moved to another scope. Fix this by not
creating a systemd scope when PID is 0.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2305>
When calculating the on screen coordinates of events from the window
relative coordinates, using the frame rect will include the decorations
added by the WM for SSD windows. This was causing the calculated
coordinates to be slightly off. Fix this by using the client rect for
SSD windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2319>
Absolute screen coordinates are impossible for Wayland clients to
provide, because the clients don't know where the window is positioned.
Some clients, such as the ones using GTK 3 were providing window
relative coordinates even when screen coordinates were requested,
while others, such as GTK 4 clients, were just returning an error for
caret events or also window-relative coordinates for focus events.
So for this to work on Wayland we have to request window-relative
coordinates and translate them to the current focus window.
To ensure the correct coordinates, we have to only consider events
coming from the current focus window. All other events are filtered out
now. As a side effect this also fixes the magnifier always jumping
to a terminal cursor whenever there was some output, even if the window
was not focused.
This also needs some special handling for events coming from the shell
itself, which should not be translated to the focus window either. As
another side effect this fixes another bug that was caused by these
events already including scaling and getting scaled again.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5509
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2301>
If we don't set the height property to -1 before requesting the
preferred height, get_preferred_height() will just return us the fixed
height that has been set before. We don't want this behavior here, so
set the height to -1 before calling get_preferred_height().
This fixes a resizing issue where the keyboard is sized incorrectly
after switching the monitor into portrait mode and back.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2306>
Both bluetooth and screencast support are based on build checks
right now. However in both cases, the dependency is only consumed
at runtime via the typelib, so let's actually check for that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2297>
We currently decide at build time whether to include screencast
support, based on whether the required gst/pipewire library headers
are installed.
That check is imprecise, because having the library headers available
at build time doesn't necessarily mean that the libraries are there
at runtime, or that the corresponding typelibs are installed.
It makes more sense to check the requirements at runtime, so prepare
for that by installing the screencast service unconditionally, but
bail out early if the dependencies aren't met.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2297>
The problem is that " 9:59 AM" (notice the space at the beginning) and
"12:59 AM" strings, when centred, look misaligned —
strings padded with a space look off to the right by nearly
half a character. This happens because the font feature "tnum",
used to make numbers monospace, doesn't work on spaces.
The commit overcomes this by aligning time labels to the end.
However, this won't work for locales with AM/PM strings of different
lengths, so they are aligned to the start instead to minimise offset.
It's too complex to know whether the used locale has different
AM/PM string lengths. Instead, every time the time changes, it
determines whether all the time labels have the same amount of characters.
Fixes#5438
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2294>
We update the visibility on state or stream changes, but those
changes may never happen if pipewire-pulse/pulseaudio isn't
available (for example when running as root).
Hiding the sliders is preferable in that case to showing non-working
controls.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2295>
GTK4 added a convenience property for icon-only buttons. While that
use case is not quite as common in the shell as in GTK apps, it still
seems common enough to mirror the GTK API.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2254>
When selecting the largest possible icon size for restricted vertical or
horizontal space the options for low resolution icons were rather coarse
grained. This could often result in seemingly too small icons being
chosen in the app grid on systems with low vertical resolution, because
the next larger size would exceed the limit by a few pixels.
This adds two more commonly used sizes for application icons to have
some more options with restricted space.
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2173
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2289>
Commit 7419674b changed some grabs from requiring both mouse and
keyboard grabs to be considered successful to only requiring either of
them.
Due to this it was possible for example to open the overview or the
screenshot UI with a client (such as Chrome when opening a menu) holding
the mouse grab. This then made it impossible to interact with the UI
using the mouse (or keyboard) and if attempted could result in an
unresponsive UI.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5414
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2287>
Commit ca4f6e0123 was supposed to show the
"cellular-disabled" icon when wwan is disabled. For wwan, just like for
bluetooth wwan networks, we probably want this to include the "not
connected" state, because disconnecting from cellular service de-facto
means disabling it.
So switch the check to show the "cellular-disabled" icon to also use the
icon whether there's no active connection, not only when the wwan device
is turned off.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5401
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2283>
The layout manager of the calendar/notifications popup is using the
calendar width to determine the width of the whole right area of the
calendar popup. When enabling large text, this means the cards used for
world clocks, weather etc. get larger, while the calender doesn't get
larger, leading to the cards getting clipped.
Make sure the calendar grows in size just as the cards do when large
text is enabled and define its size in em's instead of pixels.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5392
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2282>
The swipeTracker wants the distance between two pages passed to it in
confirmSwipe(). In case of the app grid, the correct distance is not the
size of the scrollView (which has the width of the whole screen), but
instead the allocation size of the iconGrid (which is the actual size
of a page in the grid).
So pass the allocation size of the iconGrid to the swipeTracker, this
makes sure the pages move perfectly in sync with the pointer when
dragging using the mouse or touchscreen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2275>
With commit c29e0cf6e6 the grabHelper
already started using a similar mechanism to funnel events to the osk
while a ClutterGrab is in effect. ModalDialog, the unlockDialog and
lookingGlass don't make use of the grabHelper though, they use
Main.pushModal() themselves, so those need to funnel the events to the
OSK themselves.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2263>
We currently complete the animation using an onComplete handler,
which only runs if the corresponding transition was stopped when
finished.
While it is unexpected that the transition is interrupted, it can
apparently happen under some circumstances (like VMs with qlx).
The consequences of that are pretty bad, mainly due to the cover
pane that prevents input during the animation not getting removed.
Address this by always completing the animation when the transition
is stopped, regardless of whether it completed or not.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5337
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2269>
If one of these libraries breaks its GIR API in future, then upgrading
packages unrelated to gnome-shell might pull in the newer version,
causing gnome-shell to crash when it gets a newer GIR API that is
incompatible with its expectations. For example, this seems to be
happening in Debian testing at the moment, when GNOME Shell 41.4
imports GWeather and can get version 4.0 instead of the version 3.0 that
it expected.
Adding explicit API versions at the time the newer version is released
is too late, because that will still let the newer version of the GIR API
break pre-existing GNOME Shell packages. Prevent similar crashes in
future by making the desired versions explicit.
This is done for all third-party libraries except GLib, similar to the
common practice in Python code; if GLib breaks API, then that will be
a disruptive change to the whole GLib/GObject ecosystem, regardless.
Gvc, Meta, Shell, Shew, St are not included because they're private
(only exist in a non-default search path entry).
Clutter and Cogl *are* included, because we need to import the fork of
them that comes with Meta, as opposed to their deprecated standalone
versions.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/1008926
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2261>
MetaWindow.move_to_monitor() can no longer be assumed to have updated
the monitor on return, as under wayland, if the move involves a size
change, the monitor state will only be updated after the new size has
been synced with the client.
If that happens, trying to change the workspace of the moved window
fails, as it is still considered on-all-workspaces until it leaves
the secondary monitor.
It's possible to work around this by waiting for the window to actually
enter the requested monitor. That's finicky enough to warrant a helper
funtion, so add one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/893
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2259>
We started tracking all windows to make sure the assumption that any
window can be match to an app holds. It is not expected however to
ever represent OR windows in the UI, so it seems better to exclude
them from get_windows() instead of expecting everyone to filter the
return value themselves.
(The returned list still includes "uninteresting" windows like attached
dialogs, which can be important for cases like the correct MRU order in
alt-tab)
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5233
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2252>
When neither the theme node itself nor any of its parents specifies
an explicit text direction, we default to aligning to the left.
That's a good default for LTR locales, but for RTL aligning to the
right is a better one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2247>
If the timezone offset calculation in the World Clocks contains non-zero
minutes, then a decimal Hours value is being displayed. Limit the Hours value
to integers by using Math.floor().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2255>
On some hardware combinations the display can be known, then unknown again. Meaining that
when the update monitors function is called it will have a value, then be called again
setting this.primaryMonitor to null. If the timing is just right gnome shell will
loadBackground, then by the time the animation is ready the monitor will be gone,
thus methods will be called on a null value. This adds more checks for a valid
primary monitor, and wont play the animation until the system is idle AND has a valid
priamry monitor.
Fixes: #5003
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2144>
T_() is a convenience shortcut for looking up a string from the
locale defined by LC_TIME, but it isn't recognized as a gettext
keyword. To do that, we also have to wrap the string in N_() or
NC_().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2246>
It existed to fade out/in `nautilus-desktop` for the overview, but it only
ever worked for X11 sessions (`Meta.WindowType.DESKTOP`) and
`nautilus-desktop` no longer exists anyway.
While I had suggested extending it in the past (!1395), that work was
never finished and since then the DING extension has implemented its
own visibility toggling. There seems little value in keeping the old
fade logic around in gnome-shell. Removing it actually fixes a bug with
DING (https://launchpad.net/bugs/1965072).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2244>
Creating these default folders still doesn't work. After some
investigation I found that's because the template we use for
the path when creating the `child` `Gio.Settings` instance
results in a double slash - it comes out as e.g.
/org/gnome/desktop/app-folders//folders/Utilities/ . dconf does
not gracefully handle this as many other things that handle
paths do, it considers it a programmer error. It results in
error messages like:
dconf_changeset_set: assertion 'dconf_is_path (path, NULL)' failed
which is slightly confusing. Anyway, we fix it by removing a
slash from the template.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2242>
Since the ClutterGrab rework, grabbing properly emits crossing events.
StButtons take a ClutterGrab as soon as they are pressed, so pressing
the close StButton of the WindowPreview takes a grab and causes a
LEAVE+key-focus-out event getting sent to the WindowPreview. This in
turn makes us hide our overlay (which the StButton is part of). We
automatically ungrab ClutterGrabs when hiding actors, so the StButtons
grab now gets released again, key-focus and hover state are updated
again and we emit an ENTER event to the WindowPreview. The preview now
tries show its overlay again and things explode because we re-enter the
mapping machinery.
For the LEAVE event we can break this cycle by detecting the GRAB_NOTIFY
crossing event of our own StButton and not reacting to that.
We should do the same for the key-focus-out event, but these don't pass
context information like a GRAB_NOTIFY flag yet, so just check the
current grab actor here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3165
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2231>
Commit ba23279f1f was aimed at fixing a
bug where the layout is frozen so early that we don't have an existing
one to re-use, because no allocation cycle happened yet. It tried to fix
that by forcing the creation of a layout when needsLayout === true,
this turned out to be a bit too much, as it also forced creating a new
layout when the layout was frozen after closing a window (which would
set needsLayout to true).
To fix this regression and still avoid reintroducing the bug the
previous commit fixed, tighten the check a bit and only force creating
the new layout when there's no allocation yet. This makes freezing the
layout after closing a window work again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2236>
The magnifier uses a PointerWatcher (which is based on a simple timeout
source) to update the zoom region based on the current mouse cursor
position 60 times a second. When updating the zoom region, it would also
hide mutters cursor using meta_cursor_tracker_set_pointer_visible().
Since a few months, mutter has decoupled the handling of input events
from the monitor refresh rate though, which means it's no longer
guaranteed that the cursor changes only 60 times a second (on higher
refresh rate monitors it actually never was). This means mutter might
show the cursor more often than 60 times a second, while we hide it only
60 times a second, leading to a flickering second cursor.
To fix this, implement the cursor-hiding by listening to
MetaCursorTrackers visibility-changed signal, and immediately hiding the
cursor again when it's shown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2234>
We want to use the current event time for activating the workspace, and
this time is only available when calling global.get_current_time() or
Clutter.get_current_event_time() from the context of an event handler.
So instead of trying to get that time when the animation has finished
from the onComplete() handler, get it before and store it as a variable
to use in the onComplete() handler later.
This fixes an error message when switching workspaces using the swipe
gesture where MetaWorkspace complains about the 0-timestamp we pass it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2233>
In testing on Fedora, gnome-shell crashes here:
JS ERROR: TypeError: DEFAULT_FOLDERS[folder] is undefined
This needs to be a "for of" loop, not a "for in" loop, because
`folders` is an array of the hash's keys, not the hash itself.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2238>
In a very un-StButton fashion, OSK keys are not interested in
altering the current focus state, as otherwise pressing those
will trigger a grab that will alter key focus, so the generated
key or IM state events will not be handled by the actor that
originally had the focus as long as the OSK key is pressed.
Despite being StButtons, OSK keys do already perform their own
press/release handling with internal state tracking, so it is
not a big stretch to simply consume the events, and update the
:active pseudo-class manually.
This makes OSK keys still look and behave as usual, but without
any grabbing shenanigans that might affect the focus state. This
makes all OSK keys work again.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4986
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2237>
In the case of bringing up the OSK while there is a grab (like, every
GNOME Shell entry), we used to special case event capturing so events
directed to the OSK would be let through.
When Clutter.Grab came around, events would be propagated only within
the actor hierarchy that holds the grab, which rendered this special
case just as useless as the OSK while a grab was hold. Since it wouldn't
be part of the grab hierarchy, clicking on the OSK would do nothing.
In order to let the OSK handle events, double down on the special case
and let it forward the event directly to the actor under the device,
instead of trying to let it through somehow. Since the actor under the
device are usually OSK buttons in this case, we don't need further
propagation to make it work, which makes the OSK functional again while
the shell holds a grab.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2237>
The screencast portal supports recording a single window,
and presents a list of open windows when that option is
selected. To allow updating that list when windows are
opened or closed, add a new "WindowsChanged" signal that
the portal can listen to.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2229>
The transition from the overview freezes the workspace layout at the
start of the animation, which means that the calculated window slots
remain the same while the workspace itslef grows. This causes the
windows to appear slightly shrunk in comparison to the workspace and
shifted to the top left. This is especially noticeable during the
beginning of the animation when there is more weight on the slots than
the original window position and if there are not that many open
windows.
Unfreezing the layout for this transition is not possible, because it
would cause issues with newly opened windows abruptly changing the
layout when the animation happens after starting a new app.
This change instead tries to scale the frozen layout to the current
workspace size. While this is not entirely correct, because this scales
the spacing between the slots as well, it is still more accurate than
the completely unscaled slots.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4616
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1980>
We currently assume that any '::destroy' signal on a GObject type
has the semantics of the ClutterActor/GtkWidget signal, and should
therefore result in all signals being disconnected.
But we already have a case where the assumption doesn't hold: ShellWM
uses '::destroy' for the closing animation of windows, and the ShellWM
object itself remains very valid after the emission.
So rather than making assumptions about '::destroy', check objects
against a list of destroyable types that are explicitly registered
as such.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2226>
On some touchpads/laptops, the swipe gesture to open the overview can be
performed so fast, that it starts and ends in between two frames. Now
when this happens, and the gesture ended with too little movement to
confidently say the user intended to open the overview, we'll close the
overview again.
While closing the overview, we freeze the layout of the Workspace in
order to avoid changes to windows messing with the animation. This means
that in the case described above, we freeze the layout even before the
first frame of the opening animation happens. No frames being drawn also
means no allocations happening, and since we create this._layout in
vfunc_allocate(), this means that on the first allocation cycle of the
overview we'll see this._layoutFrozen = true, but will also not have
a this._layout nor this._windowSlots.
This creates an annoying visual glitch where for a split second all
the windows disappear (overview is visible but no WindowPreviews get
allocated).
To fix this, force creating a layout on the first allocation cycle, even
if the layout is currently frozen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2203>
In the panel we listen for button presses on the panel in order to start
a drag op of the adjacent maximized window. With the recent changes
removing the source detail of events from Clutter, we now can no longer
access buttonEvent.source, but instead need to use
ClutterStage.get_event_actor().
Since that function expects us to pass a ClutterEvent and not a
ClutterButtonEvent, let's listen for the "button-press-event" signal
instead of connecting to vfunc_button_press_event(). This will give us a
ClutterEvent we can work with.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2225>
While we don't want to position overview elements according to
the work area, it does apply in the session when the overview
is hidden. That is, we should take it into account for the HIDDEN
state, so that transitions from and to the overview are correct.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2223>
The work area is really the space that is available to application
windows. Applying it to the overview is therefore questionable,
in particular given that
- X11 clients that affect struts aren't shown
- elements added by extensions have other means
to affect the overview layout
Not applying the work area to the overview also makes ignoring
actors' visibility for struts acceptable again: Assuming that
strut actors are only hidden when the monitor is in fullscreen,
freezing the work area instead of updating it for windows that
are fully obscured by a fullscreen windows makes perfect sense.
This reverts commits 81a1e294f8 and 2b074882f4.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2223>
The changes violated too many assumptions on the mutter
side. And even if those were addressed, changing the
work area when a window enters/leaves fullscreen isn't
great, because it will force an expensive relayout on
all other windows.
This reverts commit cd1102ff30.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2223>
As first mentioned in commit 672171093, the CSS spec defines shadow
colors independently from the colors casting the shadow. It's not
a physical light simulation so a shadow is allowed to be a different
color from texture casting it.
This means we only care about the shape of the source where alpha
values of zero are adjacent to alpha values of non-zero. And all such
non-zero pixels should be treated as fully opaque for the purpose of
shadow generation. While this would be wrong for a physical light
simulation it does allow us to cast shadows around semi-translucent
shapes and better support CSS.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4477
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1918>
There are cases where we want to connect to a number of signals
for the lifetime of an object, but also other signals for a
limited period (say: between show and hide).
It is currently not possible to use disconnectObject() for the
latter, because it will disconnect all signals.
To address this use case, add a small class that can be used as
a transient signal holder, while still benefiting from autocleanup
by proxying the real owner.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2221>
The 'destroy' signal currently doesn't work with connectObject(),
because the handler is only connected after the signal tracker's
own destroy handler, which disconnects all handlers.
Address this by using connect_after for the cleanup handler, so
that other destroy handlers run before it (unless they also use
ConnectFlags.AFTER, but well *shrug*).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2221>
In order to make very short screen capture sessions more visible, let
the indicator remain visible, but a bit greyed out, for some seconds.
This makes it more obvious something was just capturing the screen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2132>
Start using the new methods to simplify signal cleanup. For now,
focus on replacing existing cleanups; in most cases this means
signals connected in the constructor and disconnected on destroy,
but also other cases with a similarly defined lifetime (say: from
show to hide).
This doesn't change signal connections that only exist for a short
time (say: once), handlers that are connected on-demand (say: the
first time a particular method is called), or connections that
aren't tracked (read: disconnected) at all.
We will eventually replace the latter with connectObject() as
well - especially from actor subclasses - but the changeset is
already big enough as-is :-)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1953>
The module exports a `addObjectSignalMethods()` method that extends
the provided prototype with `connectObject()` and `disconnectObject()`
methods.
In its simplest form, `connectObject()` looks like the regular
`connect()` method, except for an additional parameter:
```js
this._button.connectObject('clicked',
() => this._onButtonClicked(), this);
```
The additional object can be used to disconnect all handlers on the
instance that were connected with that object, similar to
`g_signal_handlers_disconnect_by_data()` (which cannot be used
from introspection).
For objects that are subclasses of Clutter.Actor, that will happen
automatically when the actor is destroyed, similar to
`g_signal_connect_object()`.
Finally, `connectObject()` allows to conveniently connect multiple
signals at once, similar to `g_object_connect()`:
```js
this._toggleButton.connect(
'clicked', () => this._onClicked(),
'notify::checked', () => this._onChecked(), this);
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1953>
The default folders used to be created by gnome-software, as that was
where folder management used to be implemented. Since then, folder
management via drag and drop was implemented in the shell, and the
gnome-software code was removed.
The only bit that still involves gnome-software are the default folders
that are created on first run. Given that everything else has moved to
the shell, it makes sense to take over that part as well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4948
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2110>
It does not make sense that the target actor is both destinatary
and content of the events being sent, so this API call is going away.
Since the event can be sent entirely unmodified (more so, it will
become immutable/readonly in the future), avoid creating a copy
since it does not matter sending one or other struct.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2216>
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>
Mutter and gnome-shell are released in lock-step, but I forgot to
bump the requirement accordingly.
Likewise the gsettings-desktop-schemas dependency is outdated, there
are a couple of keys we depend on that were added this cycle.
And while building should still be possible with the old gjs version,
we do require a newer version at runtime, so reflect that as well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2183>
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>
ClutterEffects are responsible for queueing redraws when their
properties change (and StScrollViewFade is a good citizen already), also
Clutter itself should queue a redraw when adding/removing an effect.
Users of Clutter should never have to queue redraws themselves (unless
they're implementing a custom ClutterEffect or ClutterContent), so don't
queue a redraw here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2189>
The fade effect can also be added to the scroll view programatically
instead of using CSS via the st_scroll_view_update_fade_effect() API.
We make use of this API in the appDisplay, but since commit ba547ec1d
the fade margins get overridden to 0.0 from the ::style-changed handler.
Fix this by only setting the fade margins when CSS actually defines a
custom vfade/hfade offset.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5079
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2189>
- remove tiled preview corners; merge with misc.scss
- sync general label styles from libadwaita
- use variables in ibus css
- remove redundant spacing variable as its equal to padding
- use more global styles in screenshot css
- tidy up entry styles
- cleanup the networks dialog stylesheet
- make colours less dark
- cleanup the popover stylesheet
- cleanup the mixins for tiles and overview icons
- adjust the button style definitions on checked style
- add osd button definitions
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2172>
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>
Since now the resource consumption of the "style-changed" signal
handlers should be significantly lower, we can start emitting the signal
in all cases again as it was originally intended. This fixes some small
visual issues, like the battery percentage in the panel only being shown
on hover or updating the size of StIcons on scale-factor changes.
This effectively reverts f74c07b9ac
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1708
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2099>
Just like with the last commit, listen to some ClutterText property
changes to catch style changes that were trigerred by
_st_set_text_from_style() and invalidate the shadow spec on changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1744>
We update a few properties of ClutterText when the CSS changes via
_st_set_text_from_style() (which we call when receiving the
style-changed signal).
Right now we simply invalidate the text shadow every time we receive the
style-changed signal, but we're going to change that with the next
commits. To ensure the shadow still gets invalidated on CSS changed that
might affect the shadow, listen to a bunch of property changes that will
get notified when any property that affects the shadow changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1744>
When text shadows are used, the cursor indicating the current position
also casts a shadow.
This means we have to regenerate the shadow texture after the cursor
position changed, so invalidate the shadow in that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1744>
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>
With the new borderless style of libadwaita, the global switch in the headerbar
did not look good. Moving it to the main view is the opportunity to also move
the content of the information popover.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2114>
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>
As the previous commit shows, just checking source files isn't
enough. Extending the existing check to .ui files should make
sure that we catch that kind of breakage in the future before
it hits translators.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2173>
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>
It's slightly more efficient not having to do property lookups. While
that is unlikely to be a concern for the properties in question, it's
still good practice and makes the code base a bit more consistent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2168>
We are now consistently calling notify() when a property does change.
With that we can opt out of g_object_set()'s implicit change notifications,
so that notify is only emitted when a property *actually* changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2168>
It's slightly more efficient not having to do property lookups. While
that is unlikely to be a concern for the properties in question, it's
still good practice and makes the code base a bit more consistent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2168>
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>
The calendar's timezone cache holds only timezones already received
or added to the calendar, thus when asking it for a timezone for "the first
time", it returns NULL and a wrong timezone is used instead.
The get_timezone() does not do any I/O when the timezone is already cached
on the client side, thus it's fine to use it.
This could exhibit with non-recurring events, which use custom time zones,
in which case the event is shown in a wrong time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2145>
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>
Connecting to stage events won't work from a modal dialog, since the
grab will take events from the portions of the actor hierarchy above
the grabbing actor.
Connect to events from the dialog itself, so that the end session
dialog can again show the "boot options" easter egg.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2140>
Commit d92b71d2b2 went overeager in the removal of the additional
actors that were allowed to handle events (since the new grab
infrastructure makes them unable to see events in the first place),
and removed an early return in the captured event handler meant to
let events go through in those cases.
Since the grabbing actor was also part of this group, this was also
the code path where child actors of the grabbing actor could handle
events. Removing these made the captured event handler eat most
events meant for children. Add this check back, specifically for the
grabbing actor.
While at it, explicitly check (and propagate) crossing events,
since these are now enforced to be propagated (and warned about) in
Mutter.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4991
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2140>
With the new boolean setting, the "High Contrast" toggle can now
simply toggle the setting instead of the current gtk/icon-theme
shenanigans.
This isn't only much simpler, but will also make switching between
high-contrast and a non-default theme reliable at last.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2069>
Workspace transition stopped midway when the Meta key
was released while the two-finger scroll gesture was
in progress. This commit ignores the Meta key once
the gesture has been confirmed and is in motion.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2135>
This is specifically for stopping the screenshot UI screencasts for now.
It's possible to stop arbitrary screen recording handles, however due to
an issue with pipewiresrc, this method cannot currently work for cleanly
stopping Shell's own screen recordings. Hence the best we can do is to
handle just the screenshot UI screencasts to let them stop cleanly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
The screen recording menu entry will use this to check if a screencast
is currently active and to stop the screencast.
Use a GObject property so we can bind to notify; specifically we'll bind
the visibility of a screencast area indicator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
This commit replaces a few of the screenshot UI CSS expressions with
named variables.
The shot-cast margin is not defined, but rather set to the value it ends
up equal to, given the panel padding and the capture button's
sizes + position, which would be a bit awkward to compute here. It ends
up slightly larger than the general panel padding due to the capture
button being larger than other elements, and due to having to
center-align the shot-cast container to the capture button.
The shot-cast container border radius is defined as 12px, then the panel
border radius is computed from the shot-cast border radius + margin,
then the type button border radius is computed from panel
border radius - padding.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
Currently does nothing. When we're in screencast mode, we hide the
screenshot preview because screencast doesn't start until the capture
button is pressed.
The window selection is currently left as is, but it should probably be
changed to something closer to a real overview, showing windows in
real-time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2103>
And set the dialog actor reactive. Specifically, we do not know whether
the parent actor is reactive or not, and we should not be changing that
from here, so do not use that actor to handle key events.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
All callers have been updated to keep this handle to identify their
own grab.
Also, optionally use the windowing state to determine whether
the grab is suitable for the specific uses. This removes the need
to trying to grab twice in the places where we settle for a keyboard
grab.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
With the presence of Clutter.grab(), this behaves differently enough
that needs some redoing. The larger difference is what actors are
eligible for handling events.
In the older code, a PopupMenuManager would ask the grabHelper to
capture events from all the stage, and selectively silence events
on any actor that is not the currently shown popup menu or the
"source" actor for any other popup in the group (i.e. those that
would pop up another menu).
But we don't want to just silence events, we want to emit the
correct set of crossing events when a popup menu is shown or closed,
this requires a backing ClutterGrab() on the currently shown menu.
Since the presence of a grab also affects the ability to have actors
outside the grab area to handle events, the PopupMenuManager now
must detect hovering and focus changes to other menu sources by
handling events on the grabbed popup itself.
Redo the grabbing over Main.pushModal/popModal (i.e. ClutterGrab,
plus keyboard focus restoration) and a captured event handler on
the currently shown menu, to make PopupMenuManager behave as it
is expected with this new kind of grabs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
This is subject to further possible simplifications. Use Clutter.grab
to redirect input and focus, a fundamental difference here is that
we do redirect input to the topmost owner of the grabhelper stack,
instead of the stage. This is better behaved with the presence of
other grabs, at the cost of some behavioral changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
Despite this grab happening in the dialog, we are also interested in
things happening outside of it. Move this grab to happen in the stage
itself, so the changed grab semantics don't make it impossible to
interact with parts of the login screen.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
While the menu is popped up, we artificially keep the icon highlighted
by ensuring it's hovered, and muting events on the app icon until the
menu is popped down.
This is somewhat convoluted and won't work with Clutter.grab(), where
it will be the menu itself that is the owner of input events while
shown, so cut some corners and explicitly tell the app icon to be
highlighted.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
We want to mute things like pointers hovering the BoxPointer while
it does open. However keyboard events should still be handled
promptly.
Since Clutter.grab() will involve different actors being grabbed
and focused, this will have some more presence, e.g. when navigating
panel menus. We want to be able to navigate outside a menu while it
is still being shown.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
Some dialogs like the runDialog expect this actor to receive
key events while it is not reactive. Whatever that black magic was
it will no longer work.
Make the actor reactive, so it can simply handle key events.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2045>
If a menu item in a submenu is part of a section, it should have
rounded bottom corners if both the item and the section are the
last child of its respective parent.
To express that, add a new .popup-menu-section class and use that
to undo/redo the rounding for items inside a section.
It would be possible to do without a new class with a selector like
> StBoxLayout > .popup-menu-item:last-child:hover,
:last-child > .popup-menu-item:last-child:hover
but that's hardly better with its heavy reliance on implementation
details.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4940
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2126>
The cursor texture, scale and position is captured separately and
overlaid on top of the preview, and on top of the final screenshot
image. This allows toggling it on and off post-factum.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
Allow switching the screenshot mode by pressing the "s", "c", or "w" key. Also
implement arrow-key navigation between monitors in the screen screenshot mode
and between windows in the window screenshot mode.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
UIWindowSelectorLayout is a stripped-down subclass of WorkspaceLayout
(we don't have to deal with windows disappearing or appearing or
changing size). UIWindowSelectorWindow is a heavily stripped-down
version of WindowPreview. UIWindowSelector is analogous to the Workspace
class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
As mentioned in the last commit, we'll split up taking screenshots into
creating a GPU texture first, and later saving that to disk as a PNG.
For individual windows it's already easy to get a ClutterContent with
the texture using meta_window_actor_paint_to_content (), for the stage
it's not that easy and involves a few extra steps including X11 specific
ones.
So introduce a new ShellScreenshot API which does all that and provides
the caller with a ClutterContent of the stage:
shell_screenshot_screenshot_stage_to_content ()
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
With the new screenshot UI we're introducing, we'll be capturing all
screenshots to textures on the GPU at first, and then create a PNG
stream from those textures at a later point. This will allow us to
present screenshots immediately to the user so they can inspect them and
select the right area before actually saving them to disk.
As a first step to make this work, introduce a new ShellScreenshot API
that writes an existing CoglTexture to a PNG output stream:
shell_screenshot_composite_to_stream ()
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
Right now, _setIconSize() calculates the icon size everytime the
preferred height of AppSwitcher is calculated, which happens quite
often.
Reduce the perfomance impact by only calculating the icon size once.
This has the added benefit of preventing unexpected changes to the icon
sizes while the switcher is open.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2098>
Just like in the parent _onItemMotion() function, we should check for
reentrancy in our override.
Because the hover timeout will prevent a new selection from happening
for some time, in addition to checking for this._highlighted reentrancy,
we also need to track the item that's being hovered during the timeout.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2098>
When passing an invalid or unknown app ID to FocusApp(), we currently
open the app picker and silently fail to select the desired app.
Instead of half-working like that, make it clear that the argument
was invalid by returning an appropriate error. (It's easy to get the
ID wrong, as unlike appstream/flatpak IDs, we include the ".desktop"
suffix).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/337>
- increase the looking glass outer radii
- adjust the colours to be less dark
- fix oversized notification close icon
- fix separators and reduce padding in popovers
- fix colour mismatch in switch assets
- fix color of no-notifications asset
- rename assets to be consistent with dark-as-default scheme
- update checkbox assets
- fix calendar today border
- reduce icon size of placeholder notifications icon
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2111>
- updated switch assets
- new high contrast assets
- use non-hardcoded bg color for dash
- updated palette colors
- add missing color definitions to hc
- increase radii of many elements
- update search entry style
- align icon better in search entry
- restyle panel popovers without arrow and add drop shadow
- used theme colors in panel
- fix some things with popover labels
- new slider style
- some light variant fixes
- fixes to the calendar popover
- day with event styles
- better calendar-today.svg and dark variant
- shorten calendary weekday header
- saner padding
- overhaul popover menu style
- minor fixes to app grid and alt-tab switch
- updated looking glass styles
- nm-dialog adjustments
- search results adjustments
- expand out panel button hover styles
- button drawing adjustments
- adjust notifications area
- update on-screen keyboard style
- better keyboard symbolic icon assets
- change keyboard symbolic icons to 24px
- improved keyboard style
- gave the keyboard word suggestions some styles
- less obnoxious saner media control buttons
- cleaned up the css for the dash
- reworked the alt-tab switcher style
- sync style on workspace switcher
- adjusted dialog button style drawing
- popover submenu redrawing adjustement
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2104>
Instead of testing if the videos directory exists and using the home
directory otherwise, just try to create the target directory. This
aligns with how the screenshot UI handles the screenshots folder, and
it's convenient for putting screencasts into a subdirectory.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2102>
Ultimately, we want to add support for GDM's new ChoiceList
PAM extension. That extension allows PAM modules to present
a list of choices to the user. Before we can support that
extension, however, we need to have a list control in the
login-screen/unlock screen. This commit adds that control.
For the most part, it's a copy-and-paste of the gdm userlist,
but with less features. It lacks API specific to the users,
lacks the built in timed login indicator, etc. It does feature
a label heading.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1978>
Hiding the `WorkspacesDisplay` triggers a reallocation of the
`ControlsManagerLayout` which can fail with the following error:
```
JS ERROR: TypeError: workspace is undefined
_getSpacing@resource:///org/gnome/shell/ui/workspacesView.js:229:13
vfunc_allocate@resource:///org/gnome/shell/ui/workspacesView.js:355:18
vfunc_allocate@resource:///org/gnome/shell/ui/overviewControls.js:200:33
vfunc_hide@resource:///org/gnome/shell/ui/workspacesView.js:1070:38
vfunc_unmap@resource:///org/gnome/shell/ui/overviewControls.js:672:33
hideOverview@resource:///org/gnome/shell/ui/layout.js:312:28
_hideDone@resource:///org/gnome/shell/ui/overview.js:617:32
onComplete@resource:///org/gnome/shell/ui/overview.js:390:37
_makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:134:13
_easeActorProperty/<@resource:///org/gnome/shell/ui/environment.js:298:60
```
This can be reproduced by closing the overview with the three-finger
gesture.
Thus propagate the unmap before hiding the `WorkspacesDisplay`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2088>
A property for reversing the visible order of children is a bit odd.
It has also been unused by actual gnome-shell code since 2010, and the
somewhat related pack_start()/pack_end() API in GtkBox(Layout) is gone
in GTK4.
With that in mind, turn the property into a no-op and deprecate it,
so that it can be dropped next cycle.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2085>
The unfullscreen gesture was defaulting to enabled until the first
window focus change. With it now being run in the capture phase, the
gesture was preventing clicks in the top panel except on the activities
button before the first window was opened.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2087>
Like the main gnome-shell process, the extensions service loads code from
extensions. It therefore makes sense to prevent GType name clashes there
as well, just like we already to in the gnome-shell process.
This may break some extensions that use the old type name in .ui files,
but they can be fixed easily by specifying an explicit GTypeName.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2024>
Currently only banners in the SHOWN state are hidden when the underlying
notification is destroyed, but if they are in the SHOWING state, they
remain visible. Because the 'notification' member has already been set
to null when the notification got destroyed, closing the banner by
clicking on the close button, will not do anything and clicking on the
notification itself will result in an error message. For notifications
without a timeout, i.e. critical ones, this will result in an
uncloseable notification.
This can happen if the program creating a critical notification
immediately closes it again, as might happen with power notifications
from gnome-settings-daemon in some situations.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4855
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2079>
Besides dropping its GTK dependency (which doesn't affect us),
GWeather 4.0 replaces its own timezone type with GTimeZone.
It's easy enough to adjust to that, so port over to the new
version.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2083>
Replace deprecated functions with their direct replacements:
- dep.get_pkgconfig_variable() → dep.get_variable()
- prg.path() → prg.full_path()
- source/build_root() → project_source/build_root()
In one case we need meson.global_source_root() that was only
added in meson 0.58, so bump the requirement to that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2077>
When the app is properly launched, D-Bus activation will be followed
by a call to org.freedesktop.Application.Activate() to open the window.
But it's also possible for D-Bus activation to happen in other
circumstances, for example during gdbus command line completion.
We don't want to pop up a window then, so pass the --gapplication-service
flag to properly separate D-Bus activation from activating the app.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2076>
The WorkspaceGroup class in defined as CONST, which means that,
strictly speaking, is inaccessible from outside the file
workspaceAnimation.js. But Desktop Icons NG needs access to it.
Although the current Javascript engine "tolerates" this access,
a warning message is shown in the log advertising that it's
incorrect, and that although it is still allowed, the code
should be fixed.
This patch changes the definition from CONST to VAR to allow
accessing it from extensions.
jk
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2068>
The code to highlight matches did not properly escape the passed in text
as for markup before adding its highlighting markup. This lead to some
search result descriptions not showing up, because their descriptions
contained characters, such as "<", that would have to be escaped when
used in markup or otherwise lead to invalid markup.
To work around this some search providers wrongly started escaping the
description on their end before sending them to gnome-shell. This lead
to another issue. Now if the highlighter was trying to highlight the
term "a", and the escaped description contained "'", the "a" in
that would be considered a match and surrounded by "<b></b>". This
however would also generate invalid markup, again leading to an error
and the description not being shown.
Fix this by always escaping the passed in string before applying the
highlights in such a way that there are no matches within entities.
This also means that search providers that escaped their description
strings will now show up with the markup syntax. This will have to be
fixed separately in the affected search providers.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4791
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2033>
Firstly don't use EASE_IN for any minimize/unminimize animations because
those start slow and end fast. The effect of that was minimize/unminimize
appearing to be unresponsive to user clicks for a little while before
accelerating away. All such animations should be EASE_OUT for an immediate
response followed by deceleration at the end.
Secondly we replace the shallow 200ms QUADratic curves with a steeper
400ms EXPOnetial curve. Because it's steeper and twice as long the fast part
feels the same as 200ms QUAD, but there's an extra 200ms after that in which
to slow down smoothly giving a more fluid appearance. No sudden stops.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=786789
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2066>
If you slow down the unminimize animation you will notice it overshoots and
then snaps back, but only for decorated windows. Undecorated windows would
unminimize to their correct position. So we remove decorations from the
equation and now all window types unminimize to their correct position.
This wasn't noticeable because the unminimize animation velocity is usually
so high at the end (EASE_IN_EXPO) that there are no frames rendered near the
end of the curve to show it had overshot.
This appears to be consistent with the Mutter source - associating the
actor geometry with `buffer_rect` and not `frame_rect`. See
`meta_window_actor_sync_actor_geometry` for example.
Related to: https://bugzilla.gnome.org/show_bug.cgi?id=786789#c1
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2066>
Since commit 1807be1, we clear the fallback icon when a window is
removed, and notify the icon change. The notify call currently
happens after removing the window from the running state, but
before syncing the state (and possibly clear the running state
altogether).
That state is inconsistent and results in an assertion hit when
some code tries to re-fetch the icon in response to the notify
call.
Address this by updating the state before clearing the fallback
icon, so that the app will be in the correct STOPPED state after
removing the last window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4888
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2073>
We were not properly tracking the window used for the fallback icon.
This could trigger a crash, as disconnection of the signal handler might
happen on the wrong window, which in turn could cause the icon change
notification to happen on a destroyed ShellApp instance.
Fix this by tracking the window used for the fallback icon. Disconnect
the icon notify callback explicitly for this window only when it is
removed.
Also, just to be extra safe, make sure that the icon is never NULL even
if x11_window_create_fallback_gicon should return NULL for some reason.
Closes: #4436
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2065>
We currently track windows via MetaWorkspace's ::window-added and
::window-removed signals. Those aren't emitted for override-redirect
windows though, as those aren't actually located on any workspace
(see https://gitlab.gnome.org/GNOME/mutter/-/blob/gnome-41/src/core/window.c#L1322).
While that shouldn't be an issue as there's no good reason to look up
the ShellApp of an OR window, extensions can make modifications that
result in OR windows ending up in places that assume that every window
has an associated ShellApp.
We can either
- accept that extensions break stuff (including badly)
- carefully handle app-less windows everywhere
- extend tracking to OR windows
Opt for the last option, as that's the most user-friendly and least
disruptive one.
It's also simpler to track ::window-created and ::unmanaged, as we
don't have to track workspaces or windows moving between workspaces.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4751
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2029>
The window-type property may change, and with it the skip-taskbar
property that decides whether we consider it "interesting".
As a result we can end up showing untracked window, i.e. one
which does not have an associated app.
Cover this case by simply tracking all windows regardless of
their type. This won't change the app's running state, as that
is solely based on the skip-taskbar property (which is enforced
for all previously excluded window types).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4751
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2029>
The way it is currently calculated is broken for days with DST changes
or leap seconds and it is not needed anymore anyway. This will also make
the fix in the following commit simpler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
Given the correct end date this code would be able to determine this
correctly itself and doesn't need to rely on that property. And events
without correct end dates are currently not shown anyway. This prepares
for removing the allDay property entirely.
This also fixes events going from 13:00 the current day to 01:00 not
showing "...". It also fixes multi-day events wrongly detected as
all-day events by the calendar-server showing up as "All day", despite
only covering 1 hour of the day.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
Events with a date time (not just a date) where the end time is missing
or matching the start time were considered to not overlap the selected
interval if they were happening on the start time of the interval. This
was causing such zero-length events to be omitted from the calendar if
they were starting at 0:00.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
Using a starting time other than 0:00 will prevent events before the
chosen starting time from showing up for that range. This was causing
events before 12:00 to be missing in the shell calendar on the first day
of a range.
Fix this by always starting at 0:00 and then incrementing by days rather
than a time value that depending on DST or leap seconds may or may not
correspond to a day.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
The ical events, we are comparing these intervals to use the first point
in time after the end of the event as their end time, while the code in
gnome-shell was using the last point in time within the range. This was
causing multi-day events ranging from 0:00 to 0:00 to have a trailing
"..." shown on the last day.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
MetaContext:unsafe-mode was added as a debugging tool to temporarily
remove restrictions on privileged APIs. But as it turns out, there
are now extensions that toggle the property permanently. Right now
none of them are malicious (as far as I can see), but it's still a
bad idea and should be discouraged.
Do this with a notification that warns the user when unsafe mode is
enabled non-interactively (i.e. via looking glass), and hopefully
also clarifies what the weird lock icon in the top bar is about.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4798
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2050>
libgnome-bluetooth will start to offer a 2.0 library version
depending on GTK4. Given that GNOME Shell already depends on
GTK3, it cannot use this next version of gnome-bluetooth. And
since GJS will automatically try and use the latest version
available of any library, Shell must specify it wants 1.0
explicitly.
Add a required GnomeBluetooth version number when importing it
for the status indicator.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2015>
Showing multiple preference dialogs at the same time (for instance
by repeated `gnome-extensions prefs` calls) may or may not work as
expected, depending on whether any of the dialogs is modal or not
(read: opened via the Extensions app).
The easiest way to address this is to disallow more than a single
dialog at the time. It's arguably also the more predictable behavior,
and means extensions don't have to deal with inconsistent state
caused by multiple dialogs.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
GTK4 relies entirely on refcounting for cleanup (that is,
there is no longer a destroy() method that forces a dispose
run regardless of the refcount).
Unfortunately that makes cleanup harder in (some) language
bindings, where an object may be kept alive implicitly by
closures etc.
Address this by releasing the hold count when the window
is closed rather than when it is destroyed.
This isn't the most elegant, but it ensure that the service
doesn't get stuck if an extension doesn't carefully clean
up everything in its prefs widget.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
We currently ignore any error that may occur when calling the
OpenExtensionPrefs D-Bus method. Right now such an error is highly
unlikely, given that we already checked that we are running under
gnome-shell and the extension in question exists and has prefs.
We'll soon make sure that only one dialog is shown at any time,
which is an error that we can realistically expect, so handle that
properly.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
Windows from some applications, such as guake, are created as showing on
all workspaces. When these windows are put on the workspaces via
set_workspace_state() during construction, the first time the window is
added to a workspace in the loop triggers the shell app tracker which
then tries to move the window to its startup workspace. This makes the
window unsticky which triggers another set_workspace_state() which
tries to remove the window from all workspaces, but currently it is only
on the first one and then adds it to the startup workspace. Once that is
finished, the first set_workspace_state() continues adding the window
to the remaining workspaces, despite the window now no longer having
on_all_workspaces set to true.
When the window is now unmanaged, the window according to its internal
state is only found on the startup workspace, so it will only be removed
from that. This causes the assertion to fail that checks that the window
is no longer present on any workspace after this.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4720
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2014>
Like the old Tweener API, ease() allows to transition multiple
properties at once. If autoReverse or repeatCount are specified,
they should apply to all transitions, but right now we only set
them for the first one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2007>
Now that we allow extensions at the lock screens, extensions
are allowed for every session mode gnome-shell would typically
change to at runtime.
This means there's little advantage to having an allowExtensions
property in the session mode definition.
This commit simplifies the code a bit by dropping the property.
Third party session modes can still lock down extensions through
gsettings if they need to.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1967>
Now extensions can specify which session modes they work in,
but specifying the login screen or unlock screen session modes in
an extensions metadata still won't work, because those session
modes disallow extensions.
This commit fixes that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1967>
At the moment it's not realy possible to extend the login screen to do
things it doesn't have built-in support for. This means in order
to support niche use cases, those cases have to change the main
code base. For instance, oVirt and Vmware deployments want to be able
to automaticaly log in guest VMs when a user pre-authenticates through a
console on a management host. To support those use cases, we added
code to the login screen directly, even though most machines will never
be associated with oVirt or Vmware management hosts.
We also get requests from e.g. government users that need certain features
at the login screen that wouldn't get used much outside of government
deployments. For instance, we've gotten requests that a machine contains
prominently displays that it has "Top Secret" information.
All of these use cases seem like they would better handled via
extensions that could be installed in the specific deployments. The
problem is extensions only run in the user session, and get
disabled at the login screen automatically.
This commit changes that. Now extensions can specify in their metadata
via a new sessionModes property, which modes that want to run in. For
backward compatibility, if an extension doesn't specify which session
modes it works in, its assumed the extension only works in the user
session.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1967>
At the moment a session mode either allows extensions or it doesn't.
If it allows extensions, then the entire available list of
configured extensions get enabled as soon as the session mode is
entered.
Since enabling or disabling extensions is an all or nothing situation,
the code tracks whether extensions are already enabled when entering
the session mode, and if so, avoids iterating through the extension list
needlessly. It does this using a boolean named _enabled.
In the future, the extensions themselves will be given some say on
whether or not they should be enabled in a given session mode. This
means, the configured extension list may contain extensions that
shouldn't be enabled for a given session mode, and the _enabled boolean
will no longer be appropriated.
This commit drops the _enabled boolean optimization.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1967>
Since the CI pipeline now runs `meson dist` which includes a test
for an up-to-date NEWS entry, post-branch/release version bumps
have become unwieldy.
It's still useful to increase the API version right after branching
though, so return to bumping it manually and do so now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2005>
2021-10-14 19:01:41 +02:00
906 changed files with 249366 additions and 134301 deletions
<pathd="m 110.65625 99.722656 l -37.371094 21.601563 c -5.785156 3.34375 -12.917968 3.351562 -18.714844 0.023437 l -36.867187 -21.164062 c -5.796875 -3.328125 -9.382813 -9.492188 -9.414063 -16.175782 l -0.179687 -39.480468 c -0.03125 -6.683594 3.5 -12.878906 9.269531 -16.257813 l 36.679688 -21.488281 c 5.769531 -3.378906 12.898437 -3.429688 18.714844 -0.132812 l 37.554687 21.273437 c 5.8125 3.292969 9.417969 9.441406 9.445313 16.121094 l 0.183593 39.480469 c 0.027344 6.675781 -3.519531 12.859374 -9.300781 16.199218 z m 0 0"fill="url(#a)"/>
<pathd="m 110.65625 95.722656 l -37.371094 21.601563 c -5.785156 3.34375 -12.917968 3.351562 -18.714844 0.023437 l -36.867187 -21.164062 c -5.796875 -3.328125 -9.382813 -9.492188 -9.414063 -16.175782 l -0.179687 -39.480468 c -0.03125 -6.683594 3.5 -12.878906 9.269531 -16.257813 l 36.679688 -21.488281 c 5.769531 -3.378906 12.898437 -3.429688 18.714844 -0.132812 l 37.554687 21.273437 c 5.8125 3.292969 9.417969 9.441406 9.445313 16.121094 l 0.183593 39.480469 c 0.027344 6.675781 -3.519531 12.859374 -9.300781 16.199218 z m 0 0"fill="#f6f5f4"/>
<pathd="m 64.195312 74.0625 c -4.949218 0.003906 -8.964843 4.015625 -8.964843 8.96875 s 4.015625 8.96875 8.964843 8.96875 c 4.957032 0 8.972657 -4.015625 8.96875 -8.96875 c 0 -4.953125 -4.015624 -8.96875 -8.96875 -8.96875 z m 0 0"fill="url(#b)"/>
<pathd="m 64.03125 53.421875 c -8.753906 0 -17.507812 3.324219 -24.15625 9.972656 c -2.003906 2 -2.003906 5.246094 0 7.25 c 2 2 5.246094 2 7.25 0 c 9.378906 -9.382812 24.433594 -9.386719 33.816406 -0.003906 c 2 2 5.246094 2.003906 7.246094 0.003906 c 2.003906 -2.003906 2.003906 -5.25 0 -7.25 c -6.648438 -6.648437 -15.402344 -9.972656 -24.15625 -9.972656 z m 0 0"fill="url(#d)"/>
<pathd="m 64.03125 32.925781 c -14 -0.003906 -27.996094 5.324219 -38.648438 15.976563 c -2.003906 2 -2.003906 5.246094 0 7.246094 c 2 2.003906 5.246094 2 7.246094 0 c 17.386719 -17.386719 45.417969 -17.386719 62.804688 0 c 2 2 5.246094 2 7.246094 0 c 2.003906 -2 2.003906 -5.246094 0 -7.246094 c -10.648438 -10.652344 -24.648438 -15.980469 -38.648438 -15.976563 z m 0 0"fill="url(#e)"/>
<pathd="m 64.03125 30.921875 c -14 0 -27.996094 5.328125 -38.648438 15.980469 c -2.003906 2 -2.003906 5.246094 0 7.246094 c 2 2.003906 5.246094 2 7.246094 0 c 17.386719 -17.386719 45.417969 -17.386719 62.804688 0 c 2 2 5.246094 2 7.246094 0 c 2.003906 -2 2.003906 -5.246094 0 -7.246094 c -10.648438 -10.652344 -24.648438 -15.980469 -38.648438 -15.980469 z m 0 20.5 c -8.753906 0 -17.507812 3.324219 -24.15625 9.972656 c -2.003906 2 -2.003906 5.246094 0 7.246094 c 2 2.003906 5.246094 2.003906 7.25 0 c 9.378906 -9.378906 24.433594 -9.382813 33.816406 0 c 2 2 5.246094 2.003906 7.246094 0 c 2.003906 -2 2.003906 -5.246094 0 -7.246094 c -6.648438 -6.648437 -15.402344 -9.972656 -24.15625 -9.972656 z m 0.164062 20.640625 c -4.949218 0.003906 -8.964843 4.015625 -8.964843 8.96875 s 4.015625 8.96875 8.964843 8.96875 c 4.957032 0 8.972657 -4.015625 8.96875 -8.96875 c 0 -4.953125 -4.015624 -8.96875 -8.96875 -8.96875 z m 0 0"fill="#ffa348"/>
<pathd="m 6 0 c 0.265625 0 0.519531 0.105469 0.707031 0.292969 l 7 7 c 0.390625 0.390625 0.390625 1.023437 0 1.414062 l -7 7 c -0.390625 0.390625 -1.023437 0.390625 -1.414062 0 s -0.390625 -1.023437 0 -1.414062 l 6.292969 -6.292969 l -6.292969 -6.292969 c -0.390625 -0.390625 -0.390625 -1.023437 0 -1.414062 c 0.1875 -0.1875 0.441406 -0.292969 0.707031 -0.292969 z m 0 0"/>
<pathd="m 10 0 c -0.265625 0 -0.519531 0.105469 -0.707031 0.292969 l -7 7 c -0.390625 0.390625 -0.390625 1.023437 0 1.414062 l 7 7 c 0.390625 0.390625 1.023437 0.390625 1.414062 0 s 0.390625 -1.023437 0 -1.414062 l -6.292969 -6.292969 l 6.292969 -6.292969 c 0.390625 -0.390625 0.390625 -1.023437 0 -1.414062 c -0.1875 -0.1875 -0.441406 -0.292969 -0.707031 -0.292969 z m 0 0"/>
<svgxmlns="http://www.w3.org/2000/svg"height="16px"viewBox="0 0 16 16"width="16px"><pathd="m 8 0 c -4.40625 0 -8 3.59375 -8 8 s 3.59375 8 8 8 s 8 -3.59375 8 -8 s -3.59375 -8 -8 -8 z m 0 1.941406 c 3.359375 0 6.058594 2.699219 6.058594 6.058594 s -2.699219 6.058594 -6.058594 6.058594 z m 0 0"fill="#222222"/></svg>
d="m -388,1172.4341 c 0,-0.2656 0.1055,-0.5195 0.293,-0.707 0.3906,-0.3906 1.0234,-0.3906 1.414,0 l 2.293,2.293 2.293,-2.293 c 0.3906,-0.3906 1.0234,-0.3906 1.414,0 0.1875,0.1875 0.293,0.4414 0.293,0.707 0,0.2656 -0.1055,0.5195 -0.293,0.707 l -3,3 c -0.3906,0.3907 -1.0234,0.3907 -1.414,0 l -3,-3 c -0.1875,-0.1875 -0.293,-0.4414 -0.293,-0.707 z"
fill="#2e3436"
id="path177459-1"
style="fill:#2e3436;fill-opacity:1"/>
<path
d="m -388,1183.4342 c 0,0.2656 0.1055,0.5195 0.293,0.707 0.3906,0.3906 1.0234,0.3906 1.414,0 l 2.293,-2.293 2.293,2.293 c 0.3906,0.3906 1.0234,0.3906 1.414,0 0.1875,-0.1875 0.293,-0.4414 0.293,-0.707 0,-0.2656 -0.1055,-0.5195 -0.293,-0.707 l -3,-3 c -0.3906,-0.3907 -1.0234,-0.3907 -1.414,0 l -3,3 c -0.1875,0.1875 -0.293,0.4414 -0.293,0.707 z"
<pathd="m 8 5 c 1.652344 0 3 1.34375 3 3 s -1.347656 3 -3 3 c -1.65625 0 -3 -1.34375 -3 -3 s 1.34375 -3 3 -3 z m 0 0"fill="#2e3436"/>
<pathd="m 7.992188 0 c 4.40625 0 8 3.59375 8 8 s -3.59375 8 -8 8 s -8.0000005 -3.59375 -8.0000005 -8 s 3.5937505 -8 8.0000005 -8 z m 0 2 c -3.320313 0 -6 2.679688 -6 6 s 2.679687 6 6 6 c 3.320312 0 6 -2.679688 6 -6 s -2.679688 -6 -6 -6 z m 0 0"fill="#2e3435"fill-opacity="0.2"/>
<pathd="m 7.992188 0 c 4.40625 0 8 3.59375 8 8 s -3.59375 8 -8 8 c -4.402344 0 -8.0000005 -3.59375 -8.0000005 -8 s 3.5976565 -8 8.0000005 -8 z m 0 2 c -3.320313 0 -6 2.679688 -6 6 s 2.679687 6 6 6 c 3.320312 0 6 -2.679688 6 -6 s -2.679688 -6 -6 -6 z m 0 0"fill="#2e3435"fill-opacity="0.2"/>
<pathd="m 1 0 v 19.707031 l 4.242188 -4.144531 c 0.589843 1.191406 1.160156 2.386719 1.761718 3.570312 c 1.105469 1.640626 4.15625 0.464844 3.898438 -1.496093 c 0.007812 -0.46875 -0.40625 -0.90625 -0.4375 -1.3125 l 0.78125 -0.761719 c 0.585937 1.191406 1.15625 2.386719 1.757812 3.570312 c 1.105469 1.640626 4.15625 0.464844 3.898438 -1.496093 c -0.195313 -0.902344 -0.71875 -1.695313 -1.070313 -2.546875 l -0.714843 -1.539063 h 4.828124 l -12.945312 -13.550781 v 6.242188 z m 1.5 3.726562 l 6 6.242188 v -6.242188 l 7.921875 8.324219 h -3.664063 c 0.886719 1.902344 1.785157 3.800781 2.65625 5.707031 c 0.007813 0.625 -1.226562 0.980469 -1.324218 0.207032 l -2.410156 -4.917969 l -3.0625 2.984375 c 0.261718 0.609375 0.597656 1.191406 0.816406 1.816406 c -0.183594 0.601563 -1.269532 0.835938 -1.367188 0.066406 l -2.386718 -4.867187 l -3.179688 3.101563 z m 0 0"fill="#241f31"/>
<pathd="m 4 0 v 19.644531 l 4.242188 -4.140625 c 0.613281 1.214844 1.175781 2.460938 1.820312 3.65625 c 1.144531 1.476563 3.976562 0.390625 3.847656 -1.472656 c -0.09375 -0.824219 -0.59375 -1.523438 -0.898437 -2.277344 l -0.898438 -1.921875 h 5.269531 z m 1.5 3.726562 l 8.359375 8.261719 h -4.101563 c 0.886719 1.902344 1.78125 3.800781 2.660157 5.707031 c 0.035156 0.566407 -1.148438 0.988282 -1.28125 0.296876 l -2.457031 -5.011719 l -3.179688 3.105469 z m 0 0"fill="#241f31"/>
<pathd="m 16 0 v 19.769531 l -4.242188 -4.140625 c -0.613281 1.214844 -1.175781 2.460938 -1.820312 3.65625 c -1.144531 1.476563 -3.976562 0.390625 -3.847656 -1.472656 c 0.09375 -0.824219 0.59375 -1.523438 0.898437 -2.277344 l 0.898438 -1.921875 h -5.269531 z m -1.5 3.726562 l -8.359375 8.386719 h 4.101563 c -0.886719 1.902344 -1.78125 3.800781 -2.660157 5.707031 c -0.035156 0.566407 1.148438 0.988282 1.28125 0.296876 l 2.457031 -5.011719 l 3.179688 3.105469 z m 0 0"fill="#241f31"/>
<pathd="m 7 6 c -0.265625 0 -0.519531 0.105469 -0.707031 0.292969 c -0.390625 0.390625 -0.390625 1.023437 0 1.414062 l 4.292969 4.292969 l -4.292969 4.292969 c -0.390625 0.390625 -0.390625 1.023437 0 1.414062 s 1.023437 0.390625 1.414062 0 l 4.292969 -4.292969 l 4.292969 4.292969 c 0.390625 0.390625 1.023437 0.390625 1.414062 0 s 0.390625 -1.023437 0 -1.414062 l -4.292969 -4.292969 l 4.292969 -4.292969 c 0.390625 -0.390625 0.390625 -1.023437 0 -1.414062 c -0.1875 -0.1875 -0.441406 -0.292969 -0.707031 -0.292969 s -0.519531 0.105469 -0.707031 0.292969 l -4.292969 4.292969 l -4.292969 -4.292969 c -0.1875 -0.1875 -0.441406 -0.292969 -0.707031 -0.292969 z m 0 0"fill="#241f31"/>
<pathd="m 2.175781 0 h 3.648438 c 1.203125 0 2.175781 0.972656 2.175781 2.175781 v 2.648438 c 0 1.203125 -0.972656 2.175781 -2.175781 2.175781 h -3.648438 c -1.203125 0 -2.175781 -0.972656 -2.175781 -2.175781 v -2.648438 c 0 -1.203125 0.972656 -2.175781 2.175781 -2.175781 z m 0 0"/>
<pathd="m 7.796875 2.652344 l 2.050781 -1.523438 c 0.214844 -0.160156 0.503906 -0.1875 0.742188 -0.066406 c 0.242187 0.121094 0.394531 0.367188 0.394531 0.636719 v 3.605469 c 0 0.265624 -0.152344 0.511718 -0.394531 0.632812 c -0.238282 0.121094 -0.523438 0.09375 -0.742188 -0.066406 l -2.050781 -1.53125 c -0.265625 -0.199219 -0.421875 -0.511719 -0.421875 -0.84375 c 0 -0.332032 0.15625 -0.644532 0.421875 -0.84375 z m 0 0"/>
<pathd="m 9.042969 7 h 2.914062 c 0.574219 0 1.042969 0.449219 1.042969 1 s -0.46875 1 -1.042969 1 h -2.914062 c -0.574219 0 -1.042969 -0.449219 -1.042969 -1 s 0.46875 -1 1.042969 -1 z m 0 0"/>
<pathd="m 7.011719 8 c -1.113281 0 -2.011719 0.898438 -2.011719 2.011719 v 3.976562 c 0 1.113281 0.898438 2.011719 2.011719 2.011719 h 6.976562 c 1.113281 0 2.011719 -0.898438 2.011719 -2.011719 v -3.976562 c 0 -1.113281 -0.898438 -2.011719 -2.011719 -2.011719 z m 3.488281 1 c 1.378906 0 2.5 1.121094 2.5 2.5 s -1.121094 2.5 -2.5 2.5 s -2.5 -1.121094 -2.5 -2.5 s 1.121094 -2.5 2.5 -2.5 z m 0 0"/>
<pathd="m 6.929688 8.011719 h 4.140624 c 1.066407 0 1.929688 0.863281 1.929688 1.929687 v 3.140625 c 0 1.066407 -0.863281 1.929688 -1.929688 1.929688 h -4.140624 c -1.066407 0 -1.929688 -0.863281 -1.929688 -1.929688 v -3.140625 c 0 -1.066406 0.863281 -1.929687 1.929688 -1.929687 z m 0 0"/>
<pathd="m 12.796875 10.664062 l 2.050781 -1.523437 c 0.214844 -0.160156 0.503906 -0.1875 0.742188 -0.066406 c 0.242187 0.121093 0.394531 0.367187 0.394531 0.636719 v 3.605468 c 0 0.265625 -0.152344 0.511719 -0.394531 0.632813 c -0.238282 0.121093 -0.523438 0.09375 -0.742188 -0.066407 l -2.050781 -1.53125 c -0.265625 -0.199218 -0.421875 -0.511718 -0.421875 -0.84375 c 0 -0.332031 0.15625 -0.644531 0.421875 -0.84375 z m 0 0"/>
<pathd="m 0 4.011719 c 0 -1.652344 1.359375 -3.011719 3.011719 -3.011719 h 7.976562 c 1.652344 0 3.011719 1.359375 3.011719 3.011719 v 1.953125 c 0 0.554687 -0.449219 1 -1 1 s -1 -0.445313 -1 -1 v -1.953125 c 0 -0.578125 -0.433594 -1.011719 -1.011719 -1.011719 h -7.976562 c -0.578125 0 -1.011719 0.433594 -1.011719 1.011719 v 4.976562 c 0 0.578125 0.433594 1.011719 1.011719 1.011719 c 0.550781 0 1 0.449219 1 1 s -0.449219 1 -1 1 c -1.652344 0 -3.011719 -1.359375 -3.011719 -3.011719 z m 0 0"/>
<pathd="m 10.042969 6 c -0.566407 0 -1.019531 0.425781 -1.039063 0.964844 h -0.992187 c -1.113281 0 -2.011719 0.898437 -2.011719 2.011718 v 4.011719 c 0 1.113281 0.898438 2.011719 2.011719 2.011719 h 5.976562 c 1.113281 0 2.011719 -0.898438 2.011719 -2.011719 v -4.011719 c 0 -1.113281 -0.898438 -2.011718 -2.011719 -2.011718 h -0.988281 c -0.019531 -0.539063 -0.476562 -0.964844 -1.042969 -0.964844 z m 0.957031 3 c 1.105469 0 2 0.894531 2 2 s -0.894531 2 -2 2 s -2 -0.894531 -2 -2 s 0.894531 -2 2 -2 z m 0 0"/>
<pathd="m 3.007812 11.984375 h -0.316406 c -1.507812 0 -2.722656 -1.210937 -2.722656 -2.722656 v -0.269531 c 0 -0.550782 0.445312 -1 1 -1 c 0.550781 0 1 0.449218 1 1 v 0.269531 c 0 0.394531 0.328125 0.722656 0.722656 0.722656 h 0.316406 c 0.550782 0 1 0.449219 1 1 c 0 0.554687 -0.449218 1 -1 1 z m 0 0"/>
<pathd="m 14 3.039062 v -0.316406 c 0 -0.394531 -0.328125 -0.722656 -0.722656 -0.722656 h -0.269532 c -0.554687 0 -1 -0.449219 -1 -1 s 0.445313 -1 1 -1 h 0.269532 c 1.507812 0 2.722656 1.214844 2.722656 2.722656 v 0.316406 c 0 0.554688 -0.449219 1 -1 1 s -1 -0.445312 -1 -1 z m 0 0"/>
<pathd="m 0 3.039062 v -0.316406 c 0 -1.507812 1.214844 -2.722656 2.722656 -2.722656 h 0.269532 c 0.554687 0 1 0.449219 1 1 s -0.445313 1 -1 1 h -0.269532 c -0.394531 0 -0.722656 0.328125 -0.722656 0.722656 v 0.316406 c 0 0.554688 -0.449219 1 -1 1 s -1 -0.445312 -1 -1 z m 0 0"/>
<pathd="m 9.042969 6 h 1.914062 c 0.574219 0 1.042969 0.449219 1.042969 1 s -0.46875 1 -1.042969 1 h -1.914062 c -0.574219 0 -1.042969 -0.449219 -1.042969 -1 s 0.46875 -1 1.042969 -1 z m 0 0"/>
<pathd="m 7.011719 6.964844 c -1.113281 0 -2.011719 0.898437 -2.011719 2.011718 v 4.011719 c 0 1.113281 0.898438 2.011719 2.011719 2.011719 h 5.976562 c 1.113281 0 2.011719 -0.898438 2.011719 -2.011719 v -4.011719 c 0 -1.113281 -0.898438 -2.011718 -2.011719 -2.011718 z m 2.988281 2.035156 c 1.105469 0 2 0.894531 2 2 s -0.894531 2 -2 2 s -2 -0.894531 -2 -2 s 0.894531 -2 2 -2 z m 0 0"/>
<pathd="m 0 4.011719 c 0 -1.652344 1.359375 -3.011719 3.011719 -3.011719 h 7.976562 c 1.652344 0 3.011719 1.359375 3.011719 3.011719 v 0.988281 c 0 0.550781 -0.449219 1 -1 1 s -1 -0.449219 -1 -1 v -0.988281 c 0 -0.578125 -0.433594 -1.011719 -1.011719 -1.011719 h -7.976562 c -0.578125 0 -1.011719 0.433594 -1.011719 1.011719 v 4.976562 c 0 0.578125 0.433594 1.011719 1.011719 1.011719 c 0.550781 0 1 0.449219 1 1 s -0.449219 1 -1 1 c -1.652344 0 -3.011719 -1.359375 -3.011719 -3.011719 z m 0 0"/>
<pathd="m 3.5 2 c -1.929688 0.007812 -3.4921875 1.570312 -3.5 3.5 c 0 1.386719 0.820312 2.59375 2 3.15625 v 3.34375 h 2 v -3.035156 c 1.53125 -0.230469 2.734375 -1.433594 2.964844 -2.964844 h 2.035156 v -2 h -2.34375 c -0.578125 -1.21875 -1.808594 -1.996094 -3.15625 -2 z m 25 0 c -1.347656 0.003906 -2.578125 0.78125 -3.15625 2 h -2.34375 v 2 h 2.035156 c 0.230469 1.53125 1.433594 2.734375 2.964844 2.964844 v 3.035156 h 2 v -3.34375 c 1.21875 -0.578125 1.996094 -1.808594 2 -3.15625 c 0 -1.921875 -1.578125 -3.5 -3.5 -3.5 z m -25 2 c 0.839844 0 1.5 0.660156 1.5 1.5 s -0.660156 1.5 -1.5 1.5 s -1.5 -0.660156 -1.5 -1.5 s 0.660156 -1.5 1.5 -1.5 z m 7.5 0 v 2 h 4 v -2 z m 6 0 v 2 h 4 v -2 z m 11.5 0 c 0.839844 0 1.5 0.660156 1.5 1.5 s -0.660156 1.5 -1.5 1.5 s -1.5 -0.660156 -1.5 -1.5 s 0.660156 -1.5 1.5 -1.5 z m -26.5 10 v 4 h 2 v -4 z m 26 0 v 4 h 2 v -4 z m -26 6 v 3.34375 c -1.21875 0.578125 -1.99609375 1.808594 -2 3.15625 c 0 1.921875 1.578125 3.5 3.5 3.5 c 1.347656 -0.003906 2.578125 -0.78125 3.15625 -2 h 2.34375 v -2 h -2.035156 c -0.230469 -1.53125 -1.433594 -2.734375 -2.964844 -2.964844 v -3.035156 z m 26 0 v 3.035156 c -1.53125 0.230469 -2.734375 1.433594 -2.964844 2.964844 h -2.035156 v 2 h 2.34375 c 0.578125 1.21875 1.808594 1.996094 3.15625 2 c 1.921875 0 3.5 -1.578125 3.5 -3.5 c -0.003906 -1.347656 -0.78125 -2.578125 -2 -3.15625 v -3.34375 z m -24.5 5 c 0.839844 0 1.5 0.660156 1.5 1.5 s -0.660156 1.5 -1.5 1.5 s -1.5 -0.660156 -1.5 -1.5 s 0.660156 -1.5 1.5 -1.5 z m 25 0 c 0.839844 0 1.5 0.660156 1.5 1.5 s -0.660156 1.5 -1.5 1.5 s -1.5 -0.660156 -1.5 -1.5 s 0.660156 -1.5 1.5 -1.5 z m -17.5 1 v 2 h 4 v -2 z m 6 0 v 2 h 4 v -2 z m 0 0"fill="#241f31"/>
<pathd="m 5 3 c -2.265625 0 -4.09375 1.847656 -4.09375 4.074219 v 13.828125 c 0 2.230468 1.828125 4.074218 4.09375 4.074218 h 5.894531 v 2.46875 c 0 1.410157 1.132813 2.542969 2.542969 2.542969 h 5.414062 c 1.40625 0 2.542969 -1.132812 2.542969 -2.542969 v -2.46875 h 5.390625 c 2.265625 0 4.097656 -1.84375 4.097656 -4.074218 v -13.828125 c 0 -2.226563 -1.832031 -4.074219 -4.097656 -4.074219 z m 0 1.976562 h 21.785156 c 1.15625 0 2.074219 0.910157 2.074219 2.097657 v 13.828125 c 0 1.191406 -0.917969 2.097656 -2.074219 2.097656 h -21.785156 c -1.15625 0 -2.074219 -0.90625 -2.074219 -2.097656 v -13.828125 c 0 -1.1875 0.917969 -2.097657 2.074219 -2.097657 z m 7.890625 20 h 6.5 v 2.46875 c 0 0.304688 -0.238281 0.542969 -0.539063 0.542969 h -5.414062 c -0.304688 0 -0.546875 -0.238281 -0.546875 -0.542969 z m 0 0"fill="#241f31"/>
<pathd="m 2.953125 1.074219 l 2.417969 13.210937 l 3.238281 -2.398437 l 2.054687 2.648437 c 1.03125 1.433594 3.148438 -0.210937 2.011719 -1.5625 l -2.015625 -2.59375 l 2.984375 -2.175781 z m 0 0"fill="#2e3436"/>
<pathd="m 3 3 c -1.644531 0 -3 1.355469 -3 3 v 14 c 0 1.644531 1.355469 3 3 3 h 4 v 3 c 0 1.644531 1.351562 3 3 3 h 18.996094 c 1.644531 0 3 -1.355469 3 -3 v -14 c 0 -1.644531 -1.355469 -3 -3 -3 h -4 v -3 c 0 -1.644531 -1.355469 -3 -3 -3 z m 0 2 h 18.996094 c 0.570312 0 1 0.429688 1 1 v 3 h -12.996094 c -1.648438 0 -3 1.355469 -3 3 v 9 h -4 c -0.570312 0 -1 -0.429688 -1 -1 v -14 c 0 -0.570312 0.429688 -1 1 -1 z m 7 6 h 18.996094 c 0.570312 0 1 0.429688 1 1 v 14 c 0 0.570312 -0.429688 1 -1 1 h -18.996094 c -0.574219 0 -1 -0.429688 -1 -1 v -14 c 0 -0.570312 0.425781 -1 1 -1 z m 0 0"fill="#241f31"/>
<pathd="m 12.105469 1 c -2.265625 0 -4.097657 1.847656 -4.097657 4.078125 v 9.832031 c 0 2.230469 1.832032 4.078125 4.097657 4.078125 h 3.894531 v 1.46875 c 0 1.40625 1.132812 2.542969 2.542969 2.542969 h 3.414062 c 1.410157 0 2.546875 -1.136719 2.546875 -2.542969 v -1.46875 h 3.390625 c 2.265625 0 4.097657 -1.847656 4.097657 -4.078125 v -9.832031 c 0 -2.230469 -1.832032 -4.078125 -4.097657 -4.078125 z m 0 1.980469 h 15.789062 c 1.15625 0 2.078125 0.90625 2.078125 2.097656 v 9.832031 c 0 1.191406 -0.921875 2.097656 -2.078125 2.097656 h -15.789062 c -1.15625 0 -2.078125 -0.90625 -2.078125 -2.097656 v -9.832031 c 0 -1.191406 0.921875 -2.097656 2.078125 -2.097656 z m 5.894531 16.007812 h 4.5 v 1.46875 c 0 0.300781 -0.242188 0.542969 -0.542969 0.542969 h -3.414062 c -0.300781 0 -0.542969 -0.242188 -0.542969 -0.542969 z m 0 0"fill="#242032"fill-opacity="0.2"/>
<pathd="m 4 21 c -1.644531 0 -3 1.355469 -3 3 v 5.585938 l -0.707031 0.707031 c -0.2851565 0.285156 -0.371094 0.714843 -0.214844 1.089843 c 0.152344 0.375 0.515625 0.617188 0.921875 0.617188 h 14 c 0.40625 0 0.769531 -0.242188 0.921875 -0.617188 c 0.15625 -0.375 0.070313 -0.804687 -0.214844 -1.089843 l -0.707031 -0.707031 v -5.585938 c 0 -1.644531 -1.355469 -3 -3 -3 z m 0 2 h 8 c 0.570312 0 1 0.429688 1 1 v 5 h -10 v -5 c 0 -0.570312 0.429688 -1 1 -1 z m 0 0"fill="#241f31"/>
<pathd="m 4 21 c -1.644531 0 -3 1.355469 -3 3 v 5.585938 l -0.707031 0.707031 c -0.2851565 0.285156 -0.371094 0.714843 -0.214844 1.089843 c 0.152344 0.375 0.515625 0.617188 0.921875 0.617188 h 14 c 0.40625 0 0.769531 -0.242188 0.921875 -0.617188 c 0.15625 -0.375 0.070313 -0.804687 -0.214844 -1.089843 l -0.707031 -0.707031 v -5.585938 c 0 -1.644531 -1.355469 -3 -3 -3 z m 0 2 h 8 c 0.570312 0 1 0.429688 1 1 v 5 h -10 v -5 c 0 -0.570312 0.429688 -1 1 -1 z m 0 0"/>
<pathd="m 12.105469 1.007812 c -2.261719 0 -4.09375 1.847657 -4.09375 4.078126 v 9.828124 c 0 2.230469 1.832031 4.074219 4.09375 4.074219 h 3.894531 v 1.46875 c 0 1.410157 1.132812 2.542969 2.542969 2.542969 h 3.414062 c 1.410157 0 2.542969 -1.132812 2.542969 -2.542969 v -1.46875 h 3.394531 c 2.261719 0 4.09375 -1.84375 4.09375 -4.074219 v -9.828124 c 0 -2.230469 -1.832031 -4.078126 -4.09375 -4.078126 z m 0 1.980469 h 15.789062 c 1.152344 0 2.074219 0.90625 2.074219 2.097657 v 9.828124 c 0 1.191407 -0.921875 2.09375 -2.074219 2.09375 h -15.789062 c -1.152344 0 -2.074219 -0.902343 -2.074219 -2.09375 v -9.828124 c 0 -1.191407 0.921875 -2.097657 2.074219 -2.097657 z m 5.894531 16 h 4.5 v 1.46875 c 0 0.300781 -0.242188 0.542969 -0.542969 0.542969 h -3.414062 c -0.300781 0 -0.542969 -0.242188 -0.542969 -0.542969 z m 0 0"/>
<pathd="m 12 1 c -2.265625 0 -4.09375 1.847656 -4.09375 4.074219 v 9.832031 c 0 2.226562 1.828125 4.074219 4.09375 4.074219 h 3.894531 v 1.46875 c 0 1.40625 1.132813 2.539062 2.542969 2.539062 h 3.414062 c 1.40625 0 2.542969 -1.132812 2.542969 -2.539062 v -1.46875 h 3.390625 c 2.265625 0 4.097656 -1.847657 4.097656 -4.074219 v -9.832031 c 0 -2.226563 -1.832031 -4.074219 -4.097656 -4.074219 z m 0 1.980469 h 15.785156 c 1.15625 0 2.078125 0.90625 2.078125 2.09375 v 9.832031 c 0 1.1875 -0.921875 2.09375 -2.078125 2.09375 h -15.785156 c -1.15625 0 -2.074219 -0.90625 -2.074219 -2.09375 v -9.832031 c 0 -1.1875 0.917969 -2.09375 2.074219 -2.09375 z m 5.894531 16 h 4.5 v 1.46875 c 0 0.300781 -0.242187 0.539062 -0.542969 0.539062 h -3.414062 c -0.304688 0 -0.542969 -0.238281 -0.542969 -0.539062 z m 0 0"fill="#241f31"/>
<pathd="m 4 21 c -1.644531 0 -3 1.355469 -3 3 v 5.585938 l -0.707031 0.707031 c -0.2851565 0.285156 -0.371094 0.714843 -0.214844 1.089843 c 0.152344 0.375 0.515625 0.617188 0.921875 0.617188 h 14 c 0.40625 0 0.769531 -0.242188 0.921875 -0.617188 c 0.15625 -0.375 0.070313 -0.804687 -0.214844 -1.089843 l -0.707031 -0.707031 v -5.585938 c 0 -1.644531 -1.355469 -3 -3 -3 z m 0 2 h 8 c 0.570312 0 1 0.429688 1 1 v 5 h -10 v -5 c 0 -0.570312 0.429688 -1 1 -1 z m 0 0"fill="#242032"fill-opacity="0.2"/>
<pathd="m 7 4.945312 c -2.199219 0 -4 1.800782 -4 4 l -0.003906 11.054688 c 0 2.199219 1.800781 4 4 4 h 2.003906 c 0.550781 0 1 -0.449219 1 -1 s -0.449219 -1 -1 -1 h -2.003906 c -1.125 0 -2 -0.875 -2 -2 l 0.003906 -11.054688 c 0 -1.125 0.875 -2 2 -2 h 18 c 1.125 0 2 0.875 2 2 l -0.003906 11.054688 c 0 1.125 -0.871094 2 -2 2 h -1.996094 c -0.550781 0 -1 0.449219 -1 1 s 0.449219 1 1 1 h 1.996094 c 2.199218 0 4 -1.800781 4 -4 l 0.003906 -11.054688 c 0 -2.199218 -1.800781 -4 -4 -4 z m 9 14.0625 c -0.484375 0 -0.972656 0.214844 -1.265625 0.644532 l -3.523437 5.136718 c -0.609376 0.890626 0.085937 2.210938 1.164062 2.210938 h 7.257812 c 1.078126 0 1.773438 -1.320312 1.164063 -2.210938 l -3.53125 -5.136718 c -0.296875 -0.429688 -0.78125 -0.644532 -1.265625 -0.644532 z m 0 2.332032 l 2.515625 3.660156 h -5.023437 z m 0 0"fill="#241f31"/>
<pathd="m 7.988281 6 c -1.109375 0 -2 0.890625 -2 2 s 0.890625 2 2 2 s 2 -0.890625 2 -2 s -0.890625 -2 -2 -2 z m 8 0 c -1.109375 0 -2 0.890625 -2 2 s 0.890625 2 2 2 s 2 -0.890625 2 -2 s -0.890625 -2 -2 -2 z m 8 0 c -1.109375 0 -2 0.890625 -2 2 s 0.890625 2 2 2 s 2 -0.890625 2 -2 s -0.890625 -2 -2 -2 z m -16 8 c -1.109375 0 -2 0.890625 -2 2 s 0.890625 2 2 2 s 2 -0.890625 2 -2 s -0.890625 -2 -2 -2 z m 8 0 c -1.109375 0 -2 0.890625 -2 2 s 0.890625 2 2 2 s 2 -0.890625 2 -2 s -0.890625 -2 -2 -2 z m 8 0 c -1.109375 0 -2 0.890625 -2 2 s 0.890625 2 2 2 s 2 -0.890625 2 -2 s -0.890625 -2 -2 -2 z m -16 8 c -1.109375 0 -2 0.890625 -2 2 s 0.890625 2 2 2 s 2 -0.890625 2 -2 s -0.890625 -2 -2 -2 z m 8 0 c -1.109375 0 -2 0.890625 -2 2 s 0.890625 2 2 2 s 2 -0.890625 2 -2 s -0.890625 -2 -2 -2 z m 8 0 c -1.109375 0 -2 0.890625 -2 2 s 0.890625 2 2 2 s 2 -0.890625 2 -2 s -0.890625 -2 -2 -2 z m 0 0"fill="#241f31"/>
<pathd="m 32 3 v 2 h -25 c -2.789062 0 -5 2.210938 -5 5 v 12 c 0 2.789062 2.210938 5 5 5 h 25 v 2 h -25 c -3.859375 0 -7 -3.140625 -7 -7 v -12 c 0 -3.859375 3.140625 -7 7 -7 z m -15 8 c 0.554688 0 1 0.445312 1 1 s -0.445312 1 -1 1 s -1 -0.445312 -1 -1 s 0.445312 -1 1 -1 z m -4 0 c 0.554688 0 1 0.445312 1 1 s -0.445312 1 -1 1 s -1 -0.445312 -1 -1 s 0.445312 -1 1 -1 z m -4 0 c 0.554688 0 1 0.445312 1 1 s -0.445312 1 -1 1 s -1 -0.445312 -1 -1 s 0.445312 -1 1 -1 z m 8 4 c 0.554688 0 1 0.445312 1 1 s -0.445312 1 -1 1 s -1 -0.445312 -1 -1 s 0.445312 -1 1 -1 z m -4 0 c 0.554688 0 1 0.445312 1 1 s -0.445312 1 -1 1 s -1 -0.445312 -1 -1 s 0.445312 -1 1 -1 z m -4 0 c 0.554688 0 1 0.445312 1 1 s -0.445312 1 -1 1 s -1 -0.445312 -1 -1 s 0.445312 -1 1 -1 z m 8 4 c 0.554688 0 1 0.445312 1 1 s -0.445312 1 -1 1 s -1 -0.445312 -1 -1 s 0.445312 -1 1 -1 z m -4 0 c 0.554688 0 1 0.445312 1 1 s -0.445312 1 -1 1 s -1 -0.445312 -1 -1 s 0.445312 -1 1 -1 z m -4 0 c 0.554688 0 1 0.445312 1 1 s -0.445312 1 -1 1 s -1 -0.445312 -1 -1 s 0.445312 -1 1 -1 z m 0 0"/>
<pathd="m 32 7 v 18 h -5 c -1.660156 0 -3 -1.339844 -3 -3 v -12 c 0 -1.660156 1.339844 -3 3 -3 z m 0 0"fill-opacity="0.2"/>
<pathd="m 0 3 v 2 h 25 c 2.789062 0 5 2.210938 5 5 v 12 c 0 2.789062 -2.210938 5 -5 5 h -25 v 2 h 25 c 3.859375 0 7 -3.140625 7 -7 v -12 c 0 -3.859375 -3.140625 -7 -7 -7 z m 15 8 c -0.554688 0 -1 0.445312 -1 1 s 0.445312 1 1 1 s 1 -0.445312 1 -1 s -0.445312 -1 -1 -1 z m 4 0 c -0.554688 0 -1 0.445312 -1 1 s 0.445312 1 1 1 s 1 -0.445312 1 -1 s -0.445312 -1 -1 -1 z m 4 0 c -0.554688 0 -1 0.445312 -1 1 s 0.445312 1 1 1 s 1 -0.445312 1 -1 s -0.445312 -1 -1 -1 z m -8 4 c -0.554688 0 -1 0.445312 -1 1 s 0.445312 1 1 1 s 1 -0.445312 1 -1 s -0.445312 -1 -1 -1 z m 4 0 c -0.554688 0 -1 0.445312 -1 1 s 0.445312 1 1 1 s 1 -0.445312 1 -1 s -0.445312 -1 -1 -1 z m 4 0 c -0.554688 0 -1 0.445312 -1 1 s 0.445312 1 1 1 s 1 -0.445312 1 -1 s -0.445312 -1 -1 -1 z m -8 4 c -0.554688 0 -1 0.445312 -1 1 s 0.445312 1 1 1 s 1 -0.445312 1 -1 s -0.445312 -1 -1 -1 z m 4 0 c -0.554688 0 -1 0.445312 -1 1 s 0.445312 1 1 1 s 1 -0.445312 1 -1 s -0.445312 -1 -1 -1 z m 4 0 c -0.554688 0 -1 0.445312 -1 1 s 0.445312 1 1 1 s 1 -0.445312 1 -1 s -0.445312 -1 -1 -1 z m 0 0"/>
<pathd="m 0 7 v 18 h 5 c 1.660156 0 3 -1.339844 3 -3 v -12 c 0 -1.660156 -1.339844 -3 -3 -3 z m 0 0"fill-opacity="0.2"/>
<pathd="m 3 3 c -1.660156 0 -3 1.339844 -3 3 v 19 c 0 1.660156 1.339844 3 3 3 h 26 c 1.660156 0 3 -1.339844 3 -3 v -19 c 0 -1.660156 -1.339844 -3 -3 -3 z m 0 3 h 26 c 0.554688 0 1 0.445312 1 1 v 18 c 0 0.554688 -0.445312 1 -1 1 h -26 c -0.554688 0 -1 -0.445312 -1 -1 v -18 c 0 -0.554688 0.445312 -1 1 -1 z m 0 0"fill="#241f31"/>
<gfill="#231e2d"fill-opacity="0.2">
<pathd="m 25.75 8 h 1.5 c 0.414062 0 0.75 0.335938 0.75 0.75 v 1.5 c 0 0.414062 -0.335938 0.75 -0.75 0.75 h -1.5 c -0.414062 0 -0.75 -0.335938 -0.75 -0.75 v -1.5 c 0 -0.414062 0.335938 -0.75 0.75 -0.75 z m 0 0"/>
<pathd="m 25.75 12 h 1.5 c 0.414062 0 0.75 0.335938 0.75 0.75 v 1.5 c 0 0.414062 -0.335938 0.75 -0.75 0.75 h -1.5 c -0.414062 0 -0.75 -0.335938 -0.75 -0.75 v -1.5 c 0 -0.414062 0.335938 -0.75 0.75 -0.75 z m 0 0"/>
<pathd="m 25.75 16 h 1.5 c 0.414062 0 0.75 0.335938 0.75 0.75 v 1.5 c 0 0.414062 -0.335938 0.75 -0.75 0.75 h -1.5 c -0.414062 0 -0.75 -0.335938 -0.75 -0.75 v -1.5 c 0 -0.414062 0.335938 -0.75 0.75 -0.75 z m 0 0"/>
<pathd="m 3 3 c -1.660156 0 -3 1.339844 -3 3 v 19 c 0 1.660156 1.339844 3 3 3 h 26 c 1.660156 0 3 -1.339844 3 -3 v -19 c 0 -1.660156 -1.339844 -3 -3 -3 z m 0 3 h 26 c 0.554688 0 1 0.445312 1 1 v 18 c 0 0.554688 -0.445312 1 -1 1 h -26 c -0.554688 0 -1 -0.445312 -1 -1 v -18 c 0 -0.554688 0.445312 -1 1 -1 z m 0 0"fill="#241f31"/>
<gfill="#231e2d"fill-opacity="0.2">
<pathd="m 4.75 8 h 1.5 c 0.414062 0 0.75 0.335938 0.75 0.75 v 1.5 c 0 0.414062 -0.335938 0.75 -0.75 0.75 h -1.5 c -0.414062 0 -0.75 -0.335938 -0.75 -0.75 v -1.5 c 0 -0.414062 0.335938 -0.75 0.75 -0.75 z m 0 0"/>
<pathd="m 4.75 12 h 1.5 c 0.414062 0 0.75 0.335938 0.75 0.75 v 1.5 c 0 0.414062 -0.335938 0.75 -0.75 0.75 h -1.5 c -0.414062 0 -0.75 -0.335938 -0.75 -0.75 v -1.5 c 0 -0.414062 0.335938 -0.75 0.75 -0.75 z m 0 0"/>
<pathd="m 4.75 16 h 1.5 c 0.414062 0 0.75 0.335938 0.75 0.75 v 1.5 c 0 0.414062 -0.335938 0.75 -0.75 0.75 h -1.5 c -0.414062 0 -0.75 -0.335938 -0.75 -0.75 v -1.5 c 0 -0.414062 0.335938 -0.75 0.75 -0.75 z m 0 0"/>
<pathd="m 30 3 c 2 0 2 1.714844 2 2 v 22 h -2 v -17 c 0 -1 -1 -1 -1 -1 h -29 v -6 z m -2 2 h -4 c -0.554688 0 -1 0.445312 -1 1 s 0.445312 1 1 1 h 4 c 0.554688 0 1 -0.445312 1 -1 s -0.445312 -1 -1 -1 z m -7 0.25 c -0.414062 0 -0.75 0.335938 -0.75 0.75 s 0.335938 0.75 0.75 0.75 s 0.75 -0.335938 0.75 -0.75 s -0.335938 -0.75 -0.75 -0.75 z m 0 0"/>
<pathd="m 21 5 h -1 c -0.554688 0 -1 0.445312 -1 1 s 0.445312 1 1 1 h 1 c 0.554688 0 1 -0.445312 1 -1 s -0.445312 -1 -1 -1 z m 0 0"fill-opacity="0.34902"/>
<pathd="m 2 3 c -2 0 -2 1.714844 -2 2 v 22 h 2 v -17 c 0 -1 1 -1 1 -1 h 29 v -6 z m 2 2 h 4 c 0.554688 0 1 0.445312 1 1 s -0.445312 1 -1 1 h -4 c -0.554688 0 -1 -0.445312 -1 -1 s 0.445312 -1 1 -1 z m 7 0.25 c 0.414062 0 0.75 0.335938 0.75 0.75 s -0.335938 0.75 -0.75 0.75 s -0.75 -0.335938 -0.75 -0.75 s 0.335938 -0.75 0.75 -0.75 z m 0 0"/>
<pathd="m 11 5 h 1 c 0.554688 0 1 0.445312 1 1 s -0.445312 1 -1 1 h -1 c -0.554688 0 -1 -0.445312 -1 -1 s 0.445312 -1 1 -1 z m 0 0"fill-opacity="0.34902"/>
<pathd="m 20.996094 30 c 1.644531 0 2.996094 -1.355469 3 -3 l 0.003906 -2 h -2 l -0.003906 2 c 0 0.570312 -0.429688 1 -1 1 h -17.996094 c -0.570312 0 -1 -0.429688 -1 -1 v -13 c 0 -0.570312 0.429688 -1 1 -1 h 3 v -3 h -3 c -1.644531 0 -3 1.355469 -3 3 v 14 c 0 1.644531 1.355469 3 3 3 z m 8 -7 c 1.644531 0 3 -1.355469 3 -3 v -14 c 0 -1.644531 -1.355469 -3 -3 -3 h -18 c -1.644532 0 -3 1.355469 -3 3 v 14 c 0 1.644531 1.355468 3 3 3 z m 0 -2 h -18 c -0.570313 0 -1 -0.429688 -1 -1 v -13 c 0 -0.570312 0.429687 -1 1 -1 h 18 c 0.570312 0 1 0.429688 1 1 v 13 c 0 0.570312 -0.429688 1 -1 1 z m 0 0"fill="#241f31"/>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
