Ideally, the use case we have for MetaGroup would be removed but that
requires investigation that could be done as a future step
The function also expects a MetaWindowX11, so add a check to ensure
we don't crash at runtime if the function gets called on a wayland
client
Also removes an unused header import
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3157>
This reverts commit 575ba13b9b4efa40f07d57d87d50d8f0466f2e16.
That commit did not actually prevent the "Unknown" application from
showing up in the dash or app switcher when the recorder was running,
but it introduced a problem with Proton which also uses gstreamer OpenGL
elements in its transcoder. This was causing the overview to get stuck
while the transcoder was running due to the app for the
"OpenGL Renderer" window being null.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7042
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3000>
The pipeline contains a GST plugin that pops up an unclosable
zero-sized window.
Unfortunately we did not manage to come up with a proper fix
in time, so for now explicitly exclude it from app tracking.
This does not address all issues (it still prevents the
window's workspace from getting removed, even when it appears
empty), but at least it avoids the most confusing effect by
preventing the "app" from showing up in dash, alt-tab etc.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6763
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2956>
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>
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>
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>
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>
Since commit b60836932 we only allow WM_CLASS matches for sandboxed
applications if the found app's ID is prefixed by the sandbox ID.
The existing check still has a hole in it though: "org.example.Foo"
and "org.example.FooDevel" are different applications, yet the former
is a prefix of the latter.
So tighten the check by including a trailing "." in the checked prefix;
this excludes cases like the above, while still working for the regular
case of a single .desktop file because our app IDs include the ".desktop"
suffix.
Spotted by wjt.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1357
Currently our heuristics for matching a window to its app check
for the application ID before the WM_CLASS, as the ID is more
reliable in so far that it is outside the application's control
and so it cannot use it to spoof a different application.
However this also prevents applications with multiple .desktop
files like LibreOffice from matching any .desktop files other
than the one under the main ID.
Since we now no longer allow the WM_CLASS to match a .desktop
file that doesn't belong to the sandboxed application, we can
fix that issue by checking the WM_CLASS first, without opening
the door to spoofing.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/219
At least flatpak (no idea about snap, sorry) enforces that all .desktop
files exported by a sandboxed app use the application ID as prefix.
Add the same check when trying to find a match based on the WM_CLASS,
to prevent sandboxed apps from matching a .desktop file they do not
own.
At the moment this is unlikely as we check for a match on the
sandboxed app ID first, but we are about to change that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/219
MetaWindows get_pid() API changed to use the client PID, which also
works for Wayland clients instead of only X11 clients now. This API
returns 0 instead of -1 for invalid PIDs, so update our check according
to that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1184
Popups and other override-redirect windows are meaningless to everything
that depends on the ShellWindowTracker. Ignoring those windows will result
in less ShellApp::windows-changed signal emissions, and less activity in
the AppMenuButton and everything else that depends on them.
Reduces gnome-shell CPU activity while typing on the Epiphany addressbar,
as the pop up animation there results in a number of xdg_popup being
created and destroyed.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/642https://gitlab.gnome.org/GNOME/mutter/issues/556
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
Back in the day, there was a proposed system of tracking apps in a
specific context.
The inspiration was that you may have used apps in multiple modes:
Firefox may have been used in both "Programmer Reference" and
"Kitten Videos" contexts. Early user response to the feedback wasn't
too positive - context switching is something that humans have trouble
doing implicitly, let alone explicitly. The old codebase still has a
few remnants of this around; let's finally put them to rest.
Note that we still write out a dummy context tag to the XML file - old
versions of the shell will flat out crash if you don't have one of those
in there, so just leave it in for compatibility sake.
https://bugzilla.gnome.org/show_bug.cgi?id=673767
Remove any usage of MetaScreen, as it has been removed from libmutter
in the API version 3. The corresponding functionality has been moved
into three different places: MetaDisplay, MetaX11Display (for X11
specific functionality) and MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Our window matching currently fails frequently with Flatpak
applications, as one of the primary hints used to link windows
with .desktop files - the WM_CLASS - no longer matches when
flatpak renames the exported .desktop file. Worse, as Flatpak
applications are run in their own PID namespace, different
apps frequently share a common _NET_WM_PID, resulting in
unrelated apps being grouped together by one of the fallback
paths. To match Flatpak applications reliably, take the newly
exported Flatpak ID into account.
https://bugzilla.gnome.org/show_bug.cgi?id=772615
The lookup table used by get_app_from_window_pid contained only pids of
apps launched by gnome-shell itself, but not pids of apps running before
gnome-shell was (re-)started. Also the pids in that table might not even
be the pid of the process that is actually showing the window if wrapper
scripts are used.
Instead use shell_window_tracker_get_app_from_pid which uses the pids
from the windows themselves.
This removes the only use of launched_pid_to_app which will be removed
in the following commit.
This fixes: https://bugzilla.gnome.org/show_bug.cgi?id=736527
Wayland applications don't tend to have very useful WM Class properties,
as GTK+ isn't very good at picking an appropriate application ID. While
we should likely fix GTK+ to pick a better app ID, we do have the
existing gtk_shell for more accurate information. The only problem is
that the gtk_surface is set after the MetaWindow is constructed, and
we're not listening for changes on the GTK+ application ID.
Listen to changes on the GTK+ application ID to fix app tracking for
most GTK+ applications under Wayland.
Since we started tracking non-interesting windows, we can no longer
assume that if we manage to find an app associated with the focus window,
it should appear focused - we now can find apps for docks, the DESKTOP
window etc.
To restore the old behavior, make sure that the focus window or one of
its parents is "interesting".
https://bugzilla.gnome.org/show_bug.cgi?id=722928
The code from shell_window_tracker_is_window_interesting() is equivalent
of MetaWindow's skip-taskbar property, so use it to avoid code duplication.
https://bugzilla.gnome.org/show_bug.cgi?id=723308
It is possible to associate an application's window with a different
application using the transient_for hint. However we currently only
consider the hint in get_window_app() and not when making the original
association, which opens the door to some confusing inconsistencies;
for instance, get_window_app() will not necessarily return the same
value for all windows retrieved via shell_app_get_windows().
Fix this by looking at the transient_for hint when making the original
association, not just in get_window_app().
https://bugzilla.gnome.org/show_bug.cgi?id=722434
All get_app_from_*() helpers are transfer full, but
get_app_from_gapplication_id() was directly returning the result
of lookup_app(), which is transfer none.
https://bugzilla.gnome.org/show_bug.cgi?id=721439
Filtering out "non-interesting" windows beforehand as we currently do
means that we may get properties that should be based on all windows,
like the last time the application was used, wrong.
Just track all windows and filter out non-interesting windows manually
in the one place we actually care about the difference.
https://bugzilla.gnome.org/show_bug.cgi?id=719824
In the new application model, there is one ID shared by GApplication,
DBus and .desktop files, so we can use that for the association,
instead of fiddling with badly cased wm classes.
https://bugzilla.gnome.org/show_bug.cgi?id=706252
Chromium (but not google-chrome) has a StartupWMClass in the desktop
file, so we must match the instance part first to have chrome
web apps working.
Also, we must take care of apps without a wm_class or instance at
all.
https://bugzilla.gnome.org/show_bug.cgi?id=673657
