modarin256: a new 256-color skin for mc

[bloody]

As i wrote in a mail in the devel list, mc still lacks a few more
256-color skins. I've attached a new one, created in 8 different
setups for solid/transparent backgrounds, regular/root users, and
even four 16-color fallback skins in case 256colors is not available.

Detailed info is in the file comment inside the skin files.

Maybe you like to add the skin(s) to mc (at least the 256-color
versions, but the 16-bit fallback skins would actually make
sense..)

Furthermore:

Maybe you want to add a bit documentation about using 256-color
skins with mc in general, like:

begin add to mc docs

With most of the common desktop terminals, enabling 256-color mode is easily
done just by setting $TERM to "xterm-256color". Ubuntu users: make sure that
the ncurses-term package is installed.

Hint: if you decide to use a 256-color skin as default skin in your mc ini,
note that if mc is started in a 16-color terminal, mc will pop up a warning
saying that 256 color skins can't be used and that mc will switch to the
"default" skin. To get a skin of your choice loaded instead of mc's default
skin, you might consider the following solution:

Create an alias for mc in your ~/.bashrc, like:

if [ $TERM = "linux" ]; then

if [ $USER = "root" ]; then

myMCFallbackSkin="modarcon16root-defbg"

else

myMCFallbackSkin="modarcon16-defbg"

fi
alias mc="mc --skin $myMCFallbackSkin"
alias mcedit="mcedit --skin $myMCFallbackSkin"
alias mcview="mcview --skin $myMCFallbackSkin"
alias mcdiff="mcdiff --skin $myMCFallbackSkin"

fi

Linux users: to use 256-color skins in the linux console, run fbterm,
set $TERM to "fbterm" and then run mc within fbterm.
You need to specify a gfx mode in your bootloader for the kernel to use a
framebuffer console instead of the default text mode.

end add to mc docs

Cheers,

Oliver.

[bloody]

modarin256 skin pack

[bloody]

fixed input bg color for the 16-color-defbg skins

[egmont]

Hi Oliver,

I'm not an mc developer so it won't be my call whether to include these skins, but here's my 2 cents:

I love the modarin256 and modarin256root skins a lot! They really look great!

On the other hand, I have a not too good feeling about including 2³ versions of the skin. The list could easily grow further, e.g. you might want to create one with the same color scheme but single line borders instead of double ones, reverted down up/down arrows for sorting, fancy utf-8 vs. ascii-compatible special chars, etc., and you'll soon end up with 2⁷ or so variations of the same skin. (Btw, if the reason for the 16 color scheme is the linux console, you should consider going ascii-safe there.) It's your call, it's your skin, I would say that you decide, but I'd prefer if you chose 1, maybe 2 skins to include.

The defbg schemes have a problem: They are useless on white terminals. So I vote for keeping the solid background ones only.

Also I'm not sure if it's worth putting that much effort into maintaining similar 16-color and 256-color skins. Maybe you have your reason, though.

As for the doc: where would you exactly put it? I think it's a good idea to clarify the behavior and how to set up 256 colors with mc. But I wouldn't go as far as including advices with .bashrc, e.g. I'd set it up totally differently. (E.g. where's the branch for when it's root under a graphical terminal? Why is the whole thing not in root's .bashrc etc...) But again, I'm not sure, maybe including this might be a good idea for beginner sysadmins.

And in the mean time it'd be nice to allow to specify two skins, and mc would automatically fall back if the first can't be loaded because of the number of colors. But this is a different story.

Anyway, thanks a lot for the new skins!

[bloody]

Frank y i don't really expect the developers to include all 8, if any.

On the other hand, having a different variant of a skin for the root user does make sense, right? And what if you area 256-color Desktop user who must all the sudden boot into the Linux console for a long maintenance session? Well i guess if i had to decide about cutting variants of these skins, drop the 16-color fallback skins.

