Would a new fossil skin in fact be feathers?

This is interesting, because it’s sometimes difficult to adapt the CSS to what we try to do, especially when the skin we use breaks the design when we update for a new version. So it would be good to rely on a reliable skin we can change easily.

The Inskinerator is now in an alpha-usable state. The docs are far more useful, it is considerably more clever about handling per-color and whole-skin overrides, and the demo skin set now fills all of the "draft" slots on the repo:

1. Fossil Default Rebuilt
2. Fire
3. PDP-11/70
4. Mint Green
5. Fizzbuck Light
6. Fizzbuck Dark
7. Amber VT Rebuilt
8. Green Bar VT
9. Paperwhite VT

Each demo skin is meant to demonstrate something specific. See the README.md file for details.

The Paperwhite VT skin is perhaps most on-topic here, being a sort of demo of the whitespace and other changes I'd like to see merged upstream here. However, realize that I am not advocating a wholesale replacement.

Consider the mainmenu bar: the only reason it looks so different in Paperwhite VT relative to the Fossil default is that I changed it in Amber VT, and Inskinerator isn't able to pick-and-choose elements of an override skin. All I can do is attempt to back out individual elements, which has strong practical limitations, which I'm pretty much hard up against right now. The next step is to clone the Amber VT override and rip out the elements that change things in Fossil Default that I'm not actually interested in upstreaming.

Speaking of, I'm open the to the idea of merging this into Fossil someday. Ideally, every current Fossil skin should be a target for running through the Inskinerator. Want Khaki in a pink theme? Okay!

I realize that Perl and its CPAN dependencies are a potential problem from a Fossil build system perspective, but I think we can treat it the say way www/mkindex.tcl works: it would generate skins/default/css.txt from skins/default/css.scss and such, but we'd check those generated files in so you wouldn't have to have Perl and the script's CPAN dependencies just to build Fossil. Only those making new skins would have to have a working Perl environment and the script's small set of dependencies.

TODO: Port more Fossil stock skins over to the mechanism to prove the point.

See the documentation for an explanation of each skin and how it's made. Or, dig into the sources: it's not so complicated at the moment that I expect people to be completely lost when diving in. (Though it's getting there. :) )

Nice work on the skins. They look really good.

You are correct that a Perl/CPAN dependency would be a problem.

I also noticed that diff highlight colors obscure the text in dark skins like "Fire". (example)

Nice work, Warren!

The rebuilt default Fossil and Fizzbuck Light are really nice. I like
Fizzbuck Dark, too, but when diffing two check-ins the highlighted text
is obfuscated.

a Perl/CPAN dependency would be a problem.

Perl's pretty much everywhere, if not by default, then easily installed.

Installing the required CPAN modules is a one-liner if you have cpanm, which is nearly as widely available these days.

And yes, I did look into the Tcl options, but the top option for libsass in Tcl looked like a bigger hassle than the Perl option. Still, if one wanted to rewrite inskinerator script in Tcl to make use of it, it would be doable.

Most of the work's in the SCSS code, not in the Perl code. There's a fair bit of cleverness in the concatenation algorithm, but now that I've worked out the proper ordering and other details, copying that to another language would be trivial.

diff highlight colors obscure the text in dark skins like "Fire".

That sort of thing happens when libsass wraps around in its color math, which gets triggered because the Fossil default skin starts light and darkens individual elements, so when you try to darken "black", it doesn't clamp to 0, it pushes out through the bottom and creates pastels.

This is one of the areas where it's probably better to start with an "override" skin rather than just passing a few new color variables in. Having done that, then you'd have a useful base for creating other dark skins by passing in variables, because the math would then work: start dark and add lightness to style elements.

Hmm, looks like my post got lost....

In any case, is the a recipe for producing the css.sccs files? I have a skin that is a derivative of the eagle skin that I would like to generate using inskinerator.

I assume I will need diffs between the eagle skin and the default skin along with the diffs between my skin and the eagle skin.

The docs now cover that.

From the current priorities in the project wish list, you can see that converting Eagle to Inskinerator form is not high on my to-do list. Therefore, you're best off doing it yourself, then possibly sending the result to me for inclusion with Inskinerator so you don't have to continue maintaining it.