Sogatori wrote:

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.

... but, that is not possible
In Qt, applications have no control on tab alignment, the style has
And on the other hand, the style does not know if tabbars are customizable or not (and has no way to know)
So unless Qt is patched, its a dead end.

alake wrote:

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.

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.

I mostly agree with the above except for the minor restriction below: The style does not know much either about the alignment of the rest of the page, when it is asked to render a titlewidget. It also has little control on the layouting of widgets one with respect to the other (as opposed to internal layouting, for monolythic widgets). For instance it cannot change margins, spacings, alignment of widget's layout.

See already how many kcms have different margins for their pages. Either zero (which is good: make the page aligned with the title widget), or > 0, which is ugly.

Examples:
good - http://wstaw.org/m/2014/08/28/plasma-desktopF30996.png
bad - http://wstaw.org/m/2014/08/28/plasma-desktopw30996.png

Still, I agree that ktitlewidgets should have minimal layouting, padding, margins, frames, so that at least the applications (and not the style ) can have control over it (that is: add a frame, add margins, etc.). Also, remember that ktitlewidget must look good with all styles, and not only breeze. (or rather: look decent on all styles, and good with breeze)

If you (or someone else), post mockups on how these titles should look for e.g. kcm page, and about dialogs, I can try hack ktitlewidget in that direction and submit review for code changes.
Also, this discussion should better take place on kde-frameworks-devel@kde.org, since low level library development and change would be needed.

hugo.pereira@free.fr wrote:In Qt, applications have no control on tab alignment, the style has
And on the other hand, the style does not know if tabbars are customizable or not (and has no way to know)
So unless Qt is patched, its a dead end.

In that case, tabs always have to be left-aligned. The aesthetic gain from the center-alignment in static tab-bars is far outweighed by the disadvantages in dynamic ones. Actually it seems to me like dynamic tab bars are more common than static ones, especially in UIs which are used regularly (static ones seem to be used mostly in configuration and about dialogs, both of which are used only infrequently).

Imagine Dolphin or Rekonq or Konsole with tabs jumping around whenever one is opened or closed, that is definitely a usability problem and also looks and feels weird.

I really like the looks of the centered tabs in static tab bars, but if we can't differentiate between static and dynamic, we cannot keep them.

rule of thumb:
qtabwidget is likely static, documentMode tabbars are likely dynamic, the rest is a coin flip (so rather to be left aligned)

this is however not guaranteed and there will probably glitches (to be special cased unless the client is too exotic)

Regarding the tab alignment: I think if a gtk theme is planned you should consider how it's done there and if you can influence the tab alignment there for consistency.

kdeuserk wrote:Regarding the tab alignment: I think if a gtk theme is planned you should consider how it's done there and if you can influence the tab alignment there for consistency.

You can do both in gtk too. so it is up to us.

hugo.pereira@free.fr wrote:See already how many kcms have different margins for their pages. Either zero (which is good: make the page aligned with the title widget), or > 0, which is ugly.

Examples:
good - http://wstaw.org/m/2014/08/28/plasma-desktopF30996.png
bad - http://wstaw.org/m/2014/08/28/plasma-desktopw30996.png

I think the good one looks better because the frame provides a visual reference for alignment. For a title without a frame, as would be the case for Breeze, the left padding would need to be zero so the left edge of the text provides the visual anchor. kcm's with inconsistent margins eventually need to be addressed. However without the padding removed for frameless titles like for Breeze, application designers can't rely on a consistent visual reference for the title in the application layout. And I'd hope that applications would not need style-specific code (like checking for frameless titles) to get the alignment correct - regardless of style, framed or frameless titles should have the same visual reference point.

If you (or someone else), post mockups on how these titles should look ..

Hmm... Ok, this is what breeze titles should look like:

That's a screenshot of how titles look in QtCurve with the Breeze QtCurve settings file. That's also generally how titles look in plasmoids and I think the Oxygen style as well. Note that these are the intended visuals for titles generically, not for the ktitlewidget specifically. I'll try to focus my feedback on the visual design objectives while trying to avoid discussions on which changes required at which layer to achieve this without breaking other styles.

Hope this helps!

notice that qtcurve -like bespin, virtuality (and probably even oxygen as well to some degree)- hacks around on the titlewidget ("fixing" background, frame and margin)

