Port the xdg_shell implementation to use the unstable v6 protocol. This
includes:
- making xdg_surface a generic base interface for xdg_shell surface
roles
- create a xdg_toplevel role replacing the old xdg_surface
- change the xdg_opup role to be based on xdg_surface
- make xdg_popup not grab by default
- add support for xdg_positioner
https://bugzilla.gnome.org/show_bug.cgi?id=769936
Emit a 'configure' signal before configuring the role. This will enable
extensions to send its own configure events before the role is
configured.
https://bugzilla.gnome.org/show_bug.cgi?id=769936
Add support for assigning a window a custom window placement rule used
for calculating the initial window position as well as defining how a
window is constrained.
The custom rule is a declarative rule which defines a set of parameters
which the placing algorithm and constrain algorithm uses for
calculating the position of a window. It is meant to be used to
implement positioning of menus and other popup windows created via
Wayland.
A custom placement rule replaces any other placement or constraint
rule.
https://bugzilla.gnome.org/show_bug.cgi?id=769936
Allow passing parameters (only GObject parameters supported for now) so
that role assignment can affect the paremeters set during construction.
If a role was already assigned when assigning, the passed parameters
are set using g_object_set_valist().
https://bugzilla.gnome.org/show_bug.cgi?id=769936
Instead of piping the protocol file content to wayland-scanner, pass
the file name as an argument. This enables a new enough wayland-scanner
to print more meaningful error messages.
https://bugzilla.gnome.org/show_bug.cgi?id=769936
We can only honor this properly in the MUTTER_STAGE_VIEWS=1 case. When using
the legacy view, software implemented transforms are only exposed if there is
only one output, as we can only transform the entire stage there.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The texture is only created if the view is transformed at the software level,
otherwise the texture is NULL, and rendering happens on the onscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
"Blit" the result on the framebuffer after each view is painted.
This of course only applies if there is an offscreen buffer to
perform any blitting. Otherwise the onscreen framebuffer is rendered
to directly and this step is not necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The offscreen is given through the ::back-buffer property, the ClutterStageView
will set up the the CoglPipeline used to render it back to the "onscreen"
framebuffer.
The pipeline can be altered through the setup_pipeline() vfunc, so ClutterStageView
implementations can alter the default behavior of blitting from offscreen to
onscreen with no transformations.
All getters of "the framebuffer" that were expecting to get an onscreen have
been updated to call the right clutter_stage_view_get_onscreen() function.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The call to _cogl_framebuffer_winsys_update_size() results in no-op here,
as the framebuffer has already the right size when rebuilding the views.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
Those will need a separate treatment from the modes that we eventually
support through "software", so split those into a separate enum so we
can can do the right thing when applying the configuration.
Also, add a helper function that returns the transform that the software
fallbacks should perform, which should be "normal" if the rotation is
already handled via hw.
The function applying the configuration has been modified to always set
a HW rotation mode (even if normal), when we come to support SW rotation
modes, we'll be relying on a normal transformation, so it will be
necessary to have mixed HW/SW managed transforms.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
Various clutter test directly use cogl symbols, so they should be linked
against mutter-cogl as well.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=769636
This commits adds support for exporting xdg_surface handles via
xdg_exporter and importing them via xdg_importer.
This bumps the required wayland-protocols version to 1.6.
https://bugzilla.gnome.org/show_bug.cgi?id=769786
Meant to be used by users of MetaWaylandSurface's that need to know
when the surface was unmapped. So far only emitted by shell surfaces
(surfaces with MetaWindow's).
https://bugzilla.gnome.org/show_bug.cgi?id=769786
As whether edge scrolling is enabled depends on whether two-finger
scrolling is disabled, make sure to update two-finger scrolling first.
Note that this only fixes the problem on startup. Changing the
settings in GSettings directly might cause an inconsistent state, but
the main UI for this setting, gnome-control-center, makes sure to
update two-finger scrolling before edge scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=769276
intltool is unmaintained nowadays while upstream gettext gained
support for formats like GSettings schemas and .desktop files,
and offers a mechanism to teach it about other XML formats not
yet supported out of the box which we can use for the rest.
So there's nothing stopping us, just make the switch ...
https://bugzilla.gnome.org/show_bug.cgi?id=769073
An empty argument list means "unspecified arguments", and not
"no arguments" like it does in C++. If an implementer of Mutter
plugins uses gcc -Wold-style-definition, as configured by
AX_COMPILER_FLAGS_CFLAGS, they will get warnings about this.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Florian Müllner <fmuellner@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=769971
The scale will have been set to 1 no matter what when initializing the
MetaOutput since it at the time didn't have an CRTC assigned to it.
Now, when we assign the CRTC to the output, we need to update the scale.
https://bugzilla.gnome.org/show_bug.cgi?id=769505
This is somewhat gross at the moment, because we're after all mimicking
real keyboard events, we can only lookup keycodes that are available
in the current map, and the control of levels is rather limited.
Eventually, we want to implement the text_input protocol, handle these
events separately to MetaWaylandKeyboard, so event->key.keyval is
is guaranteed to be the final result. Until then, this is the farthest
we can get.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
Evcodes don't cut it when we have something already specifying the
character to be printed, despite the current group/level. This API
allows some more control on the intended output.
https://bugzilla.gnome.org/show_bug.cgi?id=765009
