Skinnable hint bar & cmdline

[egmontkob]

Is there an existing request for this?

• I have searched the existing issues

Is your feature request related to a problem?

It's hardcoded that the hint bar, the prompt, and the command line are "transparent", i.e. use the terminal's default colors.

(Except for marked text within the command line: [core].commandlinemark.)

There's no reason to keep this limitation.

For the command line, the rationale is probably that we want to provide the impression that mc is transparent here, although technically that's not true, we do paint the prompt ourselves, and e.g. colors in the user's prompt are lost. The hint bar being "transparent" can't even be justified by us trying to give this impression of transparency, I don't have an idea what was the design thought here.

It might be handy to separate the prompt and the command line using a different color, I expect a few skin authors wanting to do so. A third color for the hint bar (maybe some skins want to repeat the panels' colors, or so).

[core]
    hintbar = ...
    shellprompt = ...   (or prompt?)
    commandline = ...

Skins can already refer to the terminal's default color using the "default" keyword, as used intensively in the modar*debfg* themes. That is, the current look can be preserved by adding these keywords to our existing skins, with default;default values.

Now, this change would break the look of 3rd party skins until they're updated (since if a keyword is missing then we fall back to [core]._default_); #4975's fallback key might be a remedy.

Nitpicking: shall we call it "prompt" or "shellprompt"? The latter is more specific and is IMO more intuitive (mc's dialogs are also prompts in some sense), although technically not correct if subshell support is disabled and thus there's no shell.

---

This change would not only add a feature, but allow an internal cleanup.

The internal transparent flag would no longer be needed, it could be removed (replaced by a custom color). (Also remove it from the hline widget where it's unused now.)

The badly named CORE_DEFAULT_COLOR, referring to the terminal's default, would no longer be needed. Similarly, we'd no longer have to have color pair 0 always referring to the terminal's default color. The terminal's default colors, if used at all, would be allocated a random color pair number. The badly named CORE_NORMAL_COLOR could be renamed to its proper name CORE_DEFAULT_COLOR. See also #4950.

Describe the solution you'd like

.

Describe alternatives you've considered

No response

Additional context

No response

[egmontkob]

we'd no longer have to have color pair 0 always referring to the terminal's default color. The terminal's default colors, if used at all, would be allocated a random color pair number

Nope, it's an ncurses (and maybe slang too) thing that color pair 0 always refers to the terminal's default colors. This needs to stay.

[egmontkob]

There's one more place where the badly named CORE_DEFAULT_COLOR, referring to the terminal's defaults, is used.

This is the bottom-right corner of the screen when the window is narrower than 70 columns.

I think it's a fair game that we don't want to expand the button labels to that space, just so that if the user slightly widens the terminal then a new button appearing would make these labels narrower again.

I really don't want to introduce a new skin color for this corner case [pun intended]. Yet I want to get rid of this badly named keyword and its functionality, along with the [skin] section's terminal_default_color (which, as far as I understand, should be used here, but isn't, I don't know why); I don't want to have any remaining cells that are necessarily of the terminal's default colors without being redefineable in the skin.

So, how about using [buttonbar].hotkey here, i.e. the color of the 1, 2 ... 10 buttons? I think it's a fair choice.

Does this sound like a reasonable goal and a reasonable solution for that?