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>
- 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>
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>
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>
commit 8721c5db37 made StPasswordEntry
honor the 'disable-show-password' setting.
Unfortunately, it introduced a lifecycle bug where the signal handler
for noticing setting changes can out live the entry itself.
This commit fixes the problem by using g_signal_connect_object
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2004>
Icons that are changed while an actor is not mapped may not have a theme
node associated with, and thus we'd end up not updating them at all.
In fact we return early in st_update_icon(), and this was not an issue
until commit 0b1dfbf6f3, because we'd end up to update the icon anyways
once the style was changed (and so with a valid theme node), but since
such change we might not updating the icon if no theme detail changed.
To prevent this, add a flag to require an icon update when the theme
changed, if no successfully update happened earlier.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4568
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1983>
St's theme test now requires the libmutter-test library, which is only
built when tests are enabled. Instead of mandating a particular build
configuration in mutter, add a corresponding option in gnome-shell as
well.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1975>
If an actor is not on any stage view, then it doesn't have a valid
resource scale, which will hit an assert later.
When that is the case (for example when running headless), we expect
that there is no valid theme node (yet) either, so simply moving
the clutter_actor_get_resource_scale() call after peeking at the
theme node is enough to avoid the crash.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4522
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1935>
There's now a setting
org.gnome.desktop.lockdown disable-show-password
that ostensibly lets admins prevent from users from
showing their password in password dialogs.
gnome-shell currently ignores this key.
As a first step, this commit adds the setting to StSettings.
Future commits will use the new setting.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/687>
Most of the keys are aligned, but "screen-magnifier-enabled" isn't.
This commit lines all the keys up, giving a little more breathing
room for future keys that have longer names.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/687>
Since we correctly call the `style_changed` vfunc superclass at the end
of our own function anyway, the style changes will get propagated to the
children of the scrollView inside `st_widget_real_style_changed` anyway.
So remove those unneeded and quite expensive (because they cause the
theme node to be regenerated) calls to `st_widget_style_changed`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/953>
Properly compare the new icon properties of StIcon to the old ones on
style-changes and only update the icon texture in case something
changed. This should help reduce the amount of texture cache requests
when we start emitting all "style-changed" signals again.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/953>
This makes it easier to track size changes when the paint scale changes,
since in those cases we basically want to do the same thing as when the
normal icon size changes: Request a new texture from the cache.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/953>
This ports over gnome-shell and the theme test case to MetaContext,
instead of the various functions that were available before.
The test case is changed to use the special test context, used to
construct contexts for testing. It's part of a shared libary separate
from the main libmutter one.
This enables building mutter tests during CI, as the test framework is
needed by some of gnome-shell's tests.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1840>
Until now, the absence of a `background-color` would cause `box-shadow`s
to be invisible. That was a bug because `box-shadow` is meant to be either
the color specified in `box-shadow`, or if none was specified then the
foreground `color`.
There is nothing in the spec that says the `box-shadow` rendering should
depend on `background-color`, so separate them. This ensures `box-shadow`
is rendered even when `background-color` is absent or transparent.
https://www.w3.org/TR/css-backgrounds-3/#box-shadow
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1904>
From [the spec](https://www.w3.org/TR/css-backgrounds-3/#shadow-blur):
> the resulting shadow must approximate (with each pixel being within 5%
> of its expected value) the image that would be generated by applying to
> the shadow a Gaussian blur with a standard deviation [sigma] equal to
> half the blur radius
This does not change the value of `sigma`, it only corrects the value of
`sampling_radius` used to size the shadow texture. Since the texture is
no longer being slightly oversized it won't get scaled down when rendered
according to the dimensions provided by `st_shadow_get_box` in
`_st_paint_shadow_with_opacity`.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4409
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1897>
Having an inaccurate paint volume didn't matter until ae338af1e8, but
after that having too small a paint volume resulted in apparent clipping.
Not because `clip_to_allocation` is set, but because the offscreen
framebuffer is sized to fit the paint volume only.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1897>
Not when the main actor dimensions change. So now the shadows don't get
constantly regenerated during the overview animation. In my case this
reduces the render time of the overview animation (tapping Super) by
approximately 10% with 2 windows, or 20% with 10 windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1869>
We do notify on the ::pressed property after touch begin/end and
recording the event sequence, but we do not return the correct value
if the button was triggered via touch.
Consider the event sequence also in the ::pressed getter, so the
button is considered pressed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1774>
Since commit f60a469a34, everything outside the fade area is painted
fully transparent. That is required for the fade effect during app
grid navigation, to prevent unfaded parts of surrounding pages
becoming visible on wide-screen displays.
However in most other cases, that behavior is the exact opposite
of what we want: Elements outside the fade area (like scroll bars)
should never fade.
In order to fix the regular case, hide the new behavior behind a
property.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4234
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1831>
With commits fab39bbea5 and
62e40a1350 we started depending on a new
ClutterActor API: clutter_actor_invalidate_paint_volume()
Given that this commit was applied to the 40 stable release, it broke
ABI compatibility with mutter, which is something we guarantee between
stable releases. So use GModule to dynamically find the symbol in our
loaded libraries. If it exists, use it and invalidate the paint volume.
If it doesn't exist, libmutter is still at version 40.0 and we don't
need to invalidate the paint volume.
This also adds a dependency on gmodule. We need to link against gmodule
to use g_module_open() and g_module_symbol() APIs.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1807>
StWidget is overriding ClutterActors get_paint_volume() vfunc to adjust
for overpaint of things like box shadows that get set in CSS, it does
that by setting the paint volume to the theme nodes paint box.
Since StWidget can't really get notified when the paint box changes, we
just invalidate the paint volume when the theme nodes paint_equal()
returns FALSE.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1484>
Since StViewport uses the value of the StAdjustment to create its custom
paint volume, ClutterActors newly introduced proper caching of paint
volumes doesn't get notifed about changes to that paint volume and will
simply reuse the cached old one.
So make use of the newly introduced
clutter_actor_invalidate_paint_volume() method to make sure ClutterActor
will ask for the paint volume again on the next paint.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1484>
Creating a content object from a cairo surface may fail, in which case
we return an empty content with a 0x0 preferred size.
However when we treat such a content object as GIcon, we happily load
it anyway. Don't do that, so consumers like StIcon can fall back properly
to an alternative.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
While most GIcons passed to this function cause a StImageContent to be
created with the requested size, cairo surface based icons already are
passed as StImageContent with a preferred size corresponding to the
size of the surface they were created from. As a result icons of window
backed applications were never scaled up like the other icons. Fix this
by ignoring the content size for these case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1751>
This is how the code works and how it is already used from the C side.
There would also be no point in keeping this transfer none, because
textures generated from this function will not be shared and are not
kept in the cache.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
This reverts commit 87558efbf1.
The commit did not fix the bug it was supposed to fix, it just
complicated the code. The hopefully correct fix is in the previous
commit.
The point of this commit was to ensure everything gets removed when
bind->source gets removed. This however was already the case since the
signal handler was already connected to bind->source and has a
destructor registered that takes care of everything. And since gobject
destroys its signal handlers before it clears the weak refs, this new
weak ref was effectively never being used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
If the icon surface of a window got updated and its type or format no
longer match what we expect, st_texture_cache_reset_texture() might
overwrite the existing image in the bind with a new image, while still
keeping the weak ref on the old image. Due to this the old image might
trigger a st_texture_cache_on_pixbuf_notify() after the bind has already
been freed by g_signal_handlers_destroy() in the bind source. While this
usually would remove the weak ref, the weak ref it tries to remove is
on the new image, not the old one. The call to
st_texture_cache_on_pixbuf_notify() then tries to read the already
free'd memory from the bind which causes the cast to G_OBJECT to fail,
resulting in the crash.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3785
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
This will be needed for fine tuning of the visible area for appGrid
navigation purposes. We most nominally can let it happen via CSS as
the size calculations happen on size allocate, so we want to avoid
triggering relayouts while adapting to the given size.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
