Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: It appears to be the case that the invisible resize border is broken for many (all?) Qt/KDE apps, making their windows unnecessarily painful and alien to resize under GNOME 3. Basically I need to click the exact 1-2px border, which especially when being conditioned to GNOME 3's very comfortable wider resize click range around the window frame means I will constantly misclick when resizing and curse these broken-feeling applications. Affected apps are for example: 1. kate (both as packaged by Fedora, and downloaded via Flathub) 2. kmail 3. konsole Version-Release number of selected component (if applicable): qt5-qtbase-5.15.2-2.fc33.src.rpm How reproducible: 100% Steps to Reproduce: 1. Start GNOME 3 Wayland session 2. Install & launch kate 3. Resize a gnome terminal 4. Resize kate Actual results: kate resizes with a way, way smaller tolerance for where you need to click on the window border, while gnome terminal is way easier to resize Expected results: kate has same, wider tolerance with invisible resize area around the window compared to gnome terminal Additional info:
Okay so I asked in a Fedora chat just to be sure, and it seems to be broken for most (all?) other people who tried this as well. Now what I find weird is, why is this even up to the application? I thought surely GNOME 3 is handling this resizing outside the frame in particular. Or does Qt set some sort of special flag that it doesn't want this behavior enabled? (That'd be weird...) All in all, a very confusing bug.
Triaging to qgnomeplatform (not entirely sure this is in our realm either, may be CSD issue)
It is a QGnomePlatform bug. I'm currently working on improvements. Hopefully all issues will be solved soon.
It turns out wine also seems to have this problem for me right now. Does wine somehow have wayland patches that use Qt? Or is this a different issue? Because the impact is the same, and I am wondering now if it will also affect all SDL2 applications once SDL2 merges the Wayland decoration support https://github.com/libsdl-org/SDL/pull/4068 .
Like thinking more about this, shouldn't pixels being grabbed outside the window's own area be a compositor side thing anyway? If that is not, this seems like an architectural problem that will pop up again and again with every single Wayland client lib that renders its own decorations (as GNOME asks them to). Maybe it might be worth revisiting if this needs to actually be moved into Mutter instead, and removed from the client code?
If I should file an upstream bug somewhere, e.g. with mutter, please let me know. I would like to see this solved since it's quite bad for usability. And will a QGnomePlatform change even do anything for Flatpak sandboxed Wayland Qt applications that don't use anything of the host system outside? I am a bit concerned that the fix might be occurring in the wrong spot.
I have already a fix, I even pushed it to Fedora, but a new issue in QtWayland is breaking it and I'm currently in the middle of investigation.
FEDORA-2022-69bf07b7ea has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-69bf07b7ea
FEDORA-2022-69bf07b7ea has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-69bf07b7ea` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-69bf07b7ea See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-69bf07b7ea has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
This seems to be broken still for Opera! I'm also wondering, isn't qgnomeplatform something used on the Wayland app's side? It seems to me like this would need to be fixed in gnome-shell. As a result, even Wayland apps not really meant for or written with GNOME in mind would work fine, I don't really understand how it's a good idea to have this handled by the app. Why even allow an app to have no such resize border?
(In reply to ell1e from comment #11) > This seems to be broken still for Opera! > > I'm also wondering, isn't qgnomeplatform something used on the Wayland app's > side? It seems to me like this would need to be fixed in gnome-shell. As a > result, even Wayland apps not really meant for or written with GNOME in mind > would work fine, I don't really understand how it's a good idea to have this > handled by the app. Why even allow an app to have no such resize border? QGnomePlatform will not be used in Opera as it's not a Qt application, is it?
Yes, that was my point. That this probably needs to be fixed in the compositor to work correctly for all apps, right? So this doesn't actually seem like a QGnomePlatform bug to me, or only in part.
Reopening since it doesn't seem to be fixed, my apologies if this is the wrong thing to do. Also, I have no idea of the internals so this might be a completely the wrong guess, ut it seems to me like this can never work unless it's addressed in gnome-shell. Or how would a random wayland application even know that it's running under gnome-shell and needs to somehow locally supply this larger resize border if it's client-side, is that part of the protocol? If it's not part of the protocol it seems a bit odd and hacky and like the wrong approach to solve this on the wayland client side (=which includes Gtk+/Qt platform side).
(Sorry for being unclear, when I said "this can never work" I meant this can never work for any new toolkit or other sort of client-side application popping up. Like, this doesn't seem like it's a Qt problem but rather why-doesn't-gnome-shell-just-enforce-a-proper-resize-area problem, if that makes sense? Sorry if nothing I'm saying is any sort of understandable.) In any case, in Opera it's still not working which seems to support this guess of mine at least. That it's not really possible to make all applications adhere unless it's done at the compositor end, I mean.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This component is maintained by the GNOME project. Issues with it should be reported directly to GNOME at https://gitlab.gnome.org/GNOME/. This issue should only be kept open if it: 1. Relates to Fedora packaging or integration with other Fedora components 2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions If this issue isn't needed for either of these two reasons, please: * create an issue with GNOME * add a link to the GNOME issue here * close this issue as CLOSED/UPSTREAM Thank you!