xiate gets a `config.ini`

2021-05-08

xiate currently uses a config.h file. Options like your font or color scheme are configured in that file. If you want to change one of those options, you have to … recompile xiate. This follows the model of many suckless programs. There are pros and cons.

Pros:

It’s easier for me as a developer. I compile xiate via make anyway, I don’t install a package from my distribution.
There’s less potential for bugs, since there is no code to read, parse, or evaluate a “true” configuration file. The C compiler handles all of this.
In the case of suckless programs, it is a truly elegant way to provide a user-facing configuration. Those programs usually don’t depend on any external libraries (intentionally and with good reason), so they would have to implement a config file parser of their own. Plus, it is the norm to apply additional patches, so you compile from source anyway.

Cons:

It is extremely annoying to users. You basically have to reinvent your own package management. You can’t just run apt install xiate, instead, you have to manually clone the repo, edit the config.h file, and then come up with some process to watch for my upstream updates.
Even to me, recompilation can be annoying. It’s extra work. I can’t just update the config file, e.g. by pull my dotfiles repo, and be done with it.

I think config.h only makes sense for programs with very few external libraries. xiate is not such a program. It uses VTE and, thus GTK and GLib. GLib comes with an INI-style parser anyway. Why not just use that?

xiate’s repo now contains a branch called ini, which contains a first implementation of that.

I’m only 80% sure if I want to go in this direction. Even if I don’t have to write my own parser and don’t have to pull in new libraries, it still means more code. Granted, it’s only about 200 lines, but still. It means more potential bugs.

– Update 2021-05-18: This has been merged into main.

Comments?

xiate gets a config.ini

xiate gets a `config.ini`