Winterbloom: add theme

[torchipeppo]

This pull request proposes a new theme, characterized by gradients, transparencies, and a general cool-color aesthetic.
More info can be found in the readme file.

This theme has been developed exclusively on Cinnamon 5.0.7 (Mint 20.2), but I also gave a cursory look on a Mint 21.3 VM and found no critical issues.

I have actually prepared a few variants of this theme, which differ exclusively in the direction of the gradient fill, because I believe one style may be better than the other depending on the panel settings. I'll post screenshots in a few minutes to show them off better, but the readme already provides a description.
Right now, the only way to configure this is to edit a specific import instruction in the SCSS source and recompile the theme, as documented in the readme. I'm not sure how many different variants it would be appropriate to submit, since I don't think "inverting a few gradient directions" is that much of a difference, so for now this PR only contains the variant that I am personally using. Should I add more before this PR is merged?

[torchipeppo]

Screenshots incoming. I show all four panels for completeness, but I'd expect most Cinnamon setups to only have one or two.

Variant A: The "solid" side of the gradient is on the inside of the screen, so I think this works well if the panel is set on "always show".

Variant B: The more natural "solid-to-transparent" direction makes it suited for just looking at the desktop wallpaper and/or panels set to automatically hide, IMHO.

Variant X,: It combines A and B, and it happens to be my setup. Its intended use case is for setups which combine both types of panel settings, like mine (top panel always shown, left panel on auto-hide). I also like that the "solid" sides all connect to each other.

Variant Y: Just the vice versa of X.

[rcalixte]

I'm not sure how many different variants it would be appropriate to submit, since I don't think "inverting a few gradient directions" is that much of a difference, so for now this PR only contains the variant that I am personally using.

There was another thread on this recently in this repository and @fredcw opened a pull request near the envisioned functionality. I still don't know the ultimate direction but it is a feature that would be well-received whenever it lands to be sure.

[torchipeppo]

Is it this one? #784

[rcalixte]

Is it this one? #784

That's the thread and there's a pull request too:

linuxmint/cinnamon#12100

[fredcw]

@torchipeppo If you can write a shell script or a python3 script to update the theme, then you could include the original SCSS source in the theme and compile it with an included copy of sassc/libsass as I done in Fuent theme. I used an older version of sassc/libsass to ensure compatibility with older versions of Mint and other distros as the newer versions of sassc/libsassc depend on newer versions of GLibc. If you also include options.py and config_gui.py then in options.py, you should set rename_theme_on_update = False as renaming the theme or restarting cinnamon is only needed to update the WM theme.

I guess you even write a script in javascript if that's your preferred language, the script would start with #!/usr/bin/cjs

The install.sh in Fluent theme is a bit messy and probably contains much unnecessary code as I adapted it from the original file and I'm not too familiar with bash scripting.

[rcalixte]

We should maybe start on the documentation before the implementation so that everything is understood upfront. I would have to check about the support for versioning for Themes as that would solve the extra overhead for maintaining different versions as well. As far as I know, only Debian-based downstreams could have the problem of a newer version of Cinnamon with older potential libraries. Most everywhere else will have updated libraries next to newer versions of Cinnamon. (Debian will catch up eventually too. 😀)

[fredcw]

@torchipeppo If only a few lines need changing for each version then perhaps you could include a template version of cinnamon.css, copy it into the theme directory on each config change and use grep or sed programs to replace the relevant lines?

Edit: Or you could even include all compiled versions of cinnamon.css and copy the relevant one each time.

[fredcw]

Latest spec here: https://github.com/fredcw/theme-config

[torchipeppo]

EDIT: This message has been ninja'd by @fredcw 's two above messages. I have no idea how I missed them.

The pull request on Cinnamon is still open, so I suppose this hasn't been officially introduced to Cinnamon yet? I guess I could start looking into @fredcw 's work and adapt it while staying as faithful as possible, but part of me wants to wait until a stable version is officially merged before starting any work.

support for versioning for Themes

I think that would be nice to have, too.

[torchipeppo]

If only a few lines need changing for each version then perhaps you could include a template version of cinnamon.css, copy it into the theme directory on each config change and use grep or ed programs to replace the relevant lines?

I set up the SCSS code specifically so that variant selection is controlled by a single import instruction, so making I think a template would be pretty easy to do.

[fredcw]

@rcalixte

We should maybe start on the documentation before the implementation so that everything is understood upfront

Agreed. I've abandoned the idea of making options.py and config_gui.py follow some standard as unnecessary and too complicated. So it's just config_options.json that needs a definition I think.

versioning for Themes

Do you mean versioning in the way that applets are versioned? I'm not sure how much demand there would be for that as gtk themes available on sites such as gnome-look.org don't usually have versioning, although you would think that it would be useful as APIs change. In any case, I think it should be optional as otherwise it could be quite a burden for theme designers.

[rcalixte]

although you would think that it would be useful as APIs change

This is precisely my thinking. From what I've seen with themes, they tend to workaround this by just including everything in the CSS and files. I agree that the gain from an "optimized" version might offset the maintenance work though. It's easy enough most of the time to just continuously append to an existing theme to adjust for new cases or features.

In any case, I think it should be optional as otherwise it could be quite a burden for theme designers.

The current support for versioning in other Spices is already optional. I wouldn't want to force anything on developers or break an existing standard either. If having it as an option is helpful enough, it might be worth looking into. This is all very up in the air at the moment.