Fwd: Thoughts about decoration information in the xdg_shell

[Cedric BAIL]

Hello,

On Fri, Nov 15, 2013 at 12:17 PM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> this is a reply to the topic of whether to have information about decorations
> in the xdg_shell at all (see [1]). Sorry that I don't reply to the right
> message, had not been subscribed to the list.
>
> I want to outline why we in the KDE Plasma team would prefer to have the
> possibility to tell clients whether to draw decorations or not. In Plasma we
> have multiple shells and will be able to switch at runtime. From the window
> manager perspective the main difference is currently the handling of window
> decorations. Our touch oriented shell doesn't have decorated windows, our
> netbook shell only has decorated windows for dialogs and our desktop shell has
> a typical window decorated style, but not enforcing SSD (there are valid use
> cases like yakuake).
>
> This gives us quite some flexibility to adjust at runtime (add keyboard to
> tablet to get a desktop). An application doesn't need to know what the shell
> currently looks like. The shell takes care of handling all of that.

We do have the same kind of functionality with Enlightenment and EFL
on X right now, but it doesn't work the same way.

The application does expose a list of profile it is designed for in a
ordered list of strings (things like: "mobile", "tablet", "tv",
"desktop", ...). The window manager when first seeing the window try
to find the best matching place for that list of profile and set back
the chosen profile on the window. The toolkit and the application then
can take advantage of that information to best fit the current
environment. Of course after the initial frame is pushed to screen, it
is possible for Enlightenment to change the profile and move the
window to a screen that better fit its need.

There is arguably a lot of trick to make that work with X and avoid
rendering the wrong frame on the wrong screen, so I don't feel like we
should try to care about it there. But as we are still early in the
process of Wayland, it is maybe a good time to just think about the
right solution to this use case. So how could we do this kind of
negotiation on Wayland so that it work best with all toolkits and
Wayland implementation ? Is there any interest from others to have
this feature working across environment ?
-- 
Cedric BAIL