Can we do something about the widget style not being dpi-aware?
Oxygen used to scale with the fonts but all the borders and stuff did not (they grew, sure, but didn't get thicker, same for radii), especially the scroll bars.

Is it possible you borrow some logic from Martin G's breeze KDecoration 2 (which handles that due to my nagging )?

Looking great!

hugo.pereira@free.fr wrote:box around header: you mean the title at the top of the screenshot ? Its a KTitleWidget. Yes I can remove the box.should the background go as well ?

Yeah the box and the background should go. As for the implementation details, I'm fine whether this is done in KTitleWidget or in the style. As long as we can avoid having any release shipped with that background.

progressbars: agreed, centering is broken. One possibility is to write the % text on the side rather than at the top (some built-in Qt style do that).

I think that would be a good solution for now (% text on the side). We'll run a design cycle here to come up with a final target design for the progress bar.

sliders vs progressbars: difficult. Would need to enlarge the slider (length of progress bar is aligned to other widgets). But then (I checked), when slider is at the limits, the progressbar still extends beyond the slider, by one pixel, as a consequence of the shadow around the slider. Which looks weird, since then you feel like you would like to drag the slider even more. I'll think more about it.

Rather than enlarge the slider length, would it be possible to reduce the progress bar length to match the slider groove length? Since the visual meaning of the slider groove and the progress bar are very similar the hope is that they would look quite similar as well.

Anyway, exciting work you've put in Hugo. As has been said, just share here if you have any additional questions or ideas. Thanks for everything!!

One more little thing:

Those ugly underlined letters ("keyboard accelerators") always bugged me in Oxygen. There is the option to have them always there, on demand (when you press Alt), or never. Oxygen defaulted to always but now Breeze defaults to never.

Could we use "On demand" as default instead?

kbroulik wrote:One more little thing:

Those ugly underlined letters ("keyboard accelerators") always bugged me in Oxygen. There is the option to have them always there, on demand (when you press Alt), or never. Oxygen defaulted to always but now Breeze defaults to never.

Could we use "On demand" as default instead?

Yes, absolutely, I'd say it's a requirement form the usability perspective, and "on demand" is the best default setting.

colomar wrote:Yes, absolutely, I'd say it's a requirement form the usability perspective, and "on demand" is the best default setting.

That's now the default.

One thing that I find a major usability regression are the horizontally aligned tab bars.
KSysguard became unusable for me because that thing shifts around constantly when switching between pages (the custom pages have a sidebar to add new graphs which the default ones lack), QtCreator's compiler/search/console thing is also cumbersomb to use with it.
In most of the KCMs you cannot even use the mousewheel on the full width, just where the buttons are, which renders your muscle memory "point here, mousewheel" useless.

@Kay
Personally I like the centered tabs a lot, though I understand your troubles (but they are corner cases, no ?)
I guess I can add an option to change between center and left (or right, depending of font direction)
Will keep you posted

Can we do something about the widget style not being dpi-aware?

Get Qt 5.4, export QT_HIGHDPI_SCALE_FACTOR=2.
*BAM* every app is now perfect (goes the theory)

I'd rather we make that work, it will need some tweaks especially when loading assets, than put in custom code in the theme; as it will fix more things and be less fragmented.

kbroulik wrote:

colomar wrote:Yes, absolutely, I'd say it's a requirement form the usability perspective, and "on demand" is the best default setting.

That's now the default.

One thing that I find a major usability regression are the horizontally aligned tab bars.
KSysguard became unusable for me because that thing shifts around constantly when switching between pages (the custom pages have a sidebar to add new graphs which the default ones lack), QtCreator's compiler/search/console thing is also cumbersomb to use with it.
In most of the KCMs you cannot even use the mousewheel on the full width, just where the buttons are, which renders your muscle memory "point here, mousewheel" useless.

Ok: reconsidering
For ksysguard, just checked. This is really just poor application ui, really
no matter how the tabbar is centered, that its total width varies depending on which tab you select is just bad.

For KCMs (and elsewhere), the mousewheel issue is really a qt bug. Should work on the full width
The same happens on left aligned toolbars: can't mousewheel from the right side.
I'd rather try to fix that (the real bug) than changing the alignment, IMHO

hugo.pereira@free.fr wrote:

kbroulik wrote:

colomar wrote:Yes, absolutely, I'd say it's a requirement form the usability perspective, and "on demand" is the best default setting.

That's now the default.

One thing that I find a major usability regression are the horizontally aligned tab bars.
KSysguard became unusable for me because that thing shifts around constantly when switching between pages (the custom pages have a sidebar to add new graphs which the default ones lack), QtCreator's compiler/search/console thing is also cumbersomb to use with it.
In most of the KCMs you cannot even use the mousewheel on the full width, just where the buttons are, which renders your muscle memory "point here, mousewheel" useless.

Ok: reconsidering
For ksysguard, just checked. This is really just poor application ui, really
no matter how the tabbar is centered, that its total width varies depending on which tab you select is just bad.

For KCMs (and elsewhere), the mousewheel issue is really a qt bug. Should work on the full width
The same happens on left aligned toolbars: can't mousewheel from the right side.
I'd rather try to fix that (the real bug) than changing the alignment, IMHO

<-- this (the incorrect mousewheel rect) actually happens only for QTabWidget widgets, not for QTabBars widgets
so a Qt bug, really

alake wrote:

hugo.pereira@free.fr wrote:box around header: you mean the title at the top of the screenshot ? Its a KTitleWidget. Yes I can remove the box.should the background go as well ?

Yeah the box and the background should go. As for the implementation details, I'm fine whether this is done in KTitleWidget or in the style. As long as we can avoid having any release shipped with that background.

Titlewidget frame and border gone:

http://wstaw.org/m/2014/08/27/plasma-desktopW32589.png

Honestly, I dont like it. Text and icon appear "out of the blue" (especially the icon)

Same in "about" dialogs (because it is the same widgets):
http://wstaw.org/m/2014/08/27/plasma-desktopB32589.png
http://wstaw.org/m/2014/08/27/plasma-desktopy32589.png

Here the fact that the frame is gone makes it more visible that the alignment is completely broken between header and contents.

Note that this (no frame, no color) is how it was rendered in oxygen, and people complained (with the same arguments) already at that time.
Really what is needed is a proper design for this ktitlewidget (at the widget level, not at the style level)

I can volunteer to implement such a design (that would work on whole widget styles), once there is one, and would prefer that to hacking into breeze

Would it be doable to use center alignment for headers, I wonder? It's one way of giving prominence to the header without using a border.

hugo.pereira@free.fr wrote:

kbroulik wrote:

colomar wrote:Yes, absolutely, I'd say it's a requirement form the usability perspective, and "on demand" is the best default setting.

That's now the default.

One thing that I find a major usability regression are the horizontally aligned tab bars.
KSysguard became unusable for me because that thing shifts around constantly when switching between pages (the custom pages have a sidebar to add new graphs which the default ones lack), QtCreator's compiler/search/console thing is also cumbersomb to use with it.
In most of the KCMs you cannot even use the mousewheel on the full width, just where the buttons are, which renders your muscle memory "point here, mousewheel" useless.

Ok: reconsidering
For ksysguard, just checked. This is really just poor application ui, really
no matter how the tabbar is centered, that its total width varies depending on which tab you select is just bad.

I differentiate between "static" and "dynamic" tab bars. Static ones are those where the number and label of tabs remains static. For those I see no problem with centered tabs.
Dynamic tab bars are those where tabs can be added or removed (like in web browsers, for example). For those, centering the tabs indeed causes major usability issues because the position of each tab changes whenever a tab is added or removed. Imagine a web browser with a centered tab bar. That would be really weird.

Now the question is whether we want different tab alignment for static vs. dynamic tab bars.

What do we need the little icon on the right side for anyway? It creates alignment issues and does not add any information since the identical icon is already shown on the left side, only bigger, so I would vote for dropping that icon.

hugo.pereira@free.fr wrote:Titlewidget frame and border gone:

http://wstaw.org/m/2014/08/27/plasma-desktopW32589.png

Honestly, I dont like it. Text and icon appear "out of the blue" (especially the icon)

Same in "about" dialogs (because it is the same widgets):
http://wstaw.org/m/2014/08/27/plasma-desktopB32589.png
http://wstaw.org/m/2014/08/27/plasma-desktopy32589.png

Here the fact that the frame is gone makes it more visible that the alignment is completely broken between header and contents.

Note that this (no frame, no color) is how it was rendered in oxygen, and people complained (with the same arguments) already at that time.
Really what is needed is a proper design for this ktitlewidget (at the widget level, not at the style level)

I can volunteer to implement such a design (that would work on whole widget styles), once there is one, and would prefer that to hacking into breeze

Thanks for taking the time to do this Hugo. The primary problem with what I'm seeing, and the reason for the "out of the blue" appearance is due to improper alignment with the rest of the layout - the title should not be indented/padded to a greater degree than its content. The result is a broken visual hierarchy and an almost complete visual disconnection of the title from its content.

Perhaps the problem may be that KTitlewidget assumes it requires it's own internal padding? Left alone, that would compel altering the visual design to add some visual framing to re-establish the alignment, and thus the visual hierarchy of the layout. I'm not particularly fussy about where this is fixed but, ideally, I think the widget implementations should not constrain the visual design in this way - the widget doesn't have the context to determine how much, if any, padding is necessary to fulfill the visual design styling objectives. If it's a title widget, my own thought is that it ought to let the style properly specify all aspects of the visuals for a title that satisfies the overall visual design. For the overall Breeze visual design, the visual hierarchy of the title is meant to be established not with framing, but with the type and proper alignment.

So, wherever the problem lies, my current thought is that we resolve the alignment problems first. After that, we can certainly revisit the visual design for titles everywhere (regardless of implementation) if necessary.

Hope this helps! Of course thanks for EVERYTHING!! Everything else is really looking great.

colomar wrote:

hugo.pereira@free.fr wrote:Ok: reconsidering
For ksysguard, just checked. This is really just poor application ui, really
no matter how the tabbar is centered, that its total width varies depending on which tab you select is just bad.

I differentiate between "static" and "dynamic" tab bars. Static ones are those where the number and label of tabs remains static. For those I see no problem with centered tabs.
Dynamic tab bars are those where tabs can be added or removed (like in web browsers, for example). For those, centering the tabs indeed causes major usability issues because the position of each tab changes whenever a tab is added or removed. Imagine a web browser with a centered tab bar. That would be really weird.

Now the question is whether we want different tab alignment for static vs. dynamic tab bars.

I think we definitely would want them to look different, let alone to indicate that tabs can be added or not. A lot of KDE applications seem to add tabs to their UI, but not a "new tab" button. One doesn't even know how to add a new tab unless one searches the menus. So I'd say we definitely would want to have a difference in tab alignment.