Re: Custom shell surface protocol for Plasma surfaces

>  From implementation point-of-view, the main problem with our protocol
> is that it bloats XdgShellClient with desktop shell-specific things,
> e.g. positioning, taking focus, panel behavior, etc. Ideally,
> XdgShellClient should be concerned only about things that matter to
> xdg-shell clients.
>
> plasmashell has special needs and I think it deserves its own protocol.

I 100% agree we should have a different role than extending
xdgshell-toplevel as a long term goal.

What I would question is if we're going to make a change, whether we
should go directly to layer-shell.

It has a lot of advantages, but it means some bigger invasive changes
in how do things on the client side.

What I hoped to do was introduce a class in KWindowSystem that would
take semantic positions, then either move the window directly (on X)
or call into layer-shell somehow.

I'm not sure how feasible that would be to introduce within Plasma 5.

> I propose to revisit the plasma_shell protocol and maybe create v2 of
> it, which doesn't piggyback on existing protocols. This would simplify
> XdgShellClient and lead to cleaner code overall.
>
> I had a quick look at QtWayland's source code and so far it looks like
> we (KDE) can implement a custom shell surface extension on our side and
> instruct QtWayland to use it rather than xdg-shell(take my words with a
> grain of salt, though).
>
I looked before. The part that I didn't think was doable at the time
was having a custom protocol defer the first commit with a buffer
until it's been configured from the compositor, something we would
definitely need for layer-shell.

The other problem you'll hit is you need our qmenu popups to be
parented to a surface that Qt knows about.

David