Color collisions

[egmont]

Midnight Commander's color/skin engine often reuses the same color definition for multiple elements on the UI. This unnecessarily limits the possibilities when playing with colors.
See the list below for many examples. Please split all of them into separate color definition keywords. This would allow them to have different colors (and even different attributes, such as underline, if the patch in ticket #2169 gets accepted).
[core]->marked is used in at least three places: for the header of the panels ("'n Name | Size | Modify time"), for files selected with Insert, and for bold font when viewing a preformatted manual page. These three contexts have nothing in common. For the header of the panels, I'd like to have a modest color (probably the same as mc's base colors), because they are always shown and have no reason to be highlighted. Selecting a file is something special, I'd like these selected files to have a really outstanding color with bold font, maybe even a different background. I'd like to have a third pair or colors/attributes for bold in manpages.
The F2 and Alt-e menus use [menu]->menuhot for their title. Dialog and history boxes use [dialog]->dhotnormal. Error boxes use [error]->errdhotnormal for their title. This means if I wish to underline the hotkeys, the title is necessarily underlined, too. In all three cases, the title's color should be a separate new entry, independently of the hotkey colors or any other currently defined colors.
Prompts using the error color scheme (e.g. confirming file deletion) use [error]->_default_ and [error]->errdhotnormal for the non-selected button. For the selected button, the hotkey is colored [error]->errdhotnormal. However, I cannot specify the color for the rest of the selected button: it is always [core]->reverse, the same color as used for the current directory at the very top of the active panel. This is yet again not logical at all, a new color [error]->errdfocus should be used here.
The [caret] symbols to open history are always colored [core]->_default_. In dialogs I'd prefer if I could specify a color matching the dialog's color scheme. Using the panels' main color gives the feeling as if the dialog box was punched here showing whatever's behind.

[egmont]

separate quite a few colors

[egmont]

The attached patch forks off the following colors:

marked -> header (top of the panels), viewbold (nroff's bold and hex offset)
markselect -> viewselected (in hex mode)
reverse -> errdfocus
dhotnormal -> dtitle
errdhotnormal -> errtitle
helpbold -> helptitle
core/_default_ -> inputhistory, commandhistory (buttons opening the history dialog in the cmd line, and everywhere else)

The patch is designed to be applied in top of the 256color patch (#2169) and mc-4.7.0.5-popup-menu-uses-dialog-colors.patch (#2171). If this latter patch is not accepted by you, then yet another color, the new "menutitle" has to be forked off from "menuhot".

Skins are updated, too. Sand256 is the only one that actually changes.

The only part of the patch that probably needs some explanation is layout.c. I believe that COLOR_HOT_NORMAL there is a leftover that's not needed anymore. update_split(), if decides to output anything, sets the color on its own anyway. And the next character, the "=" sign needs to be printed with normal color.

[egmont]

Todo:

• add "old" color name for these
• update builtin black and white scheme
• documentation

[gotar]

Maybe #1670 someone? Any comments there please...

[egmont]

update (whitespace/indent changes only)

[andrew_b]

Unfortunately, mc-4.7.0.6-separate-colors.patch is incomlete:

• new colors are available via skins only and cannot be set via command line, ini file and environment variale;
• color help (mc --help-color) is not patched;
• man page is not patched.

[egmont]

andrew_b: I'm aware of these, see my earlier comment. This ticket depends on two others, one of them has a patch changing the behavior that I'm not sure you'll accept or reject... I'd pretty much like to see those issues resolved, and then I'll move forward with the missing bits here... Does this sound reasonable?

[egmont]

update (whitespace/indent changes only)

[slavazanko]

Created branch 2170_separate_colors (parent: master)

changeset:9b08798e1c290749c8679f7e2c12945100b10725

Review, please.

[slavazanko]

New changesets:

• ecd9b2db325375dfb051c17221d90dee73f433a5: refactoring: renamed some types and enums
• 5db6e8199ca9e5acfc9f66aa3002981847b47c41: Newly added colorpair names now described in man-page

Review, please.

[slavazanko]

ops,

• 1c6538c2f257f01698d9c14ac7fc76c433d3fe75: Newly added colorpair names now described in man-page

[slavazanko]

Commited in master; changeset:f53ed400fbe4f55c13c1c2ca7c54e3f6ba805b9f

[andrew_b]

Russian man page is not updated.
Help info is not updated.

[slavazanko]

Created branch 2170_docs:

• 59ea9300689c1a318bcc7066c5c2cd33d8fdbdb2: Update docs.
• 84041ad8dc76ea4889ba9fedd738ab4041283317: Refactor: for WInput widget while creating object used defined constant USE_DEFAULT_COLORS instead of caling input_get_default_colors().

Review, please.

[slavazanko]

Well, new changesets in branch:

• 59ea9300689c1a318bcc7066c5c2cd33d8fdbdb2: Update docs;
• 67fbfd0a82c6cfd54e11e902a6ade5cb61c7342c: Refactor: for WInput widget while creating object used defined constant USE_DEFAULT_COLORS instead of caling input_get_default_colors();
• 60a5c225b1cb006d857badf9b8e03f7592200dcc: Updated help output (by command mc --help-color);
• 84fb60d6ee7d937e70d7fd6617f2d362fb96eab1: Added definitions of new colorpairs in lib/skin/color-old.c;
• 3e5d3aa82ee9d83db6e6fd9e8a925a44ae15909e: identation of code.

Chenches in Black&white hardcoded scin not needed.

Review, please.