Skip to content

Config file for theming/customization💄 #745

Open
@o2sh

Description

@o2sh
Owner

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

changed the title [-]Config file for theming/customization[/-] [+]Config file for theming/customization 💄[/+] on Aug 20, 2022
changed the title [-]Config file for theming/customization 💄[/-] [+]Config file for theming/customization💄[/+] on Aug 20, 2022
spenserblack

spenserblack commented on Aug 20, 2022

@spenserblack
Collaborator

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

o2sh commented on Aug 20, 2022

@o2sh
OwnerAuthor

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

spenserblack commented on Aug 20, 2022

@spenserblack
Collaborator

🤔 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

spenserblack commented on Sep 27, 2022

@spenserblack
Collaborator

🤔 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

o2sh commented on Sep 28, 2022

@o2sh
OwnerAuthor

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

spenserblack commented on Sep 28, 2022

@spenserblack
Collaborator

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

amelenty commented on Sep 30, 2022

@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.

4 remaining items

spenserblack

spenserblack commented on Sep 1, 2023

@spenserblack
Collaborator

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.

--image profile-pic.png
--exclude dist
--disabled-fields churn

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

Sk7Str1p3 commented on Mar 18, 2025

@Sk7Str1p3
Contributor

may i ask if some progress with config was made?

spenserblack

spenserblack commented on Mar 18, 2025

@spenserblack
Collaborator

may i ask if some progress with config was made?

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

Sk7Str1p3 commented on Mar 19, 2025

@Sk7Str1p3
Contributor

I'd be happy to know your preferred implementation as a user.

TOML as more readable and flexible format imo.

Sk7Str1p3

Sk7Str1p3 commented on Mar 23, 2025

@Sk7Str1p3
Contributor
Sk7Str1p3

Sk7Str1p3 commented on Mar 23, 2025

@Sk7Str1p3
Contributor

Possibly i may try implement this in around a week

spenserblack

spenserblack commented on Mar 23, 2025

@spenserblack
Collaborator

Possibly i may try implement this in around a week

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

spenserblack commented on Mar 23, 2025

@spenserblack
Collaborator

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

-- if this is a Jekyll project, include prose like Markdown
local types = { "programming", "markup" }
if file_exists("_config.yml") then
  table.insert(types, "prose")
end
local config = {
  -- ...
  types = types,
  -- ...
}

return config
Sk7Str1p3

Sk7Str1p3 commented on Mar 23, 2025

@Sk7Str1p3
Contributor

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

Sk7Str1p3 commented on Mar 25, 2025

@Sk7Str1p3
Contributor

Attempt on implementation at #1548

Sk7Str1p3

Sk7Str1p3 commented on Mar 29, 2025

@Sk7Str1p3
Contributor

@o2sh I would pin this issue so we get help way faster

linked a pull request that will close this issue on Mar 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @spenserblack@o2sh@amelenty@Sk7Str1p3

      Issue actions

        Config file for theming/customization💄 · Issue #745 · o2sh/onefetch