Yes "please use the familiar shape" is the main concern. Using the familiar shape for a different purpose is risky.

Here's the case, people accustomed with Oxygen style (similar to Windows 9x style in this regard) radio button then see the small box like a dot. The purpose changed, the look is familiar:



Just my concern. Looking forward to test the current style on more users.

I assume that one should rather place it next to the present radiobutton (w/ shrinked dot to check whether it's uncertain in relation.

However, w/o feeling the need to defend other peoples design decision and on a general scope:
please reconsider whether the purpose (would have) actually changed.

Just that checkboxes and radiobuttons do look much different on OtherOS™ does not imply they're actually much different.
Both are simple option toggles (yes, CBs have tristates...) with the major difference in not what they do, but in that one's exclusive and the other's not.

That doesn't mean one should use the very same look on them, but even a "slightly" different look (as long as consistent and you don't need a magnifier to spot the difference) is imo sufficient.
The user wants to alter options, not seek "Well, what checkboxes do we have available here? DARN, it's a radio!! Why aren't they more distinct?!")
So if "option toggles" look similar, he'll easily find that group.

As a matter of fact:
motif checkboxes are squares and radiobuttons are 45° rotated squares.

Users will regularly use our system and hence they will regularly be confronted with the design of our checkboxes and radiobuttons. So, as long as they are distinguishable (which they are imho), users will learn how they look. Even though the new design does not use checks, it still refers to the squareish (checkbox) vs. roundish (radiobuttons) base shape - which is the most important reference to be able to learn the stuff.

I think: If it is important from a design perspective to use this design language, do not make any compromises - the design will work.

