| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Glib stopped providing any fallback implementations on systems without
memmove() all the way back in 2013. Since then, the symbol is a simple
macro around memmove(); use that function directly now that glib added
a deprecation warning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/689
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
It's now unused.
https://gitlab.gnome.org/GNOME/mutter/issues/491
|
|
|
|
| |
https://gitlab.gnome.org/GNOME/mutter/merge_requests/361
|
|
|
|
|
|
|
|
|
|
|
|
| |
The app menu is in the process of being retired[0], and the shell
stopped displaying it while applications are in the process of
dropping it. It therefore doesn't make sense to always show a
fallback menu in server-side decorations, applications that still
set the menu can rely on GTK+'s own fallback instead.
[0] https://gitlab.gnome.org/GNOME/Initiatives/wikis/App-Menu-Retirement
https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
|
|
|
|
|
|
|
|
|
| |
Commit 25f416c13db 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.
|
|
|
|
|
|
| |
Get rid of the deprecated gdk_display_get_default_screen ()
https://bugzilla.gnome.org/show_bug.cgi?id=759538
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This will ease handling of touch events through these same handlers.
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
|
|
|
|
|
|
|
| |
The value is not scaled by default so it needs to be adjusted
depending on the window scaling, as it's done in other places.
Fixes: #87
|
|
|
|
| |
So it does gtk headerbar, so mutter should do.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
update_context_styles is using the wrong variable when advancing
to the next key in the hash table which can cause an infinite
loop if # of variants is ever greater than 1.
This problem was originally reported here:
https://github.com/linuxmint/Cinnamon/issues/5254
The following patch was commited in Mint:
https://github.com/linuxmint/muffin/commit/6120bdde
This patch is just a shorter version of the Mint patch
and they deserve all the credit for the idea.
https://bugzilla.gnome.org/show_bug.cgi?id=780254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
GDK doesn't support multiple screens, so effectively we don't either.
Lets stop pretending we do.
This fixes a few -Wdeprecated warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=769070
|
|
|
|
|
|
|
|
| |
This was added in commit d05b750b8dec3825d286e3ae30c41b41bd6aed98 and
later removed inadvertently in commit
d561b3b18f73a66bcd7947dce7ab1aab9e09965a .
https://bugzilla.gnome.org/show_bug.cgi?id=767969
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=764807
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
GtkWindow actually uses two CSS nodes, 'window' and 'decoration'.
Simulate that by using two separate style contexts for the frame.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Related change in GTK+:
https://git.gnome.org/browse/gtk+/commit/?id=8eb261988869608604c78ed90de5579beb4ef2b0
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 reverts commit 8a481b3e1039f58067293132777c80c061a63b72.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=751857
|
|
|
|
|
|
|
|
|
|
|
| |
This is a really old behavior introduced in commit
585e3625266dd0fadcdb033739760db423d31714 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
|
|
|
|
|
|
| |
GTK+ started to complain when the state parameter passed to any
gtk_style_context_get*() method mismatches the context's current
state a while ago.
|
|
|
|
|
| |
GTK+ has updated some more widgets to use element names, so do some
catching up again ...
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
As design patterns have evolved, dialogs that use CSD do use titlebar
buttons, so it's time to re-enable them for SSD as well.
https://bugzilla.gnome.org/show_bug.cgi?id=641630
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
fixes bug 747326
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
These interfere with our touch handling.
|
|
|
|
| |
gcc is super smart and notices that we don't have a default case here.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|