The new hint is meant to indicate that the text input already provides an on-screen means to enter data, and that using the system provided input method may not be needed.
It should be used when the client presents the user with a custom on-screen input method, like an on-screen keyboard, or perhaps a dropdown list.
The new hint is meant to address the issue when the system input method is an on-screen keyboard. Without the hint, the input method would not know that it's not needed, unless the client refrained from using the input method protocol at all.
With the hint, the input method can still be enabled, while not displaying a second on-screen keyboard. This allows for the system input method to still provide accessibility services, as well as text completion or prediction.
Based on discussion in https://gitlab.gnome.org/GNOME/gtk/merge_requests/978
Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
IBus update_preedit_string_with_mode feature send the preedit text and
the commit mode to the input method module, use preedit_commit_mode event
to send the commit mode together with the preeedit text.
IBusInputContext specify how input context interact with the keyboard,
but sometimes mouse click also interacts with the input context, too.
For Firefox, if some preedit text is visible with ibus-hangul input method;
after mouse click, the preedit will be committed twice.
To fix this issue, ibus-hangul can send preedit text and commit mode
together; after mouse click, the preedit is handled directly in
input method module of Firefox, and the preedit is committed in
the current text widget.
For detailed analysis, please read the merge request comments.
URL: https://gitlab.freedesktop.org/wayland/wayland-protocols/merge_requests/30
Signed-off-by: Peng Wu <pwu@redhat.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
v4 will be used for iterating over the protocol.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
This reverts commit 353ed023c4.
This made a protocol addition without bumping the version.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
IBus update_preedit_string_with_mode feature send the preedit text and
the commit mode to the input method module, use preedit_commit_mode event
to send the commit mode together with the preeedit text.
IBusInputContext specify how input context interact with the keyboard,
but sometimes mouse click also interacts with the input context, too.
For Firefox, if some preedit text is visible with ibus-hangul input method;
after mouse click, the preedit will be committed twice.
To fix this issue, ibus-hangul can send preedit text and commit mode
together; after mouse click, the preedit is handled directly in
input method module of Firefox, and the preedit is committed in
the current text widget.
For detailed analysis, please read the merge request comments.
URL: https://gitlab.freedesktop.org/wayland/wayland-protocols/merge_requests/30
The output description is a human-readable text describing the output. Unlike
the name which uniquely identifies the output, it's intended to be displayed to
the user.
It might be desirable for a compositor to update an output's description. For
instance, when only one output is plugged in, it's not necessary to dump make,
model, serial and connector to the description, something like "Dell U2717D" is
enough. However when two identical outputs are plugged in it's necessary to add
e.g. the connector type to tell them apart ("Dell U2717D on HDMI"). See [1] for
a discussion about this.
This commit bumps xdg_output's version to allow compositors to update the
property.
[1]: https://github.com/swaywm/wlroots/issues/1623
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
This allows clients to destroy a gesture object before they disconnect.
The request isn't named "destroy", as this would conflict with
wayland-scanner's auto-generated destructor (which just destroys the
client-side object without sending any request).
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This commit makes it so a wl_output.done event is guaranteed to be sent with a
xdg_output.done event.
This protocol change has been discussed in a recent xorg-devel discussions [1].
First let's recap why a change is needed: Xwayland listens to both wl_output and
xdg_output changes. When an output's properties change, Xwayland expects to
receive both a wl_output.done event and an xdg_output.done event. If that's not
the case, Xwayland doesn't update its state (so old state is still exposed to
X11 clients).
Most of the time, both objects will be updated at the same time (e.g. the
current mode is changed, so both wl_output.mode and xdg_output.logical_size are
sent) so this won't be an issue. However in some situations only one of
wl_output or xdg_output changes. For instance:
- The mode is changed at the same time as the scale, resulting in the same
logical_size.
- The compositor doesn't expose the outputs' position via wl_output, so whenever
the position changes only xdg_output is updated.
Both KDE [2] and wlroots [3] have experienced this issue.
For this reason, I'd like to update the xdg-output protocol to make it mandatory
to always send a wl_output.done event after xdg_output changes. This effectively
makes wl_output.done atomically apply all output state (including the state of
add-on objects like xdg_output). This approach is pretty similar to
wl_surface.commit: this request will atomically apply surface state including
the state of e.g. the xdg_surface object tied to the wl_surface.
To update the protocol to reflect this new requirement we can either:
- **Bump xdg_output version**. The current protocol doesn't specify that
wl_output.done must be sent, adding this new requirement would be a breaking
change. We need to fix Xwayland for the current xdg_output version (maybe make
it non-atomic for the current version, atomic for the new one?). Should we
deprecate xdg_output.done in the new version?
- **Don't bump xdg_output version**. This clarifies what is expected in practice
by Xwayland, a major xdg_output consumer, and what is currently implemented by
all compositors.
There's one issue with the "don't bump" approach: indeed in practice compositors
always send wl_output.done and xdg_output.done in pairs, however the ordering
between those two events is not guaranteed. This means some compositors might
send this sequence:
wl_output.geometry(…)
wl_output.done()
xdg_output.logical_position(…)
xdg_output.done()
In this case the wl_output.done event fails to atomically apply the xdg_output
state.
For this reason, I think bumping the version is a better approach.
This commit also deprecates xdg_output.done, which doesn't have any purpose
anymore.
[1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html
[2]: https://phabricator.kde.org/D19253
[3]: https://github.com/swaywm/sway/issues/4064
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
It provides legacy support and makes it easier to replace wl_drm.
v3: DRM_FORMAT_MOD_INVALID must be advertised to be supported (which
requires a version bump)
v4: no version bump, but a note for now
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Clarify that after zwp_buffer_release_v1 events, otherwise unused
buffers can be reused without any additional implicit synchronization.
This is in contrast to wl_buffer.release, which doesn't guarantee that
implicit synchronization is not required to safely use a buffer after
the event is received.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Graphics APIs are expected to use this protocol under the hood, and
since there can only be one user of explicit synchronization per
surface, warn about using the protocol directly in such cases.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add opaque EGL buffers to the supported buffer types for use with the
explicit synchronization protocol. Opaque EGL buffers rely on the same
EGL implementation in both the compositor and clients, which makes it
straightforward to manage client expectations about fence support for
such buffers.
Also make it clearer that implementations are free to support other
buffer types beyond the required ones.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This primary selection is similar in spirit to the eponimous
in X11, allowing a quick "select text + middle click" shortcut
to copying and pasting.
It's otherwise very similar to its Wayland counterpart, and
explicitly made consistent with it.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
This protocol enables explicit synchronization of asynchronous graphics
operations on buffers on a per-commit basis. Support is currently
limited to dmabuf buffers and dma_fence fence FDs.
Explicit synchronization provides a more versatile notification
mechanism for buffer readiness and availability, and can be used to
improve efficiency by integrating with related functionality in display
and graphics APIs.
This protocol is also useful in ChromeOS ARC++ (running Android apps
inside ChromeOS, using Wayland as the communication protocol), where it
can enable integration of the ChromeOS compositor with the explicit
synchronization mechanisms of the Android display subsystem.
Finally, the per-commit nature of the release events provided by this
protocol potentially offers a solution to a deficiency of the
wl_buffer.release event (see
https://gitlab.freedesktop.org/wayland/wayland/issues/46).
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
[Pekka: dropped Reveman from maintainers]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Although it would probably default to the license at the root of the
repository anyway, it's best to be explicit about it, and also be
consistent with the other extensions.
The copyright holders have been assembled from git history and the
README.
Signed-off-by: Johan Klokkhammer Helsing <johan.helsing@qt.io>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
This new protocol description is an evolution of v2.
- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
Compositors are still free to handle situations where the keyboard
focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
interface instead.
- All state is double-buffered, with specified defaults.
- The compositor can be notified about external changes to the state.
- The client can detect outdated requests.
Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This adds a new protocol to negotiate server-side rendering of window
decorations for xdg-toplevels. This allows compositors that want to draw
decorations themselves to send their preference to clients, and clients that
prefer server-side decorations to request them.
This is inspired by a protocol from KDE [1] which has been implemented in
KDE and Sway and was submitted for consideration in 2017 [2]. This patch
provides an updated protocol with those concerns taken into account.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Drew DeVault <sir@cmpwn.com>
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Eike Hein <hein@kde.org>
Reviewed-by: Alan Griffiths <alan.griffiths@canonical.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
[1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
[2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
This adds two events to the protocol. The goal is to allow clients to
give the user the ability to select outputs with the same names the
compositor uses and to identify outputs consistently across sessions.
The output name is a short and stiff identifier with strict limits on
permitted characters, which is suitable for storing in config files,
command line arguments, etc. A warmer "description" event is also
provided to (optionally) provide a more human readable name, and has
much broader restrictions on its form.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
[Jonas: Fixed formatting and commit subject]
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
wl_pointer, wl_keyboard and wl_touch events currently use a 32-bit
timestamp with millisecond resolution. In some cases, notably latency
measurements, this resolution is too coarse to be useful.
This protocol provides additional high-resolution timestamps events,
which are emitted before the corresponding input event. Each timestamp
event contains a high-resolution, and ideally higher-accuracy, version
of the 'time' argument of the first subsequent supported input event.
Clients that care about high-resolution timestamps just need to keep
track of the last timestamp event they receive and associate it with the
next supported input event that arrives.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
As export is a reserved keyword in C++, in order for the output
generated by wayland_scanner to compile correctly rename export to
export_toplevel and import to import_toplevel this needs a new protocol
version as is an incompatible change
[jadahl: Fix various documentation issues]
Signed-off-by: Marco Martin <notmart@gmail.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This protocol aims at describing outputs in way which is more in line
with the concept of an output on desktop oriented systems.
Some information are more specific to the concept of an output for a
desktop oriented system and may not make sense in other applications,
such as IVI systems for example.
The goal is to gradually move the desktop specific concepts out of the
core wl_output protocol.
For now it just features the position and logical size which describe
the output position and size in the global compositor space.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This adds a new protocol to let Wayland clients specify that they want
all keyboard events to be sent to the client, regardless of the
compositor own shortcuts.
This protocol can be used for virtual machine and remote connection
viewers which require to pass all keyboard shortcuts to the hosted or
remote system instead of being caught up by the compositor locally.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This patch introduces a new protocol for grabbing the keyboard from
Xwayland.
This is needed for X11 applications that map an override redirect window
(thus not focused by the window manager) and issue an active grab on the
keyboard to capture all keyboard events.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
advertise the supported fourcc format modifiers along with supported
formats to the client. the 'modifier' event introduced here is
intended to replace the 'format' event from zwp_linux_dmabuf_v1
version 1.
bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
versions to 3.
v2: specify request name in event description for clarity (Yong Bakos)
v3: grammar fixup (Yong Bakos)
v4: add deprecation warning against 'format' event usage (pq)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
provide a mechanism that allows clients to import the added dmabufs
and immediately use the newly created wl_buffers without waiting on
an event. this is useful to clients that are sure of their import
request succeeding, and wish to avoid the wl_buffer communication
roundtrip.
bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
versions.
v2: specify using incorrectly imported dmabufs as undefined behavior
instead of sending success/failure events. (pq, daniels)
v3: preserve the optional protocol error added in v2 and explicitly
state the outcome of import success or failure (pq)
v4: clarify create_immed failure cases and error codes (pq)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
some restrictions must be placed on this or else it becomes legal for
the compositor to place popups in unexpected locations
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
clearly state the request name in format event to avoid abmiguous
interpretation between 'zwp_linux_buffer_params_v1::create' and
'zwp_linux_dmabuf_v1::create_params' requests.
v2: grammar fixup (Yong Bakos)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Suggested-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Enum entries and message arguments are sometimes preceded by a blank line, but
often aren't.
Standardize the format of the protocol specification by removing blank lines
preceding a list of message arguments and enum entries.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Make all the descriptions consistent by starting the description with a
simple verb (set instead of sets, etc.) Add or rework a few of the
existing descriptions to fit this form.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
These should all be pretty straightforward; there are no behavioral
changes.
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Adjust minor grammar issues, for clarity.
This patch cherry-picks some relevant changes from an earlier series,
patches 3 to 5. See:
https://lists.freedesktop.org/archives/wayland-devel/2016-April/028078.html
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Interface names are lower_snake_case, and corresponding descriptions
should match, for accuracy and clarity. This renaming only affects
description text, to follow the convention that exists elswhere in
this protocol document and in other protocol docs, when referring to
interface names.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Replace the tab indentation of the MIT license with appropriate spaces.
Add one missing line break between two description paragraphs.
Adjust two line breaks to keep descriptions under 80 chars / line.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
In order to get feedback of available space where a client can create
its popup, let it create requset that its popup rectangle being resized
would it not fit the within the work area. This adds two new constraint
adjustment values to the adjustment enum, and dimension parameters to
the xdg_popup.configure event.
The existing constraint adjustment actions take precedence, and resizing
will only be triggered if all other adjustments requested didn't manage
to make the popup rectangle fully visible.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Instead of allocating state ranges that desktop environments can use as
they want, let them introduce their own protocol and their own enums.
If such desktop environment protocols need the configure/ack_configure
semantics, they can design their protocols to extend xdg_surface, and
make their private configure events a latched state tied to
xdg_surface.configure.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Acked-by: Bryce Harrington <bryce@osg.samsung.com>
Make it clearer what the focus semantics are during a popup grab. In
short, when a grabbing popup is mapped, the top most popup will always
have keyboard focus, while pointer and touch focus works just as normal
except that only surfaces from the grabbing client will receive pointer
and touch focus.
This patch doesn't really change any semantics but rather clarifies
what was ambiguous before.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@osg.samsung.com>
xdg_positioner is a method for declarative positioning of child surfaces
(currently only xdg_popup surfaces). A client creates a description of a
positioning logic using the xdg_positioner interface. The xdg_positioner
object is then used when creating a xdg_popup for describing how the
child surface should be positioned in relation to the parent surface.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Mike Blumenkrantz <zmike@samsung.com>
Acked-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Turn xdg_popup into plain temporary child surfaces without any grabbing
or mapping order requirements by default.
In order to create grabbing popup chains, a new request 'grab' is
introduced which enables more or less the same semantics and
requirements as xdg_popup previously had related to grabbing, stacking
and mapping order.
This enables using xdg_popup for creating tooltips and other user
interface elements that does not want to take an explicit grab.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Mike Blumenkrantz <zmike@samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Quentin Glidic <sardemff7+git@sardemff7.net>
The reason for using wl_surface before was that xdg_popup and
xdg_surface (now xdg_toplevel) had no common interface other than
wl_surface, but since xdg_surface is now the base interface, lets use
that.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Benoit Gschwind <gschwind@gnu-log.net>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
The long lines stood out, break them by putting the summary on its own
line.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Benoit Gschwind <gschwind@gnu-log.net>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
It makes the structure consistent with most other protocols and
provides a clear separation between what is done by the server and what
is done by the client.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Split out toplevel window like requests and events into a new interface
called xdg_toplevel, and turn xdg_surface into a generic base interface
which others extends.
xdg_popup is changed to extend the xdg_surface.
The configure event in xdg_surface was split up making
xdg_surface.configure an event only carrying the serial number, while a
new xdg_toplevel.configure event carries the other data previously sent
via xdg_surface.configure. xdg_toplevel.configure is made to extend,
via the latch-state mechanism, xdg_surface.configure and depends on
that event to synchronize state.
Other future xdg_surface based extensions are meant to also extend
xdg_surface.configure for relevant window type dependend state
synchronization.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Mike Blumenkrantz <zmike@samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Some application may wish to restrict their window in size, but
xdg-shell has no mechanism for the client to specify a maximum or
minimum size.
As a result, the compositor may try to maximize or fullscreen a window
while the client would not allow for the requested size.
Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
the client can tell the compositor what would be its smallest/largest
acceptable size, and that the compositor can decide if maximize or
fullscreen is achievable, draw an accurate animation, etc.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
