Ticket #4974: Skinnable hint bar, prompt and cmdline; plus other cleanups

[egmontkob]

Proposed changes

• Make the hint bar, shell prompt and command line skinnable
• Use buttonbar hotkey color for unused areas of buttonbar (if the winow is narrower than 70 columns), so that we don't have any non-skinnable characters
• Remove "base" color value
• Remove "[skin].terminal_default_color" key
• Internal renames, cleanups and other minor fixes

• Resolves: Skinnable hint bar & cmdline #4974
• Resolves: Revise "terminal_default_color" #4950
• Resolves: Revise "base" color #4951

Checklist

👉 Our coding style can be found here: https://midnight-commander.org/coding-style/ 👈

• I have referenced the issue(s) resolved by this PR (if any)
• I have signed-off my contribution with git commit --amend -s
• Lint and unit tests pass locally with my changes (make indent && make check)
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation (if appropriate)

[egmontkob]

Please review along with pending questions in the referred issues, including:

• will the next release be called 4.9?
• if not, are we okay with landing this entire PR, or only the first 2 commits out of the 5?
• are we okay with the slight visual change at the bottom-right corner if the window is narrow?
• shall the keyword be "prompt" or "shellprompt"?

[mc-worker]

Hintbar and prompt are parts of file manager. hintbar_colors and prompt_colors should be defined and declared in filemanager.[ch].

[egmontkob]

We've had pretty much the same discussion in PR #4916 :)

I continued the existing pattern to keep the code consistent.

I agree with you that it would be a cleaner design pattern to declare and initialize these colors at the caller, rather than the widget knowing about them. In order to keep our code consistent, I guess the existing code (e.g. alarm a.k.a. error, listbox, and help colors) should also be ported to this pattern.

Practically, it would mean the introduction of several tiny new methods, e.g. adding an init() to help as per the discussion of that PR. Also, when initializing mc or when applying a skin, we'd need to call many more such small methods.

I have doubts that it would be an overall win. But let me know if you still want me to do this, I will do then. Or maybe meet halfway: if you'd want to do that refactoring around alarm_colors / listbox_colors / help_colors in the exisiting code and then I'll rebase my changes and keep following your pattern?

[mc-worker]

hintbar_colors and prompt_colors assignments should be moved to a separate function in the file manager area.

[egmontkob]

Labels in error dialogs have the wrong color.

I need to figure out how to denote in a label whether to inherit the colors from the parent widget (the wrongly removed colors = widget_get_colors (w); bits) or to store the colors in itself.

In a way that mostly fits the current design.

The "disabled" color is now hardwired to always use [core].disabled. The feature is only used in regular dialogs, not in error boxes -- and not in the newly added fields either. So it can probably stay hardcoded.

Which means that only a single color needs to be configurable. I might eliminate label_colors_t (and via that make the previous review comment irrelevant), just store either -1 for inheriting the color, or >=0 for an explicit value.

[zyv]

Please review along with pending questions in the referred issues, including:

I'm not sure what's the best place to have this discussion such that the posts are not mixed up with posts related to specific issues/PRs. Probably we could open a GitHub discussion for that. I would answer here, and if it becomes too annoying, then I would suggest we split it out.

• will the next release be called 4.9?

My understanding is that Andrew didn't veto it, so in as far as I'm concerned, I'd say yes.

• if not, are we okay with landing this entire PR, or only the first 2 commits out of the 5?

Irrelevant considering the above.

• are we okay with the slight visual change at the bottom-right corner if the window is narrow?

In as far as I'm concerned, yes, I'm okay with that.

• shall the keyword be "prompt" or "shellprompt"?

I think maybe this should be discussed in the ticket. I understand and agree that ambiguity is not good. However, I would tend towards "shell-prompt" or something like this if we decide to change it, because I find "separatorless" words annoying and very hard to read.

And, for the record, I'm still struggling to get through my mail.

[egmontkob]

However, I would tend towards "shell-prompt" or something like this if we decide to change it, because I find "separatorless" words annoying and very hard to read.

I will go for "shellprompt" in this PR, to be consistent (separatorless) with all the other color words.

I agree with your preference of using a separator, see #3159. I'll probably address that, along with a backwards compatible fallback option as per #4975, for all existing keywords. Then it'll turn into "shell-prompt". If I get to do this in the same dev cycle (which I'm truly hoping and aiming for) then there'll be no need for compat fallback for this one.