Add a method meta_context_destroy() that both runs dispose and unrefs
the context. Tear down is moved to dispose() so that things owned by the
context are destroyed when calling meta_context_destroy(), or when the
last reference is released.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This object intends to replace the scattered functions that are used to
make up what is effectively a "mutter context". It takes care of the
command line arguments that is now done in main.c, persistant virtual
monitors, and the like.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Users can add option entries, and it'll be part of the configuration
phase.
Create the main group manually to be able to set a user_data pointer;
this will be required to not have to rely on globals when parsing
options using a callback.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This intends to replace the call to `meta_register_with_session()` that
deals with X11 session management, and is called when the user is
"ready". In thet test context, doing that makes no sense, so make it a
no-op.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
The start phase creates the MetaDisplay object, and initializes Wayland, and
creates the main loop.
The run phase runs the main loop and handles returning an error if the
context was terminated with an error.
The terminate phase terminates the main loop, with or without an error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Configuration is the first step of the lifetime of a context, after
creation; it's here where argc/argv is processed, and it's determined
what kind of compositor, etc, it is going to be.
The tests always run as Wayand compositors, so the configuration is
quite simple, but will involve more steps later on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
It'll be part of and owned by MetaContext, intending to replace
`meta_is_wayland_compositor()`, but place it in a new file for public
enums so that it can be used from wherever.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This type is intended to replace the scattered functions used to
configure how the Mutter compositor is run. It currently doesn't do
anything, and only has a human readable name, intended to be set to e.g.
"GNOME Shell".
It's an abstract type, and is intended to be used via either a future
`MetaContextMain` for real display server use cases, and a
`MetaContextTest` for test cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This object takes over the functionality of meta-idle-monitor-dbus.c,
meta-idle-monitor.c and meta-backend.c, all related to higher level
management of idle watches etc.
The idle D-Bus API is changed to be initialized by the backend instead
of MetaDisplay, as it's more of a backend functionality than what
MetaDisplay usually deals with.
It also takes over the work of implementing "core" idle monitors. The
singleton API is replaced with thin wrapper functions on the backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1859>
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 the "volatile" qualifier from these static variables as it's expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1785>
We're going to round the workspace backgrounds in the new overview for
gnome-shell 40.
So far corner-rounding was only possible for StWidgets because the
rounded clipping was done using cairo drawing. We now need rounded
clipping for ClutterActors too because backgrounds are drawn using
ClutterActors (or more specifically a ClutterContent). To implement
that, first a ClutterOffscreenEffect subclass together with a fragment
shader from GSK (see gskSetOutputColor() [1] in the GSK GL renderer
code) was investigated, and while that was generic and worked quite
well, it was extremely slow for the case of drawing wallpapers because
of all the FBOs that had to be allocated.
This is the new, more performant approach: Use the same fragment shader,
but perform the rounded clipping right in MetaBackgroundContent while
we're painting the wallpaper. This has almost no performance impact,
with the downside of not being a generic solution.
To allow for rounded clipping not only at the edges of the wallpaper,
but using any given bounding rectangle, the API exposes not only the
radius, but also a bounding rect.
[1] https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gsk/resources/glsl/preamble.fs.glsl
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1717>
Since commit c255031b6d we pass scroll-events through to
the compositor if the window_grab_modifiers are pressed;
in order to allow gnome-shell to check for those events,
expose the struct member as a MetaDisplay property.
Also take the opportunity to pick a more generic name, now
that the modifier is no longer used exclusively for mouse
clicks (unless we maintain the notion of scroll events as
button 4 and 5 "clicks").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1695>
It's pointless to call into functions that produce information that will
end up nowhere, so lets not. This will generate less angst when doing
more intense data gathering and string generation in debug log calls.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1467
Mutter itself is versioned now, so passing the version information
to the plugin is redunant now: The version is already determined by
linking to a particular API version (gnome-shell) or by installing
to a versioned plugin path (external plugins).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1473
Instead of having everyone check net.hadess.SensorProxy themselves, have
this all controlled by the MetaOrientationManager, and proxied everywhere
else via a readonly property in org.gnome.Mutter.DisplayConfig.
We want to attach more complex policies here, and it seems better to
centralize the handling of the autorotation feature rather than
implementing policy changes all over the place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
Analogous to `ClutterDrawDebugFlag` but intended for concepts that
are not present in Clutter, such as Wayland/X11 opaque regions.
Also add the first flag for the later.
To set the flag, run:
`Meta.add_debug_paint_flag(Meta.DebugPaintFlag.OPAQUE_REGION)`
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1372
Allowing code from inside mutter to create a child process and
delegate on it some of its tasks is something very useful. This can
be done easily with the g_subprocess and g_subprocess_launcher classes
already available in GLib and GObject.
Unfortunately, although the child process can be a graphical program,
currently it is not possible for the inner code to identify the
windows created by the child in a secure manner (this is: being able
to ensure that a malicious program won't be able to trick the inner
code into thinking it is a child process launched by it).
Under X11 this is not a problem because any program has full control
over their windows, but under Wayland it is a different story: a
program can't neither force their window to be kept at the top (like a
docker program does) or at the bottom (like a program for desktop icons
does), nor hide it from the list of windows. This means that it is not
possible for a "classic", non-priviledged program, to fulfill these
tasks, and it can be done only from code inside mutter (like a
gnome-shell extension).
This is a non desirable situation, because an extension runs in the
same main loop than the whole desktop itself, which means that a
complex extension can need to do too much work inside the main loop,
and freeze the whole desktop for too much time. Also, it is important
to note that javascript doesn't have access to fork(), or threads,
which means that, at most, all the parallel computing that can do is
those available in the _async calls in GLib/GObject.
Also, having to create an extension for any priviledged graphical
element is an stopper for a lot of programmers who already know
GTK+ but doesn't know Clutter.
This patch wants to offer a solution to this problem, by offering a
new class that allows to launch a trusted child process from inside
mutter, and make it to use an specific UNIX socket to communicate
with the compositor. It also allows to check whether an specific
MetaWindow was created by one of this trusted child processes or not.
This allows to create extensions that launch a child process, and
when that process creates a window, the extension can confirm in a
secure way that the window really belongs to that process
launched by it, so it can give to that window "superpowers" like
being kept at the bottom of the desktop, not being listed in the
list of windows or shown in the Activities panel... Also, in future
versions, it could easily implement protocol extensions that only
could be used by these trusted child processes.
Several examples of the usefulness of this are that, with it, it
is possible to write programs that implements:
- desktop icons
- a dock
- a top or bottom bar
...
all in a secure manner, avoiding insecure programs to do the same.
In fact, even if the same code is launched manually, it won't have
those privileges, only the specific process launched from inside
mutter.
Since this is only needed under Wayland, it won't work under X11.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/741
Instead of blindly hoping that `$INCLUDE` contains the parent directory
of `gsettings-desktop-schemas`.
Because `gsettings-desktop-schemas.pc` says:
```
Cflags: -I/SOME/DIRECTORY/gsettings-desktop-schemas
```
Which means to include the version that Meson has configured you need
to drop the directory prefix and only `#include <gdesktop-enums.h>`.
This fixes a build failure with local installs triggered by 775ec67a44
but it's also the right thing to do™.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1370
