id summary reporter owner description type status priority milestone component version resolution keywords cc blockedby blocking branch_state votes 3169 Additional Appearance options 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." enhancement new minor Future Releases mc-skin master 3160 no branch