Screenshots coming. Reproducible: Always
Created attachment 87369 [details] Hovered radio button in QtCurve+Breeze
Created attachment 87370 [details] Hovered checkbox in QtCurve+Breeze
For the moment this is a QtCurve issue. While not ideal, the radio button is remains appropriately discernible as a radio button and functions as it should. Not a critical issue. Will be addressed either by fixing the issue in QtCurve or when a C++ implementation of the reference UI controls design becomes available for QWidget-based applications. Leaving open as needs info until the underlying QtCurve issue is identified.
I personally disagree that issues like this are "not critical". Rendition quality is an important aspect of graphical user interfaces that significantly affect the look and feel of software, and present a barrier-to-use in a very real way - many users will refuse to use or not enjoy using interfaces displaying sub-par rendering quality. This is especially true for users we're currently not yet reaching, and so also poses a barrier to expanding our userbase. It's made more critical by the fact that the style engine carries enormous responsibility simply by dictating the appearance of so much software. The poor impression this and other bugs leave aren't a localized problem - they weigh heavy on the relationships of users with many different products made by KDE and others. More pragmatically, it's also a regression over previous releases of the Plasma Workspace, since many dozens of similar problems have been solved in the Oxygen style engine - to the point of sometimes addressing single poorly-rendered pixels caused by overlapping drawcalls, or paying attention to sampling quality. On the whole, I don't think QtCurve is currently up to the quality standards of a stable release - at least with the Breeze preset - and I think trying to ship it as a default is a mistake.
All I can do is simply state what I did. From a visual design standpoint, for the reasons provided, I simply do not think this is critical. The issue identified here has no discernible effect on the user's ability to recognize or use the controls. There are many other regressions throughout Plasma 5, including real functional regressions, that go far beyond the pixel-level imperfections identified here. Whatever criteria we're using for determining that those regressions are either acceptable or not, I would argue should be consistent for these issues as well. There exists no implementation using the Oxygen style engine that satisfies the target visual design for the UI controls. If an implementation becomes available that uses the Oxygen style engine to satisfy the target visual design then we'll review that then. The QtCurve with the Breeze theme was reviewed by both the VDG and the plasma team. The conclusion was that it sufficiently satisfies the visual design targets, and was acceptable to be shipped as default. The issue identified here does not, at least by my view, overwhelm the results of that review such that the decision should be reversed.
We're upstream now, reopening.
Resetting assignee.
@Eike Hein I've tried to implement your suggestions of scaling the images although I'm only using it as a way to do AA sliently differently. Can you check if they looks better now?
Created attachment 87986 [details] Current appearance Still pretty bad here I'm afraid, doesn't look properly round at all ...
And it also seems to affect combobox highlight somehow T_T... Need to work on it more....
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.