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
As per GNOME/mutter!385 [1], the compositor is finalized an its pointer
cleared on display close.
However, since the shell reacts to such events instead of controlling them,
when the shell is stopping or restarting and its display closing, the shell
stage destroys its children after the display closing is finished and during
this process the focus is unset, causing focus_actor_changed() to be called
and thus calls to meta_stage_is_focused() which deferences the now NULL
compositor, leading to a crash on shutdown.
Since after this point we should just ignore any stage event, disconnect
from them all.
[1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/385https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/746
If graphical applications want to start from systemd units, they need to
start after we're properly ready to display them. This is particularly
important under X where `_GTK_FRAME_EXTENTS` and other xprops are needed
to have the right theming.
We're doing this in an idle callback so that the dynamic starting of
`gnome-session-x11-service.target` (which launches `gsd-xsettings`) as
the result of a signal emission happens before us signalling we're ready
for later things to start.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/750
Until commit 506b75fc7f we got away with not handling a NULL return
value, as cairo_surface_destroy() deals with a NULL surface; the same
isn't true for get_width/get_height, so guard to code in question to
prevent a crash.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1678
This is now handled in Mutter. Also, respect the result size instead
of assuming it to be equal to the clip size, as the clip takes actor
coordinates while the result takes buffer coordinates.
This can be fixed in a future API iteration.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/728
We allow opening new windows as a fallback in case the app doesn't give
us explicit information about it, but we don't want to allow opening new
windows if we're unable to ask for this information (we can only use the
APIs to get this information while the app is RUNNING).
So always return FALSE in case the app is STARTING, always return TRUE
in case the app is STOPPED (starting an app always opens a new window)
and go through the usual checks in case the app is RUNNING (and
eventually fall back to FALSE).
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/121
The use of box-shadow on a StWidget that has a background-gradient was
not been rendered correctly, the shadow borders was calculated inside
the st_theme_node_prerender_shadow function and in the case that we've a
prerendered_texture the max_borders was not calculated and are 0.
This patch creates a new static function to compute shadow maximum
borders copying the code from st_theme_node_prerender_shadow, and call
this new method in the case that we've a prerendered_texture.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1186
Evolution draws in libsoup, which exposes deprecated types in its
API. While its headers have been fixed to guard the affected symbols,
those fixes aren't in our CI images yet.
Until we get a fixed version, just disable all deprecation warnings
during the include in order to not trip over "foreign" bugs.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/709
We aren't using any deprecated evolution-data-server API, so we can
turn it off; this avoids compiler warnings for glib deprecations
used by those functions, which makes it harder to spot warnings for
our own code base.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/709
We translate the raw stream content far too directly into a char*,
it notably forgets that the stream does not have nul-ended data,
this means we are potentially adding garbage after the pasted content.
Tentatively fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1570
An Endless OS system was found in the wild with a malformed
.local/share/gnome-shell/notifications. When deserialized in Python,
after passing trusted=True to g_variant_new_from_bytes(), the first
element of the first struct in the array looks like this:
In [41]: _38.get_child_value(0).get_child_value(0)
Out[41]: GLib.Variant('s', '\Uffffffff\Uffffffff\Uffffffff\Uffffffff\Uffffffff')
When deserialised in GJS, we get:
gjs> v.get_child_value(0).get_child_value(0)
[object variant of type "s"]
gjs> v.get_child_value(0).get_child_value(0).get_string()
typein:43:1 malformed UTF-8 character sequence at offset 0
@typein:43:1
@<stdin>:1:34
While g_variant_new_from_bytes() doesn't have much to say about its
'trusted' parameter, g_variant_new_from_data() does:
> If data is trusted to be serialised data in normal form then trusted
> should be TRUE. This applies to serialised data created within this
> process or read from a trusted location on the disk (such as a file
> installed in /usr/lib alongside your application). You should set
> trusted to FALSE if data is read from the network, a file in the
> user's home directory, etc.
Persistent state is read from the user's home directory, so it should
not be trusted. With trusted=False, the string value above comes out as
"".
I don't have an explanation for how this file ended up being malformed.
I also don't have an explanation for when this started crashing: my
guess is that recent GJS became stricter about validating UTF-8 but I
could be wrong!
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1552
Instead of going via the MetaShapedTexture to get the cairo surface, get
it from the window actor. The window actor can then handle this in a way
that makes it include potential subsurfaces.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/692
Using the bus name to notify service startup to systemd has some
disadvantages. The main one being that systemd will consider a
gnome-shell restart (Alt+F2 r) a service failure and restart the shell,
cleaning up all its children (i.e. user launched applications). In the
future the shell should launch applications in their own transient unit
so that a service restart does not affect applications.
Another potential issue is that we must never load
gnome-shell-wayland.service and gnome-shell-x11.service at the same
time, as systemd does not like two services providing the same bus
name.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1496https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/690
Mutter's Clutter fork can no longer be initialized separatedly, as
its backend now draws from MetaBackend. Adjust the code to use the
newly added test initialization function instead to get the test
back up.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/691
Clutter's backend code depends on MetaBackend now, which makes it
impossible to initialize without resorting to private mutter API.
Luckily we only need Clutter for interactive tests which are broken
anyway, as Clutter.main() and friends were removed a while ago.
So for now, get at least unit tests working again by simply the
unnecessary Clutter initialization.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/691
Popups and other override-redirect windows are meaningless to everything
that depends on the ShellWindowTracker. Ignoring those windows will result
in less ShellApp::windows-changed signal emissions, and less activity in
the AppMenuButton and everything else that depends on them.
Reduces gnome-shell CPU activity while typing on the Epiphany addressbar,
as the pop up animation there results in a number of xdg_popup being
created and destroyed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/642https://gitlab.gnome.org/GNOME/mutter/issues/556
Now that we allow to disable session mode extensions, it can be useful
to reset an extension to its original state, that is disabled in the
regular session, but possibly enabled via the session mode.
Add a corresponding command.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
Change both 'enabled-extensions' and 'disabled-extensions' keys as in
commit ce1bee727. While those actions are now also exposed by the
shell's D-Bus API, there is some value in allowing the tool to be used
outside a running GNOME session (for example in setup scripts), so
keep changing the GSettings keys directly.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
With the addition of the 'disabled-extensions' key in commit ce1bee727,
the way extensions are enabled/disabled changed: Now a UUID is always
added to one list and removed from another.
Prepare for that by generalizing the relevant bits of the existing
enable/disable commands as helper functions.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
The ability to install unaudited extensions directly from a zip file
can be useful for testing and code review, so implement a corresponding
command that complements the previously added 'pack' command.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
Extensions are uploaded to extensions.gnome.org as zip files that
not only contain the extension sources, but also compiled GSettings
schemas and message catalogues. To make this more convenient, add
a corresponding command for creating an archive suitable for up-
loading.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
We already support displaying extension details for the list command,
so it's a logical extension to also support showing extension info
for a particular extension (not least because the shell has a
corresponding D-Bus method).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
In addition to a plain list of all extensions, add options to display
additional details of each extensions and to filter the list by
enabled state or install location.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
This implements more functionality of the existing tool and, as
'reload' is an unreliable feature that doesn't work more often
than not, the last bit that we will replicate.
The command follows the original for the most part, with the most
important difference being the installed template, which doesn't
provide any sample functionality and uses modern JS syntax.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
This replicates the most basic functionality of the existing
gnome-shell-extension-tool, albeit using a git/gio/gsettings
style command interface rather than plain options; this will
allow us to implement more complex commands that have options
on their own in the future.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1234
