This vfunc was added as a was to work around the convoluted
initialization process. Now that we figured it out and moved
the MetaWindowActor-specific initialization to constructed(),
we can override that.
Remove post_init() and use GObject.constructed() entirely.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
MetaWindowActor handles sending _NET_WM_FRAME_* X atoms to
clients - even pure Wayland clients.
Now that we have Wayland- and X11-specific implementations of
MetaWindowActor, we can delegate this to MetaWindowActorX11,
and allow pure Wayland apps to not even connect to
MetaSurfaceActor:repaint-scheduled.
Do that by moving all the X11-specific code to the X11-specific
MetaWindowActorX11 class. Add vfuncs to MetaWindowActorClass
that are necessary for the move, namely:
* pre_paint() and post_paint()
* post_init()
* frame_complete()
* set_surface_actor()
* queue_frame_drawn()
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
Those are stub specialized classes for MetaWindowActor. This will
help ensuring that we do not execute X11-specific code paths on
pure Wayland clients.
The relationship between the window actor and the surface is the
following:
* Wayland: MetaWindowActorWayland + MetaSurfaceActorWayland
* X11: MetaWindowActorX11 + MetaSurfaceActorX11
* Xwayland: MetaWindowActorX11 + MetaSurfaceActorWayland
It is not possible to have MetaWindowActorWayland backed by a
MetaSurfaceActorX11 surface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
