| Age | Commit message (Collapse) | Author |
|---|
|
Since the abbreviation "XDG" starts with a vowel sound, the correct
article is "an."
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
|
|
This wasn't explicit reading the mapping requirements.
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
Signed-off-by: Simon Ser <contact@emersion.fr>
|
|
This commit adds protocol additions making it possible to request that a
popup should be repositioned according to a new xdg_positioner object.
Explicit popup moving is done using a new request on xdg_popup:
xdg_popup.reposition. What it does is change the parameters used for
positioning a popup by providing a new xdg_positioner object. This
request is coupled with a new event; xdg_popup.repositioned, sent
together with the configure events (xdg_popup.configure and
xdg_surface.configure) to notify about the completion of the reposition
request. The reposition request also takes a token that is later passed
via the repositioned event; this is done so that a client may determine
for which reposition request the compositor has sent configure events.
Synchronization between surfaces to avoid state application race
condition are deliberately left out, and should be handled by an
external protocol.
To brief the compositor of the future dimension of the parent that the
compositor should position the popup against, a
xdg_positioner.set_parent_size request is added.
Lastly, a request to couple a xdg_positioner object with a parent
configure event is added (xdg_positioner.set_parent_configure) in
order for a compositor to pair a popup reposition request with a pending
configure event, and it's resulting window geometry. This is necessary
to, for example, properly constrain a popup given a future parent state.
An example of when this may be necessary is an interactive resize where
both the toplevel position and the relative popup position changes.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
|
|
This commit adds protocol additions making it possible to implicitly
reposition an already mapped popup if the conditions for the constraint
changed (e.g. toplevel moved).
Implicit popup moving is done by setting a adjustment flag on the
positioner used to create it that will cause the compositor to adjust
the position as the conditions used to constrain it change.
These changes may include, for example, changes in the position of the
parent window or the geometry of the work area. To allow the client to
update its content in response to the updated position, the client must
ack the configure event, optionally with new content. Until the client
acks this configure event, the existing positioner will continue to be
used.
Implicit repositioning by itself is racy regarding inter-surface
synchronization of applied state. Inter-surface synchronization is
deliberately left out of xdg-shell, and left to be handled externally.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
|
|
It mentioned the now removed x, y parameters of xdg_surface.get_popup.
The xdg_positioner now has the relevant documentation that was
previously documented by the now removed paragraph.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
|
|
This helps binding generators such as the one in wayland-rs.
Signed-off-by: Ivan Molodetskikh <yalterz@gmail.com>
|
|
LibreOffice is one big binary with explicit brandings for different
application modules. This is represented in X11 by a different
WM_CLASS setting for a window. The WM_CLASS is changed based on the
loaded document at runtime. As a result LibreOffice already offers
multiple desktop files with different icons, StartupWMClass
entries and application names.
This amendment of the set_app_id request just explicitly specifies
the use case to change a surfaces' app ID at runtime, so a compositor
implementor is made aware of it. Just as the WM_CLASS, a change of
the app ID should result in an update of the propertes of a surface
depending on the app ID, like the window icon specified in the
desktop file or a re-grouping of the surfaces in a task manager.
Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
|
|
As requested by Mike, update the E-mail address listed in the README.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Signed-off-by: Sebastian Krzyszkowiak <dos@dosowisko.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com>
|
|
The wording in xdg-shell's `set_*` requests implies the compositor
*will* honour the client's request.
This would give clients the control over their actual state, while the
general expectation is that clients kindly ask for state changes which
the compositor may follow.
This patch ensures the actual protocol text reflects these expectations.
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
The xdg-shell documentation had part of the maximized state render
implications in the `set_maximized` request documentation, not the
actual state.
This moves the relevant lines into the state description.
Signed-off-by: Markus Ongyerth <wl@ongy.net>
Reviewed-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
It seems that this was partially done in
a3cf97ff982638bf7ed23b4303eba280c521b54d; this patch just corrects an
oversight.
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
this adds implementation from a related discussion long ago in which
it was decided that it would be useful for clients to know if/where their
windows were tiled so that various behaviors and visuals could be modified
to improve UX
a window which is e.g., tiled on the right side of the screen would set the
right|top|bottom tiled states in configure
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
[Jonas: Minor formatting fixes]
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Changes since v2: simplified docs
Changes since v1: added since=2 to enum members
|
|
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
|
|
Having a strict requirement on clients obeying the configured window
geometry for fullscreen toplevel surfaces might have the side effect of
making it harder or impossible to implement various hardware
optimizations on certain system configurations. By softening
requirements on the geometry while loosely defining the border fill, we
remove that restriction.
Clients that still want total control of the surrounding area can
still for example prepare the attached buffers to match the configured
surface size, or use subsurfaces in combination with wp_viewporter to
make up a surface matching the fullscreen window geometry dimensions.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Arnaud Vrac <rawoul@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@samsung.com>
|
|
The description for xdg_toplevel.unset_fullscreen was completely
missing, so add it.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@samsung.com>
|
|
It was not explicitly specified (as it is in set/unset_maximize) that
the compositor will respond with a configure event when a client asks to
be fullscreened, and the meaning of the output parameter was somewhat
awkwardly described.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@samsung.com>
|
|
Specify that the maximize/unmaximize state requests only affects the
state a surface will return to if it is currently fullscreen.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@samsung.com>
|
|
There is no configure 'request' only configure 'events'.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Mike Blumenkrantz <zmike@samsung.com>
|
|
While there is no currently known usages of setting an anchor offset on
the same axis as the 'flip' constraint action is set, it must still be
specified so compositors behave the same.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Bitfields allowed for impossible combinations of anchor edges, such as
being on the left and right edge. Use of explicit enumerations means we
don't need to handle that case.
Signed-off-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
ensure that this is as precise and explicit as possible for all useful
cases and also define previously-unspecified behavior
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Allow using some other protocol (custom, or future xdg_* based) to set
up the parent-child relationship of a popup. This allows future
protocols to use xdg_popup when mapping popups over surfaces not based
on xdg_surface.
An example use case for this is the window menu, where a shells UI
client can use xdg_popup to create popup menus over windows it does not
have a xdg_surface of by having a custom protocol setting up the proper
parent-child relationship.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-By: Mike Blumenkrantz <zmike@osg.samsung.com>
|
|
Change the semantics of xdg_toplevel.set_parent to allow chaining
multiple parent-child relationships together, while allowing
arbitrarily unmapping parents, while keeping what is left over of the
chain intact.
This makes things easier to manage when parent-child relationships
cross client borders, for example when using xdg_foreign.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
|
|
Setting a null-surface as a toplevel parent should unset the
parent-child relationship. This was not specified, so lets do that.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
|
|
A client might want to change the window geometry without wanting the
window to be moved, for example when changing the width of the border.
Point out that the compositor should treat the (x,y) coordinate of the
geometry as the top-left corner of the window, and not change the
position of the window as it appears on the screen if the (x,y)
coordinate changes.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-By: Mike Blumenkrantz <zmike@osg.samsung.com>
|
|
There is no such thing as 'monitor' in Wayland, only outputs.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-By: Mike Blumenkrantz <zmike@osg.samsung.com>
|
|
Allow setting an empty anchor rectangle, so that one can map a popup
against a coordinate, not a pixel.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-By: Mike Blumenkrantz <zmike@osg.samsung.com>
|
|
Don't refer to things as "traditional desktop" as it is not defined
nor clear what that refers to; instead reword things in a more explicit
way. A reason for this is that xdg-shell is not strictly meant only for
traditional window stacking based desktop environments, but should be
equally suitable for stacking, tiling and potentially other styles as
well.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-By: Mike Blumenkrantz <zmike@osg.samsung.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Mike Blumenkrantz <zmike@osg.samsung.com>
|
|
Rename the interfaces according to the wayland-protocols policy. Since
the name 'xdg_shell' as an interface was already taken (by
xdg-shell-unstable-v5) zxdg_shell_v6 was renamed xdg_wm_base. The
surface role related interfaces were not renamed, as naming collision
is only unmanagable when exposed as globals via the registry.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-By: Mike Blumenkrantz <zmike@osg.samsung.com>
|
|
Add a copy of xdg-shell unstable v6 to stable/xdg-shell/xdg-shell.xml.
Folliwing this commit, it will go through a set of changes, before
being declared stable.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: David Edmundson <davidedmundson@kde.org>
|
