[PATCH] xdg-shell - yet another proposal (this time for real).
davy at clipper.ens.fr
Thu Nov 14 10:44:47 PST 2013
There has been some discussions on IRC about the possible support of
decoration side negociation in xdg_shell.
A client would have to support CSD if it uses xdg_shell.
And I suggested the folowing mechanism:
.when binding to xdg_shell,
the client gets an event telling him the compositors's
preferred mode between CSD and SSD.
. When creating a surface, the client tells which he prefers between
CSD and SSD
. The client gets back an event to tell him what will be the decoration mode
for the surface (the compositor can follow client choice, or enforce CSD
And I suggest too to be able to change that after creation (ie be able to
send a new request to tell to the compositor the client wants to change
and the client would get the back the same event than before, telling
him what the compositor wants him to use).
Le 07/11/2013 10:32, Rafael Antognolli a écrit :
> Hello all,
> Following is the same description as in my previous wrong email, but with the
> correct patch attached.
> I'm trying to summarize part of the discussion in this new patch, but it's not
> the final one.
> As far as I understood, the goal is to end up with something like this for
> keyboard focus:
> W = compositor
> A, Z = client surfaces
> Viewport change:
> W to Z: You are deactivated.
> W to A: You are activated.
> A to W: Do these things.
> So, I added "activated" and "deactivated" events, that the compositor can use
> to inform clients what they are. And there's a take_focus request that can be
> used by a client to ask for activation, but it's up to the compositor to
> Regarding the surface fullscreen, maximized, etc, I added surface states as
> enum's, that can be set/unset, and events from the compositor to request that a
> given state should be set/unset.
> For those states that take parameters, I added separate requests for setting
> the parameters before setting the state. It should all take place after commit
> anyway, so that shouldn't matter much. Take a look at the docs and say what you
> I didn't change transient/popup surface types yet, but from what has been said
> in the ML thread, I think they also should be surface states now. Correct me if
> I'm wrong. Otherwise I'm going to send an updated version with those changes
> I also talked to jekstrand (I think) about stacking, will send an updated
> version with what I understood from that tomorrow. Should be simple.
> Any feedback is appreciated, and thank you guys for the input so far and the
> Rafael Antognolli (1):
> xdg_shell: Add a new shell protocol.
> protocol/Makefile.am | 2 +-
> protocol/xdg-surface.xml | 381 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 382 insertions(+), 1 deletion(-)
> create mode 100644 protocol/xdg-surface.xml
More information about the wayland-devel