The callback would schedule a clutter_actor_destroy() on the first
argument. Unless told otherwise, this is the same actor that is
already being destroyed, so this is a no-op.
Instead, the intent is to make the clone follow up destruction of
the window actor so that it results in correct removal of this
window from the ShellWindowPreviewLayout. Use a swapped connection
to pass the clone actor as the first argument of the signal callback.
Fixes: 04c781674c ("Move WindowPreviewLayout from JS to C")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6570
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2756>
(cherry picked from commit 356bab1121)
If we have multiple desktop ID's that share the same startup-wm class
and none of them is actually matching the desktop-id, then we should
exclude the ones that should not be shown in the current desktop.
This will help preventing cases such as the previous one in case no
desktop file ID would match the startup-wm-class exactly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721>
(cherry picked from commit 12bb3a601d)
When fetching the desktop ids into a map of startup-wm classes we meant
to give the ones that match the desktop ID more priority, however
this did not happen because we were always comparing a desktop
file id, including the `.desktop` suffix, with a wm-class that generally
does not include that.
This is the case of gnome-system-monitor, that provides two desktop
files, one of which is OnlyShowIn=KDE but both have the same
StartupWMClass and thus the first parsed is preferred, even though its
desktop-id is gnome-system-monitor-kde.
As per this, remove the .desktop suffix when comparing it with the
startup-wm-class, keeping the old check just in case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721>
(cherry picked from commit e7a09946ca)
Since commit a1d650ce27, window title changes are listened for in the
ShellWindowTracker in order to emit ::tracked-windows-changed when
there are window title changes.
The rest of the things that happen in between (removing the window
from a ShellApp, possibly have it destroyed, and possibly creating a
new ShellApp to re-insert the window) are superfluous and even result
in the altTab switcher popup ending up confused about the applications
available.
Only emit the signal so changes can be followed on D-Bus, but avoid
the ShellApp fiddling otherwise.
Fixes: a1d650ce27 - window-tracker: Emit 'tracked-windows-changed' on title changes
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6385
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2634>
(cherry picked from commit 41c91c7a3b)
This means the screen share window view gets updated also when the title
of a window changes. This is important since it often changes shortly
after mapping, which would otherwise go unnoticed by
xdg-desktop-portal-gnome.
An example is launching Files and it showing up as 'Loading..', or
launching a terminal, and it not showing the proper title (current
directory), but some place holder that is never visible on the
application window.
Adding it to the window tracker instead of in introspect.js itself is
for convenience - there is no per window signal tracking there, and it
already listens to the signal emissions about changed windows.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2578>
(cherry picked from commit a1d650ce27)
Commit 9168f6055e marked the parameter as nullable, which is in
conflict with the precondition check. But given that NULL is
valid for the underlying ClutterText (and GtkLabel accepts it
as well), there's no strong argument for disallowing NULL, so
remove the precondition check.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2465>
Only when part of it is actually visible.
Because the central rectangle is generally the largest part, this
eliminates most of the shadow's render time. For example, animating
`.workspace-background` by tapping Super, the shell's overall render
time is reduced about 15%.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1915>
WorkspaceBackground's allocate is a hot function called every frame
during overview animations. Port it to C.
While we're at it, cache the work area and the monitor geometry, which
do not need to be re-fetched on every allocation.
This reduces the average WorkspaceBackground allocation time from
0.134 ms to 0.017 ms. With four workspaces, scrolling the overview sees
an average WorkspacesView allocation time improvement from
1.104 ms to 0.678 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2394>
The iterator was pointing to NULL when going out of scope, leading to
autofree not clearing the list.
==300183== 32 bytes in 2 blocks are definitely lost in loss record 14,798 of 38,939
==300183== at 0x484586F: malloc (vg_replace_malloc.c:381)
==300183== by 0x4D7D980: g_malloc (gmem.c:127)
==300183== by 0x4D95AB3: g_slice_alloc (gslice.c:1074)
==300183== by 0x4D96D96: g_slist_prepend (gslist.c:282)
==300183== by 0x487854F: shell_app_get_windows (shell-app.c:794)
==300183== by 0x48791A1: shell_app_get_pids (shell-app.c:1201)
==300183== by 0x488B293: shell_window_tracker_get_app_from_pid (shell-window-tracker.c:702)
==300183== by 0x488B632: get_app_from_window_pid (shell-window-tracker.c:370)
==300183== by 0x488B632: get_app_for_window (shell-window-tracker.c:436)
==300183== by 0x488B632: track_window (shell-window-tracker.c:549)
==300183== by 0x4CDBB75: g_cclosure_marshal_VOID__OBJECTv (gmarshal.c:1910)
==300183== by 0x4CD8BE9: _g_closure_invoke_va (gclosure.c:893)
==300183== by 0x4CF2A28: g_signal_emit_valist (gsignal.c:3406)
==300183== by 0x4CF2C2C: g_signal_emit (gsignal.c:3553)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2367>
Even though GNOME Shell is not explicitly using structured logging via
G_LOG_USE_STRUCTURED, GLib uses it as default since 2016 [1], and so
we're de facto using it.
As per this, if backtrace on warnings is enabled, it is ignored since the
log handler isn't used anymore, and no dump is printed.
Thus, replace the default log handlers with writer functions instead, honoring
backtrace-warnings debug string.
[1] fce7cfaf40
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/697>
Applications launched using D-Bus activation will have a returned PID of
0, which systemd interprets as moving the requesting process to a new
scope, causing GNOME Shell to be moved to another scope. Fix this by not
creating a systemd scope when PID is 0.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2305>
GTK4 added a convenience property for icon-only buttons. While that
use case is not quite as common in the shell as in GTK apps, it still
seems common enough to mirror the GTK API.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2254>
We started tracking all windows to make sure the assumption that any
window can be match to an app holds. It is not expected however to
ever represent OR windows in the UI, so it seems better to exclude
them from get_windows() instead of expecting everyone to filter the
return value themselves.
(The returned list still includes "uninteresting" windows like attached
dialogs, which can be important for cases like the correct MRU order in
alt-tab)
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5233
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2252>
When neither the theme node itself nor any of its parents specifies
an explicit text direction, we default to aligning to the left.
That's a good default for LTR locales, but for RTL aligning to the
right is a better one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2247>
As first mentioned in commit 672171093, the CSS spec defines shadow
colors independently from the colors casting the shadow. It's not
a physical light simulation so a shadow is allowed to be a different
color from texture casting it.
This means we only care about the shape of the source where alpha
values of zero are adjacent to alpha values of non-zero. And all such
non-zero pixels should be treated as fully opaque for the purpose of
shadow generation. While this would be wrong for a physical light
simulation it does allow us to cast shadows around semi-translucent
shapes and better support CSS.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4477
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1918>
ClutterEffects are responsible for queueing redraws when their
properties change (and StScrollViewFade is a good citizen already), also
Clutter itself should queue a redraw when adding/removing an effect.
Users of Clutter should never have to queue redraws themselves (unless
they're implementing a custom ClutterEffect or ClutterContent), so don't
queue a redraw here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2189>
The fade effect can also be added to the scroll view programatically
instead of using CSS via the st_scroll_view_update_fade_effect() API.
We make use of this API in the appDisplay, but since commit ba547ec1d
the fade margins get overridden to 0.0 from the ::style-changed handler.
Fix this by only setting the fade margins when CSS actually defines a
custom vfade/hfade offset.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5079
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2189>
Since now the resource consumption of the "style-changed" signal
handlers should be significantly lower, we can start emitting the signal
in all cases again as it was originally intended. This fixes some small
visual issues, like the battery percentage in the panel only being shown
on hover or updating the size of StIcons on scale-factor changes.
This effectively reverts f74c07b9ac
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1708
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2099>
Just like with the last commit, listen to some ClutterText property
changes to catch style changes that were trigerred by
_st_set_text_from_style() and invalidate the shadow spec on changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1744>
We update a few properties of ClutterText when the CSS changes via
_st_set_text_from_style() (which we call when receiving the
style-changed signal).
Right now we simply invalidate the text shadow every time we receive the
style-changed signal, but we're going to change that with the next
commits. To ensure the shadow still gets invalidated on CSS changed that
might affect the shadow, listen to a bunch of property changes that will
get notified when any property that affects the shadow changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1744>
When text shadows are used, the cursor indicating the current position
also casts a shadow.
This means we have to regenerate the shadow texture after the cursor
position changed, so invalidate the shadow in that case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1744>
