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>
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>
If a user hits escape twice really fast when coming back to
their machine to unlock it, they made end up getting presented
with a non-functional unlock screen that doesn't show their
user icon and doesn't ask for a password.
This is because showPrompt assumes that if an auth prompt already
exists, it's ready to go. That may not be true, if it's in the
process of getting torn down at the time because it's in the middle
of a cancel animation.
This commit solves the problem by ensuring the auth prompt is always
in a fresh reset state before showing it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1999>
If the the unlock dialog gets finished before an auth dialog is
created, the code currently creates one just to tell it to finish.
This commit changes the code to skip creating the auth dialog in
that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1999>
Commit dd2cd6286c restricted callers of the screenshot methods to
portal implementations, gnome-settings-daemon and gnome-screenshot.
That restriction does make sense for the actual screenshot methods,
but `PickColor` is actually used by GTK in its color picker (and
therefore may be called from arbitrary applications).
Fix this by unrestricting access to `PickColor` again. Considering that
the method is always interactive, it's not very privacy/security-sensitive
anyway.
https://gitlab.gnome.org/GNOME/gtk/-/issues/4283
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1990>
Previously we used `get_image()`, which returned `cairo_surface`,
in order to create a `ClutterContent` with a screenshot of the
`MetaWindowActor`. This added a roundtrip from GPU to CPU memory.
Instead, use the new `paint_to_content()` API which lets us use a
`CoglTexture` directly as source of our `ClutterContent`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1879>
This signal announces the preferred commit mode of the preedit text when
the input context is reset. Keep this mode around, and ensure to honor this
mode (e.g. maybe commit the preedit string) whenever the input method would
be reset.
This is delegated to the internal layers, so propagate this mode via
clutter_input_method_set_preedit_text().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1929>
The Eval() method is unarguably the most sensitive D-Bus method
we expose, since it allows running arbitrary code in the compositor.
It is currently tied to the `development-tools` settings that is
enabled by default. As users have become accustomed to the built-in
commands that are enabled by the same setting (restart, lg, ...),
that default cannot easily be changed.
In order to restrict the method without affecting the rather harmless
commands, guard it by the new MetaContext:unsafe-mode property instead
of the setting.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3943
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970>
Since touchpad smooth scroll events with source finger are handled by
the swipeTracker, the workspace scroll handler can focus on discrete
events.
Thanks to Mutter emulating discrete scroll events, see
meta_seat_impl_notify_scroll_continuous_in_impl in meta-seat-impl.c,
it is safe to ignore smooth scroll in the workspace scroll handler
and handle exclusively discrete events.
In addition, once high-resolution scroll events land in Mutter [1], a
mouse will be able generate non emulated smooth scroll events that
should be ignored in favour of the discrete scroll events.
Otherwise, a single mouse wheel click will scroll through multiple
workspaces at once.
[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1959>
The keyboard is placed outside of the screen when shown and then slides
in via a transition that changes the translate-y property. This
translation does not affect the allocation of the Keyboard actor and as
such does not trigger any of the signals LayoutManager is connected to
to update the input region. This means the input region remains at the
original position of the actor outside of the screen and as a result on
X11 clicks will go through to the underlying window.
There was a workaround for this by queuing a relayout at the end of the
transition, but this stopped working due to optimizations avoiding
unnecessary allocation changes.
This updates that workaround to toggle the visibility of the actor
instead, which is the other signal that LayoutManager reacts to. Once
ClutterActor provides better ways to react to transforms this can
hopefully be removed entirely.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4556
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1955>
Sometimes when an icon is dragged and dropped in Dash, one Favourite app icon
can appear to the right of Dash separator. This can happen when available system
resources are low and the PlaceHolder destroy animation is delayed and the
corresponding container child is still present. With this commit the separator
position is calculated correctly, even when the animation is pending.
Fixes#3966, #3799
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1804>
eee2ccac fixed window opacity being changed outside of transitions but
resulted in the final step of the transition, that would set the window
to fully opaque, being missed.
This change now moves the opacity change entirely out of allocation and
instead follows the adjustment changes directly, which still fixes the
original bug and ensures the opacity is also applied for the last step
in the transition.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4561
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1957>
GJS added a console module that extensions may start using. To ensure that
extensions using console.log() and similar functions don't show up as
'Gjs-Console' in users' system logs, we should call setConsoleLogdomain()
with 'GNOME Shell'.
This GJS API addition is only accessible using ECMAScript Modules (ESM),
this commit moves shell startup to a small init.js module and adapts
CI jobs to either handle or ignore it.
We can drop the .jscheckignore file when future versions of SpiderMonkey
allow for compile checks without validating module specifiers.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1958>
!1940 added support for soup 3, including a fallback to soup 2.4
where the newer version isn't available.
Unfortunately it missed that libgweather has a hidden soup dependency,
and now gnome-shell fails to start if a weather location has been set
up and soup 3 is available.
We don't have a good way to detect that case, so hide the soup 3 support
behind a build option. Distributors are expected to switch it at the
same time as libgweather.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1966>
Unlike for the old Soup.SessionSync/SessionAsync classes,
Soup.Session:ssl-use-system-ca-file already defaults to true.
In Soup3, the behavior was made unconditional and the property
removed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
Quoting the documentation:
In libsoup 2.44 and later, you can set the session's “proxy-resolver”
property to the resolver returned by g_proxy_resolver_get_default() to
get the same effect. Note that for "plain" SoupSessions (ie, not
SoupSessionAsync or SoupSessionSync), this is done for you automatically.
libsoup 2.44 was released in 2013, so we can safely assume that Soup is
new enough to handle this for us.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1940>
