All KConfig files inherit kdeglobals keys by default, good or bad?

[Thomas Lübking]

On Dienstag, 25. Juni 2013 10:10:03 CEST, Aurélien Gâteau wrote:
> [Continuing the discussion started on 
> https://git.reviewboard.kde.org/r/111171/ ]
---------

> kdeglobals in mind. As such, I think this code should opt-in to 
> inherit from 
> kdeglobals, instead of expecting all code reading configuration to opt-out 
> from it.

As mentioned and you apparently agreed, i fear the "opt" path has already been left.
Breaking API to make developers take an explicit choice seems inevitable.

Nevertheless, doing so to push them into actually understanding the KConfig design and abilities and the implications of their choice seems reasonable to me and worth the efforts to port the API (also no #ifdef requirement)

The only real "loss" would be the ability to keep all immuted settings in one place, but that feature carries the broadsword factor ("[General]background" - immuted the wallpaper and stop application X from forking...) and may thus reasonably be dropped regardless.


-------------------
The rest is reply on general considerations and argumentation - not the particular question on sane defaults of KConfig
-------------------------------

> I asked for an example, you provided one about kiosk, I answer 
> how your kiosk  example is actually painful.

I refered to this statement:
"Furthermore, since this code is specific to Kiosk, it makes sense for it to actively look at KConfig::isImmutable() and KConfigGroup::isEntryImmutable()."

> I disagree. It is wrong for developers to copy things without understanding 
> them
That's actually what i said ...

> It is OK to learn by reading code.
Yes.

> The trick here is that the way you infer 
> KConfig works by reading code using it does not exactly match the way it 
> actually works. One often use tools or applications reading 
> their config from 
> /etc/foorc then ~/.foorc, so it is reasonable to assume KConfig is going to 
> behave the same.

It's also usual and thus reasonable to believe that the config *file* might inherit random other files in one or another way which are then suddenly blended into the config *object* (eg all gtk works like that)

Implicit assumption on an object/function's internal bahavior is explanation, but no valid excuse for misconceptions.

If you use an API as blackbox than you get blackbox behavior. Always.
If you just copy and paste KGlobal::dirs()->locate(), you don't know what paths that will lookup and you don't care. You may also have missed that you actually wanted to use KGlobal::dirs()->locateLocal().

Same goes here.

If you're copypasted KConfig as magic blackbox to get you some config values, that's what you get: config values as figured by the magic config system.

You can either question the presence of object defaults in general or question whether the defaults are sane.
But if "developers are too lazy to understand what they use" is an argument, every code has to be explicit and that rules out any complexity abstraction.


> This can be a serious problem: what happens when my app uses 
> [General]thingy 
> which defaults to "foo" and then in the next version of KDE SC, a generic 
> component writes in kdeglobals [General]thingy=bar. All of a sudden my app 
> behaves differently.
a) Not if you have actually ever written the config.
b) Yes, name conflict. Happens on any common resource usage. Don't use common resources to prevent it for sure. Parse and clamp input.
The user will however see this "configured" value in the config dialog as well and can "correct" it.


Cheers,
Thomas