[Suggestion]: Add theme presets

[rubyFeedback]

First, this can be closed. It is an idea, a suggestion. I understand that some ideas or suggestions take time to implement. Nonetheless it would be nice if the main developers of conky could read this.

The title is just "catchy". A more realistic title would be:

"Consider adding ten curated conky themes by default to conky."

That is more realistic.

Now, we can grab conky themes from the world wide web, which is fine, but I would like to have
a "top ten" conky theme already distributed by conky, to then pick from.

This could also have commandline aliases such as:

conky --theme1
conky --theme2
conky --theme3

and so forth.

Take a look at those four conky themes:

https://ubunlog.com/wp-content/uploads/2017/05/conky-harmatten.jpg.webp

I think it would be nice to have them in conky by default as-is.

Or, similar variants. Suggesting ten would be more realistic, but I propose 100,
just to satisfy every people's preference. ;)

These themes should be curated. Perhaps people, conky devs, can vote on which
ones to include if there are more than ten or hundred.

I would like to have that so I can just select through them via the commandline and
then pick one of those. Also an option such as "--copy-theme-1" should then be
added to dump the config into the current directory and allow users to modify it.
That way they can base their modifications on that modern conky theme.

I actually have an old conky but I haven't changed it in +10 years. I think I would
prefer to use someone else's conky but from a curated base; but also have a look
at different variants from within conky itself rather than external conky resources.

Anyway that is my suggestion. Please feel free to do with that suggestion whatever
you want to.

[Caellian]

I like this idea and it would make it simpler for new users to start using conky. From what I can gather, a somewhat common experience is that people want to add conky, try using someone's dotfiles, and then sometimes fail to get them to work correctly for their system and stop using it, or find the process to tedious to repeat after a reinstall.

Problem with presets is that they have to be maintained. But this can also be used to our advantage by turning these presets into tests - people (myself included) often modify things without testing all the edge cases and combinations, and that can cause regressions in UI layouting which breaks stable existing config files. Turning these into tests would shift the maintenance burdain to feature implementers.

However, testing these raises a separate problem - there's no mocking support for most of conky features. I'm slowly working on this, but it requires some really complicated changes to the existing source code (i.e. Lua config handling).

I don't see the need to limit these, ideally we'd have some system that downloads (and caches) the presets from the repo to avoid installing 10+ different themes. And that system could also support local theme repositories to allow distros to provide their own sets of themes.