Bug 1773650

I cannot reproduce any cursor size issue, there used to be one, but it was fixed some time ago. Do you you keepassxc from Flatpak or regular Fedora package? I also tried to copy non-ascii characters from/to keepassxc to gedit and that works just fine.

Can you be more specific about your issues? How can I try to reproduce them?

Created attachment 1638120 [details]
Theming issues under QPA=wayland. Cursor isnt shown by gnome-screenshot

Created attachment 1638121 [details]
obs draw surface not working

Created attachment 1638122 [details]
Kdenlive isnt clickable at all, not resizable and just generally stuck.

(In reply to Waffshappen from comment #2)
> Created attachment 1638120 [details]
> Theming issues under QPA=wayland. Cursor isnt shown by gnome-screenshot

Theming issue in your case are different client side decorations. This is unfortunately not really easy to fix. The reason why it works in case you use xcb platform plugin is that the decorations are painted by Mutter, which is not the case when wayland platform is used and we have to paint them instead in QGnomePlatform.

(In reply to Jan Grulich from comment #1)
> I cannot reproduce any cursor size issue, there used to be one, but it was
> fixed some time ago. Do you you keepassxc from Flatpak or regular Fedora
> package? 

Regular package. I have flatpak and gnome-store disabled/removed.

> I also tried to copy non-ascii characters from/to keepassxc to
> gedit and that works just fine.
I just re-tested it, that must have disappeared with the very last update, as is the cursor size. Yay!

> 
> Can you be more specific about your issues? How can I try to reproduce them?

However, theming issues and broken-ness are still there. The cursor has the default adwaita/breeze-dark look, the window decorations look out of place entirely and obs/kdenlive are broken, only under QPA=wayland.


obs-studio: from rpmfusion
no draw surface under qpa=wayland, works under xcb
kdenlive: from rpmfusion
entire ui stuck under qpa=wayland, works under xcb

qt theme issues under qpa=wayland
(cursor changes on hover to a wrongly colored variant, window decoration theme not applied):
all qt applications.

As Jan Grulich already wrote, the window decoration issues are a deliberate GNOME "feature": they refuse to support compositor-drawn window decorations under Wayland. (They cannot do that under X11 because it would affect too many legacy applications.) As a result, all applications are forced to draw client-side decorations. Needless to say, it is impossible for applications using different toolkits to draw exactly the same window decorations. (Unless maybe we can get GTK to draw them somehow? But that is definitely not trivial in a Qt application.) To me, this looks like a deliberate move to make non-GTK applications look bad and force developers to use GTK.

Hi, Qt Wayland developer here:

I'm also not quite happy about the combination of gnome-shell, qt and wayland yet. However, much of what has been mentioned we are actually unable to do anything about.

> 1. Open keepassxc. Copypaste a non-ascii password.

Should be fixed in Qt 5.13.0 and later. If not, please report a bug

> Telegram-desktop: mixed issues, most notably screenshot pasting from clipboard is broken

Should probably be reported to Telegram, perhaps Qt (I haven't seen any such reports).

> 2. Open kdenlive/obs-studio. Observe it not working.

obs-studio has lots of platform specific code, they probably need to port it to wayland, as far as I know, nothing we can solve from within Qt Wayland. If we are going to wait for every application to port their platform-specific code before switching the default, it's probably never going to happen.

> Theming: the gtk theme is not respected, at all.

As mentioned, window decorations won't look gtk-ish and gnome has actually been one of the main opponents of xdg-decoration. Could perhaps be solved with libdecoration, but someone would need to put in the work.

> The cursor is enlargened.

There is actually no cross-compositor way to configure cursor theme and size on Wayland. Qt reads environment variables XCURSOR_THEME and XCURSOR_SIZE, as many other toolkits do. Work was started by wlroots developers on a wayland protocol, but it was abandoned as other things were more broken and time was needed there. https://patchwork.freedesktop.org/patch/257280/ in case someone want's to pick it up (I have an implementation ready for Qt Wayland in case it gets accepted into wayland-protocols).

Btw, we have a list in the Qt bug tracker with things we would like to fix in Qt before removing gnome-shell from the blacklist for Qt Wayland: https://bugreports.qt.io/browse/QTBUG-68619

The only thing on that list now, is positioning of menus, which is pretty broken due to Qt being built around absolute window positioning being available (which is not the case on wayland). 

Btw: If you decide to keep QT_QPA_PLATFORM set in fedora, you should probably change it to QT_QPA_PLATFORM="wayland;xcb" otherwise statically compiled applications without wayland are going to fail.

So I guess there are four categories:

1. Things that can't yet be solved in an acceptable cross-platform way. Examples are decoration consistency without xdg-decoration, cursor configuration without env vars or compositor-specific dbus APIs. When people say wayland isn't ready, in a way they are right, because there are no solutions for these things that people agree on.
2. Things not working because applications aren't ported or haven't blacklisted Wayland yet.
3. Bugs in gnome-shell that are exposed by running Qt applications (such as https://gitlab.gnome.org/GNOME/mutter/issues/199 (fixed) https://gitlab.gnome.org/GNOME/mutter/issues/963 (recently opened))
4. Legitimate bugs in qtwayland. (menu positioning)

I think categories 1 and 2 are annoying, yes, but they are not reasons for turning off Wayland for a single toolkit, they are reasons for not using Wayland at all. 

Category 3 and 4 is IMO what matters in this case. As far as I know menu positioning (https://bugreports.qt.io/browse/QTBUG-68636) and a freeze on gnome-shell (https://gitlab.gnome.org/GNOME/mutter/issues/963) are the only significant unsolved issues in these categories.

(In reply to Johan Helsing from comment #8)
> Hi, Qt Wayland developer here:
> 
> I'm also not quite happy about the combination of gnome-shell, qt and
> wayland yet. However, much of what has been mentioned we are actually unable
> to do anything about.
> 
> > 1. Open keepassxc. Copypaste a non-ascii password.
> 
> Should be fixed in Qt 5.13.0 and later. If not, please report a bug

Can you please link here the fix so I can backport it to Fedora? 

> > Telegram-desktop: mixed issues, most notably screenshot pasting from clipboard is broken
> 
> Should probably be reported to Telegram, perhaps Qt (I haven't seen any such
> reports).
> 
> > 2. Open kdenlive/obs-studio. Observe it not working.
> 
> obs-studio has lots of platform specific code, they probably need to port it
> to wayland, as far as I know, nothing we can solve from within Qt Wayland.
> If we are going to wait for every application to port their
> platform-specific code before switching the default, it's probably never
> going to happen.
> 
> > Theming: the gtk theme is not respected, at all.
> 
> As mentioned, window decorations won't look gtk-ish and gnome has actually
> been one of the main opponents of xdg-decoration. Could perhaps be solved
> with libdecoration, but someone would need to put in the work.
> 

We have some basic decoration support in QGnomePlatform to make the decoration look like Adwaita, but it's not in our hands to support all possible themes. 

> > The cursor is enlargened.
> 
> There is actually no cross-compositor way to configure cursor theme and size
> on Wayland. Qt reads environment variables XCURSOR_THEME and XCURSOR_SIZE,
> as many other toolkits do. Work was started by wlroots developers on a
> wayland protocol, but it was abandoned as other things were more broken and
> time was needed there. https://patchwork.freedesktop.org/patch/257280/ in
> case someone want's to pick it up (I have an implementation ready for Qt
> Wayland in case it gets accepted into wayland-protocols).

What we do in QGnomePlatform is that we read cursor size from Gnome/Gtk configuration and set XCURSOR_THEME, because Gnome apparently doesn't do that. This should improve the cursor size situation. There might be probably some corner cases, but nobody else complained about this so far after I pushed the mentioned feature. 

> Btw, we have a list in the Qt bug tracker with things we would like to fix
> in Qt before removing gnome-shell from the blacklist for Qt Wayland:
> https://bugreports.qt.io/browse/QTBUG-68619
> 
> The only thing on that list now, is positioning of menus, which is pretty
> broken due to Qt being built around absolute window positioning being
> available (which is not the case on wayland). 

> Btw: If you decide to keep QT_QPA_PLATFORM set in fedora, you should
> probably change it to QT_QPA_PLATFORM="wayland;xcb" otherwise statically
> compiled applications without wayland are going to fail.

Thanks, I'll change it.

> So I guess there are four categories:
> 
> 1. Things that can't yet be solved in an acceptable cross-platform way.
> Examples are decoration consistency without xdg-decoration, cursor
> configuration without env vars or compositor-specific dbus APIs. When people
> say wayland isn't ready, in a way they are right, because there are no
> solutions for these things that people agree on.
> 2. Things not working because applications aren't ported or haven't
> blacklisted Wayland yet.
> 3. Bugs in gnome-shell that are exposed by running Qt applications (such as
> https://gitlab.gnome.org/GNOME/mutter/issues/199 (fixed)
> https://gitlab.gnome.org/GNOME/mutter/issues/963 (recently opened))
> 4. Legitimate bugs in qtwayland. (menu positioning)
> 
> I think categories 1 and 2 are annoying, yes, but they are not reasons for
> turning off Wayland for a single toolkit, they are reasons for not using
> Wayland at all. 
> 
> Category 3 and 4 is IMO what matters in this case. As far as I know menu
> positioning (https://bugreports.qt.io/browse/QTBUG-68636) and a freeze on
> gnome-shell (https://gitlab.gnome.org/GNOME/mutter/issues/963) are the only
> significant unsolved issues in these categories.

I wasn't aware of the freezing issue, but it looks it's not Qt's fault. The menu issue is probably the only one I consider as an issue for having Qt on Wayland by default, but it doesn't seem to hit all the applications, I think those who set QMenuBar as parent for QMenus behave correctly, but I might be wrong.

FEDORA-2019-690a29587a has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-690a29587a

qt5-qtbase-5.12.5-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-690a29587a

qt5-qtbase-5.12.5-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.