fastfetch 2.0 plan & discussion

Still a thought process, so please note what you like / dislike, and what should change!
If you have an idea about a breaking change that should become part of 2.0 too, please post it!

I plan on regularly updating this post with new ideas, and once i (and hopefully most active users) think it is good, i start implementing it.

General idea

The plan is to completely rewrite the configuration system in a way, that the same module can be printed multiple times with a different configuration.

This would allow for some pretty nifty configuration options, for example one could print the Theme module multiple times, one time showing QT, the other time showing GTK theme.

Merging of modules

This would clean up both code and user config. Since the resulting modules can then be printed with different configs, all existing configurations should still be possible to achieve.

• Date, Time, Datetime
• Host, Bios, Board
• Terminal, Shell
• CPU, CPUUsage
• Memory, Swap
• Battery, Power Adapter

New config file

For a simpler configuration, i am currently thinking about using a yaml file for config. It would make config pretty easy, but i am still a bit concerned about parsing time. A config file could look like this for example:

color:pinkbinaryPrefix:sidisableLinewrap:falselogo:name:archcolors:1:greenpadding:right:2modules:  -type:titlecolor:blue  -type:separator  -type:os   -type:packageskey:packages (native)format:{1} (pacman)  -type:packageskey:packages (sandboxed)format:{13} (flatpack), {14} (snap)

Changed command line flags

Boolean flags

Currently the have a lot of boolean command line flags. They default to true. This is counter intuitive if they change a value, that also defaults to true. For example--multithreading must always be--multithreading false to take effect.
I want to change those flags, so that they default to the opposite of the value they change.--multithreading would therefore become--disable-multithreading. Thetrue/false behind those flags should always be truly optional.

Module flags

I am currently unsure what the better way is. I still want to provide flags that change to config of modules. The following behaviour is possible:

• They overwrite the config for each time the module is used
• They overwrite the config only in configs where it is not explicitly set

Please tell me what you prefer!

Implementation details

Format strings

I want to change format string functions to take callbacks instead of values. This should increase execution speed, since we only detect what is really printed. But because this is such a big change, requiring an update for literally every module, i think this should be part of 2.0 too.