<table><tr><td style="">zzag created this revision.<br />zzag added a reviewer: KWin.<br />Herald added a project: KWin.<br />Herald added a subscriber: kwin.<br />zzag requested review of this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D24660">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>KDE is known for having a strong view on the client-side decorations vs<br />
server-side decorations issue. The main argument raised against CSD is<br />
that desktop will look less consistent when clients start drawing window<br />
decorations by themselves, which is somewhat true. It all ties to how<br />
well each toolkit is integrated with the desktop environment.</p>

<p>KDE doesn't control the desktop market on Linux. Another big "player"<br />
is GNOME. Both KDE and GNOME have very polarized views on in which<br />
direction desktop should move forward. The KDE community is pushing more<br />
toward server-side decorations while the GNOME community is pushing<br />
more toward client-side decorations. Both communities have developed<br />
great applications and it's not rare to see a GNOME application being<br />
used in KDE Plasma. The only problem is that these different views are<br />
not left behind the curtain and our users pay the price. Resizing GTK<br />
clients in Plasma became practically impossible due to resize borders<br />
having small hit area.</p>

<p>When a client draws its window decoration, it's more likely that it also<br />
draws the drop-shadow around the decoration. The compositor must know<br />
the extents of the shadow so things like snapping and so on work as<br />
expected. And here lies the problem... While the xdg-shell protocol has<br />
a way to specify such things, the NetWM spec doesn't have anything like<br />
that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with<br />
it is that it's a proprietary atom, which is specific only to GTK apps.</p>

<p>Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing<br />
anything like that would require major changes in how we think about<br />
geometry.</p>

<p>Recent xdg-shell window geometry patches adjusted geometry abstractions<br />
in kwin to such a degree that it's very easy to add support for client<br />
side decorated clients on X11. We just have to make sure that the<br />
X11Client class provides correct buffer geometry and frame geometry when<br />
the gtk frame extents are set.</p>

<p>Even though the X11 code is feature frozen, I still think it's worth<br />
to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize<br />
issues. Also, because KWin/Wayland is unfortunately far from becoming<br />
default, it will help us with testing some implementation bits of the<br />
window geometry from xdg-shell.</p>

<p>BUG: 390550<br />
FIXED-IN: 5.18.0</p></div></div><br /><div><strong>TEST PLAN</strong><div><p>Things like quick tiling, maximizing, tiling scripts and so on work as<br />
expected with GTK clients.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R108 KWin</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D24660">https://phabricator.kde.org/D24660</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>abstract_client.cpp<br />
abstract_client.h<br />
atoms.cpp<br />
atoms.h<br />
events.cpp<br />
geometry.cpp<br />
manage.cpp<br />
netinfo.cpp<br />
plugins/platforms/x11/standalone/glxbackend.cpp<br />
toplevel.cpp<br />
x11client.cpp<br />
x11client.h</div></div></div><br /><div><strong>To: </strong>zzag, KWin<br /><strong>Cc: </strong>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, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart<br /></div>