On 2019-11-19 09:32:21 EST, Bollinger, John C <john.bollin...@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. > 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. > No doubt the specs could be so modified, but I don't think they should be. > Themes already serve effectively as namespaces for icon names. It would be > less disruptive and more portable to build support for multi-theming than to > make themes themselves more complex. If you want to look at it this way, I > suppose I'm suggesting that you approach the problem by adding a new layer of > indirection. As a rather inexperienced designer/developer, I'm not sure how that should be done. Once again, thank you. This has been a problem I've been struggling with for a while.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
