This debug statement is actually applied all the times, while it could be useful
for crashes analysis, these days the same can be done using `MALLOC_CHECK_` and
`MALLOC_PERTURB_` env variables.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
Make meson link libmutter using -fvisibility=hidden, and introduce META_EXPORT
and META_EXPORT_TEST defines to mark a symbols as visible.
The TEST version is meant to be used to flag symbols that are only used
internally by mutter tests, but that should not be considered public API.
This allows us to be more precise in selecting what is exported and what is
not, without the need of a version-script file that would be more complicated
to maintain.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
Instead of using gtk_css_provider_get_default(), add a
static GtkCssProvider and fetch it instead. Creating
GtkCssProviders consume a bit more memory, so keeping
a single one alive is slightly more memory saving.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
Commit 47131b1d ("frames: Handle touch events") introduced an assert to
make sure that all mouse button actions are handled in mutter.
However, mice can have a more than 5 buttons, so simply ignore the
"other" actions instead of aborting.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/160
This is just done on wayland as it'll break horribly on X11, we let
this happen through pointer emulated events in XISelectEvents evmask
instead.
Some things had to be made slightly more generic to accomodate touch
events. The MetaFrames shall lock onto a single touch at a time, we
don't allow crazy stuff like multi-window drag nor multi-edge resizes.
https://bugzilla.gnome.org/show_bug.cgi?id=770185
Gtk now is caching the themed cairo surfaces, then as per
commit gtk@e36b629c the surface device scale is used to figure
out the current paint scaling.
Without this when using background-image's for window buttons
the -gtk-scaled icons isn't properly resized.
Fixes#99
When painting the titlebar, button icons that aren't available in the
desired size need to be scaled. However the current code inverses the
scale factor, with the result that the adjusted icons are much worse
than the original icons, whoops.
This went unnoticed for a long time given that most icons are availa-
ble in the desired 16x16 size, and the most likely exceptions - window
icons - are not shown by default.
https://gitlab.gnome.org/GNOME/mutter/issues/23
Currently tiled windows are not resizable and their size is fixed
to half the screen width. Adjust the code to work with fractions
other than half, and allow users to adjust the split by dragging
the window edge that is not constrained by a monitor edge.
Follow-up patches will improve on that by resizing neighboring
tiled windows by a shared edge, and making the functionality
available to client-side decorated windows implementing the
new edge constraints protocol.
Ungrabbed pointer motion events over a client window area don't even
reach mutter in X compositor mode, but as a wayland compositor we
process those events which ends up in a call stack like:
- meta_window_handle_ungrabbed_event
- meta_ui_frame_handle_event
- handle_motion_notify_event
- get_control
- meta_ui_frame_calc_geometry
Computing frame geometry is a relatively CPU expensive operation and
doing it on every motion event over a client window is pointless work
since we aren't going to change the cursor or prelight any frame
widget.
This commit special cases the determination of
META_FRAME_CONTROL_CLIENT_AREA using a much faster method. When
continuously moving the pointer over an X (client) window, it results
in a ~40% decrease in mutter cpu usage.
https://bugzilla.gnome.org/show_bug.cgi?id=779436
Frames are painted on the frame window according to the GTK+ theme.
Depending on the target's visual, this means either drawing over
a black destination or a fully transparent one. So in cases where
the theme doesn't paint decorations with full opacity, decorations
for windows with an rgba visual look different from those with a
non-rgba visual. Using an rgba visual for all frames independent
from the client's visual can potentially break clients, so our
only option for a consistent appearance is to explicitly initialize
the frame background to black before painting the theme's decoration
on top.
https://bugzilla.gnome.org/show_bug.cgi?id=745060
The GTK+ theme may draw parts of the decorations outside the actual
frame. Since commit f9db65f47f we make sure that the frame is big
enough to account for any overdrawing, however as we still clip the
cairo context to the actual frame before drawing the decorations,
those parts aren't actually painted.
This issue is not very obvious for most frames, as they use a non-rgba
visual where the unpainted parts appear black, which gives the expected
result with many themes once the shape mask is applied (as the mask does
include any overdrawn parts). For frames using an rgba visual however,
unpainted parts are transparent, so any overdrawn decorations are clearly
missing.
Fix this by only clipping out the client area when drawing decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=745060
GTK+ paints some elements like box shadows (which Adwaita likes to (ab)use
for borders) outside the rectangle passed to gtk_render_*. This is not
an issue if our own invisible frame border is big enough, but in case
of non-resizable windows we end up clipping away part of the decoration.
Use the newly added gtk_render_background_get_clip() to make sure we
always use a mask that is large enough to contain all decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=752794
Use global theme variant only if window does not have _GTK_THEME_VARIANT
property. This allows applications to request default theme variant when
global dark theme is enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=761543
GTK+ improved its CSS support, and the default theme started to make
use of it, so we must update our theming code accordingly. Add support
for margins where they make sense.
GTK+ improved its CSS support, and the default theme started to make
use of it, so we must update our theming code accordingly. Start by
supporting min-width/min-height where it makes sense.
This is a really old behavior introduced in commit
585e362526 which is inconsistent since
it only applies to SSD windows.
If we really want this, we should focus the window elsewhere so that
it applies consistently to all windows.
https://bugzilla.gnome.org/show_bug.cgi?id=756789
The default theme started to use them in GTK+ commit 371f50, so
we need to update the style contexts to keep matching the style
of client-side decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=757101
We have been ignoring those buttons since 3.16 after they had been
broken in the default theme for a couple of versions. As nobody
appears to miss them, it's time to remove them for good.
We use a single style context to draw titlebar buttons, updating
its state according to each button's prelight state as necessary.
This assumes that the original state is neither ACTIVE nor PRELIGHT,
which means we need to reset the state after drawing to avoid
propagating the state of the last-drawn button.
We can get this operation in some cases, for example when
we're trying to resize window that cannot be resized.
This can occur with maximized windows that have a border
(without border we couldn't resize them by mouse in maximized state).
In this case we reached abort() beacuse we did not handle this op.
https://bugzilla.gnome.org/show_bug.cgi?id=751884
In commit cc5def1, buttons were changed from GdkRectangles to
MetaButtonSpace units, but the corresponding memset hack was not.
This means that the clickable portion of the unshade rectangle
was always set to uninitalized memory. The effects of this were
random, but in cases where the moon is aligned just right, the
rectangle would graze over the borders, and so it would take priority
over other borders and show a pointer cursor instead of a resize
cursor.
As we opt out of GTK+/Clutter's HiDPI handling, we need to apply the
window scaling factor manually to decorations, both the geometry and
when drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=744354
There is no good reason to do so, besides a nice way to check whether
a particular button is enabled. However there are legitimate reasons
for overdrawing like box-shadows or outlines, so remove the clip.
