Description of problem:
When running in a wayland session one cannot drag & drop widgets in Qt Creator to design the UI
Version-Release number of selected component (if applicable):
Fedora 31 fully updated, Qt Creator 4.10.2
Steps to Reproduce:
1. Create a new Qt Widget Application with all default settings
2. Open the mainwindow.ui Form
3. Drag Drop any widget
In Wayland, the drop is rejected
Under X11, the widget is added to the Form
Is this in Gnome wayland session? I cannot reproduce in Plasma Wayland session and it also works for me under Weston, which indicates it might be a bug in Mutter.
It is indeed a GNOME session. Forgot to say.
Wayland I tried GNOME
X11 I tried GNOME Classic
I think you can add another odd behaviours:
text cursor disappears every now and then.
By changing focus a few times it comes back.
Do I need to open a new bug report for mutter?
I opened upstream bug: https://bugreports.qt.io/browse/QTBUG-80303
We will see if it's a bug in Qt or Mutter.
I have tried again downloading the debug info.
But I dont really know if/where the report was uploaded. The crash tool is very sparse with useful information.
Comment 6 is about a different issues.
There are other odd behaviours of Qt applications in GNOME Wayland:
QMainWindow::restoreState() and QMainWindow::restoreGeomerty() do not work.
They do work with -platform xcb.
I think Qt on GNOME Wayland is just not ready.
(In reply to Andrea from comment #8)
> There are other odd behaviours of Qt applications in GNOME Wayland:
> QMainWindow::restoreState() and QMainWindow::restoreGeomerty() do not work.
> They do work with -platform xcb.
> I think Qt on GNOME Wayland is just not ready.
I'm not sure if this is intentional, because in my opinion windows on Wayland shouldn't be able to position or resize themself, but I might be wrong.
I saw there are some patches on review which will add support for maximize/minimize/fulscreen for the clients, which should at least partially solve your problem.
Fine, if it turns out to be a feature rather than a bug, I am not going to argue (here).
I will try to read about the principles behind this decision and how the whole wayland thing work as a whole.
It is very strange as in Plasma / Wayland (not just Plasma, but the Plasma on Wayland) it behaves correctly.
Not sure what to make of it.
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
I would like to add that this issue looks to be a Mutter bug: https://gitlab.gnome.org/GNOME/mutter/issues/965
Not everything is QWayland fault.
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.
It "does work" now but I think it is simply because it does not run on wayland by default.
If I start qt creator with "-platform wayland" it still does not work.
These are the release notes for the new package
* Tue Dec 10 2019 Jan Grulich <firstname.lastname@example.org> - 5.12.5-2
- Blacklist some applications from being used on Wayland
- QMimeData: Prefer UTF-8 when multiple charsets are available
I think QT Creator has simply been blacklisted...
QtCreator has been blacklisted until this is fixed in Mutter. Either we can close this with thw workaround I did or I close it as a bug in Mutter. Anyway there is nothing else I can do.
The only thing Fedora could consider in the future is blacklist *all* Qt application.
If drag & drop is deemed a *key* feature of Qt applications then I think this applies.
And the whole point is really to push for the Mutter bug to be fixed as a top priority.
As one of the main distros using GNOME I am sure Fedora voice has a big weight in Mutter's bug triage.
This is now fixed upstream in master  and in 3.34 branch . Reassigning to mutter for consideration whether to backport the patch.
F31 has mutter-3.34.6-1.fc31 which I believe contains the fix.