D24455: [wayland] Implement window geometry more properly

[Vlad Zahorodnii]

zzag added a comment.


  In D24455#556025 <https://phabricator.kde.org/D24455#556025>, @romangg wrote:
  
  > Please give this diff a more telling name what it is about. You introduce a new cached buffer size value and redefine geom via window geometry. What this does and how it relates to all the other sizes we have is not clear to me.
  >
  > What would help: Create some images where the different areas of a window and what our sizes relate to are described. I mean it's clear from the specs what window and buffer geometry are supposed to be but we have/had geometry, client size, requested client size and so on.
  
  
  So, as said, the buffer geometry specifies a rectangle on the screen occupied by the main surface. The frame geometry is the geometry of the client excluding things like drop-shadows. Both the buffer geometry and the frame geometry don't have strict order between each other, so to speak. The buffer geometry can be completely inside the frame geometry, and vice versa.
  
  About redefining geom in terms of the window geometry... Well, we don't other sensible choices. If the client is decorated by kwin, the server-side decoration must be put around the window geometry and thus the frame geometry is actually window geometry + frame margins. If the client is not decorated or client-side decorated, the frame geometry corresponds to the window geometry. Such design doesn't require dramatic changes in things like snapping, or placement code. Last but not least, such geometry choice will help us fix all corner cases related to restoring from maximized or fullscreen mode. Of course we could send a configure event with width and height set to 0, but we don't do that.
  
  About the client geometry. I think it's worth to make the client geometry more explicit. We have two heavy users of it - X11Client and decorations, though decorations only need the size. In long term, I think we have to aim for the introduction of the client geometry. So, just to re-iterate, we would have four fundamental geometries: input, frame, client, and buffer (a zoo full of different geometries).
  
  requestedClientSize is the last requested window geometry size.
  
  I know that this patch does a couple of things at the same time, but there's no any other way around. In order to implement the window geometry, we need to have the buffer geometry to some extent.
  
  This patch is nasty as f but I do hope that this whole geometry hell will be resolved by 5.18.

INLINE COMMENTS

> romangg wrote in xdgshellclient.h:197
> Reducing complexity: can we just check `m_xdgShellSurface->windowGeometry().isValid()`?

Will change. I added this bool to avoid a few unnecessary comparisons in QRect::isValid. However, I guess it's a premature optimization.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D24455

To: zzag, #kwin
Cc: romangg, kwin, LeGast00n, The-Feren-OS-Dev, sbergeron, jraleigh, fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwin/attachments/20191029/89daa5cd/attachment-0001.html>