+1 for the full bleed highlight hugo.

Three tabs designs for document mode, and their look in three applications :

• Konqueror : tabs below toolbar, whole width
• Dolphin : tabs below toolbar, panels on the window sides
• Rekonq : tabs above toolbar, whole width

As the HIG says nothing about tab placement, I think we should support both layouts equally well.
Focused tab bars are difficult to do, because focus on a single tab doesn't make sense (just as with lists). That's why all three versions use a 2px line below the whole bar.

Louis

louis94 wrote:Three tabs designs for document mode, and their look in three applications :

• Konqueror : tabs below toolbar, whole width
• Dolphin : tabs below toolbar, panels on the window sides
• Rekonq : tabs above toolbar, whole width

As the HIG says nothing about tab placement, I think we should support both layouts equally well.
Focused tab bars are difficult to do, because focus on a single tab doesn't make sense (just as with lists). That's why all three versions use a 2px line below the whole bar.

Louis

I really like 1 and 3, 2 is too heavy for me. The current Breeze in 5.4 implementation (non-focused tabs are dimmed) is very clear and nice too, to be honest, so I'd really like keep that option too.

+1 on keeping the current one, the focus is much more obvious to me.

ScionicSpectre wrote:I'm not worried about changing the saturated icons in menus as they tend to use color for a specific reason that should remain intact (like the Ø in the menu you've shown or the X on buttons).

On coloring icons, I'm not sure I understand completely the statement above.
Anyway: the way I do it now in my local breeze, every color, from every icon, is turned into "white". That's the easiest way I can think of (basically, I take the alpha channel of the icon and compose that with a white square).

So that the close button becomes white entirely when hovered too.
I believe it works decently for all "monochrome" icons.
It fails completely on others, for which you basically end up with a white square.
For instance, it completely fails in Dolphin's "open with" submenu, where all icons are application icons, and are not monochrome.

Basically, for this to work at the style level, we need a mecanism to know which icon should be colorized and which should not. I have no idea about which mechanism could work.

on adding an extra semi-transparent black pixel around the menus, first:
the same is done already for windows (it is part of the kwin shadow)
it can be done also for menus, but last time I tried the result was rather poor because it would just blured the current menu's outline. (which windows do not have).
So that one would need to drop the outline entirely.
... which, in turn, breaks when compositing is not available.
(and it does break already for windows).
So that you'd basically need two setups, one with outline (and no shadow) when compositing is off; one without outline and with 1pixel shadow, when compositing is off.
I'd consider this low priority, since
- complicated
- and current design with outline only is already pretty good.

@Hugo Agreed on the menus given that information. If using a thin shadow yields similar benefits for twice the work while making non-composited menus indistinguishable, among other downsides, it's certainly not worth it. I'd say stick with what you've got and tweak it if necessary.

So far as icons are concerned, I thought you may have meant grey, but now I see that you meant monochrome in the more literal sense. Now that I know the effect is applied to all icons indiscriminately, I can see how it wouldn't be possible to implement as-is. As it may be burdensome to somehow qualify icons as monochrome in the theme data itself, I'd say we should evaluate the colors in realtime.

Is it possible to read the pixel information of the icons before you apply the alpha to the white square? If so, we could take the first pixel with any degree of opacity and find its hue, then only apply the alpha if each semi-opaque/opaque pixel has the same color information. If one pixel varies just don't make the white square in the first place. You could also accept a maximum of 2 colors in case an icon has something extra like a green + or red x (I'm sure there's something like that somewhere).

If it's even possible, the downside is that the majority of menu icons are monochrome, so evaluating all pixels is the default while you'd skip most pixels in the less common case of application icons being present in a menu. It would be silly to introduce a great deal of image processing to the theme, but if the cost is negligible it may be worth a shot.

P.S. Another, less reliable but also less costly operation would be to evaluate only the alpha channel and count the transparent pixels. Most of Breeze's monochrome icons are more than 60% transparent, while the application icons are mostly opaque. If an application icon happens to be mostly transparent, it would arguably look okay as a silhouette.

