Feedback on xdg-shell v5

[Martin Graesslin]

On Thursday, April 28, 2016 2:08:07 PM CEST Pekka Paalanen wrote:
> > > The biggest problem for me is the request set_window_geometry. I think I
> > > mentioned it already before on the wayland list. Basically I have no
> > > idea how to implement that in KWin. We have only one geometry for a
> > > window and that's mapped to the size of the surface/x11 pixmap. This
> > > geometry is used all over the place, for positioning, for resizing and
> > > for rendering. I cannot add support for this without either breaking
> > > code or having to introduce a new internal API. That's lots of work
> > > with high potential for breakage :-(
> Have you looked at what you need to do to support windows that are
> built from non-overlapping sub-surfaces, like what Jonas describes below?
> 
> I suspect you might end up having to do that major internal API work
> anyway by the sounds of it. A window may be a collection of surfaces,
> not just one.

Yes that's clearly a problem. I'm not happy with sub-surfaces allowing to 
overlap the parent. It's one of the many things where I think that sub-surface 
protocol is overdone and too complex.

So when implementing sub-surfaces in KWin I ignored this aspect. And will look 
into it when I first see a client doing that (pragmatic approach: don't 
implement something for a theoretical aspect)

> 
> How do you do the window geometry with server-side decorations? Why is
> using only a part of client surface so different from using a
> combination of client and server-only surfaces?

yes it sounds similar on first look and yes for server-side decorations we have 
such an architecture in place. We know the position where the actual window 
content starts and it's size. The geometry is in that case the combination of 
content and decoration. But this case is rather the opposite around. We don't 
add to the content size, we reduce. Also it doesn't help much even if it were 
similar. All the checks if (isDecorated) just won't hit for it.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160429/eacf9a18/attachment.sig>