by default it has an outline, base color background and a randomly sized text (sometimes using html markup and sometimes not) and features which make it partially redundant w/ (css styled...) KMessageWidget - it has frankly become quite a mess.

so, if there's a vdg position on titles and inline messages, pointing them out in a bugwish to tidy up this by
- deprecating widgets/features
- defining the look (or pass them to the style entirely via the custom element extension) and/or
- have the API clearly state when to use what.

luebking wrote:notice that qtcurve -like bespin, virtuality (and probably even oxygen as well to some degree)- hacks around on the titlewidget ("fixing" background, frame and margin)

by default it has an outline, base color background and a randomly sized text (sometimes using html markup and sometimes not) and features which make it partially redundant w/ (css styled...) KMessageWidget - it has frankly become quite a mess.

so, if there's a vdg position on titles and inline messages, pointing them out in a bugwish to tidy up this by
- deprecating widgets/features
- defining the look (or pass them to the style entirely via the custom element extension) and/or
- have the API clearly state when to use what.

I'll try to be as clear as possible about this. I apologize that I haven't. The current UI controls design for which the VDG has authorship is the Breeze UI controls design. To be clear, it is the design for which we have authorship, for which we have provided a deliverable and for which we're happy to review implementations against. In the generic design sense, the Breeze design target for titles (not ktitlewidget specifically) is as shown here:



There should be no additional padding or margins for titles beyond what is used by default for any other UI element. Please let us know if you need additional or more specific design information. We'd be happy to provide it.

Now what does that mean regarding the VDG's position on the ktitlewidget? I don't personally have a strict position on ktitlewidget because I don't have a specific understanding of what might be deficient beyond the fact that apparently many styles hack around it. What I do have a position on is fulfilling the visual design objectives, which in this case means working together to ensure that titles for the Breeze style look as described. I'm rather biased towards leaving developers to identify potential deficiencies in the stack that will prevent fulfilling those visual design objectives and making the changes they deem appropriate to achieve that. All the VDG can credibly provide at this point is a visual design target for titles, which we have. Widget/feature deprecation and API clarifications are squarely in developers' wheelhouse. If there are changes being proposed somewhere in the stack for which VDG support would be helpful, just let us know how those proposed changes will affect the visual design objectives and we'd be happy to chime in, as we have so far.

So the VDG won't likely tell Hugo or other devs what the best approach is for the kstyle implementation of the Breeze UI controls design. Whether the choice is to "hack around" ktitlewidget like other styles do, fix deficiencies in ktitlewidget or do something else entirely, devs are in a far better position than the VDG to determine the best approach for implementation.

Hope this helps!

I can understand Andrews diplomatic point of view and I think it is really appreciated.
However I think ktitlewidget should be fixed for the better, hacking around with this in the theme seems a rather ugly approach.
I think now is the ideal time for changing something in ktitlewidget, since most applications need porting to kf5 anyway and changing things like this later wont be ideal imho.

Andrew: Do we need the icon on the right side?

kdeuserk wrote:Andrew: Do we need the icon on the right side?

Good question kdeuserk. I think we could manage without the icon on the right, even though it does seem to provide a some visual balance. What do other folks here in our wonderful community think?

We have to remember that the current KCM layout is at the end of its lifecycle. With the new System Settings layout, things will be different altogether, so we should rather focus on that when redesigning things.

colomar wrote:We have to remember that the current KCM layout is at the end of its lifecycle. With the new System Settings layout, things will be different altogether, so we should rather focus on that when redesigning things.

Good point colomar.

Please let us know if you need additional or more specific design information. We'd be happy to provide it.

