https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #19 from Martin Flöser <mgraess...@kde.org> --- Ok, I think I need to explain more on the situation on X11. The problem is not that the code is fragile, undocumented or umaintained. The code is good, the quality of the code in question is superb and one can easily understand which area of X11 it reflects. No increase of documentation would make it possible to implement this change request. Let's look at the root problem. On X11 the window geometry is retrieved through the get_geometry call: https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:GetGeometry This specifies the geometry of a drawable - either a pixmap or a window. That's what KWin's geometry handling code is based on. Now what GTK did is use this window geometry and added the shadow into it. Additional there is a property which indicates what to subtract from the x geometry to get to the window geometry. If we wouldn't subtract it, we would snap to shadow, quick tiling would include shadow, maximize would include shadow, etc. etc. So basically everywhere where we use geometry we would have to remove that this maps to x window geometry and replace it by an abstract geometry concept which is either the geometry or the geometry subtracted by shadow. And this is the fundamental problem for us. When KWin was developed nobody thought that the geometry of a window would not match the geometry. Now you might wonder how things like window decorations work? Well it's still a window. The actual client window gets reparented to the window decoration and then we just use the geometry of the decoration window again. The geometry handling in KWin is deep involved and the assumption is carried everywhere. It goes into the effect system (e.g. Present Windows uses it to layout), it's deep in the compositor (we actually have a check to verify the geometry matches the pixmap size, if it doesn't we don't render the window, see https://phabricator.kde.org/source/kwin/browse/master/scene.cpp$1042). We have multiple level of convenient api for it: Toplevel::width, Toplevel::height, Toplevel::x, Toplevel::y, Toplevel::size, Toplevel::pos, etc. So it's not just one method we have to check. Then there are methods like isOnScreen intersecting the screen geometry with the window geometry. So all of that is a huge effort to restructure the code base to support this new requirement. And then there are multiple things which are completely unknown to me as this is a not standardized protocol: when resizing do we have to add the shadow or not? A maximized window does it include the shadow or not? How does gravity interact with shadow? What if a base increment is set? What about vertical only or horizontal only maximize state? Gtk doesn't like those, so do they support it? Is it possible to have shadows only on some sides or is it always all? Can we expect that Gtk won't change that? After all they broke us here several times. So to reiterate some important points: * this is not a bug on our side, our code is written against the X protocol, ICCCM and EWMH * GTK changed basic understanding of what a window geometry is, this understanding is completely incompatible to the assumptions KWin was implemented on * The code base is in a superb state, geometry handling has very seldom bugs, it's a done and working code base * The effort is comparable to adding Wayland support - the difficult part was getting the geometry handling done * implementing the change is a huge effort as the code base is large and it touches complex areas of X where the expected behavior is undocumented by GTK (I just tried google for _GTK_FRAME_EXTENTS and found nothing) ---- Comparing to the state on Wayland: on Wayland the geometry and visual geometry are separated. The visual geometry is defined by the size of the attached buffer. The geometry of the window is not directly mapped from the buffer as we have concepts such as scale built into the protocol. While KWin still is largely based on the idea that visual geometry matches window geometry, it's not as bad as on X11. We already weakened the assumption a lot by adding window decorations ;-). Implementing the required request should be relatively straight forward and doable without larger problems. We have a well tested code base on Wayland and I am sure it can be implemented without regressions. The main reason why the request is not implemented is that there was a little bit of version mess when that area of code got written. That's now resolved and it's possible to test with real world applications. Overall I think the way forward is supporting Wayland. On X11 we need to find different solutions which don't involve changing KWin or convince GTK to not build a GUI based on fundamental changes to X11. I understand that they are not able to understand KWin's problems - after all Mutter supports it. Maybe it's possible to talk to the devs again if someone other than me approaches them. I got from the responsible dev once the reply that he ignored all my bug reports because it was me. Looking around it seems to me that Emmanuale Bassi is more open to us and more open to changes to support us. Maybe Nate could try to approach them - he is not a dev involved and focused on the quality of the whole system. Explaining that KWin cannot implement it for the reasons given here might help. Explaining that you are afraid of breakage might help. After all if one is responsible for quality the change in KWin is something one needs to take a step away from if quality is supposed to matter. -- You are receiving this mail because: You are watching all bug changes.
