Uri has done a great job coming up with icon design guidelines, that we just completed integrating into the KDE Human Interface Guidelines (HIG). The Breeze color palette has been expanded and mapped to the KColorScheme color roles. Paired together the hope is that you'll have a little more help on designing icons and using color in icon designs. (There have been lots of other HIG updates as well which I'll do a blog post about soon.)

For now visit the KDE HIG here: https://techbase.kde.org/Projects/Usability/HIG. The updated Colors and Icon Design guidelines are under Presentation/Style.

Hope this helps!

Great job! And thanks for the hex values of colors.

On the monochrome toolbar icons:
Are there any any considerations on how to "make them work" with dark color schemes and/or inverted toolbars (by style or eg. application stylesheet, eg. for fullscreen modes etc.)?

Any chance to pass them some contrasting outline or similar?

They could be outlined or inverted when painting them but that's rather slow and usually visually inferior (value reversion should look better than inversion, but is even slower)

Great question luebking,

Uri has graciously provided versions of the monochrome icons for use with dark themes. With those we now have a Breeze Dark icon theme made specifically for use with dark color schemes. We're Just awaiting some final reviews and permissions but the hope is that it will be available for Plasma 5.

Here's a quick screenshot of my desktop from this weekend of the icons with a new Breeze Dark color scheme and the existing Breeze Dark Plasma theme:



Perhaps we'll be able to put together a "Dark" Look and Feel package, that makes it easy to switch out all the underlying theme elements (color scheme, plasma theme, icons, etc.) to get a nice functional dark theme in a couple clicks.

Hope this helps!

My concern was rather the "I use a bright colorscheme but have digikam configured to a dark scheme" setup, or things like

Code: Select all

m_toolbar->setStyleSheet("background:black;color:white;");

Also color schemes can be split (bright base color, dark window color - the toolbar takes the "button" color in some styles, iirc following the MS Windows approach)

Last but not least: virtuality allows to "invert" dialogs, docks and toolbars - so i'm under special pressure here

luebking wrote:My concern was rather the "I use a bright colorscheme but have digikam configured to a dark scheme" setup, or things like

Code: Select all

m_toolbar->setStyleSheet("background:black;color:white;");

Also color schemes can be split (bright base color, dark window color - the toolbar takes the "button" color in some styles, iirc following the MS Windows approach)

Last but not least: virtuality allows to "invert" dialogs, docks and toolbars - so i'm under special pressure here

Ahh, yes that is indeed a tougher problem. I'm not sure what the correct implementation solution is. If I had my druthers though, I wish I could specify a simple alias for the full collection of theme assets (colors, icons, etc) necessary to run an application using a dark/alternate theme. Something like:

Code: Select all

$ KDE_LOOK_FEEL="Breeze Dark" digikam

which would set the color scheme, the icon theme, etc. that digikam will use for that instance. Set that as the launch command for digikam's .desktop file (or maybe a .desktop key/value pair) and it always runs with the collection of theme assets represented by that alias. Maybe even a system setting, with sensible defaults, that let the user set theme individual theme assets for the system Darl/Alternate theme.

Basically any solution that keeps the changes required by either theme designers, desktop developers or application developers to an absolute minimum - zero if possible. Otherwise I think we end up with visually challenging, complicated solutions like having to add double contrast to monochrome icons, programatically changing icon colors based on the background color (which can lead to unexpected results) or potentially having application-specific code to handle changing certain visual elements and not others. At some point though, so long as a user is able to change one aspect of the visuals and not others, I think it's probably worth more to make it easier for things to look right than it is to prevent things from looking bad.

Just some random thoughts that popped into my head luebking. Good questions as always.

alake wrote:Perhaps we'll be able to put together a "Dark" Look and Feel package, that makes it easy to switch out all the underlying theme elements (color scheme, plasma theme, icons, etc.) to get a nice functional dark theme in a couple clicks.

Ah yes, that absolutely makes sense! We should put "Create a Breeze Dark L&F Package" on the todo for 5.2

It's possible to "shadow" the icon theme by adding per application icons, but you'd just get "/usr/share/apps/digikam/icons/Breeze/64x64/..." - it *might* be possible to "abuse" this system to provide different icons for bright and dark schemes/conditions, but that is of course terrible overhead. Atm. icons are shared memory among all processes and by such system one would bring duplicates in memory and on disk for every interested application.

