https://bugs.kde.org/show_bug.cgi?id=444249
--- Comment #7 from AK-47 <chkb...@safe-mail.net> --- (In reply to Nate Graham from comment #6) > I don't know. It's not KDE code, so from a KDE perspective, it doesn't > matter to us. :) Intersting, is this a Qt internal thing? > I don't think there is. > The point remains: A QtWidgets-based app shouldn't assume a particular > visual representation. QStyle styles can do all sorts of crazy things; it's > all explicitly supported. This defeats the whole purpose of a GUI toolkit, yet alone one such as Qt. I agree an app should not assume particular visual details, such as the nature of a border or the default font, but apps should be able to have basic expectations for what something roughly looks like: - A push button is a box with text/icon inside it, instead of a small box with the text right next to it. Users can click on it and it may result in something. - A check box is a tick with some text next to it, rather than a giant banana with text all on the tip. - A scroll bar looks like a bar which you can drag a slider up/down or back/forth, to view a different portion of the area. - A progress bar looks like a box with some text inside it, and filled in with some colour, which together indicates the status of an operation. Or should app developers now recreate these basic controls because their visual representation is undefined? -- You are receiving this mail because: You are watching all bug changes.
