Except the X11 backend test, it still needs an X server. Eventually we
can replace it with the equivalent that uses Xwayland, but that needs a
"scaled down" mutter that runs as the host compositor for Xwayland, that
doesn't expose anything on the session bus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3812>
The new CLUTTER_FRAME_CLOCK_STATE_SCHEDULED_NOW state is almost
identical to CLUTTER_FRAME_CLOCK_STATE_SCHEDULED, with one important
difference being that it avoids updates from being repeatedly
rescheduled "now" when multiple calls to
clutter_frame_clock_schedule_update_now() are done before the source
is actually dispatched.
Such repeated calls to schedule an update "now" may actually postpone
the dispatch if the CPU is very busy and the source dispatch is
delayed, defeating the purpose of scheduling a frame "now".
It also allows rescheduling "now" when the frame clock is uninhibited
after being inhibited while an update was scheduled "now". This may
be important in cases where the frame clock is inhibited for very
short periods in which it would otherwise lose the state of being
scheduled "now".
Scenarios such as this would become more common with the introduction
of variable refresh rate since it makes scheduling "now" a commonplace
occurrence.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3561>
Eventually we want to have all the high-level code documentation in the
component API reference documentation. However, gi-docgen is currently
missing support for mermaid so we just keep the files in `doc/` and link
to them from `code-overview.md`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3505>
Let's try to consolidate our documentation in doc/ in the repo. This
includes some documentation from README.md, the HACKING.md coding style
and the gitlab wiki.
The README.md file now links to all top-level topics (i.e. not reachable
via other topics).
This also includes a few small changes to make things more consistent.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3465>
Currently, Meta/Cogl/Clutter makes use of cairo_rectangle_int_t despite
the existance of MetaRectangle.
In order to make MetaRectangle usable in Cogl/Clutter as well, Mtk would
provide such base types that are shared across the various private
libraries
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3128>
Since MetaWindowDrag took a lot of this code to handle window drags
internally with less interactions with the rest of the stack, this
code in display/window/keybindings is unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Flip the switch in using MetaWindowDrag, leaving display grab
ops and a bunch other code unused. Some places checked the grab op
and/or window in complex ways, others just checked for grab existence
and should now look for clutter ones, and others already were already
doing this in addition.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
gtk-doc support was taken out about six years ago, but never replaced.
Add support for the newer gi-docgen, which should hopefully encourage
both C and GJS users of these libraries to improve the reference.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2248>
MetaGravity is an enum, where the values match the X11 macros used for
gravity, with the exception that `ForgetGravity` was renamed
`META_GRAVITY_NONE` to have less of a obscure name.
The motivation for this is to rely less on libX11 data types and macros
in generic code.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
I saw Meson fade from the sky
On the wind I heard a sigh
As snowflakes cover fallen Makefiles
I will say this last goodbye
Meson is now coming
So ends Autotools days
Future is now coming
And we must away
Over Python and without Bashisms
Through lands where never Meson touched
By silver streams that run down to the Sea
Under parsers, beneath old legacy
Over snow one winter’s morn
I turned at last to paths that lead home
And though where the road then takes me
I cannot tell
We came all this way
But now comes the day
To bid you farewell
Many places I have been
Many sorrows I have seen
But I don’t regret
Nor will I forget
All Makefiles that took that road with me
I bid you all a very fond farewell.
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
The gtk-doc reference is woefully maintained, and trying to actually
generate it resulted in some extremely outdated and poor documentation.
If somebody wants to actually renew the docs, just revert this commit,
otherwise, I'm not going to bother.
The elementary guys would like this as an API, and I don't see any
reason to refuse -- this is quite nice shadow painting code :)
For some reason, gobject-introspection can't seem to cope with
MetaWindowShape. I'll look into it a bit later, but for now, mark
the function it has trouble with as (skip).
Need to hide the login1 DBus wrappers from the docs, because
they use symbols that don't start with meta_ so they're not
exported from the library. And they're not public API anyway.
Rest in peace you magnificent format, love-child of arcane X11 drawing
API and markup craze, you will not be missed.
We do remember however the bravery of a many men and women, who fearlessly
descended into the guts of your intrinsics and turned ugliness into beauty;
their work will still be spoken of when you will long have been forgotten.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
From a quick code search and grep of gnome-themes-standard, none of
the themes that I inspected used this feature. Since it's the last
thing that uses a lot of old legacy GdkPixbuf code, I'd rather just
consider the feature unsupported at this point and clean up everything
I need to.
https://bugzilla.gnome.org/show_bug.cgi?id=662962
With get_input_region existing, get_input_rect is a misnomer. Really,
it's about the geometry of the output surface, and it's only used that
way in the compositor code.
Way back when in GNOME 3.2, get_input_rect was added when we added
invisible borders. get_outer_rect was always synonymous with server-side
geometry of the toplevel. get_outer_rect was used for both user-side
policy (the "frame rect") and to get the geometry of the window.
Invisible borders were meant to extend the input region of the frame
window silently. Since most users of get_outer_rect cared about the
frame rect, we kept that the same and added a new method, get_input_rect
to get the full rect of the framed window with all invisible borders for
input kept on.
As time went on and CSD and Wayland became a reality, the relationship
between the server-side geometry and the "frame rect" became more
complicated, as can be evidenced by the recent commits. Since clients
don't tend to be framed anymore, they set their own input region.
get_buffer_rect is also sort of a poor name, since X11 doesn't really
have buffers, but we don't really have many other alternatives.
This doesn't change any of the code, nor the meaning. It will always
refer to the rectangle where the toplevel should be placed.
