Color Presets and alternatives CSS

[elfi-ox]

Description

One thing I like a lot with Kando is menu themes and the ways the community participates in creating them. However, one thing that bother me is the weird family tree that emerges from theses. For example if I take my theme, Nether Labels, there is a version of it called "Nord" on github.com/kando-menu/menu-themes, with, supposedly, the only difference being the default color selection. However this version is also very outdated, so now it lacks some features of the current and future versions of Nether Labels. I can also think of ALPHA NEON and ALPHA NEON dark on the Discord server which are very, very similar while actually having a different CSS (that actually breaks the color selector but that's a problem with the css itself). I think we can find other exemple of this, like with the Bent Photon theme.

While I'm, obviously, totally okay and happy with people republishing a theme with substantial changes, I find it very inefficient to publish a whole new theme for the minimal changes (colors/vibe) that some of them bring. Well, I don't know if the word "inefficient" is right here since we'd also need a way to change the CSS and it's 99% of a theme's code... but I'll say I find it a bit messy.

What I propose are 3 features:

• The possibility to have multiple css in a theme folder, (e.q. theme.css, neon.css, dark.css, etc.) and a way to apply and export "presets" in the form of text (probably JSON ?). These "presets" would include all the selected colors and the correct CSS file to use. (Naturally, as the selected CSS theme would be part of the "preset", there would be a button near the color picker to select the CSS if there is more than one; it would be part of a theme "settings". The default CSS would be named "default" by the app, which corresponds to the theme.css file. Other CSS would be named after the file, e.q., dark.css ➜ "dark").

  To summarize, this feature would contain :
  ▪ adding a CSS selection to the individual theme settings
  ▪ a way to export and import the selected colors and CSS as a text string

• A simple preset manager inside the theme page of the app. It would consist of a "Preset" button for each theme that contains a list of all the presets for a theme, and some buttons to select, add (just by specifying a string of text), export, and remove a preset. By default, there would be no presets; these would be manually added by the user. Behind the interface, all of this would just be stored in a presets.json file containing every presets for every theme. If a css file is not found when applying a preset, it would just resort to using theme.css.

  To summarize, this feature would contain :
  ▪ a "Preset" interface inside the theme page that manages the presets.json file and applies, on request, a specific preset to a theme.

• If a theme creator decides to include by default a preset in a theme, it would be possible via the theme.json5 by adding a property like presets: [{some stuff....},{some stuff....}] . When opening the Preset tab of a theme, Kando would detect and display these as non-removable presets, just before the presets located in presets.json.
  To summarize, this feature would contain :
  ▪ The possiblity to include default presets in a theme files.

After that, we could build on this to manage themes in a more organized way. the github.com/kando-menu/menu-themes page would now have a "Presets" link on themes that have more than one, and this would lead to a page with all the Presets for that theme. All presets would have their pictures, a text string to copy, and a button to download the alternative CSS if there is one. People on Discord or elsewhere could share the CSS file with a text string instead of a zip file (which is both more secure and cleaner for those who collect a lot of themes)

Affected Desktop Environments

All

Additional Information

I would like to contribute but I'm not good at coding. I would gladely help with the github page and converting some known themes into presets, assuming that you're interested in this feature and have the time to implement it

[Schneegans]

Hi there! Thanks for the suggestion. I waited a bit with a response because, well, I'm a bit hesitant here. I understand your point really well, and I find it a bit messy myself. However, is it really a problem? I think your suggestion makes an already quite complex theming system even more complex and over-engineered.

Currently, we only have a few user-submitted themes and of course it seems weird if three of them are basically the same. But imagine a future where we have some sort of portal where everyone can easily submit themes, post comments, rate themes. A portal where we easily could have hundreds of themes. Would it really matter there? I don't think so.

So overall, I think I understand your point, but at the same time I think it will be very complex to implement, require lots of documentation, make things even harder to understand for the user and solve only a minor annoyance...