The Breeze themes all place the progress bar's text next to a thin bar, instead of placing text inside the progress bar, which makes it look hideous and out of proportion on many apps. It affects bars with other text in them, and as the text changes (eg. the current step), the bar's width fluctuates. This occurs even with the Windows 9X style. However, it doesn't appear to be a Qt problem since running an app with -style=fusion will result in normal progress indicators. Most sane UIs contain the progress bar text inside the bar itself, which makes for a compact component. Applications often expect this, and put more than just a percentage on the text.
This is intentional; there isn't room in the progress bar for this because of its intentionally thin design. If we made it thick enough to accommodate text, it would look too big and out of place with other UI elements.
(In reply to Nate Graham from comment #1) > This is intentional; there isn't room in the progress bar for this because > of its intentionally thin design. If we made it thick enough to accommodate > text, it would look too big and out of place with other UI elements. What about on the other styles such as Win95? It's definitely out of place on that style, and looks horrible there. In either case, I think this needs to be reconsidered, it isn't a natural fit in a UI especially for applications that often expect that the text will be inside the bar.
What the win95 style does isn't relevant to Breeze. If apps are expecting the text to be inside the bar, that's a bug in the app, because--as you have discovered--the style determined the placement of the text. Apps need to be designed flexible to accommodate both text locations.
(In reply to Nate Graham from comment #3) > What the win95 style does isn't relevant to Breeze. Where would be the best category/place to file this bug for the Win95 style then? > If apps are expecting the text to be inside the bar, that's a bug in the > app, because--as you have discovered--the style determined the placement of > the text. Apps need to be designed flexible to accommodate both text > locations. Is there a way for an app to find out where the text is placed? Doe Qt have any simple way to check for this? Because, if not, you can hardly blame the app for this. Breeze is pretty much the only theme I've seen that is designed the way it is.
(In reply to AK-47 from comment #4) > Doe Qt have any simple way to check for this? By this, I mean in a platform/desktop independent manner. Otherwise this defeats the purpose of Qt.
(In reply to AK-47 from comment #4) > (In reply to Nate Graham from comment #3) > > What the win95 style does isn't relevant to Breeze. > > Where would be the best category/place to file this bug for the Win95 style > then? I don't know. It's not KDE code, so from a KDE perspective, it doesn't matter to us. :) > Is there a way for an app to find out where the text is placed? Doe Qt have > any simple way to check for this? > Because, if not, you can hardly blame the app for this. Breeze is pretty > much the only theme I've seen that is designed the way it is. 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.
(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?