Qt 5 "deactivates" the window once you stop moving it around

[guihkx]

Sorry for the terrible title, but I don't know how to better describe it. 😄

Basically, after the introduction of startSystemMove(), after you finish moving the window, Qt 5.15 seems to "deactivate" the window (tested only on Linux at the moment), and you can't "interact" with any of the UI elements using the mouse, unless you activate the window again.

Still lost? Hopefully the videos below will explain this better. 😅

Steps to reproduce

1. Drag the window around a bit
2. Release it
3. Hover over any UI elements inside the window (e.g. trash icon, buttons, notes list, etc.)

Current behavior

You can not interact with UI elements right away using your mouse, you must first click on the window to "re-activate" it:

qt5.15-startsystemmove.mp4

Expected behavior

You should still be able to interact with UI elements using your mouse, like this (Qt 6.3):

qt6.3-startsystemmove.mp4

I haven't found a workaround for this yet...

[nuttyartist]

Hmm very weird. I can't reproduce this on my macOS. Have you tested on Windows?

[guihkx]

Curiously, I have, and it doesn't seem to be a problem there.

I have yet to check if startSystemMove() is actually being called there, though.

Because if it were, I think we'd be able to aero snap our window by now (#414), and we currently can't... 🤔

[nuttyartist]

Because if it were, I think we'd be able to aero snap our window by now (#414), and we currently can't... 🤔

You sure? Last time I tested it worked. I will test again.

[guihkx]

I tried it a couple of days ago on a Windows 11 VM and it wasn't working... 🤷

But please do check, so we can close #414!

[guihkx]

I think I found the upstream bug, which appears to only affect the Xcb plugin, namely X11 sessions:

• http://bugreports.qt.io/browse/QTBUG-91077

And the fix, which unfortunately was only included in Qt 6.3:

• https://codereview.qt-project.org/c/qt/qtbase/+/343520

I personally don't see any easy workarounds that we could add to our Qt 5 build, but if someone has an idea, please do share. :)

[bjorn]

I personally don't see any easy workarounds that we could add to our Qt 5 build, but if someone has an idea, please do share. :)

A possible workaround is to increase the Qt version number from which we'll try to use startSystemMove from 5.15 to 6.3. Of course that would break window moving again on Wayland, but I think people on Wayland will be wanting to use the Qt 6 build anyway?

[guihkx]

I don't know, that seems like a broad assumption to make...

For example, Ubuntu 20.04 users on Wayland sessions can't build with Qt 6 (yet?), since there's no package on Ubuntu repos. And that's just one distro...

Also, I think this is just a minor annoyance for us to get rid of something so important like startSystemMove()... 🤔

[bjorn]

For example, Ubuntu 20.04 users on Wayland sessions can't build with Qt 6 (yet?), since there's no package on Ubuntu repos. And that's just one distro...

Well, I think we can safely assume that a very small minority of users would be compiling Notes themselves, let alone on such an old Ubuntu version. :-)

Also, I think this is just a minor annoyance for us to get rid of something so important like startSystemMove()... thinking

In that case, we can just let this be a "known issue", which will go away by itself as less and less people will be still be using Qt 5.

I also just tested this on GNOME 43 btw, and could not reproduce this issue at all. 🤷‍♂️

[guihkx]

I also just tested this on GNOME 43 btw, and could not reproduce this issue at all. 🤷‍♂️

Weird... I'm also on GNOME 43 (X11 session) and I was able to reproduce it even after building with Qt 5.15.8.

Depending on your distro (I'm on Arch), it's possible that the package maintainers backported that patch...

[bjorn]

I tested with the AppImage built on GitHub CI, which must be using Qt 5.15.2. It's also possible it's a regression, or something else is different...