Additional appearance options for skins

[egmont]

Forking from #2165:

Currently skins define multiple things: colors, single vs double lines, certain Unicode symbols etc. One might argue that it's the intended behavior: a skin should define all details of the look (but not the layout or behavior). On the other hand, it might be reasonable to decouple these from each other, since that gives more flexibility for those users who don't dig into editing skin files. For all the three ideas listed here there might be scenarios (e.g. Linux console) where one of the two states is not supported, hence currently the available skins are quite limited and moving these properties to separate options significantly increases the number of usable skins. It's also useful because it allows the users to easily create something that visually pleases them more, e.g. I personally prefer single lines but there are some great color schemes using double lines.

I have three ideas in mind. At this moment the first two are implemented.

1. Single lines vs. double lines.

All the skins were altered to properly define the double line drawing characters. It's a runtime decision whether those are actually used or not.

It's not only a personal preference, it's also a workaround for some limited terminals. E.g. my Linux console cannot display double lines, whereas the modarcon* skins specifically designed for console uses double lines.

The "darkfar" skin is removed, since this was the double-line version of "dark". The "double-lines" skin was also removed, it's quite like the default with double lines, except for the (IMO very ugly) dark blue menu/button lines. If you prefer to keep this skin, it should be renamed to something else. The "featured" skin could probably also be removed, it's almost like "default", but uses UTF-8 instead of ASCII compatibility stuff (see the 3rd point). Maybe the whole [Lines] section could be removed from the skins and be hardcoded in mc, I see no reason why anyone would want to redefine them - but in the initial patch it's not removed so I didn't remove any feature.

2. Underlined hotkeys

So far all skins used a different color for the hotkey. This is against the common UI approach of using underline, and IMHO results in too much visual clutter (too many colors). My sand256 skin was the only one using underlines (also demoing the then new feature of having underlined attribute). Now you can choose for each skin if you'd prefer the color from the skin, or make the hotkeys underlined (and same color of non-hotkey characters). I've also changed the hotkeys in sand256 to use color instead of underline, so you get two possibilities here just as in any other skins.

Technical detail: This required some special hacking, since from now on we use color+attr combos that are not explicitly mentioned in the skin file. I decided to add both kinds of hotkey colors (the special color, as well as the normal color underlined) to the color hashtable, so we can toggle the hotkey look without re-reading the skin and regenerating the color palette. I also thought that this should be private business belonging to the skin engine, rather than branching on the setting all over the code. So I put it in the caching layer, the cached table at the corresponding indexes is populated with either the actual different color, or with the underlined version, depending on the setting. Toggling the setting leaves the hash table intact, requires only the color cache to be regenerated.

3. Unicode symbols

Some skins use fancy Unicode symbols, e.g. ↑ and ↓ for sorting order which look really great. Some others use ASCII symbols for compatibility (and then it's quite hard to tell what the arrow's replacement characters actually stand for). Interestingly, even though I don't have double lines on my Linux console, I do have all these fancy Unicode characters. My recommendation is to make all the skins contain fancy Unicode characters, and make it a compatibility UI-checkbox to revert to builtin ASCII characters. This one's not yet implemented.

[egmont]

v1: add Double lines and Underlined hotkeys options

[ossi]

i'm very much in favor of this, because it allows an elegant way to address #4539.

more broadly, there is a tradeoff to be struck between skins being self-contained representations of their creators' visions, and actually addressing users' needs. it's bonkers to ask users to fork a theme whenever they are dissatisfied with some aspect of it that can be easily expressed algorithmically.

[zaytsev]

Probably it would have been a fine idea if we had mc^2 - one could allow pluggable transformers in JavaScript, which would work whatever magic on skins the user cares to express programmatically and not overload the core with code, options, etc.

Until then, maybe skin inheritance would strike the tradeoff between being unopinionated and generic enough... hard-wiring opinionated transformers into the core in C doesn't feel great. But anyways, I think the skin activity level is more or less manageable at the moment.

[ossi]

i don't think that scriptability is a reasonable precondition for that. it's not something many users would want to deal with, even if they'd be able to.

and using scripting for an upstream implementation would only complicate matters, if anything.

one could embed the scripting into the skins themselves, so they'd offer their own config dialog extensions. however, that would be totally over-engineered for the purpose, and highly redundant (because in practice, all options that make sense at all, make sense for all skins).

skin inheritance (or just the ability to comfortably modify a skin in the ui) wouldn't be a particularly good solution for the problems under consideration here, because it would still require a lot of redundant manual work.

i find the current skin selector to be a nightmare, with tens of entries that demultiplex all permutations that someone deemed worthwhile including. the user-friendly thing to do is to present orthogonal options as such.