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
