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

egmontkob · 2026-01-28T12:56:52Z

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 · 2026-01-28T12:59:06Z

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 · 2026-01-28T14:20:13Z

lib/widget/label.c

+/* Color styles for label widgets */
+label_colors_t label_colors;
+label_colors_t hintbar_colors;
+label_colors_t prompt_colors;


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

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 · 2026-01-28T14:24:02Z

lib/widget/label.c

+
+    prompt_colors[LABEL_COLOR_MAIN] = CORE_PROMPT_COLOR;
+    prompt_colors[LABEL_COLOR_DISABLED] = CORE_DISABLED_COLOR;  // unused
+}


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

egmontkob · 2026-01-28T21:23:22Z

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 · 2026-01-29T07:07:08Z

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 · 2026-01-29T07:12:31Z

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.

zyv · 2026-01-31T07:00:57Z

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.

👍

egmontkob · 2026-02-04T09:58:56Z

Rebased. Renamed "prompt" to "shellprompt". Removed the last commit for now (there are more variables named similarly, I'll have to rename all or none).

Still haven't addressed Andrew's comments, I'm thinking about a bit of underlying refactoring around color handling, let's see how that turns out...

…dget Signed-off-by: Egmont Koblinger <egmont@gmail.com>

Variables referring to a color pair may now contain either the lowlevel color pair id, or an identifier of the color role, the latter to be looked up in a map according to the skin. By using the color role id for as long as we can, rather than the resolved color pair id, initializing colors and later changing skins becomes much more straightforward. Signed-off-by: Egmont Koblinger <egmont@gmail.com>

egmontkob · 2026-02-08T00:30:04Z

Rebased and adjusted to go on top of the current state of PR #4995. This addresses @mc-worker's two review comments.

Let's review / finish #4995 first and then we can return to this one.

…mmand line skinnable New keywords "hintbar", "shellprompt" and "commandline" under the "[core]" section of skin files control the colors of these parts of the screen. Update the skins to still use terminal's default colors here, as before. Remove the hline widget's unused transparent parameter, so that our widgets don't have this concept anymore. Fix some typos in comments. Signed-off-by: Egmont Koblinger <egmont@gmail.com>

…areas of buttonbar This only affects windows narrower than 70 columns. With this change, there are no more characters on the skin that aren't skinnable and are necessarily of the terminal's default colors. Signed-off-by: Egmont Koblinger <egmont@gmail.com>

…color and "terminal_default_color" role Remove support for the "base" color value which was presumably never used. Remove support for the "[skin]" section's "terminal_default_color" keyword which did not work and whose intent was unclear. Remove the no longer used and misleadingly named internal variable CORE_DEFAULT_COLOR. Signed-off-by: Egmont Koblinger <egmont@gmail.com>

egmontkob · 2026-02-08T09:26:58Z

Labels in error dialogs have the wrong color.

Fixed now.

github-actions bot added needs triage Needs triage by maintainers prio: medium Has the potential to affect progress labels Jan 28, 2026

github-actions bot added this to the Future Releases milestone Jan 28, 2026

egmontkob requested review from mc-worker and zyv January 28, 2026 12:57

egmontkob force-pushed the 4974-cmdline-color branch 2 times, most recently from 1da4a18 to a79a9de Compare January 28, 2026 13:12

mc-worker reviewed Jan 28, 2026

View reviewed changes

egmontkob mentioned this pull request Jan 28, 2026

Skin files: fix badly chosen keywords #3159

Open

zyv added area: skin Theming support and skin files and removed needs triage Needs triage by maintainers labels Jan 31, 2026

egmontkob force-pushed the 4974-cmdline-color branch from a79a9de to 076afb2 Compare February 4, 2026 09:56

egmontkob marked this pull request as draft February 4, 2026 09:59

This was referenced Feb 5, 2026

Color handling refactoring #4995

Open

Add MashDark skin #5006

Open

egmontkob added 2 commits February 7, 2026 18:34

Rename the input widget's color enums to be consistent with dialog wi…

4251504

…dget Signed-off-by: Egmont Koblinger <egmont@gmail.com>

egmontkob force-pushed the 4974-cmdline-color branch 2 times, most recently from 95c6cc6 to 36d8cd6 Compare February 8, 2026 00:26

egmontkob added 3 commits February 8, 2026 10:23

egmontkob force-pushed the 4974-cmdline-color branch from 36d8cd6 to 2e89dad Compare February 8, 2026 09:26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

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

egmontkob commented Jan 28, 2026

Uh oh!

egmontkob commented Jan 28, 2026

Uh oh!

mc-worker Jan 28, 2026

Uh oh!

egmontkob Jan 28, 2026

Uh oh!

mc-worker Jan 28, 2026

Uh oh!

egmontkob commented Jan 28, 2026

Uh oh!

zyv commented Jan 29, 2026

Uh oh!

egmontkob commented Jan 29, 2026

Uh oh!

zyv commented Jan 31, 2026

Uh oh!

egmontkob commented Feb 4, 2026

Uh oh!

egmontkob commented Feb 8, 2026

Uh oh!

egmontkob commented Feb 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Uh oh!

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

Are you sure you want to change the base?

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

Conversation

egmontkob commented Jan 28, 2026

Proposed changes

Checklist

Uh oh!

egmontkob commented Jan 28, 2026

Uh oh!

mc-worker Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

egmontkob Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

mc-worker Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

egmontkob commented Jan 28, 2026

Uh oh!

zyv commented Jan 29, 2026

Uh oh!

egmontkob commented Jan 29, 2026

Uh oh!

zyv commented Jan 31, 2026

Uh oh!

egmontkob commented Feb 4, 2026

Uh oh!

egmontkob commented Feb 8, 2026

Uh oh!

egmontkob commented Feb 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants