Truecolor skins: Four seasons

[egmont]

#3145 implements true color support, which ideally should be shipped with at least one demo skin.

I started to work on one, and without having any concept I just realized that I went for the typical colors of autumn's falling leaves, probably inspired by a nice little hike a few days earlier. And then I had the idea to make it into a complete set for the four seasons:

• Spring: Blooming, maybe even a bit like Gmail's Cherry Blossom theme

• Summer: Sun, ocean, beach, beachball

• Autumn: Falling leaves, Halloween pumpkins

• Winter: Snow, ice, skiing, cold

I attach the current preliminary version of the idea. Note that it's just a rough sketch, I haven't touched some of the less important colors at all, and things are likely to change a lot, especially if I get nice feedback. Also I don't quite like the current state of "summer", I'd like to bring more vivid colors to it. I'm more satisfied with the other three.

The main purpose of these skins is to demo the truecolor feature and perhaps be something a bit more outstanding, a bit more special or unusual than the default ones. Right after this the second priority is usability.

I also attach a single screenshot showing all the four skins, as well as the script which almost fully automates creating this screenshot (at least the boring bits).

In order to actually try it out, you need the patches from #3145 and #3711, a terminal supporting true colors (e.g. gnome-terminal or konsole), slang-2.3.1, a 64-bit machine, and export COLORTERM=truecolor.

Comments are welcome! I'm open to even major changes to the colors if they depict the given season better. Text comments, patches, proof of concept updated screenshots using gimp's Bucket Fill tool, whatever... I'm also super curious whether you like the overall idea at all :)

[egmont]

Spring, v0

[egmont]

Summer, v0

[egmont]

Autumn, v0

[egmont]

Winter, v0

[egmont]

Screenshot, v0

[egmont]

Script for creating the screenshot

[egmont]

The colors are way brighter on my mobile phone's AMOLED than on my laptop's matte LED. Especially "spring" is way too intense there, I'll definitely make it much more pale.

I'm also planning to buy a new laptop with good quality IPS display in about a month or two (don't worry, not because of this ticket :D), and I'll do the final bits of color adjustments from that.

[egmont]

Haha, after long months of dying my laptop finally gave it up shortly after I wrote the previous comment. So I'll have a new one with IPS display and beautiful colors in like a day or two. :)

Alas that won't make me a better graphic designer at all, and won't make me know anything about color calibration and such. Nevermind.

[egmont]

Spring, v0.1

[egmont]

Summer, v0.1

[egmont]

Autumn, v0.1

[egmont]

Winter, v0.1

[egmont]

Screenshot, v0.1

[andrew_b]

Applied: [7b9d78d28caaafa46e0d69dd9165955814df026f].

[egmont]

Please please please don't commit these yet :)

As I said, these are work-in-progress, waiting for feedback.

In particular:

• help, diffviewer, file extension highlight colors are not yet changed from sand256,

• I really don't like "summer", I'm planning to swap the yellow-ish (sand) and blue-ish (sea/sky) colors.

Any plans for 4.8.19 release date? I'm pretty busy nowadays but would really like to address these issues. I'll try to do these in a week, would that be that okay?

[andrew_b]

Replying to egmont:

Please please please don't commit these yet :)

Too late. :)

As I said, these are work-in-progress, waiting for feedback.

Ok. Revert: [76849655bad17141fb205884d7717b8117f98d5e].

Any plans for 4.8.19 release date?

No, as usual.

I'll try to do these in a week, would that be that okay?

Sure. No problem. :)

[zaytsev]

I think you were a bit too fast to revert ;-) nobody would mind if they stay in master for a few weeks before egmont comes up with an update... but well, it doesn't hurt.

No, as usual.

My secret plan that I wanted to discuss with you was to do an RC at the end of December, and then if no-one complains in a few weeks make a release early in January? The thing is that I'll hopefully get a couple of weeks off the grid, so maybe that'll make it possible to do something for mc again :-/ I think that this plan is no worse than any other, and I believe that striving for ~quarterly releases as we've been more or less doing this year is a about right, how do you feel about it?