ScionicSpectre wrote:Is it possible to read the pixel information of the icons before you apply the alpha to the white square? If so, we could take the first pixel with any degree of opacity and find its hue, then only apply the alpha if each semi-opaque/opaque pixel has the same color information. If one pixel varies just don't make the white square in the first place. You could also accept a maximum of 2 colors in case an icon has something extra like a green + or red x (I'm sure there's something like that somewhere).

One can just take pixels not very different from the text color or selection bg color and change them to the selection fg color. It works fairly well for Breeze and even Oxygen (click for source .kra) :

ScionicSpectre wrote:Is it possible to read the pixel information of the icons before you apply the alpha to the white square?

It is possible only for QImage, not QPixmap (which is what the style works with. And conversion from pixmap to image is quite expensive.
Still: we could possibly cache.

But then that is not the whole story. We also do not always get the "raw" pixmap (with the original color). Effects (on mouse-over for instance) can be added, that are configurable, and applied at run-time, on which we have no control (see systemsettings->icons->advanced). So you cannot predict which color to actually trigger on the colorization.

ScionicSpectre wrote:P.S. Another, less reliable but also less costly operation would be to evaluate only the alpha channel and count the transparent pixels. Most of Breeze's monochrome icons are more than 60% transparent, while the application icons are mostly opaque. If an application icon happens to be mostly transparent, it would arguably look okay as a silhouette.

ok. Except again, that counting pixels is not trivial on QPixmap. I'll try to look into this a bit more though (that could be promising)

... in any case: there will be no heuristic that works 100%.

QWidget/Qt5 uses the raster graphicssystem almost exclusively, QPixmap <-> QImage is close to noop (the pixmap is internally an image) - QtQuick is however GL, that up/download is expensive.

Simply turning the pixels white is however close to an instant fail - notably when not using the breeze icon theme. I usually go for mapping the (conditionally inverted) grey value into the alpha level of a single colored image, that's however not cheap. To avoid the inversion detection, one could just compare the value of the highlight color to that of the regular background (darker -> invert icon values, ie. dark get much alpha)

This should work fine for the menus (you can "forcefully" load the normal icon variant for internal processing), but fail in eg. dolphin or wherever the selected item is not entirely painted by the style, but composed by the client code.

luebking wrote:QWidget/Qt5 uses the raster graphicssystem almost exclusively, QPixmap <-> QImage is close to noop (the pixmap is internally an image) -

Nice !
Did no know.
me I'm focusing on the QWidget style anyway !

luebking wrote:Simply turning the pixels white is however close to an instant fail
- notably when not using the breeze icon theme.

Yes sure. I made it an "option", which you could even tie to the icon theme name.

luebking wrote:I usually go for mapping the (conditionally inverted) grey value into the alpha level of a single colored image, that's however not cheap. To avoid the inversion detection, one could just compare the value of the highlight color to that of the regular background (darker -> invert icon values, ie. dark get much alpha)
This should work fine for the menus (you can "forcefully" load the normal icon variant for internal processing), but fail in eg. dolphin or wherever the selected item is not entirely painted by the style, but composed by the client code.

ok

Thanks for digging in and informing us about these limitations, Hugo. I suppose the methods I mentioned could at least help us automate some of the work involved with a more explicit mechanism if we end up going that route.

For those who want to test from latest, I have pushed to git master the changes we discussed on menu highlight, as well as a couple more changes that I discussed with Andrew:

1/ reduced (1pixel) the size of the chexboxes and radiobuttons (so that they match better the default icon size), and restore balance in the new (borderless) menus;
2/ added an outline to the button's focus, similar to what was added to menus, in order to prevent the same "bleeding" of the blue fill over the shadow.

Feel free to give it a shot and come back

In the /dev folder icons are missing for block and character devices.