The config system in pcb-rnd - why

Why, what was wrong with the old one?

The old config system had several limitations that would have been hard to fix keeping the original design:

What the new system offers

But isn't this more complicated for the user?

Hopefully not much. There are a few extra features, like multiple sources with levels that did not exist in pcb and lists with prepend/append. Some of these features present in other software so users should be comfortable with the ideas. The learning curve is probably compensated by the more orthogonal system. The syntax is also geared for simplicity and easy use with text editors. Finally, the new preferences dialog and config actions help the user to explore how settings got used from all the config sources. There's an intended layering in complexity: simple things can be done easily without having to understand the whole system.

All in all, the extra features the user needs to learn is comparable with the old customs that he/she can forget.

And did it make the code more complicated?

The size of the code did not change much after the initial config rewrite. The new system has new features, some of which brought in a few hundred lines of code, but a similar amount of old code could be removed. What came in is infrastructure, what had to go was a bunch of repetitive config parsing, boolean-setting-accessor-action code. This means on the long run, the more settings are added, the more the new system pays back.

Read access, which is far the most common way to use the config in the code (e.g. if (setting == true) { }) is very similar to the old Settings system. Write access needs to go through a function call API, but this is usually a single call per setting (instead of directly modifying a variable).

For plugin programmers, the new system makes life much easier as they can plug their settings in.