[egmont]

Replying to zaytsev:

I think you were a bit too fast to revert ;-)

Doesn't really matter :)

I can't promise anymore that I'll polish up these skins this week, but I'm definitely planning to do this by the end of the year.

[zaytsev-work]

Hi Egmont, how is it looking for you now? The "release in January" plan didn't really work out as you can see, but new stuff is accumulating in master, and I think we should release in February at latest. It would be stupid it ship the true color support without demo skins though...

[egmont]

I'm really planning to finish them in just a few days. Please ping me in a week or so if I still haven't done this by then.

[egmont]

Screenshot, v0.2

[egmont]

Version 0.2 (aka. ".3." in the filenames) attached -- sorry for the stupid version numbers.

Changed/fixed since the previous version:

• New look for "summer". It's still my least favorite skin, but at least I like it better than the previous version. I'm afraid I'm out of ideas how to improve it. Nevermind.

• Help and Diffviewer use colors that match the skin.

• Added comments to the files.

TODO:

• Gauge and Disabled colors.

• Editor and Filehighlight colors.

• Fix diffviewer -> changed. Requires me to find out (again) where this is used.

• Eliminate all non-true colors.

• Generic cleanup of the files.

If anyone could please help me figure out where [diffviewer] -> changed is used, that'd be highly appreciated :) I sure managed to do it for the gray skins, but now I'm puzzled again.

[egmont]

(Please still don't commit these until I say they're fairily mature. I'll keep on working on these in the next couple of days.)

[egmont]

As for my previous question about the [diffviewer] -> changed color, the answer is in #3759.

[egmont]

Spring, v0.2

[egmont]

Summer, v0.2

[egmont]

Autumn, v0.2

[egmont]

Winter, v0.2

[egmont]

Replaced the v0.2 version, the diffviewer is now finished.

[egmont]

Spring, v0.3

[egmont]

Summer, v0.3

[egmont]

Autumn, v0.3

[egmont]

Winter, v0.3

[egmont]

Version 0.3 (aka. ".4." in the filenames) attached.

The gauge, disabled, diffviewer and editor colors should be usable, okay-ish. I might fine-tune them later.

The remaining big TODO item is the filehighlight colors.

[egmont]

Screenshot, v0.4

[egmont]

Version 0.4 (aka. ".5." in the filenames) attached.

Did plenty of minor cleanups and tweaks. Filehighlight colors left to do.

[egmont]

Spring, v0.4

[egmont]

Summer, v0.4

[egmont]

Autumn, v0.4

[egmont]

Winter, v0.4

[egmont]

Release Candidate 1 attached. Feedback would be highly appreciated :)

Please commit if (you're about to make a release) OR (no update from me AND no feedback from anyone arrives in about a week or so).

[egmont]

Spring, release candidate 1

[egmont]

Summer, release candidate 1

[egmont]

Autumn, release candidate 1

[egmont]

Winter, release candidate 1

[egmont]

Replaced the RC1 version in place. Only the comments were updated to point to the 32-bit slang wiki page.

[mooffie]

(I rebased mc² yesterday and it now has the "16M colors" feature. I used its ​skin sampler to ​generate screenshots for these skins.)

Replying to egmont:

Release Candidate 1 attached. Feedback would be highly appreciated :)

Well, these skins are nice.

This art is not my cup of coffee, though, so I'm not the one to opine, but seeing these skins I can certainly appreciate your taste.

Now, I remember that you once wrote that you're using the viewer much but seldom the editor. With me it's the opposite, which is why such skins aren't practical for me (see the screenshots to understand why; it's not your fault: see #3712).

