With the new decoration of the GTK Engine and the Breeze theme I cant resize any windows that use this new title bar e.g. Tilix, File-Roller etc. Maximize & minimize works just fine. Around the window I could identify some spots where you can resize the window in height. It's usually around the UI elements such as maximize/minimize etc.
this also affects Firefox
We've been trying to find the best way around this while preserving client-side decorations for a long time now. So long as GTK's CSD implementation relies on undocumented behavior in Mutter-like compositors, it looks like the only long-term solution will be to force KWin's server-side decorations on these applications. This should be negotiated properly in the Wayland session, but for X11 we will have to make some sort of script to force SSDs, something which was possible in the past but might require us to name each specific GTK CSD application in recent versions of GTK. Just letting everyone know the situation and why we can't get normal invisible resize areas around GTK's CSD windows. Other CSD-using applications appear to work, however, just not with GTK.
*** Bug 394417 has been marked as a duplicate of this bug. ***
*** Bug 403696 has been marked as a duplicate of this bug. ***
This bug makes various GTK apps unusable, such as the Peek screen recording app which requires resizing its window to change the selected capture area.
I'm still getting a 1px resize handle around my window on peek. I will admit it's not an easy target, but can we confirm if we have the same behaviour
I tested it before and didn't find a one-pixel resize border. Just tried it again and it seems that I do in fact have a one-pixel resize border and the left and top edges, but not on the right and bottom edges. I must have been trying the bottom or right edge before.
Fixed for me (at least with fire fox) Operating System: Fedora 30 KDE Plasma Version: 5.15.5 KDE Frameworks Version: 5.58.0 Qt Version: 5.12.1 Kernel Version: 5.1.6-300.fc30.x86_64 OS Type: 64-bit
Firefox must be doing its own thing then, because this is still very much broken for the common case.
With 5.16.4 I get a 1px border but at least it's resizeable now... With the 5.14.5 shipped by debian buster, I only get a 1px invisible resizing area on the top edge.
This already works on Wayland, but requires implementing the GTK_FRAME_EXTENTS protocol in KWin to work on X11. Moving to KWin since that's where the work needs to be done. Happily, this work is in fact planned and I'm hoping it will land in Plasma 5.18.
*** Bug 379637 has been marked as a duplicate of this bug. ***
*** Bug 365924 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #11) > This already works on Wayland, but requires implementing the > GTK_FRAME_EXTENTS protocol in KWin to work on X11. Moving to KWin since > that's where the work needs to be done. Happily, this work is in fact > planned and I'm hoping it will land in Plasma 5.18. In my opinion this should be fixed both at kwin and breeze-gtk. Kwin should implement the GTK_FRAME_EXTENDS protocol but the breeze gtk theme should detect if the window manager doesn't support it (like for example openbox) and add at least a 2px border, in case that someone wants to use breeze theme outside of KDE (I assume that you want breeze theme to be widely adapted even outside of KDE). I don't have any experience with gtk themes, but I was maintainer of the manjaro lxde for a while and I can confirm that at least adwaita and adapta gtk themes are doing this (CSD gtk apps have no border when used in window managers like xfwm4 but have a thick border when used in window managers like openbox).
That seems reasonable. Since we're now using this Bugzilla ticket to track the KWin side of the work, can you file a new one for the proposed changes to the Breeze-GTK theme?
Git commit 84d75cb5674577098d584c7f3634ea2a81d8b9f2 by Vlad Zahorodnii. Committed on 27/11/2019 at 12:12. Pushed by vladz into branch 'master'. [x11] Add support for _GTK_FRAME_EXTENTS Summary: KDE is known for having a strong view on the client-side decorations vs server-side decorations issue. The main argument raised against CSD is that desktop will look less consistent when clients start drawing window decorations by themselves, which is somewhat true. It all ties to how well each toolkit is integrated with the desktop environment. KDE doesn't control the desktop market on Linux. Another big "player" is GNOME. Both KDE and GNOME have very polarized views on in which direction desktop should move forward. The KDE community is pushing more toward server-side decorations while the GNOME community is pushing more toward client-side decorations. Both communities have developed great applications and it's not rare to see a GNOME application being used in KDE Plasma. The only problem is that these different views are not left behind the curtain and our users pay the price. Resizing GTK clients in Plasma became practically impossible due to resize borders having small hit area. When a client draws its window decoration, it's more likely that it also draws the drop-shadow around the decoration. The compositor must know the extents of the shadow so things like snapping and so on work as expected. And here lies the problem... While the xdg-shell protocol has a way to specify such things, the NetWM spec doesn't have anything like that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with it is that it's a proprietary atom, which is specific only to GTK apps. Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing anything like that would require major changes in how we think about geometry. Recent xdg-shell window geometry patches adjusted geometry abstractions in kwin to such a degree that it's very easy to add support for client side decorated clients on X11. We just have to make sure that the X11Client class provides correct buffer geometry and frame geometry when the gtk frame extents are set. Even though the X11 code is feature frozen, I still think it's worth to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize issues. Also, because KWin/Wayland is unfortunately far from becoming default, it will help us with testing some implementation bits of the window geometry from xdg-shell. FIXED-IN: 5.18.0 Test Plan: Things like quick tiling, maximizing, tiling scripts and so on work as expected with GTK clients. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: cblack, trmdi, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24660 M +38 -0 abstract_client.cpp M +38 -1 abstract_client.h M +0 -1 atoms.cpp M +0 -1 atoms.h M +3 -2 events.cpp M +90 -74 geometry.cpp M +11 -5 manage.cpp M +2 -1 netinfo.cpp M +1 -1 plugins/platforms/x11/standalone/glxbackend.cpp M +4 -1 toplevel.cpp M +172 -17 x11client.cpp M +19 -9 x11client.h https://commits.kde.org/kwin/84d75cb5674577098d584c7f3634ea2a81d8b9f2