<div dir="ltr"><div>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. </div>If you write some code, on the other hand... :) </div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Nov 14, 2013 at 1:44 PM, Axel Davy <<a href="mailto:davy@clipper.ens.fr" target="_blank">davy@clipper.ens.fr</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 :<div class="HOEnZb"><div class="h5"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 </blockquote> </div></div><div class="HOEnZb"><div class="h5"> _______________________________________________ wayland-devel mailing list <a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </div></div></blockquote></div> -- Jasper </div>