There's an mp4 of the behaviour here https://forum.manjaro.org/t/stable-update-2019-12-29-kernels-kde-apps-19-12-xorg-stack-mesa-qt5/116899/297. I couldn't explain it better than the video does, but basically, as one types into a text box, the cursor gets further and further away from the end of the text. Trying to set the cursor to some character using the mouse is then impossible.

As the post shows (and the other tests below it. The behaviour is limited to KDE Plasma, other desktop environments don't exhibit the same behaviour with otherwise similar set-ups. Testing on Plasma 5.17.4.

I just want to know whether I should report this as a bug, or if It's more likely to be Qgis's problem (the application this happens on).

A direct link to the video would have been easier: https://manjaro.moson.eu/custom/qgis_kde.mp4

I don't have Qgis, so I can't test, but I have never seen that in any other application on Plasma. Which points to Qgis or actually Qt being the culprit.

Mamarok wrote:A direct link to the video would have been easier: https://manjaro.moson.eu/custom/qgis_kde.mp4

I don't have Qgis, so I can't test, but I have never seen that in any other application on Plasma. Which points to Qgis or actually Qt being the culprit.

That's why I linked to the whole sub-thread. Other posters demonstrate that the problem is confined to KDE Plasma, so it can't be as simple as Qgis or Qt being the culprit, otherwise the problem would persist on all systems using Qgis and Qt, and it doesn't.

It may be something about the way in which Qgis or Qt interact with Plasma, but that would, at the very least, make it a joint problem (some protocol not having been properly communicated to application developers).

Still, the bug report needs to be done in Qgis, the applications is the downstream who has to act, unless they can tell us if/what is to be changed in Plasma. Even more so since Qgis is not a KDE application. The problem can well be a Qt one, too, but again, without specifications on what is different causing the issue this is just guesswork. It's a bit like when a small ship (application) encounters a large one (platform), it's always the small one who has to give way

Mamarok wrote:Still, the bug report needs to be done in Qgis, the applications is the downstream who has to act, unless they can tell us if/what is to be changed in Plasma. Even more so since Qgis is not a KDE application. The problem can well be a Qt one, too, but again, without specifications on what is different causing the issue this is just guesswork. It's a bit like when a small ship (application) encounters a large one (platform), it's always the small one who has to give way

That's an unusual outlook. Personally, I see open source enterprises working together collaboratively to give as good a user experience as they can, otherwise they just become pet projects, which seems a bit pointless.

Regardless, I can't see any way in which Qgis could possibly investigate this problem since it isn't a problem in any other desktop environment besides KDE. It follows then, that to investigate it at all they'd have to know how Plasma differs from the other desktop environments in this respect. There's only one group who know that, and that's KDE, not Qgis.

I'm active on the Qgis github, so if I'm missing something, then I'll happily take it to them - what steps do you imagine Qgis (or Qt) should be taking to investigate this problem? What should I suggest they do next?

What I suggest is filing a bug to Qgis first, if they decide it's a Plasma bug, you can still file it as a Plasma bug, with the exact reasons why this is our problem (only happens in Plasma is not sufficient, btw. we would have to know how this text mask is made, and that is in the Qgis code, not in ours AFAICS).
The forum is definitely not the right place to report a bug anyway.

Mamarok wrote:What I suggest is filing a bug to Qgis first, if they decide it's a Plasma bug, you can still file it as a Plasma bug, with the exact reasons why this is our problem (only happens in Plasma is not sufficient, btw. we would have to know how this text mask is made, and that is in the Qgis code, not in ours AFAICS).
The forum is definitely not the right place to report a bug anyway.

I've opened a bug report for it.

How is the fact that it only happens in Plasma "not sufficient" to make it a problem with Plasma? Are you suggesting there's a way in which Plasma are implementing this feature correctly and all the other DEs are implementing it incorrectly, but by sheer luck their incorrect implementation just happens to to coincide with Qgis's incorrect implementation is such a way as to accidentally yield the exactly correct result?

There's some code in Qgis, that code displays correctly in all other DEs tested from both Linux and Windows using a range of different versions of Qt. Change just one factor (the Desktop Environment) and it no longer displays correctly. I don't understand how you could draw any other conclusion than that the Desktop Environment is where the problem lies. Am I missing something?

"a problem with Plasma" doesn't necessarily mean "a problem of Plasma", I hope you understand that. If the Qgis developers can point out that Plasma is at fault, then they will report it to us, but problems with applications need to always be reported to the application first, not to the platform.

Mamarok wrote:"a problem with Plasma" doesn't necessarily mean "a problem of Plasma", I hope you understand that.

Well, no. That's exactly the bit I don't understand. If some feature works on all DEs except plasma, then only one of two possibilities exist - either plasma is implementing the feature incorrectly, or all other DEs in existence are implementing the feature incorrectly but by complete co-incidence just happens to render the text in exactly the expected manner.

Surely KDE don't just develop a DE in isolation and then just expect all other applications to interact with it on it's own terms. The process has to be collaborative, I find this 'shifting of blame' game really opposed to what I though was the open-source ethos. Obviously developers are busy people who give their time for free (mostly) and so their efforts should not be called upon lightly, but that's true of Qgis too, which is also FOSS, so that alone can't help decide how bug-fixing effort gets apportioned.

Mamarok wrote:problems with applications need to always be reported to the application first, not to the platform.

That's all very well, but, as I said, Qgis works fine in all other Desktop Environments. At the very least, the matter of whether it's a problem with the application is moot, it's certainly not clearly the case.

You can apply that logic the other way too: All other applications behave as expected except Qgis. There's something about the combination of Qgis and Plasma that results in Qgis applying the wrong cursor theme.

Applications should be applying the cursor theme defined by the application theme used by the application's toolkit (qt or gtk), and the toolkit should be defining the cursor theme based on the system settings set by the user. However, applications are also free to override that and provide their own cursor theme. There are potentially a few places in between where things may not link up correctly which could result in the application using the wrong cursor theme when running on Plasma.

airdrik wrote:You can apply that logic the other way too: All other applications behave as expected except Qgis.

No we can't, not logically anyway. We know that Qgis behaves oddly combined with Plasma (but not other desktops) because we have tested that. We don't know that all other applications behave as expected in Plasma because we've not tested all other applications. We might make a presumption based on the absence of bug reports, but an absence of evidence to the contrary is not the same as the presence of confirmatory evidence.

airdrik wrote:There are potentially a few places in between where things may not link up correctly which could result in the application using the wrong cursor theme when running on Plasma.

It would be good to know what some of these places are. I could potentially raise them as possible places to look with the Qgis developers.

Ultimately, arguing about it on the forum is not going to get the problem fixed. Please just file the bug report (with Plasma or with QGis, I don't really care, I figure the devs for either will have a better idea where the problem is anyway and get the right changes made in the right place regardless).

I don't have any more details than what I described in my previous comment which is largely anecdotal based on my experiences using applications and changing themes on various desktops.

Other things you can experiment with include (and should include the results in your bug report):
Can you reproduce the issue in a from-scratch environment (new user, and/or fresh install of the same or a different distro)?
What desktops did you use in your testing? Did you include any others that are Qt-based such as LxQt?
Did you check on X vs. Wayland based desktops (including some of the newer ones that are Wayland only)?
How did you install Qgis? Are there other means of installing it (e.g. source vs. distro package vs. flatpak vs. snap vs. appimage)? Does the behavior change depending on how you installed it?
Have you found any other applications which exhibit the problem?