But the rest... You say "white background"? Yeah well, obviously you would want to choose
a skin with a solid background as all transparent skins are usually made for either light or dark background. And btw., the bg color for the input line can not be configured, so no matter which skin you use (try all default skins), they all show a white background for the command line. With a pink background color, all MC skins look terrible..

I made this skin because i wanted an all-purpose personal favorite skin and eventually i realized that the different scenarios cannot be realized within a single configuation.
For example, a skin could define variables for root and regular users and decide on startup which of the values to use. It can also auto-decide on startup if 256 colors are available or only 16 colors, and read the according variables from the skin.

For example r_something_16 would be a color value for the skin for use by the root user on a 16-color terminal, u_something-256 would be another variable in the same skin for regular users on a 256-color terminal, so skin desingers can take care of this and so you only need 2 variants of the skin afterall, one for transparent bg and one for solid, boring one-color bg.

I find it very hard to estimate how many desktop users actually prefer an mc skin with a solid bg color or a (semi)-transparent background color. So which skin to include by default? Hard choice..

If i had to make a cut, leave the 16-color variants out as the skin was primarily designed for 256-color terminals. If it MUST be only two, it might be the ones with a solid bg color (the default skin), but that would leave users behind who only want transparent skins..

I don't like the idea of having 8 versions of the aame skin either. Of course it doesn't make sense to create minor variants like "single-line borders vs. double-line borders" because that would be trivial nonsense, but root vs user, solid vs. transparent and 256-color vs 16-color are major differences, right..

And look at the default skins "default", "double-lines", "featured" and "mc46" and tell me, where's the big difference between these four?

Cheers..

[egmont]

You're right with the 4 very similar skins shipped by default, I wasn't aware of these default skin variations.

Your idea with r_something_16 and u_something_256 is a good starter idea, but I'm afraid they're not quite scalable, e.g. they would also make things way more complicated as soon as we introduce other variables. I would personally rather think in a preprocessor that the skin is run through before parsing according to the ini syntax. Something along these lines, of course the syntax could change to anything:

# if $TERM == linux

selected = green;yellow

# else

# if 256color

selected = color78;color120

# else

selected = blue;purple

# endif

# endif
# if utf-8

horiz = some fancy unicode char
vert = another fancy unicode char

# else

horiz = -
vert = |

# endif

and so on...

At startup time, mc would preprocess the skin according to its environment, like locale, terminal etc.

It's not clear to me whether it's a proper thing to offer preprocessing based on user ID (root vs. not root), maybe one can say that the right place to address this is outside of mc and different users should have different skins set for themselves. But maybe it's nice if mc offers a convenient way of branching on this. Then other similar ideas might include branches on hostname so that one can maintain one single skin file for himself which looks a bit different on different computers.

Oliver, are you by any chance a develper who is motivated, has time, etc. to work on this? :)

Until then, of course, having multiple variants of the skins is probably the way to go.

[bloody]

fixed: temp file color (was a bit too dark)

[bloody]

That's not a bad idea either. Although, it would require rewriting the ini parser (not sure if it's native/hand-crafted or using some glib or other external function for this).

Anyway, it would be helpful if mc was able to make these kind of distictions to make it possible to join multi-purpose skins into a single skin file.

Another idea may look like this:

[core]

# default/fallback (for 16 colors and/or if not otherwise defined)
_default_=color1;color2

[core256]

# if 256 color mode is available
_default_=color3;color4

[core_root]

# for the root user
_default_=color5;color6

[core256_root]

# for the root user if 256 color mode is available
_default_=color7;color8

I think this might be a little easier to implement. It would not require tons of new variables (only the few new section names which can be easily constructed from the current environment/setup), and it would also not require changes to the ini file parser.

And yes, i got some experience with C programming, but i never worked with git and the like (not ever, got no clue about these cvs systems) and i also don't have much time ATM. The latter might change in a few months, though..

[egmont]

I see your point in keeping the file in a valid .ini syntax.

