Config file for theming/customization💄

[o2sh]

Summary 💡

What about having a configuration file in which you could customize visual aspects of onefetch? for example:

General options:

• The glyph to use for the separator (use "->" instead of ":")
• The padding between the output and its surroundings
• The spacing between the separator and the info
• The text colors (would be equivalent to --text-colors)
• Whether to hide the ASCII logo
• image path to display by default instead of the ASCII logo
• ...

Palette:

• Which glyph to use for the palette (use "●" instead of " ")
• Whether to hide the palette.
• ...

Info lines:

• Define the text to display as a title for each info lines (use "🖴" instead of "Size")
• ...

The configuration file could be placed in ${HOME}/.config/onefetch/config.conf (which format? YAML? TOML?)

As suggested by @spenserblack

• Add CLI flag to provide a different path to the config file

Motivation 🔦

Allow users to customize the look and feel of onefetch by creating themes and config files that can be shared and enjoyed by others.

For reference --> https://github.com/Chick2D/neofetch-themes
and https://github.com/spenserblack/repofetch (for an example of implementation)

[spenserblack]

Great idea! Do you think we should support the option for per-repo config files, too (I'm leaning towards no, but just want to put it out there)?

I did something similar in my (unfinished 🤣) project repofetch in case you want to reference something.

What format do you think it should be? I like YAML for human-editable files, but TOML, INI, and JSON also have some pros and cons. Or do we go the extra mile and support multiple formats?
Edit: nevermind, I think this question is answered by your example path *.conf 🤣

A cli option to print the location of the config file can also be useful, as well as an option to provide a different path to the config file.

[o2sh]

Great idea!

Thanks 😊

What format do you think it should be?

The format is still up for discussion, as you mentioned YAML and TOML seem more human-readible/editable. I like TOML because it allows for sections (maybe YAML does too 🤔), which makes it easier to organize/parse the entries by category, smth like:

[general]
spacing = 2
padding = 0
separator = "->"

[palette]
glyph = "o"

[info]
size= "🖴"

A cli option to print the location of the config file can also be useful, as well as an option to provide a different path to the config file.

Good idea, your second suggestion would be very useful 👍

[spenserblack]

🤔 Yeah in YAML I think it would just be

general:
  spacing: 2
  padding: 0
  # etc.

Now I'm leaning more towards TOML, since it provides the user with more freedom in how they choose to format.

# they can do this
[general]
spacing = 2

# or this
general = { spacing = 2 }

We might want to get some metrics to figure out the most popular format, maybe even just by searching config.toml, *rc.yaml, etc. on GitHub (does GitHub allow searching partial filenames?).

Although one other config format I've seen tools use is basically to make a 1:1 of the CLI without any nesting, where basically --option=* in the CLI becomes option=* in the config file (so pretty much INI format). In that format, ours would look like this

# flag in CLI
email=true
# option in CLI
true-color=never

IMO regardless of the format, it would be great to make it possible for a user to understand the config just by using onefetch, without needing to go on the web to reference any docs. I guess we can add it to a man page, but we can also generate a default config with all options for the user to edit, or have a CLI tool like onefetch config list|get|set|edit, or something else.

[spenserblack]

🤔 Now that I think about it, implementing serde::Deserialize on the Config struct would accomplish a lot of the necessary work. Then it's pretty easy to choose which format to support, or even support multiple formats.

For config paths, there's dirs-next and directories-next, but it looks like the original crates (not -next versions) are once again actively developed.

[o2sh]

Good point!
In that case we may need to extend the Config struct by adding more CLI flags for customization, e.g. :

• The glyph to use for the separator (use "->" instead of ":")
• Which glyph to use for the palette (use "●" instead of " ")

But we can already start with what we have and add more options later on.

[spenserblack]

I needed to double-check since it's been a while since I've used this Rust feature, but destructuring could make this really easy to implement. Might be worth making this a hacktoberfest issue 🎃

[amelenty]

Hello! I'd like to take this issue as part of Hacktoberfest 🙂

One solution for making the config easily understandable for the user would be to generate the config if it doesn't exist, populating it with default options, and make sure it has comments that help understanding. Then the simplest option to reset the config to defaults would be just to delete/move the config file, as it would be recreated on the next startup.