We want to make the extensions app code more self-contained to make it
easier to build separately, and ultimately make it available on flathub.
One complication we are facing is that it is currently all over the source
tree:
- js/extensionPrefs for the main code
- src for the launcher process
- data for .desktop file and icons
Switching from a C launcher to the imports.package module allows us to
consolidate the first two, and will also take care of the annoying
setup bits (defining JS search path, extending GI lookup, loading
resources).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
While we can use the libnm API directly from JS, the call will
synchronously load the VPN service descriptions from disk.
Previously we were lowering the impact by caching the result,
but as we stopped doing that, it becomes more important to address
the issue properly and move it off to a thread.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
For sandboxed apps, permission to talk to org.freedesktop.Notifications
looks innocent enough. However as all exported services share the same
connection to the session bus, that permission actually grants an app
access to *any* shell D-Bus API.
While we want apps to use the notification portal, it is still common
for apps to use libnotify, raw D-Bus calls or even notify-send.
We don't want to give those apps a way to circumvent most of the sandbox
restrictions, so stop owning the org.freedesktop.Notifications name.
In a next step we will implement a separate notification-daemon that
exposes the API on the well-known address and proxies any requests to
the real implementation in gnome-shell.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
This caches GAppInfo so that the compositor thread does not have to perform
costly disk access to load them. Instead, they are loaded from a worker
thread and the ShellAppCache notifies of changes.
To simplify maintenance, ShellAppCache manages this directly and the
existing ShellAppSystem wraps the cache. We may want to graft these
together in the future, but now it provides the easiest way to backport
changes to older Shell releases.
Another source of compositor thread disk access was in determining the
name for an application directory. Translations are provided via GKeyFile
installed in "desktop-directories". Each time we would build the name
for a label (or update it) we would have to load all of these files.
Instead, the ShellAppCache caches that information and updates the cache
in bulk when those change. We can reduce this in the future to do less
work, but chances are these will come together anyway so that is probably
worth fixing if we ever come across it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2282
Commit 88ac339774 changed StEntry behavior so the text hint would
stay visible while focused, as long as the text buffer is empty.
However, IMs that use preedit still should count as "started typing",
while the text buffer is still officially empty.
To fix this, check on st_entry_update_hint_visibility() that there's
indeed no preedit buffer before showing the hint. We can't directly
listen to internal preedit buffer changes in ClutterText, so handle
preedit buffer updates through the ::cursor-changed signal that will
be indirectly emitted.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1084
st_texture_cache_bind_weak_notify calls g_clear_signal_handler which
then calls st_texture_cache_free_bind. st_texture_cache_free_bind frees
the bind structure, so by the time g_clear_signal_handler tries to write
bind->notify_signal_id, bind has already been freed.
Fix this by using g_signal_handler_disconnect instead.
This partially reverts 135d178d08
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2334
Some (newer?) GCC versions complain when a g_auto variable isn't
initialized when declared, even when the initialization is guaranteed
to happen before the variable is used or goes out of scope.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2298
Now that Xwayland startup is asynchronous, the function may be called
before X11 is available, resulting in a crash.
Fix this by only managing the tray immediately if we already have an
X11 display, and wait for it to be set up otherwise.
Likewise, unmanage the screen when X11 becomes unavailable.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
Since support for legacy status icons is implemented by extensions
nowadays, they need to undo the call to manage_screen() when they
are disabled.
Right now that means bypassing garbage collection with an explicit
call to run_dispose() on the Shell.TrayManager. That works, but is
rather ugly.
An explicit unmanage_screen() method is a nicer option, and will be
useful to us as well to deal with X11 going away (once Xwayland
crashes don't bring down the entire session).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
NaTrayManager in particular is deeply tied to X11. We currently assume
that X11 support is always available, but that is already not true
anymore - Xwayland startup is now asynchronous.
It will be even less true once we handle Xwayland crashes gracefully.
Start addressing that by not creating the corresponding resources once
and assume they exist for the lifetime of Shell.TrayManager, but make
sure they exist when actually needed.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2308
The g_file_replace_contents_async() API can potentially call fsync() from
the thread calling into it upon completion. This can have disasterous
effects when run from the compositor main thread such as complete stalls.
This is a followup to 86a00b6872 which
assumed (like the rest of us) that the fsync() would be performed on the
thread that was doing the I/O operations.
You can verify this with an strace -e fsync and cause terminal to display
a command completed notification (eg: from a backdrop window).
This also fixes a lifecycle bug for the variant, as
g_file_replace_contents_async() does not copy the data during the operation
as that is the responsibility of the caller. Instead, we just use a GBytes
variant and reference the variant there.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1050
Implement ClutterActorClass.has_accessible() to ensure that CallyActor does not
recreate accessibles during the removal/destruction of an actor. This relies
on GNOME/mutter!1083 for the ClutterActorClass.has_accessible virtual function.
Running GNOME Shell for about 30 seconds results in a difference between
the two runs.
Before:
ALLOCATED TOTAL FUNCTION
[ 52.2 KiB] [ 0.05%] cally_actor_real_remove_actor
[ 36.3 KiB] [ 0.04%] st_widget_get_accessible
[ 9.8 KiB] [ 0.01%] atk_gobject_accessible_for_object
[ 3.2 KiB] [ 0.00%] g_signal_emit_by_name
[ 2.9 KiB] [ 0.00%] clutter_actor_get_children
After:
ALLOCATED TOTAL FUNCTION
[ 1.8 KiB] [ 0.00%] cally_actor_real_remove_actor
[ 1.1 KiB] [ 0.00%] clutter_actor_get_children
[ 659 bytes] [ 0.00%] g_signal_emit_by_name
Obviously 50KiB isn't a huge savings.
Although fixing things to avoid re-entrancy on destruction can be very useful
from a correctness standpoint.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2263
ShellStack implements custom focus navigation, and will only ever
navigate into its top-most child. That kind of makes sense as long
as that child is actually visible, but not when it is hidden.
Descend into the stack to look for a focusable child instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2210
If we modify the paint volume to make it larger and include the blur
radius, we should also use the gained size and draw something there.
Since the framebuffers are only the size of the actor to blur, we're not
doing that right now anyway, so remove the vfunc override.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
Use the shader for linear sampling and incremental calculation of the
gaussian kernel values as it was implemented by Patrick Walton in
webrender.
The sigma value for the blur (the standard deviation) is calculated by
taking the blur radius and dividing it by 3, this value is used by most
implementations of gaussian blurs since it covers a high percentage of
the gaussian shape.
The linear sampling optimization is implemented by skipping every second
texel (i += 2) in the for-loop that's sampling adjacent texels.
https://github.com/servo/webrender/blob/master/webrender/res/cs_blur.glsl38ec7db6f1https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
Floor the downscaled size of the new framebuffer to make sure we don't
initialize a framebuffer with a floating point value that might be
interpreted wrong by `cogl_texture_2d_new_with_size` and end up with a
slightly wrong aspect ratio of the framebuffer.
This fixes situations where the widths or heights of downscaled
framebuffers sometimes miss some pixels at the border.
While at it, remove the `downscale_factor` argument from
`setup_projection_matrix` since that function doesn't need the initial
size of the actor anyway.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/991
The used_scales hash table uses g_double_hash and g_double_equal which
try to read a double from the passed pointers. The pointers however were
pointing to a float, leading to an invalid read.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/974
`gnome-shell-perf-tool` is initially designed to run on X11, using the
`--replace` option which does not work when gnome-shell is a Wayland
compositor.
A solution would be to run `gnome-shell-perf-tool` in place of just
`gnome-shell` to run the entire perf session under Wayland, but the
script `gnome-shell-perf-tool` does not spawn `gnome-shell` as a Wayladn
compositor, so that fails as well.
Add a `--wayland` option to `gnome-shell-perf-tool` so that it can
optionally spawn gnome-shell as a Wayland compositor so the whole perf
tool can be starred from a console with:
```
$ dbus-run-session -- gnome-shell-perf-tool --wayland
```
Alternatively, for testing purposes, it can also be started nested with:
```
$ dbus-run-session -- gnome-shell-perf-tool --nested
```
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2139https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/941
On Wayland, the display server is the Wayland compositor, i.e.
`gnome-shell` itself.
As a result, we cannot spawn `gnome-shell-perf-helper` before
`gnome-shell` is started, as `gnome-shell-perf-helper` needs to connect
to the display server.
So, instead of spawning `gnome-shell-perf-helper` from the perf tool,
start it from `gnome-shell` itself.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/941
For window-backed apps (read: windows we can't match to a .desktop
file), we use the window's icon property as icon. However there is
no such property on wayland (at least in the protocols we support),
so we end up with a blank actor in that case.
Do better than that, and pick a generic fallback icon instead.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1779
Notifying the "text" property inside `st_entry_set_text()` misses all
the text changes done by ClutterText itself, including those that happen
on key-presses. Fix that by notifying that property inside the
"notify::text" handler connected to the ClutterText.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/951
Also show the hint actor of an StEntry while the entry is focused but
has no text inside it. This is part of the new dialog and lock-screen
design where there are no labels before entries anymore and labels are
instead shown as a hint-text of the entry.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/944
set_fallback_icon_name() leaks a GIcon by using the set_icon method
which adds a ref to the GIcon without removing its own ref after calling
the method.
Related to https://gitlab.gnome.org/GNOME/gnome-shell/issues/2146
St has the regular abstractions to handle actors that are bigger
than their parent could handle: StScrollable, StScrollView, and
StAdjustment.
However, the only StScrollable implementation available currently
is StBoxLayout, which forces a ClutterBoxLayout as the layout
manager (and relies on it not being unset).
Introduce StViewport, which is a minimal StScrollable implementation
that doesn't rely on any specific layout manager.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/929
Don't try to create a GIcon if the given icon name is empty, it will
lead to failure when loading the icon anyway, instead set the gicon to
NULL just as we do in the `set_gicon()` API when unsetting an icon.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/888
The brightness property of ShellBlurEffect is of float type, but
we are calling g_value_set_int() in the GObject::get_property()
handler, which throws warnings when trying to set the property
via g_object_set() and family.
Use g_value_set_float() instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/924
This is a moderately fast two-pass gaussian blur implementation.
It downscales the framebuffer dynamically before applying the
gaussian shader, which cuts down rendering time quite considerably.
The blur shader takes 2 uniforms as input: the blur radius; and
whether to blur vertically or horizontally.
The blur radius is treated as an integer in C land to simplify
calculations. The vertical parameter is treated as an integer by
the shader simply due to Cogl not having proper boolean support
in snippets.
At last, brightness is also added to avoid needing to use an extra
effect to achieve that. Brightness is applied in a different pipeline
than blur, so we can control it more tightly.
ShellBlurEffect also implements a "background" mode, where the contents
beneath the actor are blurred, but not the actor itself. This mode is
performance-heavy.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1848https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/864
StScrollViewFade depends on st-scroll-view-fade-generated.c, but
that dependency isn't expressed to the build system; we just hope
that the custom target runs before compiling the effect.
Instead, add the generated source to the st target so the dependency
is expressed properly.
(The change from .c to .h is to prevent the file from being both
included and compiled, resulting in a duplicated symbol)
https://bugzilla.gnome.org/show_bug.cgi?id=789937
The gnome-extensions tool code is really independent from the rest of the
code base, and could be used either as part of the gnome-shell build or as
stand-alone project (for example for the extension-ci docker image).
We can actually support both cases by moving the code to a subproject.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/877
The file was generated when importing gnome-extensions-tool from
a standalone repository. It isn't used by the build system, and
really shouldn't have ended up in the repository at all.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/877
Also introduce a "show-peek-icon" property to enable/disable
the peek-password-icon in the password entry. This is useful
in cases where the peeking the password functionality needs
to be avoided.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
This frees the entry's secondary icon that for other uses.
Caps-lock-warning feedback has been moved to be shown in
the various dialogs instead in the password-entries itself.
StPasswordEntry can now use a peek-password icon as the
secondary icon to show/hide the password present in the
entry.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
StPasswordEntry will be put to use for password entries
in various shell dialogs. This is done to have a consistent
behaviour for all password entries and introduce a peek
password functionality for these password entries in the
subsequent commits.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/619
Use data from switcheroo-control to know which environment variables
to use to launch an application on the discrete GPU. switcheroo-control
version 2.0 or newer should be installed on Linux platforms.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1810
Drawing windows got a lot more involved with the advent of client-side
decorations. Instead of accounting for visible and invisible borders,
titlebar and shadows when necessary, just add an empty child for the
custom drawing.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/887
Mutter and Clutter was changed to pass around the current target
framebuffer via the paint context instead of via the deprecated Cogl
framebuffer stack.
The framebuffer stack has also been removed from Cogl so change to use
the one in the paint context instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/827
While still leaving them unused, pass around ClutterPaintContext and
ClutterPickContext when painting and picking.
The reason for splitting this change up in two is to make it possible to
bisect easier in between the API change and the change to using the
framebuffer passed around with the temporary contexts.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/827
This code didn't even pay attention to the
cur_stmt->kind.media_rule->media_list, and unconditonally considered
each statement in the ->ruleset to be of kind ruleset. That seems
broken.
(The theme doesn't use any @media queries, and they are unsupported
anyway.)
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1979
Since commit 28c535e34, we use the timezone associated with the ICalTime
instead of the default timezone when converting to time_t. However while
that is correct for most events, for ICalTimes that don't have a timezone
associated we still want to fall back to the default timezone instead of
UTC.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1895
We're storing in the texture cache images and scaled images appending
the scaling factor to the key. When a file changes the cache key
corresponding to that file is removed, but not the keys for the scaled
ones so that images in the cache are never reloaded.
This patch removes all keys from the cache related to the file that
changes, including those with the scaling factor.
A new set (hash table) was added to keep track of scale used to be able
to remove all possible images in the cache.
When the KEY is removed from the cache, we can look now in the scale set
for and each scale we also remove the key "KEY1.000000", "KEY2.000000",
etc.
Assuming that the number of used scales is small (I would typically
expect one or two), the overhead should be negligible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/567
When removing a string from a settings list, we iterate over all
existing entries and copy all strings except the one that's being
removed to a new list, which is then written to GSettings.
However we currently always increment the index, so we end up with
a NULL entry in place of the removed entry, which is then interpreted
as the end of the list. In other words, we also remove all entries
that follow the removed string.
Fix this by looping over the list entries instead of the index, and
only increment the index for entries we copy.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1946
Instead of every individual StThemeNode. There are essentially two kinds
of theme nodes: Those we create for lookups, and those interned by the
theme context and used by StWidgets. Listening to the signal on the former
is pointless as they are short lived and not meant to be really used for
drawing. So it is only essential to track stylesheet changes in those we
intern for later use.
This change does precisely that, it lets the StThemeContext track the
stylesheet changes and let all known theme nodes reset their state for
it.
The internal array holding all connected handlers for this signal in glib
was about the biggest single allocation made in gnome-shell, as interned
theme nodes nodes are around the 4 to 5 digit numbers. This essentially
makes it disappear.
This however means that widgets that are explicitly set a theme through
st_widget_set_theme() don't get their theme node implicitly updated.
There's little reasons to use that API, so perhaps this is an acceptable
tradeoff.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/779
A StWidget could get its style from a) a theme set in the StThemeContext,
and b) directly through it's ::theme property. Generally, overriding CSS
through the latter cannot be recommended as it loses any connection with
the global theme (eg. the ones you get through selector specificity).
It sounds a bit too powerful and pervasive, there's no use for it in
gnome-shell and doesn't look like something that could be recommended on
extensions. So, just drop this piece of API.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/779
By now, all containers and layout managers except StBin (and its
subclasses) use the generic ClutterActor expand/align properties
to control how their children are laid out.
This is particularly confusing as two or the properties StBin uses
for layout - x-align and y-align - shadow the generic ClutterActor
ones, but work very differently: They use a different enum and
determine how the bin lays out its child, instead of how the bin
is laid out by its parent.
Address this by deprecating the StBin properties and using the same
generic ClutterActor properties as everyone else.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/803
