Since the removal of the old (pre-3.16) message tray, legacy tray icons
are very unlikely to be placed in a container that is animated using the
deprecated anchor point.
Just assume that the regular stage position is good enough.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/572
If the state we're trying to delete does not exist, do not log an
error.
Prevents this journal warning at startup:
gnome-shell[1082]: Could not delete runtime/persistent state file: Error removing file /run/user/1000/gnome-shell/runtime-state-LE.:0/screenShield.locked: No such file or directory
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/555
Instead of considering a GValue containing a NULL string to be a
programmer error, simply return NULL.
remove_mnemonics() is in fact called on the value of the
"choice-label" property as well, which has NULL as its default
value.
This prevents triggering the following gnome-shell warning:
gnome-shell[1082]: remove_mnemonics: assertion 'label != NULL' failed
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/555
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
A window being unmanaged can cause the ShellApp to be removed from
the ShellAppSystem, which if we are unlucky is the app's last
reference, causing it to be disposed and freed. It would be bad if this
happened before we finished handling the signal.
Use g_signal_connect_object to ensure that a reference is held to
the ShellApp for the duration of the signal handler, delaying its
last-unref.
In particular, when a signal handler calls _shell_app_remove_window(),
there is a brief period for which ShellApp breaks the intended
invariant (see !497) that app->running_state is non-NULL if and only if
app->running_state->windows is also non-NULL (non-empty). Freeing the
ShellApp at this point would cause a crash. This seems likely to be the
root cause of <https://gitlab.gnome.org/GNOME/gnome-shell/issues/750>,
<https://gitlab.gnome.org/GNOME/gnome-shell/issues/822> and
<https://bugs.debian.org/926212>.
Signed-off-by: Simon McVittie <smcv@debian.org>
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
If the locale doesn't honor strftime()'s %c argument, we would end up
feeding NULLs into GdkPixbuf tagging. Fallback to a sensible (although
not nicely localized) datetime string.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1017
Just like we take a remote "new-window" action into account for
opening new windows, we should call an explicit "quit" action
before falling back to closing all the app's windows on quit.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
For window backed apps, create_icon_texture() doesn't return an StIcon
but a generic widget. Set an appropriate style class to make it easier
to apply a specific style only to fallback icons.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1027
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
Since we started to support tray icons on wayland, the icon we show
is not the actual XEmbed window. Instead, we let mutter create a
MetaWindow for it, then use its window actor as source for a clone
we (or nowadays: extensions) can add, remove and destroy freely.
To not let the real icon get in the way, we set an empty input shape
and make its window actor fully transparent. This works OK on X11,
but on wayland all events still go through Clutter, so any reactive
surface actor inside the window actor will block events for any actors
underneath (and status icons go into the top-windows group, so almost
all actors are affected).
Luckily we can pile another hack onto the pile of status icon hacks ...
https://gitlab.gnome.org/GNOME/gnome-shell/issues/191