So, to sum it up: I give you my vote (as I believe there isn't much we can do about the editor at the moment).

Only the comments were updated to point to the 32-bit slang wiki page.

When I grabbed these skins yesterday and read the comments I though: "wow, somebody already wrote instructions! why did I waste my time?!"...

[egmont]

Replying to mooffie:

(I rebased mc² yesterday and it now has the "16M colors" feature. I used its ​skin sampler to ​generate screenshots for these skins.)

Geez, I should have used your skin sampler instead of the screenshot creating script I attached here. Silly me, it didn't occur to me.

No clue how your script works, but apparently you didn't have to touch it for the aliases and truecolors support? You're a magician then! (You're a magician anyways...)

This art is not my cup of coffee

Not that much mine either :D They're mostly there for fun and to promote true color support. Some people might like and use them though. Alas we won't have feedback and statistics about it.

I'll stick to my favorite gray-green-purple. I'm using these new skins now for a couple of days to catch obvious usability gotchas, if any.

Now, I remember that you once wrote that you're using the viewer much but seldom the editor. With me it's the opposite, which is why such skins aren't practical for me (see the screenshots to understand why; it's not your fault: see #3712).

Yup I'm aware of that. There's not much we can do right now, other than keeping in mind to address 3712 one day.

I'm surprised though that you remember I'm not using mcedit :D

When I grabbed these skins yesterday and read the comments I though: "wow, somebody already wrote instructions! why did I waste my time?!"...

LOL

[egmont]

Winter, release candidate 2

[egmont]

RC2 attached - winter only. The other three didn't change.

Some minor tweaks: The blue background (especially at the top bar) was a bit too dark to read the black foreground text; made them lighter. The marked files (especially with filehighlight in game) were too pale and did not stand out; made it darker.

[ossi]

the only of these skins which doesn't give me instant eye cancer is 'winter'. :D

anyway, as the express purpose of this exercise is demonstrating the superiority of 24bit directcolor over a color palette, i'll attest it, quite predictably, a complete failure: the number of colors in the palette is so small (i count 30), that ncurses' 256 indexed colors are way more than enough, as i argued in #3145. so, thanks for proving my point.

i'd be somewhat interested in screenshots juxtaposing vte's direct color rendition of the themes with xterm's auto-rounding to the default palette. this would tell us how much worse the themes actually look on terminals which don't support OSC 4 (and thus ncurses' init_color() function).

[egmont]

Replying to ossi:

the only of these skins which doesn't give me instant eye cancer is 'winter'. :D

I have also admitted that these are not my favorite skins. Their main purpose is to demo the 24bit feature, and as such, bring attention of the existence this feature to our users (also secretly hoping that they'll contribute better ones).

I'd be fine ditching these skins if (or as soon as) we have another cool truecolor skin. At this moment we don't. And as Yury also pointed out above, and I fully agree with him, it would be stupid to ship the true color feature without at least 1 true color skin. I really, honestly don't mind if it's not my skin.

Unfortunately, I don't find your opinion of "instant eye cancer" constructive or actionable. That is, I don't have any clue how to modify them in order to please your eyes.

It's unfortunate that you didn't have the opportunity to send feedback at a much earlier state of my work. At this point I'm out of ideas and pretty much out of time I wanted to dedicate. I'm fine doing a few minor quirks, but not a full redesign, let alone a full redesign of 3 out of the 4, sorry.

It's also unclear to me how much you have a problem with this skins in particular, or with the 24bit support per se.

anyway, as the express purpose of this exercise is demonstrating the superiority of 24bit directcolor over a color palette

No, you're completely wrong here. The purpose is not to demonstrate "superiority" of truecolor. The purpose is to demonstrate a new available feature.

the number of colors in the palette is so small (i count 30), that ncurses' 256 indexed colors are way more than enough, as i argued in #3145. so, thanks for proving my point.

I'm afraid you still miss the point of truecolor. The point is not to be able to use more colors at the same time. The point is to be able to pick any color, rather than being limited to a relatively small set.

The current mc codebase defines sixty-some color pairs, it'd need a heavy code change to be able to use more (such as a bended background color of panels – don't worry, I have no desire whatsoever to work on anything like this). As such, ncurses's/slang's limit on the number of color pairs is not a bottleneck at all and is absolutely irrelevant.

During the development of these skins, at some point I even changed the hotkeys not to have a separate color, but being underlined only. A separate color there was too much visual clutter for me.

As it's probably the most prominent with the "winter" skin, I often looked for colors that are actually similar to each other, to make the skins use only a few colors rather than a lot. Even different colors usually have the same Hue so that they look like lighter/darker shades of the "same" color (good luck doing that with the default 256-color palette). I guess sometimes I even took advantage of having colors that are closer to each other than the default 256-color palette offers (dunno, haven't checked).

i'd be somewhat interested in screenshots juxtaposing vte's direct color rendition of the themes with xterm's auto-rounding to the default palette.

I guess it's the simplest if you try it out. :) Seriously, I presume you'd like to see multiple screens of mc (e.g. menu, dialog, error dialog, viewer, editor etc.) and presumably it would be more cumbersome for me to create so many screenshots than for you to get mc with truecolor running. It took way too much time for me to write the screenshot-generating script that I attached above, I really don't feel like replicating the same with xterm just to see something that our users should never see (see below).

this would tell us how much worse the themes actually look on terminals which don't support OSC 4 (and thus ncurses' init_color() function).

Both of these (auto-rounding and OSC 4) are irrelevant. mc refuses to use these skins on terminals that don't advertise truecolor support. Also, (thank goodness) mc doesn't use init_color() (probably slang doesn't have an equivalent) and hence never emits OSC 4 (never modifies the palette).

[ossi]

Replying to ossi:

on terminals which don't support OSC 4
(and thus ncurses' init_color() function).

fwiw, the second doesn't have to follow: the curses implementation could just resolve the palette client-side and use directcolor behind the scenes. ncurses doesn't appear to do that, though.

Replying to egmont:

Unfortunately, I don't find your opinion of "instant eye cancer" constructive or actionable.

it's not meant to be. you might have gotten a clue from it being an obviously ridiculous statement, or it being followed by a huge smiley.

I'm afraid you still miss the point of truecolor. The point is not to be able to use more colors at the same time. The point is to be able to pick any color, rather than being limited to a relatively small set.

you seem to be rather confused about the issue yourself. the description of #3145 makes a point of the possibility to simultaneously display any number of colors, and you're consistently ignoring/rejecting the palette-based approach, which makes one wonder what you're actually thinking.

i'd be somewhat interested in screenshots juxtaposing vte's direct color rendition of the themes with xterm's auto-rounding to the default palette.

I guess it's the simplest if you try it out. :)

yes, if i cared enough. i put "somewhat" there quite deliberately.

you otoh should have a vested interest in such an approach if you actually care to convince anyone of the usefulness of the feature.

Also, (thank goodness) mc doesn't use init_color() (probably slang doesn't have an equivalent) and hence never emits OSC 4 (never modifies the palette).

maybe you want to enlighten us what makes a terminal's feature that maps perfectly to your requirements so unacceptable.

[egmont]

At this point I'm getting totally lost what your actual problem is. Could you please clarify what is it exactly that bothers you:

1. The fact that there's a new user-visible feature: The user can put any direct RGB color in the skin file and it'll appear as exactly that RGB.

2. The implementation behind: Relying on some terminal emulators' direct RGB support rather than on OSC 4.

3. The fact that the implementation of this new feature didn't come along with other changes that would allow to display more distinct colors at the same time.

4. These new skins themselves.

Or any weird combinations of these (if so, how)?

1 or 2 should have been discussed in the other bugreport (3 is also irrelevant here), and since the feature is already submitted, it's probably too late.

I suspect you're primarly worried about 2. If so, please see my answer as a long comment I made yesterday at ​https://gist.github.com/XVilka/8346728#gistcomment-1988812.

(Oh, by the way... you're a big KDE guy as far as I know, right? Interestingly Konsole does not support OSC 4 that you're so keen of, yet supports true colors which mc's new feature uses and you seem to dislike for some reason.)

[ossi]

by adding these "demo" themes you're implicitly making a claim of usefulness of the feature itself, so related discussion does very much belong here. you're sinking more and more time into this, apparently not accepting that virtually no-one cares for this stuff for very good reasons. that wouldn't be that bad as such (obviously, you can waste your time whatever way you like), but your lobbying in other projects sinks other people's time as well. and as they are trying to be helpful, and some are just falling for the hype of the "cool", you're succeeding at it.

the fact that the implementation doesn't take advantage of xterm's ability to adequately deliver the functionality also suggests that you're actually just showcasing a "cool" feature of your favorite toy vte, rather than actually trying to provide added value to mc's users.

i haven't been particularly active in kde for a decade, and am pretty much completely out for a few years. my only contributions to konsole were refactorings and stabilizations to the PTY layer. if it was up to me, it would have never gained directcolor support, and it might have gained OSC 4 support.

[egmont]

Replying to ossi:

by adding these "demo" themes you're implicitly making a claim of usefulness of the feature itself

I believe this impicit claim of usefulness of the feature was expressed by adding the feature itself rather than by the demo skins.

virtually no-one cares for this stuff for very good reasons

There were like at least 2 people apart from me wishing for this feature. That's more than for many other bugs or feature requests that we address.

I perfectly understand if someone does not care for this stuff at all. I don't even mind if most people don't care, I'm fine. I totally do not understand, however, why anyone would be explicitly against this. Does it really hurt you to have truecolor support? Could you instead, please, just simply silently not use it?

It's still absolutely unclear to me whether you have a problem with supporting truecolors per se, or with this being backed up by the emulators' truecolor support rather than OSC 4. (Not that I care too much at this point, honestly.)

but your lobbying in other projects sinks other people's time as well.

Errr... do you really think I burnt a significant amount of other people's time? And how is this to any concern of yours? I haven't heard any mc developer claiming that they have a problem reviewing my changes or the additional maintenance cost that this feature will introduce. You voluntarily came here wasting your time (and mine and everyone else's who's reading this) with a discussion that clearly doesn't lead anywhere.

the fact that the implementation doesn't take advantage of xterm's ability to adequately deliver the functionality

On the linked page I presented a couple of reasons why the OSC 4 approach would be problematic, would by design necessarily suffer from drawbacks that the real truecolor approach doesn't suffer from. I have no intent to discuss any of them any further.

If you're really worried and would really like to see an OSC 4-backed approach (in addition to, rather instead of the current real truecolor approach), I guess the team would welcome a patch.

(Just one more thing for the record. I assume you'd want to redefine the "closest" palette color everywhere, so that it looks "okay" in terminals that don't support OSC 4. I take it from your earlier comment: "this would tell us how much worse the themes actually look on terminals which don't support OSC 4". That is, it would look in konsole the same as it looks with the current codebase in xterm if you trick mc into emitting truecolor escapes. Now: what would you do if two different truecolors map to the same "closest" palette color??? The entire concept would break, and you'd hardly have any better choice than assign palette indexes quasi randomly, resulting in far from okay colors in e.g. konsole. Still, I'd be happy to see this if it's a fallback for when real truecolors are not available, and if the team accepts the patch (i.e. it's reasonably small, clean etc., the usual stuff). Oh, and it won't be me creating the patch, I just don't care.)

also suggests that you're actually just showcasing a "cool" feature of your favorite toy vte

My "favorite toy" got somewhere between 57% and 73% out of all terminal emulators on a relatively recent poll at ​https://opensource.com/life/15/11/top-open-source-terminal-emulators (which even was linked from Slashdot). Even though this poll is obviously not representative, it might give a clue that my "favorite toy" is probably by far the most used terminal emulator out there in the Linux world.

Without having any data whatsoever to back it up, let me also make a guess that there's a positive correlation between users wishing for an eye-candy like truecolors in mc, and users wishing for a neat graphical UI provided by e.g. gnome-terminal or konsole but not by xterm or urxvt.

rather than actually trying to provide added value to mc's users.

I firmly believe I have added tons and tons of added value to mc's users by my previous patches and bugreports. Maybe this one doesn't bring any value to you, but I still don't get why it hurts you.

Also, opensource is to a big extent about having fun, isn't it? I have contributed a whole lot of time to this project (and even much more to VTE). What I got back was the satisfying and fun feeling and pride of getting things done, a better tool that I myself use daily, occasional compliments, and hopefully a more impressive CV – that's it. Had I strictly had to go according to a priority list, I wouldn't have done any of this work. My employer, who pays me my living, can ask me to do that. A hobby project cannot, and luckily, did not. Allow me please to pick according to my preferences, taking into account the bug's importance, my personal taste, my current mood, the amount of available time, fun factor, randomness, and a whole lot more.

I still don't find your comments constructive at all. I still don't have a clue what is it that you would like to happen. I still don't understand why it hurts you to have a feature that you don't care about. But honestly, at this point don't even care.

I'm still open for constructive feedback that helps improve these skins or replace them with a completely different truecolor skin.

[mooffie]

Replying to egmont:

Replying to ossi:

the number of colors in the palette is so small (i count 30), that ncurses' 256 indexed colors are way more than enough, as i argued in #3145. so, thanks for proving my point.

I'm afraid you still miss the point of truecolor. The point is not to be able to use more colors at the same time. The point is to be able to pick any color

I'm with @Egmont on this.

I can talk from experience. I needed a few extra colors for the ​actors script of mc². That was my 1st encounter with the celebrated "256 colors" feature. I knew what I wanted to achieve, but, try as hard as I could, I wasn't able to do it: I needed to highlight a few names in the text but in a subtle way that won't divert the reader's attention too much. I wasted a couple of hours on this. I failed. When you're looking for a color you're often looking for one that sits well with some adjacent color. This turns out to be rather challenging with the coarse granularity of the 6*6*6 color cube.

[ossi]

Replying to mooffie:

When you're looking for a color you're often looking for one that sits well with some adjacent color. This turns out to be rather challenging with the coarse granularity of the 6*6*6 color cube.

i don't buy that. looking at the cube right now, i'm positive i wouldn't be able to tell apart the adjacent colors if they weren't juxtaposed with their immediate neighbors. that means that the palette's resolution already exceeds what is actually necessary to usefully convey information. if you make it any more subtle, you can just not do it at all in the first place.

the whole point of truecolor is to not convey information. it's for creating gradients, smooth transitions, to make photos look natural. a TTY doesn't have enough spatial resolution for that, and so that use case simply doesn't exist in this context. truecolor simply has no place in a TUI.

and yes, i do think that the accumulated waste of resources (be it human or technical) spent on this misfeature is significant enough to justify some opposition. and as far as fun goes, "because i can" has only so much pull once you truly understand that what you're doing has no practical value whatsoever (and i'm already including "visually pleasing" in "practical" here).

[egmont]

Isn't it already obvious to you that we won't revert this feature just because you find it useless? No matter what you're saying here, we'll ship it. Period.

I spent a lot of time on this feature, and I was happy to do that. Apart from that, I have a strong feeling that the overall human and technical resources we've put and will put in this feature in the next couple of years to keep it up and running is lower than the one we're wasting with this pointless discussion.

If you're really so concerned about wasted resources, you should stop this discussion right here and now, that's by far the best you can do.

As of this very comment, I promise I'm out of this discussion for good.

(I'm happy to have constructive discussions here about these skins themselves (which is the topic of this ticket, as opposed to the generic usefulness of truecolor, which is not).)

[zaytsev]

Speaking of which, when are you planning to commit them? Is there anything else left to do, or you'd like to wait for more feedback, etc. ?

[egmont]

I think they're ready to go (rc2 for winter, rc1 for the rest).

Could you guys please commit it for me? :) Thanks!

[zaytsev]

Committed to master: 20a2b6081c78d4adc045c2847961ea3c7b6b66ca

I hope I didn't mess anything up.