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
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
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
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
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
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
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
Whenever an app is installed, the usual routine is
to run 'gtk-update-icon-cache' after installing all
of the app's files.
The side effect of that is that the .desktop file of
the application is installed before the icon theme
is updated. By the time GAppInfoMonitor emits the
'changed' signal, the icon theme is not yet updated,
leading to StIcon use the fallback icon.
Under some circumstances (e.g. on very slow spinning
disks) the app icon is never actually loaded, and we
see the fallback icon forever.
Monitor the icon theme for changes when an app is
installed. Try as many as 6 times before giving up
on detecting an icon theme update.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/661
The texture cache, right now, only monitors for
complete theme changes. If the contents of the
icon theme change, however, the texture cache
isn't properly invalidated.
This manifests itself as a randomly reproducible
bug when installing an app; the app icon may be
the fallback forever, or as long as something else
updates the icon theme.
Watch for the GtkIconTheme:changed signal, and
evict the texture cache when the theme changes.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/661
StAdjustment implements the ClutterAnimatable interface, so we can
already animate its properties with ClutterPropertyTransitions.
But as it is currently not possible to associate a transition with
an adjustment, it must be owned (and kept alive in case of GC) by
the calling code.
Change that by implementing the same (add|remove|get)_transition() API
as ClutterActor, so we can use a familiar API and even duck typing in
case of javascript.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/669
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. For this reason, always try to use
`g_object_notify_by_pspec()` instead.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/652
In `st`, we can do this by using `ST_PARAM_*`. In the other code files,
just use `G_PARAM_STATIC_STRINGS` directly.
This is just a minor convenience to prevent a few unnecessary string
copies.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/646
st_theme_node_paint_equal() was originally added to preserve paint state
when a style change didn't affect any of StWidget's cached background
resources.
That's why using it for filtering out unneeded style changes as in commit
f662864a misses any non-background related properties that are relevant
for subclasses. Add additional tests to make sure we keep emitting the
signal in those cases.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1212
This is a small convenience wrapper around clutter_color_equal()
for the different color components, which also handles the case
where one (or both) of the icon colors are %NULL.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1212
Since priv->device gets set to NULL inside st_button_release, ungrab the
input device before calling st_button_release and avoid
clutter_input_device_ungrab failing with a critical error.
This fixes a regression introduced with
d5a1a888d9
While at it, also remove the superfluous line resetting priv->device to
NULL and move the check for priv->grabbed into an elseif block since
there should be no case where StButton has both grabs at the same time.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/614
Util.ensureActorVisibleInScrollView takes care of the potential scroll view fade
effect in order to compute the scroll offset, reading the ScrollViewFade's
`vfade-offset` property. This was correctly working until gnome 3.30 cycle.
However such property isn't defined now because since gjs 1.54, it can only
fetch introspected properties and St.ScrollViewFade was considered a private API
not exposed by gir.
Fix this by also introspecting st-scroll-view-fade sources.
Not being considered private anymore, install the header.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1061
Updating the :first/:last-child pseudo classes can result in a lot
of unnecessary style changes when bulk-adding children to a container,
as every child ends up as the new last child.
Address this by deferring the style change to an idle, so we only do
the work once for the actual first and last child.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/529
Images are loaded either with a supplied fixed size, or using the "native"
dimensions of the file. When creating a content image from the loaded data,
we currently simply apply this directly to the preferred size.
This works usually fine: GdkPixbuf will always keep the aspect ratio, so
if only one dimension is provided, the other will be adjusted accordingly:
Loading a 200x200 image with a requested size of (100, -1) will result in
a 100x100 content image.
There is a catch though: GdkPixbuf will only scale *down* to the requested
size, no up. That is, loading a 100x100 image with a requested size of
(200, -1) will result in a 100x100 pixbuf. But as we assume that the pixbuf
size matches the requested size, the image content ends up with 200x100.
Fix this by explicitly handling the case where only one size was supplied,
and make the other dimension take the aspect ratio into account
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/525
The parameters that may affect the icon on ::style-changed are more size
related than visual (we listen to icon theme changes for the latter). It
makes sense to just update the icon if the size came out different.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/524
With a high enough amount of actors, there may be enough theme nodes and
signal connections on StTheme::custom-stylesheets-changed that
g_signal_handlers_disconnect_by*() on dispose becomes expensive, this may
become a surprisingly hot spot in StWidget::style-changed.
Keep the handler ID around and use g_signal_handler_disconnect() to avoid
linear lookups for the matching func/data.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/524
Compare painting/geometry of old and new paint nodes, so it's ensured to
be only emitted on actual style changes. Emission still must be propagated
through to children, though.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1153
Actors themed through CSS should ideally get sizes and positions that
conform to the "pixel grid". A notorious example is the panel that has a
height of 1.86em. On unchanged font settings and hidpi that translates to
55px, which leaves the workarea with "half pixels" that hidpi wayland
applications don't know how to fully cover.
If the requested height is a multiple of the scale factor, the workarea
and maximized applications can then work on full pixels.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/91
The same code for reading the current magnifier state is repeated in both
shell-recorder, shell-screenshot and magnifier itself.
So to move this inside a property of st-settings so that we can refer to it
all over the places removing duplications.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/473
With StImageContent, the meaning of passing -1 as size parameter changed
from "load the image at its preferred size" to "abort the session". It
is therefore no longer possible to just load the image and then have it
scaled by applying a CSS size to the texture's parent.
Setting the size from CSS is useful though, so to still allow that, fall
back to the actor's size (which can be determined by the style).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1027
We need this to run `test-theme`, otherwise when run as part of the
build tests it fails like:
error while loading shared libraries: libmutter-cogl-4.so.0: cannot
open shared object file: No such file or directory
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/442
The executable is assumed to be run from $top_srcdir/src, which is
essentially an autotools left-over (it's where the program ended
up with srcdir == builddir).
Now with meson, its actual srcdir makes more senses.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/419
Clutter no longer hard-codes a resolution of 96 DPI (although that's
still the default), so any assertions of sizes for physical units
may be off.
Fix this by setting up the test environment according to the
assumptions.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/419
While mapping the :first/:last-child pseudo classes directly to the
ClutterActor:first-child/:last-child properties allows for an easy
implementation, it is unexpected that rules can appear to not have
an effect because the selected child is hidden. GTK's behavior of
applying the classes to visible children makes much more sense, so
change our implementation to do the same.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/312
It might happen that the target clutter actor that we return on call
of st_texture_cache_load_sliced_image might be destroyed while the
loading task is still running. To protect from this, let's connect
to "destroy" signal and when this happens we use a cancellable to
stop the task.
This allows to safely reuse the return value of this function to
cancel the execution and avoiding that load_callback is called
even for a request that is not anymore under our control.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When loading an actor for a sliced image actor, we can now use the
REQUEST_CONTENT_SIZE request-mode for the actor since we the content image
has now a predictable size and thus we can be sure that the size will be applied
taking care of the resource scale.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Create StImageContent as a simple ClutterImage with preferred width/height
properties in order to be able to use explicit sizing when creating clutter
contents that will be applied to actors whose size depends on the content itself.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Instead of just passing a scale when getting a cached icon, pass both a
'paint_scale', the scale of which the icon will be painted on the
stage, and a 'resource_scale', the scale of the resource used for
painting.
In effect, the texture size will use the scale 'paint_scale * resource_scale'
in a ceiled value while the size of the actor will use 'paint_scale' when
determining the size.
this would load a bigger texture, but the downscaling would keep the visual
quality.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=765011
Create the surfaces for background shadows at scaled sizes and then draw on them
using logical coordinates, by setting the surface device scale accordingly.
Use the said surface scale when generating the actual shadow cairo pattern
but in such case, to reduce the number of code changes, is better to work in
absolute coordinates, and to do so:
1) Create a temporary shadow-spec copy with scaled values to absolute sizes
2) Invert the scaling on the shadow matrix
3) Do the actual painting in absolute coordinates
4) Set the shadow matrix scaling back to the logical coordinates.
Finally scale down the created shadow pattern surface size when painting it,
applying again a reverse scale to the matrix.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Pass resource-scale to drawing phase, and use it to create texture
surfaces scaled with the widget current scaling.
Also redraw by default widgets when the resource scale changes.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
A fractional resource scale would mean we never use the fast path for
creating the shadow, because we'd cast the int to a float before
comparing, which would never match.
Instead compare the expected texture size with the source texture, to
actually potentially trigger the fast path.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
The fade shader will draw the fade effect up until the border pixel. If
we set the bottom right coordinate to the outer edge of the pixel we
might end up not drawing the fade effect on all of the pixels. This
could for example happen if one logical pixel (clutter stage pixel)
consists of more than one physical pixel.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
This commit makes StWidget manage the scale of which its associated
resources should be multiplied with. The resource scale is calculated
by clutter, and is retrieved by clutter_actor_get_resource_scale(). Due
to the resource scale not always being available, the getter may fail,
and the actual widget that draws the content will have to deal with
this situation.
As the resource scale depends on where on the stage the widget is drawn,
the resource scale will in general be available once the widget is
mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Since commit deec0bf255, the texture cache is based on ClutterImage
rather than ClutterTexture. As ClutterImage (like all ClutterContent)
is only concerned with painting, it doesn't influence the size of the
actor it is added to at all, and the returned actor will now stay at
size 0x0 after the image has been loaded.
Set up the actor to follow the content's size instead, to get closer
to the previous behavior.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/402