- font color, size and weight of the primary title (relevant?)
- font color, size and weight of the secondary title / comment (relevant? is the item acceptable at all)
- icon alignment (also vertically compared to primary, secondary or all title text)
- should a (temporary) titlewidget be used to indicate either InfoMessage, WarningMessage, ErrorMessage?
* if so, icon name and general look (colors?) of titles that are of either type
- because it was raised: right aligned icons can easily visually detach from the text (wide widget) -> how to visually re-attach them? (if that remains an issue, ie. you don't want a left aligned icon)
- to what degree user code may impact any of the above (ie. "if i use it in my application, should i be able to say i want the font 3em rather than 2em? Can I use html to impact the look?")

To *enforce* the shown look, the style must atm. perform some *really* ugly stuff (inc. text manipulation to get rid of html entities) on the widget - i would call that simply "inacceptable" for the default KDE style.

-> Depending on what is demanded, we would have to take away control from the user code and either alter the hard code or delegate it to the UI style.
The alternative would be that all devs acknowledge the HIG demands, but
- that's unrealistic (ie. you'd keep filing bugs on this
- KWidgetAddons is tier1 and cannot be thought as "KDE session only - so if they adhere to the KDE HIG, they might fail on gnome or windows etc.

luebking wrote:- font color, size and weight of the primary title (relevant?)

The font color should follow the active window text color.
The size and weight should follow the typography guidelines for Content Title as a scale size of the Content Body (which corresponds to the General font size specified in the user's font settings). If there is something about the guidelines that is incorrect or unclear please let us know.

- font color, size and weight of the secondary title / comment (relevant? is the item acceptable at all)

We haven't specifically accounted for secondary titles in the design yet, but I think Content Body should be suitable for now I think. Of course if others here have a different idea for this feel free to share.

- icon alignment (also vertically compared to primary, secondary or all title text)
- should a (temporary) titlewidget be used to indicate either InfoMessage, WarningMessage, ErrorMessage?
* if so, icon name and general look (colors?) of titles that are of either type
- because it was raised: right aligned icons can easily visually detach from the text (wide widget) -> how to visually re-attach them? (if that remains an issue, ie. you don't want a left aligned icon)[

Icons and text alignment should generally follow the icons and text guidelines. These guidelines do not currently account for right-aligned icons. I agree that icons can tend to visually detach when placed on the right with left-aligned text. My personal bias for the moment is to simply not show icons on the opposite side of the layout from text with which it is associated. I'm hopeful to hear what other folks here think about that though, in case I'm not thinking about something.

- to what degree user code may impact any of the above (ie. "if i use it in my application, should i be able to say i want the font 3em rather than 2em? Can I use html to impact the look?")

To *enforce* the shown look, the style must atm. perform some *really* ugly stuff (inc. text manipulation to get rid of html entities) on the widget - i would call that simply "inacceptable" for the default KDE style.

-> Depending on what is demanded, we would have to take away control from the user code and either alter the hard code or delegate it to the UI style.
The alternative would be that all devs acknowledge the HIG demands, but
- that's unrealistic (ie. you'd keep filing bugs on this
- KWidgetAddons is tier1 and cannot be thought as "KDE session only - so if they adhere to the KDE HIG, they might fail on gnome or windows etc.

I confess this is becoming quite difficult for me now. By my view, much of these are questions for developers not designers. But despite my expressed reservations, I'll try to respond....

If KWidgetAddons, of which I assume KTitleWidget is a part, is not restricted to KDE, then I suppose it doesn't make sense from my limited perspective that this is where Breeze-specific visual design objectives should be enforced. Rather it seems like the style is the best place to enforce style-specific visual design objectives. If changes are needed to the widget (or perhaps a new convenience widget is created without the baggage) that would allow styles to properly express style-specific visuals without performing really ugly stuff then that would also seem to make sense. The fact that our previous default style, Oxygen, and several other styles, are performing such really ugly stuff to achieve title visuals that have no framing and no additional padding is perhaps already enough to demonstrate a credible need to support this. (But here's the thing: there may well be a bunch of holes that I'm sure developers familiar with ktitlewidget and kstyles could punch into everything I just wrote. If not, then it is difficult to imagine that said developers could not already conclude much the same thing on their own.)

Ultimately, whether this is implemented the "really ugly stuff" way, or by making changes that obviate the need for really ugly stuff, is a developer decision that I'm honestly not inclined, or equipped, to get in the middle of. If the position is that the Breeze visual design for titles will not be implemented because of these implementation challenges then, of course, there's little the VDG can do but live with that result. I do hope that's not where we end up since it would be a regression in the title visuals, but it is what it is. Now if there are reservations about the proposed visual design of titles for the Breeze style (e.g. no frame, no padding, etc.) then I'm very happy to participate in that discussion with the rest of the VDG community as a visual design issue, without using the implementation challenges as a proxy for that discussion.

Hope this helps (sorry if it doesn't).