[PATCH] xdg-shell - yet another proposal (this time for real).

[Jasper St. Pierre]

And as I explained on IRC, I don't want this in an initial dump. The
motivation of this xdg_shell approach is to keep it small and land it now.
We can add functionality later, but I'd rather not spend too much time in
heated discussions on the list about client-side vs. server-side
decorations.

If you write some code, on the other hand... :)


On Thu, Nov 14, 2013 at 1:44 PM, Axel Davy <davy at clipper.ens.fr> wrote:

> Hello,
>
> 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
> or SSD).
>
> 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 of
> mode,
> and the client would get the back the same event than before, telling
> him what the compositor wants him to use).
>
>
> Axel Davy
>
> 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
>> decide.
>>
>> 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
>> think.
>>
>> 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
>> tomorrow.
>>
>> 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
>> patience.
>>
>>
>> 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
>>
>>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131114/94d9feb5/attachment.html>