I still have the problem with the notation like "core256_root" that it's hard to extend to any other future properties that you don't think of right now (e.g. utf-8 vs. ascii, value of $TERM, locale, and so on). Also it should be clear how a section exactly falls back to other sections. The config file should ideally be designed to avoid unnecessary repetition, e.g. one shouldn't need to repeat a section that's the same as another one, e.g. you don't want to have [Lines_root] that't the same as [Lines] etc. There are lots of details, like if just a certain line (e.g. "selected") is missing from [core256_root] then do we fall back to the value in [core256] or in [core_root] or to none at all or to what and why...

But suddenly we might even conclude that the simplest and most flexible thing is what you proposed originally: just multiple skins, and choose outside of mc. I don't know, I'm just thinking out loud.

Btw it's not necessary to know any version control system; creating a patch against the latest tarball is usually totally okay :)

[bloody]

Maybe you're right, it might be too much fuzz afterall. Even with 256 colours i found it pretty hard to find colors in that 256er standard palette which were really what i wanted. Lots of grayscale values, but the other colors are still few, especially dark colors are missing. If one wants a dark background, there's virtually only gray available, maybe the darkest blue (but with red & green all zero), and that's it, all other colors are too bright for use as 'dark' background color.

However, i doubt that there will be hundreds of new mc skins coming up just because 256 colors are now available. I got my skin now, and i'm happy with it. May the developers decide what to do about the skin and/or the points we discussed above. I've just supplyed what i've got. I'm not even a graphics artist, i'm totally untalented when it comes to graphics & design, but i felt it was necessary given the choice of default skins for my favorite file manager. My dream feature for the future would be an MC version which utilizes GTK widgets, if available... :P

[egmont]

Limitations of 256 colors: You're totally right :) When I created the first 256-color skin I wanted to make a standard dark scheme, but didn't find anything that I liked for background color, that's how I ended up with an unusual bright scheme (sand256) :) (Btw I'm not a graphics artist either, I suck in these things.) There are a few terminal emulators that support arbitrary RGB colors, but mc doesn't support it. Maybe it would be cool to add support into more terminal emulators, and into mc too.

There used to be a GTK port of mc, but I don't see the point in it. There are plenty of graphical file managers out there, and basically only this one for console. I love that I can use it over ssh, inside screen, or that I can use it in whichever terminal I'm currently working in, without moving the cursor to another window that randomly pops up somewhere on the desktop, and that it can launch my favorite terminal-based editor just in place. I guess the GTK port was dropped for a reason, and I don't think it's likely to come back.

[onlyjob]

Oliver, thank you so much for those beautiful skins!!

I'm using 'em for about 10 days and I must say they've made me happier.

For years I was waiting to have nice comfortable MC skins and this is just what I needed.

Now when 256 colour mode is available, I realised how badly I was missing it...

I vote for shipping all modarin skins as part of MC - I'm sure many people will be grateful.

[bloody]

Seems like there was a discussion going on about these double-lines skins not working well with certain fonts. Looks like someone created another 8 versions of this skin all with single-line characters for better compatibility..

I had no idea this was going on, otherwise i would have suggested to forget about this double-line stuff, as i personally really don't care; what counts for me is to have some eye-friendly colors for my MC.. and if someone believes that 16 versions of the same skin is overkill then i won't argue with that..

So if anyone feels like removing the double-lines versions of the skin from any distribution, i won't mind at all.

[egmont]

It was a year ago that "bloody" contributed these wonderful skins, and I'm afraid it might have been my mistake to derail the ticket by arguing about so many variants, and the whole point just got forgotten...

Dear devs, could you please add these skins (or some of them, at your discretion) to mc? I believe these are really well designed beautiful skins. Thanks!

[bloody]

If anyone ever reads this?

[andrew_b]

Applied in master: [97e37308b94b55796f25a2927d393b5319607810].
Thanks!