delta/mutter.git/src/frames, branch main

frames: Disable XDND support on the frame window

2023-04-28T10:46:58+00:00

All X11 surfaces created by gtk4 claim to support XDND via the XdndAware
property. This was leading some clients, e.g. Qt, to consider the frame
window as drop target instead of the client window.

Avoid this issue by removing the XdndAware property again after gtk has
created the surface.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2715
Part-of:

frames: Use cairo renderer on GTK frames

2023-04-24T10:07:06+00:00

Going for the default GL renderer is known to trigger rendering
artifacts using the NVidia proprietary driver. Since we don't have
too many expectatives about frames being flashy (not to the point
of mandating GL), resort to the cairo renderer in the mean time.

Part-of:

x11: Always initialize all fields of XEvents sent via XSendEvent

2023-04-16T23:52:36+00:00

The X server ignores the send_event and serial in incoming XEvents, so
they were not initialized when calling XSendEvent in a few places.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2641
Part-of:

frames: Forward _NET_WM_STATE during frame initialization

2023-04-14T13:55:23+00:00

Ensure the frame window is created at the right fullscreen state
before showing it and assigning it to the client window.

A peculiarity of this property on frame windows is that it is
typically single-handedly updated from the Mutter side, in synchronization
with client window state. It can only differ during creation, since
GTK still likes to apply its own state.

Also, the only relevant property seems to be _NET_WM_STATE_FULLSCREEN,
since the others are less relevant to the role of the frames client,
and get applied to the MetaWindow as a whole, instead.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2712
Part-of:

frames/content: Use gtk_widget_compute_point()

2023-04-05T16:38:16+00:00

The non-graphene-point variant is deprecated.

Part-of:

frames/window-tracker: Select StructureNotifyMask X11 events

2023-04-04T10:50:42+00:00

The window tracker is filtering XEvents manually as it only requires a
subset of the ones that Gdk listens to in the root window, and this is
nice, but we were restricting the set a bit too much because due to this
we were not notified when an xsettings manager was available, and thus
in case gsd-xsettings was launched after meta-window-tracker (a normal
scenario under X11), no xsetting was actually applied to the decoration
windows.

As per this, the default settings were used for everything and never
updated, until a restart of the window-tracker.

In order to be able to monitor the XSettings changes at startup, we also
need to select the StructureNotifyMask as gtk always do by default.

See also:
  https://gitlab.gnome.org/GNOME/gtk/-/blob/4.11.1/gdk/x11/gdkscreen-x11.c#L947-950

Fixes: #2580
Part-of:

frames: Select SubstructureNotifyMask too

2023-03-04T23:45:35+00:00

This is the mask that lets us receive among other events the rather
important CreateNotify, that tells us about new winows. This has went by
rather unnoticed except for cases where multiple windows show up very
quickly directly after the frames client spawned, because the drag icon
surface cache eventually already did select that particular mask.

Make things more reliably by explicitly setting the mask for the events
we rely on to function.

This fixes flaky stacking tests that map multiple X11 windows in a row.

Part-of:

frames: Fix code typo

2023-02-28T17:13:23+00:00

We are picking the wrong fallback frame title string in a
branch.

Fixes: 6df9eab88 ("frames: Handle _NET_WM_VISIBLE_NAME")
Part-of:

frames: Handle WM_NAME

2023-02-27T15:38:25+00:00

This is the most ancient form of "window titles", not guaranteed
to be UTF-8, take the usual precautions before using this string
and keep it as a last resort.

Part-of:

frames: Handle _NET_WM_VISIBLE_NAME

2023-02-27T15:38:25+00:00

This is occasionally set by Mutter, in order to hint about remote
X11 clients, etc.

Part-of: