Multiple styles in icon themes and the future of the XDG icon specs

[Simon Lees]

On 11/20/19 4:33 AM, Noah Davis wrote:
> On 2019-11-19 09:32:21 EST, Bollinger, John C <John.Bollinger at STJUDE.ORG> wrote:
>> What you're describing could be characterized as using different _themes_ for different parts of a GUI, and indeed, it may be that structuring your design around that idea would provide a way forward that benefits from reasonably good support from existing foundations.
>>
>> Do keep in mind, however, that one of the main objectives of themes is to provide UI elements that are consistent across applications and contexts.  You may not remember the days when every application provided its own icons for everything, but it was needlessly painful and made everything harder to use.  Consistent icon naming does support icon theme swapping, but that's a secondary consideration.
> 
> Thank you for the suggestion. I didn't know that was possible, but I suppose that makes sense. However, we'll still need to have a way to group the monochrome and color themes together. The fact that there are 2 parts (themes) to Breeze icons should be abstracted away when a user selects Breeze icons in the system settings. It should also be possible for users to use ungrouped themes like Oxygen and Papirus without any issues or additional configuration. I'd also like it if Breeze icons could be a popular outside of Plasma, but that's a lower priority goal than fixing this issue.
> 

I think the simplest way to do this is to focus more on implementing it
in the toolkits rather then by drastic changes to the desktop spec.
Possibly the best way forward could be to teach toolkits to use two
themes, the standard theme and the "application" theme (for lack of a
better name). If the application theme is set then the toolkit would use
it over the "main" theme for the elements you suggested such as buttons
etc. You could then extend the button api etc with a flag that tells it
to use the main theme instead. You could also add api to QApplication
(or its equivalent) that specifies certain applications like maybe
desktops should ignore the application theme.

In a similar way to the way the current spec allows you to set a
fallback theme for missing icons we could also extend it to specify a
"application" theme that it could choose to use or not to use.

If you were to then ship a breeze-monochorome theme that falls back to
the breeze theme, users of toolkits that didn't support this new
functionality could choose to use breeze-monochrome and have 95% of
there icons looking right (with the exception of ones with conflicts).
If a KDE user was to set gtk to use breeze-monochorome for example then
pretty much all of there icons would look in place.

The default enlightenment / efl icon set is taking a similar stylistic
approach but rather then using monochrome for most things like actions
it uses a single shade of blue.

>> Consistency would not be impacted too badly by a multi-theme UI if the themes involved were appropriately designed for use together.  For example, monochrome and full-color versions of the same icons would probably work together without too much friction, but even there you're stepping on user expectations: I predict that most users would suppose that there was some difference between the meaning of color and monochrome versions of an icon.  In that particular case, in fact, I'd expect that some users would confuse the monochrome icons with icons for disabled actions.
> 
> I'm not worried about this. Users these days seem to be pretty used to using monochromatic icons for buttons/menus and nobody has complained yet about monochrome icons looking like icons for disabled buttons. The color icons give us an easier way to convey more information where it matters. For instance, it's rather difficult to make unique mimetype icons without using color.
> 

In terms of disabled buttons etc, generally having a monochromatic icon
at 50% (ish) grey is enough to show that something is disabled. In terms
of mimetypes it doesn't sound like this proposal was planning to use
monochromatic icons there.


-- 

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20191120/c7d86b92/attachment.sig>