This adds the required bits to wayland surfaces and ties them up
to the compositor parts.
It is based on and very similar in nature to buffer transforms.
From the specification:
> The global interface exposing surface cropping and scaling
> capabilities is used to instantiate an interface extension for a
> wl_surface object. This extended interface will then allow cropping
> and scaling the surface contents, effectively disconnecting the
> direct relationship between the buffer and the surface size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/323
This is done through gtk-shell ATM. If a window requests focus with
an invalid startup ID, just the demands-attention flag will be set.
The "did user interaction happen in between" checks are left to
meta_window_activate_full/meta_window_focus, by passing the timestamp
of the original launch request.
This protocol supersedes the internal gtk_text_input protocol that
was in place. Functionally it is very similar, with just some more
verbosity in both ways (text_change_cause, .done event), and some
improvements wrt the pre-edit text styling.
This is the implementation of the internal text-input protocol that will
be used to communicate IMs (to be implemented by gnome-shell) with clients.
The text_input protocol has its own focus expressed through enter/leave
events, that will typically follow the keyboard's.
The client will be able to communicate its current status (eg. focus state,
cursor rectangle in surface coordinates, text surrounding the cursor
position, ...) and will receive commands from the compositor (eg. preedit
text, committing a string, ...).
Whenever there is an active input method, the compositor will route key
events directly through it. The client will not receive wl_keyboard
events if the event is consumed by the IM.
This protocol is limited to Xwayland only and is not visible/usable by
any other client.
Mutter uses the following mechanisms to determine if an X11 client
should be granted a grab:
- is "xwayland-allow-grabs" set?
- if set, is the client blacklisted?
- otherwise, has the client set the X11 window property
_XWAYLAND_MAY_GRAB_KEYBOARD on the window using a client message?
- if not, is it a client white-listed either via the default system
list or the settings "xwayland-grab-access-rules"?
https://bugzilla.gnome.org/show_bug.cgi?id=783342
The xdg-output protocol aims at describing outputs in way which is
more in line with the concept of an output on desktop oriented systems.
For now it just features the position and logical size which describe
the output position and size in the global compositor space.
This is however much useful for Xwayland to advertise the output size
and position to X11 clients which need this to configure their surfaces
in the global compositor space as the compositor may apply a different
scale from what is advertised by the output scaling property (to achieve
fractional scaling, for example).
This was added in wayland-protocols 1.10.
https://bugzilla.gnome.org/show_bug.cgi?id=787363
Following up the previous patch, this patch makes the
Wayland backend send the edge constraints through a
custom protocol extension internal to GTK.
As it mature, we can think of upstreaming the protocol
to Wayland itself.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
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
The gtk_shell protocol used some half baked unstable protocol semantics
that worked by only allowing binding the exact version of the
interface. This hack is a bit too confusing and it makes it impossible
to do any compatible changes without breaking things.
So, instead rename it to include a number in the interface names. This
way we can add requests and events without causing compatibility issues,
and we can later remove requests and events by bumping the number in
the interface names.
https://bugzilla.gnome.org/show_bug.cgi?id=763284
We now additionally send:
- wl_data_offer.source_actions
- wl_data_source.action
- wl_data_offer.action
- wl_data_source.dnd_drop_performed
- wl_data_source.dnd_finished
The protocol changes allow for compositors to implement different policies
when chosing the action, mutter uses this to reimplement the same behavior
that GTK+ traditionally had:
- Alt/Control/Shift modifiers change the chosen action to
ask/copy/move respectively
- Drags with middle button start out as "ask" by default
As mutter now also grabs the keyboard and unsets the window focus for these
purposes, the window focus is restored after the drag operation has
finished.
The Xdnd bridge code is also modified to cope with actions, so mixed
wayland-x11 scenarios are able to convey that information.
https://bugzilla.gnome.org/show_bug.cgi?id=760805
As per the spec:
- wl_pointer.axis_source determines the current source of
scroll events.
- wl_pointer.axis_stop determines when there's no further
scroll events on the given axis.
- wl_pointer.axis_discrete is emitted on "wheel"
scroll sources, measured in ticks.
- wl_pointer.frame is meant to coalesce events that logically belong
together, e.g. axis events in this case.
Co-Authored-By: Peter Hutterer <peter.hutterer@who-t.net>
https://bugzilla.gnome.org/show_bug.cgi?id=760637
Remove our own copy of the pointer gestures protocol, and us the one
installed by wayland-protocols. This also means the new fixed unstable
naming conventions are used for the new version of the protocol, which
is reflected in the change. No functional changes were made, it is only
a rename.
https://bugzilla.gnome.org/show_bug.cgi?id=758633
When a client binds an incompatible version, we should terminate it.
This check should only be there for the unstable version, as once it is
declared stable and renamed, future versions will be backward compatible.
https://bugzilla.gnome.org/show_bug.cgi?id=753855
The global wl_pointer_gestures object is now created, effectively
bridging pinch/swipe gestures with clients, so they're now
accessible to clients implementing the protocol.
Add set_modal ond unset_modal to the gtk_surface interface. When a
surface is modal, the compositor can treat it differently from non-modal
dialogs, for example attach it to the parent window if any. There is
currently no changes to input device focus; it is up to the client to
ignore events to the parent surface that is wanted.
This bumps the gtk_shell version to 2.
https://bugzilla.gnome.org/show_bug.cgi?id=745720
Clutter touch events are translated into events being sent down
the interface resource, with the exception of FRAME/CANCEL events,
which are handled directly via an evdev event filter.
The seat now announces invariably the WL_SEAT_CAPABILITY_TOUCH
capability, this should be eventually updated as devices come and
go.
The creation of MetaWaylandTouchSurface structs is dynamic, attached
to the lifetime of first/last touch on the client surface, and only
if the surface requests the wl_touch interface. MetaWaylandTouchInfo
structs are created to track individual touches, and are locked to
a single MetaWaylandTouchSurface (the implicit grab surface) determined
on CLUTTER_TOUCH_BEGIN.
https://bugzilla.gnome.org/show_bug.cgi?id=724442
