Open
Description
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)
Activity
[-]Config file for theming/customization[/-][+]Config file for theming/customization 💄[/+][-]Config file for theming/customization 💄[/-][+]Config file for theming/customization💄[/+]spenserblack commentedon Aug 20, 2022
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 commentedon Aug 20, 2022
Thanks 😊
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:
Good idea, your second suggestion would be very useful 👍
spenserblack commentedon Aug 20, 2022
🤔 Yeah in YAML I think it would just be
Now I'm leaning more towards TOML, since it provides the user with more freedom in how they choose to format.
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 becomesoption=*
in the config file (so pretty much INI format). In that format, ours would look like thisIMO 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 commentedon Sep 27, 2022
🤔 Now that I think about it, implementing
serde::Deserialize
on theConfig
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
anddirectories-next
, but it looks like the original crates (not-next
versions) are once again actively developed.o2sh commentedon Sep 28, 2022
Good point!
In that case we may need to extend the
Config
struct by adding more CLI flags for customization, e.g. :But we can already start with what we have and add more options later on.
spenserblack commentedon Sep 28, 2022
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 commentedon Sep 30, 2022
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.
4 remaining items
spenserblack commentedon Sep 1, 2023
Reviewing old issues in this project...
Yet another format, and possibly the easiest to implement, would be a simple options list. If you look at the Ruby ecosystem, with files like
.rspec
and.yardopts
, configuration files are often just a list of CLI arguments.We shouldn't have to do much more than split this file into a
&[&str]
and pass it to clap. Just split on newlines and spaces, preserving spaces inside"quotes"
.Sk7Str1p3 commentedon Mar 18, 2025
may i ask if some progress with config was made?
spenserblack commentedon Mar 18, 2025
I'm afraid not. But if you're interested in this feature, I'd be happy to know your preferred implementation as a user.
Sk7Str1p3 commentedon Mar 19, 2025
TOML as more readable and flexible format imo.
Sk7Str1p3 commentedon Mar 23, 2025
I hope ts may be useful https://github.com/LivacoNew/CrabFetch
Sk7Str1p3 commentedon Mar 23, 2025
Possibly i may try implement this in around a week
spenserblack commentedon Mar 23, 2025
Let us know if you need any help! With serde macros and the
dirs
crate, I believe it shouldn't be too complicated. The hardest part will probably be merging CLI options with config options.spenserblack commentedon Mar 23, 2025
I do want to throw out one crazy option, which will most likely be overkill:
I've been working on a personal Rust project that uses Lua for the config file, and I've been having some fun with it. Scriptable config files open up some interesting possibilities, like
Sk7Str1p3 commentedon Mar 23, 2025
We could use both. Like Yazi does, it uses TOML for basic settings and Lua for plugins and more flexible configuration. Although i will work with toml only.
Sk7Str1p3 commentedon Mar 25, 2025
Attempt on implementation at #1548
Sk7Str1p3 commentedon Mar 29, 2025
@o2sh I would pin this issue so we get help way faster