Also such system could not cover high contrasting theme, where the (very nice, i like that monochrome dark icons exist in the (bright) foldertree and on the (dark) toolbar.

Together with the nearly undetactable lack of contrast that can be caused by style sheets (sheets on widgets are relatively easy to parse, but if an application like Qupzilla uses an application wide stylesheet, the breeze style -or any other to go along this icon theme- would require a fullblown css parser to know the color of a toolbar .- unless that's don by a background image...) I can frankly not think of any "robust" (reliably visible in any case) solution that does not include contrast inside the icon (though doesn't need to be double, a 50% opacity white outline around the dark icon should do)

I do understand that this may be not an option from an artistical POV, but thought i'd better point out - so you can prepare for bugreports

colomar wrote:

alake wrote:Perhaps we'll be able to put together a "Dark" Look and Feel package, that makes it easy to switch out all the underlying theme elements (color scheme, plasma theme, icons, etc.) to get a nice functional dark theme in a couple clicks.

Ah yes, that absolutely makes sense! We should put "Create a Breeze Dark L&F Package" on the todo for 5.2

Sounds like a plan! I was actually tempted to try to get this done for 5.1 but at the moment I don't even know how to put together a look and feel package, much less put something together. So we'll all be learning a few things in the 5.2 cycle.

luebking wrote:I do understand that this may be not an option from an artistical POV, but thought i'd better point out - so you can prepare for bugreports

Indeed. Thanks for the heads up!

colomar wrote:

alake wrote:Perhaps we'll be able to put together a "Dark" Look and Feel package, that makes it easy to switch out all the underlying theme elements (color scheme, plasma theme, icons, etc.) to get a nice functional dark theme in a couple clicks.

Ah yes, that absolutely makes sense! We should put "Create a Breeze Dark L&F Package" on the todo for 5.2

Another Question is, what to do when the apps use there own icons (app specific icons). how does it work for digikam, amarok, labplot, firefox, gtk apps, ...

the question is from this thread viewtopic.php?f=285&t=123155&p=321091#p321091

does the app developer support for kde 4 oxygen styled icons and for kf5 apps breeze icons, but when you want to use oxygen in kf5. does the specific app icons are than breeze or breeze dark, ... icons and the main theme icons are oxygen? does the apps also need different theme icons?

andreas_k wrote:Another Question is, what to do when the apps use there own icons (app specific icons). how does it work for digikam, amarok, labplot, firefox, gtk apps, ...

the question is from this thread viewtopic.php?f=285&t=123155&p=321091#p321091

does the app developer support for kde 4 oxygen styled icons and for kf5 apps breeze icons, but when you want to use oxygen in kf5. does the specific app icons are than breeze or breeze dark, ... icons and the main theme icons are oxygen? does the apps also need different theme icons?

Applications shipping their own icons isn't a good idea in general, because it means that if the user chooses an icon set with a very different style, the icons which the application ships look alien.
If, for example, labplot ships Breeze icons with its KF5-based version, but a Plasma 5 user has selected Oxygen as their general icon theme (they are free to do so!), you have a mixture of Oxygen and Breeze icons in one application, which looks very very bad.
Therefore, all icons an application uses should be part of the standard icon set. If a specific icon theme doesn't provide these icons, the application can still fall back to a default set. But that way at least we give icon sets a chance to provide icons that match their style.

Ok. so the icon theme work like this.

1. look at the main icon theme for the icons if the icon isn't there
2. use the icons from the specific app folder.

the icon path extension is actually theme aware, ie. if your application requires "exotic" special icons that are shipped with the application, it's totally possible to ship breeze, oxygen and (failsafe) hicolor variants.
the best fitting variant will then be used (ie. if there'd be a theme forking/extending breeze, the breeze addons of the application will be used rather than "hicolor")

Hi,
Copying here what I already posted as "discussion" at https://techbase.kde.org/Projects/Usability/HIG/Color, hopefully for larger audience,

In the color mapping of Breeze Palette wrt KColorScheme I see that Focus and Hover are systematically assigned to the same color. Is that true ?

Has this been already pushed to kf5 ?

This will cause issues in breeze right now since hover (=mouse-over) and focus are two distinct actions and very often only the color can distinguish between the two. Example: the 1pixel frame around editors full background for some buttons. This naturally can be fixed in the breeze style (using either different alpha channels, or different visual representations, such as frame thickness) but 1/ would need more work that is usually not necessary for colorschemes with different hover and focus 2/ will not work in most of the widget styles on the market (oxygen, fusion, etc.) that have the same issues

Any chance people reconsider and assign a different blue to focus ? (usually 'stronger' = more saturated)

Obviously, this should not prevent us to also use different visualisation (aside for color) for hover and focus widgets in the style, though it is not an easy task.
mockups/ideas welcome

Hugo

Good catch Hugo. I was originally thinking that we would just rely on a different effect (opacity) for hover, but I think the right thing to do is supply a different color for hover. For now I think the focus color should remain the Plasma Blue from the primary color set - that Plasma Blue has been the anchor for much of the focus/active visual vocabulary so far across the entirety visual design for plasma. The hover state is transient and temporary so we'll need to pick a color more ephemeral - which may require adding a color to the overall Breeze palette.

I did a quick experiment with a different hover color and, while it is used mostly consistently, in a few places it seems to be used for more than hover (like pressed tool buttons and few other places). So between the potential color palette update and sorting out how the hover color is used in the style, rather than change the hover color just before Plasma 5.1 tagging, I'd like to propose that we resolve this during the 5.2 development cycle. Since artwork freeze for 5.2 is December 19th, it shouldn't be too long before this is sorted out and in the hands of users.

Thanks much for the catch Hugo! We'll work together and figure it all out.