The calendar's timezone cache holds only timezones already received
or added to the calendar, thus when asking it for a timezone for "the first
time", it returns NULL and a wrong timezone is used instead.
The get_timezone() does not do any I/O when the timezone is already cached
on the client side, thus it's fine to use it.
This could exhibit with non-recurring events, which use custom time zones,
in which case the event is shown in a wrong time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2145>
The cursor texture, scale and position is captured separately and
overlaid on top of the preview, and on top of the final screenshot
image. This allows toggling it on and off post-factum.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
As mentioned in the last commit, we'll split up taking screenshots into
creating a GPU texture first, and later saving that to disk as a PNG.
For individual windows it's already easy to get a ClutterContent with
the texture using meta_window_actor_paint_to_content (), for the stage
it's not that easy and involves a few extra steps including X11 specific
ones.
So introduce a new ShellScreenshot API which does all that and provides
the caller with a ClutterContent of the stage:
shell_screenshot_screenshot_stage_to_content ()
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
With the new screenshot UI we're introducing, we'll be capturing all
screenshots to textures on the GPU at first, and then create a PNG
stream from those textures at a later point. This will allow us to
present screenshots immediately to the user so they can inspect them and
select the right area before actually saving them to disk.
As a first step to make this work, introduce a new ShellScreenshot API
that writes an existing CoglTexture to a PNG output stream:
shell_screenshot_composite_to_stream ()
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1954>
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>
Since commit 1807be1, we clear the fallback icon when a window is
removed, and notify the icon change. The notify call currently
happens after removing the window from the running state, but
before syncing the state (and possibly clear the running state
altogether).
That state is inconsistent and results in an assertion hit when
some code tries to re-fetch the icon in response to the notify
call.
Address this by updating the state before clearing the fallback
icon, so that the app will be in the correct STOPPED state after
removing the last window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4888
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2073>
We were not properly tracking the window used for the fallback icon.
This could trigger a crash, as disconnection of the signal handler might
happen on the wrong window, which in turn could cause the icon change
notification to happen on a destroyed ShellApp instance.
Fix this by tracking the window used for the fallback icon. Disconnect
the icon notify callback explicitly for this window only when it is
removed.
Also, just to be extra safe, make sure that the icon is never NULL even
if x11_window_create_fallback_gicon should return NULL for some reason.
Closes: #4436
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2065>
We currently track windows via MetaWorkspace's ::window-added and
::window-removed signals. Those aren't emitted for override-redirect
windows though, as those aren't actually located on any workspace
(see https://gitlab.gnome.org/GNOME/mutter/-/blob/gnome-41/src/core/window.c#L1322).
While that shouldn't be an issue as there's no good reason to look up
the ShellApp of an OR window, extensions can make modifications that
result in OR windows ending up in places that assume that every window
has an associated ShellApp.
We can either
- accept that extensions break stuff (including badly)
- carefully handle app-less windows everywhere
- extend tracking to OR windows
Opt for the last option, as that's the most user-friendly and least
disruptive one.
It's also simpler to track ::window-created and ::unmanaged, as we
don't have to track workspaces or windows moving between workspaces.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4751
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2029>
The window-type property may change, and with it the skip-taskbar
property that decides whether we consider it "interesting".
As a result we can end up showing untracked window, i.e. one
which does not have an associated app.
Cover this case by simply tracking all windows regardless of
their type. This won't change the app's running state, as that
is solely based on the skip-taskbar property (which is enforced
for all previously excluded window types).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4751
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2029>
The way it is currently calculated is broken for days with DST changes
or leap seconds and it is not needed anymore anyway. This will also make
the fix in the following commit simpler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2023>
Windows from some applications, such as guake, are created as showing on
all workspaces. When these windows are put on the workspaces via
set_workspace_state() during construction, the first time the window is
added to a workspace in the loop triggers the shell app tracker which
then tries to move the window to its startup workspace. This makes the
window unsticky which triggers another set_workspace_state() which
tries to remove the window from all workspaces, but currently it is only
on the first one and then adds it to the startup workspace. Once that is
finished, the first set_workspace_state() continues adding the window
to the remaining workspaces, despite the window now no longer having
on_all_workspaces set to true.
When the window is now unmanaged, the window according to its internal
state is only found on the startup workspace, so it will only be removed
from that. This causes the assertion to fail that checks that the window
is no longer present on any workspace after this.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4720
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2014>
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>
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>
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>
We'll likely have to interact a bit with the newly added Meta.Context
object, so add a convenience property that gives us direct access
instead of getting it from the display every time we need it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1917>
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>
`mallinfo` has been deprecated in favor of `mallinfo2`:
```
The fields of the mallinfo structure that is returned by the
older mallinfo() function are typed as int. However, because
some internal bookkeeping values may be of type long, the
reported values may wrap around zero and thus be inaccurate.
```
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1786>
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>
When a GTK app is started, we create a corresponding GtkApplication
proxy to monitor the app's busy state. If the app is stopped before
the proxy request finishes, we cancel the cancellable before clearing
the running state.
Usually we clear the cancellable once it is no longer needed, namely
when we got the proxy. However when the request was cancelled, the
cancellable has already been cleared, and if there's a cancellable,
it belongs to another request (because the window was added again,
for example when moving between monitors).
Leave that cancellable alone in that case, so we can cancel the
second request as well if necessary to avoid a crash when trying
to set the proxy on a cleared running state.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1962
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1885>
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>
app_notify_events_added uses an intermediate builder to construct an
array that is then added to the main variant using g_variant_builder_add
which should clear the intermediate, but doesn't due to the way it is
passed: by value, rather than as a pointer.
This was debugged with the help of Eduardo Habkost, who believes it
works on x86 due to big structs being passed as pointers.
Fixed: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3440
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1848>
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>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop this from our logging function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1770>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop this from our logging function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1770>
Since commit 770231, StImageContent implements the GIcon interface, which
allowed us to represent all application icons as GIcon (app-info, X11 icon
property or themed fallback icon).
While that change made for a nicer ShellApp API, it did introduce a
conceptual issue in st_texture_cache_bind_cairo_surface_property():
GIcons usually represent static icons, while the ClutterContent
returned by that method updates automatically when the bound property
changes.
Address this by tracking the MetaWindow:icon property in ShellApp, and
update the fallback icon when it changes. With that, a GIcon object
always represents the same icon, and any icon change is reflected
by a corresponding GIcon change.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
We hold a reference to all windows we track for the app. While that
reference is unlikely to be the last remaining one, we still shouldn't
release it until we are done with the window.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
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>
We create a lot of BaseIcons for the appGrid, one for every app, and for
all of those we have to hop through JS to get the preferred width. That
makes it another obvious target for moving to C, so let's do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1755>
Move the get_preferred_width/height() and allocate() vfunc
implementations of WindowPreview to C, subclassing the C GObject from
JS.
This gets us another significant performance gain, allocating a
workspace with 20 windows now only takes 1.2 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
This layout manager is used quite often and the time we spend calling
it's allocate and get_preferred_width/heigth functions increases with
every open window.
We can save a lot of precious time during the layout cycle by moving
this layout manager from JS to C, thus avoiding the overhead of
trampolining between C and JS land.
In a measurement where the average time spent in vfunc_allocate() of the
Workspace actor was measured while opening an overview with 20 windows,
the average time spent went down from 3.1 ms to 2.3 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1743>
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>
Changing the workspace of a window causes the window tracker to remove
and add it to the app again. If this happens from within
_shell_app_add_window() before the window has been added to the windows
list, this will cause the check that is supposed to prevent adding the
same window multiple times to fail and the window to be added twice.
The app will then be considered still running after the last window has
been closed. Then when clicking on the corresponding app icon, the shell
would attempt to switch to a NULL workspace for the closed window
instead of starting a new instance, resulting in a crash.
Changing the workspace also needs to happen after increasing the
interesting window count, because otherwise removal of the window by
the window tracker would trigger a uint underflow leading the app to be
considered running with UINT_MAX interesting windows, despite having no
windows, leading to crashes right after launching the app.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3833
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1745>
Launching applications on a particular workspace works through
launch contexts and startup notifications. While this is no
longer required by a launcher/WM split, in theory this allows
us to reliably identify the correct window to apply startup
properties to.
However in practice we fail more often than not: Missing support in
toolkits, differences between display protocols, D-Bus activation
and single-instance applications all provide their own pitfalls.
So instead, take advantage of the fact that launcher and WM live in
the same process, and go with the unsophisticated approach: Just
remember the last workspace that was requested when launching an
app, then move the next window that is associated with the app to
that workspace.
This will break X11 applications that set an initial workspace, but
that's legacy functionality anyway (given that there's no wayland
protocol for that functionality), and seems a price worth paying
for making launching apps on workspaces more reliable.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1316>
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>
Instead of taking just vertical/horizontal offsets, take a ClutterMargin
to allow us set the fade offsets on each direction specifically. Also,
handle negative values in margins, the fade effect will run in the negative
space left by the scrollview padding instead. Another difference now is
that areas outside the extents of the effect will be transparent, instead
of the effect ending abruptly past the given extents.
This will be used by the app grid, in order to selectively let see either
of next/prev pages while navigating.
While at it, fix code style issues in st_scroll_view_update_fade_effect(),
and clean up unused variables from the GLSL code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
This property controls whether the viewport clips the content to its own
allocation or not. This will be necessary in special modes that we want to
render past the viewport inside a scrollview.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1630>
When we're painting off-stage, for example because we're screencasting
or taking a screenshot, there won't be a stage-view associated with the
paint context. The BlurEffect previously didn't handle that case and
would crash.
Fix that and handle that case by assuming the scale is 1 and not
offsetting the rectangle we blit from the draw framebuffer.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1673>
Add a "screenshot-taken" signal from the screenshot service's internal C
implementation, and use that to trigger the camera flash visual effect
and the click sound, allowing them to run in parallel with the PNG
compression instead of waiting until the file is complete to start.
This significantly improves perceived latency on high res setups such as
4K, 5K, or dual 4K screens.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/512
Co-authored-by: Brion Vibber <bvibber@wikimedia.org>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1658>
Commit 473e77e2c5 fixed applying the :insensitive pseudo class to
initially unreactive widgets, and adjusted the style test to work
with that.
In hindsight, we can do better than just making the test work, and
include a test case for the :insensitive styling as well (namely
the issue the previous commit was fixing).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1649>
We are applying the :insensitive pseudo class to unreactive widgets,
or at least we are supposed to. As we currently only update the style
on notify, we don't apply it to initially unreactive widgets.
This was covered up partially until recently when Clutter started to
use G_PARAM_EXPLICIT_NOTIFY. Before that, the notify handler would run
when explicitly setting :reactive to FALSE at construction time.
Make sure we always apply the pseudo class correctly by updating it
after construct properties have been set.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3685
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1648>
We want to use the fast path of filling the entire area if either the
left and right shadows would overlap or the top and bottom shadows. The
latter check was wrong due to a typo resulting in the regular path
being used in some cases it couldn't (and shouldn't) handle.
This was causing the inset shadow used to highlight panel buttons to
not appear for buttons above a certain width.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1646>
The shader code currently only accounts for padding for the
bottom and right fades, but not for top and left.
As a result, we only fade the right edge when swiping through app
picker pages, whoops.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1569>
