https://bugs.kde.org/show_bug.cgi?id=379637
--- Comment #20 from Gianluca Pettinello <gianluca.pettine...@gmail.com> --- (In reply to Martin Flöser from comment #19) > 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. Thanks Martin for all the explanations. I'm not an expert programmer, indeed I'm a chemical engineer and my comment about documentation comes from personal experience: I saw several very competent people leaving the company and experienced loss of knowledge because the company was not keen enough to get their knowledge documented. Coming back to your explanation I see that gtk windows don't have shadows, so kwin someway clips the shadow that gtk (sigh!) adds to window geometry to make the geometry. So my thought (probably it is naif) is that if we trap the type of window (_gtk_frame_extents) then we can apply the shadow as if it were a normal window / menu. There are some occurrences of gtk_frame_extents in kwin code but I'm not able to understand what happens. There are two methods that retrieve xwindow properties. -- You are receiving this mail because: You are watching all bug changes.