BTW: this is a typical example for the presentation layer as proposed by Baxley (sorry, original links I have seem to not work anymore, take a look at our work on that:http://user-prompt.com/styleguide-nach-dem-baxley-modell-german-language-only/). Effects on there are well visible to the users and hence get a lot of feedback, but take little or no effect on the actual usability of the software.

bjoernbalazs wrote:Users will regularly use our system and hence they will regularly be confronted with the design of our checkboxes and radiobuttons. So, as long as they are distinguishable (which they are imho), users will learn how they look. Even though the new design does not use checks, it still refers to the squareish (checkbox) vs. roundish (radiobuttons) base shape - which is the most important reference to be able to learn the stuff.

I think: If it is important from a design perspective to use this design language, do not make any compromises - the design will work.

BTW: this is a typical example for the presentation layer as proposed by Baxley (sorry, original links I have seem to not work anymore, take a look at our work on that:http://user-prompt.com/styleguide-nach-dem-baxley-modell-german-language-only/). Effects on there are well visible to the users and hence get a lot of feedback, but take little or no effect on the actual usability of the software.

I'd like to ask to analyze one thing: we only control "KDE Apps", and more 5 than 4 these days. A general purpose app (not a plasmoid gadget) works on many OSes, what is a DNA of Qt-based software. Let's see how many of these KDE apps run in their home, Plasma 5 or re-styled Plasma 4, and how many are rather foreign (or just part of a big mix):

Case 1. 99% of desktop audience sits outside of Plasma (Windows, Mac),
Case 2. within the rest, say, 0.4% is a non-KDE Plasma desktop

For 1. and 2. KDE apps creatively styled (e.g. with the check-mark-less check-box ) are surrounded by apps with "traditional" check-boxes. "Why is that", Joe User asks? What does the box mean, how it differs to the check-mark (which is clearly identified as a "system standard" on 1.+2.)? To avoid that some app authors take extra care to package apps using whatever the native style is. I can understand them.

Case 3. remaining 0.6% is a desktop coming from the KDE community, but still:

Case 3.1. There are Plasma 4 desktops. Let's say 0.2% is a properly configured KDE 4 installation with KDE4-breeze style and icons. Let's assume *nobody* changes the icons set and the style. But there for users that upgrade their systems to newer KDE 4, Oxygen stays selected for in their profiles (unless we or distributors violate this principle of not altering user settings on upgrade). No Breeze for many of these systems then at least by default. These installation would eventually migrate to Case 3.3, that's a good news. Or to competition if we alienate them...

Case 3.2 There are non-Plasma projects formed around the KDE community such as Razor and LXQt. A big achievement in itself. But no Breeze there. Let's say that's 0.1% combined.

Case 3.3. Remaining 0.3% are new Plasma 5 installations or full upgrades. A matter of future that we can already see. Breeze is there by default, and benefits from users' inertia: they often do not change defaults. Unless it really hurts to stay with defaults, then they may reinstall (I know programmers that do it - we learn that includes Linus Torvalds too). "System" design language here *is* compatible with the innovations by VDG. Still, users run GIMP, Inkscape, 3rd-party browsers. Most of time, non-KDE apps want to occupy the top-level space. It's up to distributors (non-KDE, unless we mean Kubuntu and dedicated openSUSE/whatevery guys) to theme the non-KDE software in order to increase use of the KDE's own design language across the system. But it's not as clean as we see on Mac, or mobile iOS, where 3rd-parties seem to care about being part of the "visual game". On mac even 3rd-party frameworks (think: Qt) try to mimick the "system" feel. Here in Linux we cannot expect the same: ask the GNOME project if they will offer Breeze versions of their apps. There's little chance to even compatible file dialogs...

So while innovative redesign takes place, we have a chance for future-proof consistency in 0.3% of the installation base. It's like if Ferrari were allowed design part of their spoilers only, while rest of the parts and integration comes from random manufacturers and designers. Then things are even more interesting because *compositing* and *distribution* of that "Ferrari" is handled by an Eurovan-like cooperation leading to *badge engineering*.

The numbers above, totally unscientific, are here to share some idea with you. I think the maths still work if the numbers are inaccurate by 1000%.
I see how, it all depends on the target audience for given apps. Core KDE apps, like an editor and a file manager, are shipped with the desktop. Other apps, to expand their markets, do not set such limits. Think what would LibreOffice be today if it was only offered under GNOME, just because its widgets are styled through GTK+.

Summing up, design languages are nice if we own the platform *and* its distribution channels. It's so much more doable for initiatives such as Nitrux. But isn't it true that the higher degree of freedom of aggregation and distribution comes at a cost of breaking the design language, consistency, and so on? There is no KDE OS and I think respect to our contributors supporting other OSes mean that there shouldn't be one.

I believe, in addition to the great platform level (desktop or mobile), there's a lot of work needed at a level of particular apps, to make them beautiful, distinct, so I have no doubts energy of the VDG won't be wasted, can be utilized. I am planning myself to send multiple request for support regarding various aspects of the app I am maintaining.

I don't think KDE applications should use the Breeze style if they're running outside of Plasma 5. Isn't one of the strengths of Qt that it can adopt a "native" look wherever it runs?

Qt uses visual style (including margins, button ordering and whatnot), icons, colors, shortcuts of the enviroment it's running on - be it KDE, Windows, OSX or GNOME.

On GTK+
-------------
"The answer is that GTK+ is primarily intended to be used on the GNOME desktop" "GTK+ must focus on being the toolkit of the GNOME platform first, and tackle integration second."

--- https://lwn.net/Articles/562856/

colomar wrote:I don't think KDE applications should use the Breeze style if they're running outside of Plasma 5. Isn't one of the strengths of Qt that it can adopt a "native" look wherever it runs?

I see what you mean. But there's not only the level of Qt style, there are concepts codified by HIG, most notable layouts; KDE apps will hopefully move to use the HIGs, new apps would be created too.

The end effect: apps with the KDE HIG with some other icons, some other style (even one we've never tested).

I especially detest a case related to the most visible area: some actions are app-specific so have Breeze icons, some actions are standard, and come from a random icon theme. Documentation (if it even exists) refers to icons many users have never chance to see. What's a motivation for those that contribute documentation...

Such things is rarely experienced in closed-source competition, having much finer-grained control over distribution.

This is a gray area. I am not proposing any rules or so. I'd just like to hear thoughts of non-programming designers here.

luebking wrote:Qt uses visual style (including margins, button ordering and whatnot), icons, colors, shortcuts of the enviroment it's running on - be it KDE, Windows, OSX or GNOME.

Yes, that's one of reasons for our dedication to Qt! On the other hand (now follows some stuff that must be obvious to designers): there's no tool under the Sun to switch to other HIGs on these platforms (cool, designers and developers can keep their jobs!). If I see it pays back, I am redesigning some layouts for a major platform, you know how it's performed. It's not a part of QStyle, icons, etc. The most advanced is Qt's Menu that transforms on Mac, and QFormLayout, QDialogButtonBox. Even margins, alignment are a disaster, they do not sum up. Client side decorations is a technical problem if it (or equivalent) is present for one toolkit and not another.

Plasma Active stuff will help in mobile but not replace designer's work.

There's no magical automapping that transforms a KDE chat app to this (or/and back) ...

I confirm the approach of GNOME, they kind of gave up with GTK+ as a cross platform toolkit already.

The only way to have switchable is to make sure that, say, GNOME HIG stays at level of GTK+ 1, and we're at Qt 2. And nobody implements custom widgets.

Fortunately, the VDG efforts are not intended to be limited to low level building blocks like widget styles and icons. (As colomar and luebking mentioned, these are easily swapped out at run-time by distros or users.)

For clarity, the design "structure" is not monolithic. At its highest levels are the design vision and principles which are not specific to style or visuals, the layers below that, Behavior and Presentation, become increasing more specific. The style is just one element of presentation involving icons, colors, typography. The style is applied to the UI controls design, icon design, color schemes, fonts and the like. Style, while very important, is acknowledged to be the most ephemeral and transient component of any design. As such, the style needs to be able to be swapped out without affecting the other layers of the design "stack". All the other things that go into producing functional, consistent beautiful design like layout, behavior, wording, information hierarchy, and the like, are things that the VDG is also explicitly interested in and actively working on. It's part of why usability folks are active, core participants here. Our full intention has always been to work our way up that "stack" to application design and full desktop environment design. Those are efforts are already underway with continuous KDE HIG updates and application design work already being shared here on the forums. There's no magic that'll "swap out" HIGs at runtime, because they are, by definition, design-time guidelines affecting design-time decisions.

So I'm certainly looking forward to helping out in whatever way we can on your project jstaniek. My recommendation right now is to take a glance at the updated KDE HIG, try to apply the guidelines, and help us make it and, ultimately, the application designs for your project and other KDE projects better. Of course we won't get everything perfect all at once (who does?). But the hope is that KDE will get better and better over time.

I frankly do no longer see any relation to checkboxes, but be it.

jstaniek wrote:some actions are app-specific so have Breeze icons, some actions are standard, and come from a random icon theme.

KIconLoader is theme aware even for /usr/share/app icons - you can ship a breeze, oxygen & hicolor variants and the proper one is gonna be picked.
Since you can change icon themes on Windows as well, you're in trouble there anyway.

jstaniek wrote:If I see it pays back, I am redesigning some layouts for a major platform, you know how it's performed. It's not a part of QStyle, icons, etc. The most advanced is Qt's Menu that transforms on Mac, and QFormLayout, QDialogButtonBox. Even margins are a disaster, they do not sum up.

I'n not sure whether I understand what you're trying to say, but default margins are controlled by QStyle and you can also query the pixel value

Code: Select all

style()->pixelMetric(QStyle::PM_*, 0, this); // pretty please always pass the widget, key? ;-)

If you start to bring custom margins or spacers to fit text width (epic fail or similar, you'll be in trouble anyway - yes.

About the formlayout, you'll likely run into the QStyle::SH_FormLayoutWrapPolicy, QStyle::SH_FormLayoutFieldGrowthPolicy, QStyle::SH_FormLayoutFormAlignment, QStyle::SH_FormLayoutLabelAlignment trap.
If you've a specific question on how to control your metrics in this regard (and all systems), please mail kde-devel@kde.org

jstaniek wrote:There's no magical automapping that transforms a KDE chat app to this (or/and back) ...

Button sizes and all margins and paddings are controlled by QStyle - you'd have to invoke them from custom QItemDelegates, of course.
The major difference is that this application is clearly tailored for a touchdevice - turning that into a desktop interface and vv. will of course not happen magically.

Okay, one thing I agree with jstaniek on: Currently, the situation in many KDe applications apparently isn't like it's supposed to be. Patrick von Reth (of KDE on Windows fame) told me that they set KDE applications to use Oxygen by default instead of the Windows native style, because apparently many KDE developers hard-code measures like spacing and margins so they work perfectly with Oxygen, and therefore they look bad in any other theme.
Yes, this is an epic fail, no doubt about it, and these applications will likely look horrible on Breeze as well.
It is something we definitely have to fix. As long as KDE applications on Windows cannot use native widget style because of hard-coded layout, KDE has a problem.

colomar wrote:Okay, one thing I agree with jstaniek on: Currently, the situation in many KDe applications apparently isn't like it's supposed to be. Patrick von Reth (of KDE on Windows fame) told me that they set KDE applications to use Oxygen by default instead of the Windows native style, because apparently many KDE developers hard-code measures like spacing and margins so they work perfectly with Oxygen, and therefore they look bad in any other theme.
Yes, this is an epic fail, no doubt about it, and these applications will likely look horrible on Breeze as well.
It is something we definitely have to fix. As long as KDE applications on Windows cannot use native widget style because of hard-coded layout, KDE has a problem.

Yep, on the positive side, improving for Windows/Mac most probably improves for Breeze too. And besides mobile (there's not much GUI code sharing with desktop), there are basically two platforms to target *if* someone wants to have an UX that fits there: Windows, Mac, that's the magical 99%.

@luebking Average /casual/ app developer doesn't play with QStyle metrics. Hobby engineer has no time or motivation, paid engineer totally lacks time. Layout params are largely unused. I do use some metrics (especially in proxy styles) since Kexi has quite some custom stuff, it's a RAD app builder after all. But in best case on Macs traditional apps would present a Qt main window with a Mac skin (read: backgrounds). Windows is closer to how have Qt apps are laid out (moreover people don't kill me if I ship alien style because they are used to .NET style - and dozens of other niche styles there running side-by-side); Mac and GNOME 3 and Unity is not that close. Ironically, Unity switches to Qt but common technology isn't enough to make apps HIG-switchable (Canonical uses Qt Quick but 'invented' CSS for its GUI).

The trick is to structure, separate and hide differences (coming from HIG differences) in the code. That's needed bit, even if not sufficient.

This discussion is still BTW of the check-boxes for me because their current distinctive design is apparently assumed as dominant one on the user's machine. I presented most obvious scenarios where it's not quite the case, at best KDE's style is one of many. No doubt there must be other areas making it a bit harder to blend a Breeze-styled KDE app in a foreign environment, I just found the check-box as a good example.

I'd like to see the approach analyzed: KDE apps with Breeze icons (and/or style) running in foreign environments, so the identity is somehow kept.

Thanks a lot, VDG.

What annoys me, is the fact that the Breeze Plama theme uses a checkmark for the checkbox, while the widget theme doesn't. This could become more important when Plasma Mobile Apps use the Plasma Theme, while other applications, which are ported versions of their desktop version, still use the Breeze widget theme on smartphones. In my opinion, there should be a decision wether to use checkmarks everywhere or to use squares everywhere.

janop wrote:What annoys me, is the fact that the Breeze Plama theme uses a checkmark for the checkbox, while the widget theme doesn't. This could become more important when Plasma Mobile Apps use the Plasma Theme, while other applications, which are ported versions of their desktop version, still use the Breeze widget theme on smartphones. In my opinion, there should be a decision wether to use checkmarks everywhere or to use squares everywhere.

Yes. And it's possible to develop apps that are partially QWidget-based, partially Qt Quick...

janop wrote:What annoys me, is the fact that the Breeze Plama theme uses a checkmark for the checkbox, while the widget theme doesn't. This could become more important when Plasma Mobile Apps use the Plasma Theme, while other applications, which are ported versions of their desktop version, still use the Breeze widget theme on smartphones. In my opinion, there should be a decision wether to use checkmarks everywhere or to use squares everywhere.

This difference is currently due to a technical limitation in the plasma theme engine. The reference design is what is currently implemented in the application widget style. The plasma checkbox is difficult to change to match the reference design until the current technical limitation is resolved. A bug has been filed to request a fix for the technical limitation (https://bugs.kde.org/show_bug.cgi?id=354756).