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

[Aurélien Gâteau]

[Continuing the discussion started on 
https://git.reviewboard.kde.org/r/111171/ ]

> > > Aurélien Gâteau wrote:
> > >
> > > > I see the point of having cross-app configuration files, I assume
> > > > classes
> > > > from kdelibs for example can use it to store settings. What I don't
> > > > understand is in which situation it is useful to have all
> > > > configuration
> > > > file inherit from cross-app configuration keys, compared to having
> > > > cross-app code explicitly call
> > > > KSharedConfig::openConfig("kdeglobals").
> > > > Can
> > > > someone provide an example?
> > > > 
> > > > To me it feels dangerous because application developers may not be
> > > > aware
> > > > of
> > > > this feature and may inherit values for keys they expect to be
> > > > application
> > > > specific if they are unlucky to pick a group used in kdeglobals or if
> > > > a
> > > > group they used in the past is now used by a component which writes in
> > > > kdeglobals.
> >
> > Thomas Lübking wrote:
> >
> > > https://techbase.kde.org/KDE_System_Administration/Kiosk/Introduction
> > > #KDE_Action_Restrictions
>
> Aurélien Gâteau wrote:
>
> > Kiosk is actually a good example of why inheriting from kdeglobals can be
> > painful.
> > 
> > I used to work for a company which deployed locked-down KDE systems for
> > dentists. We would create the locked-down configuration by running KDE as
> > an "empty" user, configure the desktop to our liking, then copy the config
> > files from $HOME/.kde to a custom, read-only dir which was inserted in
> > $KDEDIRS. We would of course lock-down the config files from the custom
> > dir
> > by marking their config as immutable. As you know there are 3 ways to
> > lock-down a config file: you can lock the whole file, a whole section or a
> > single key. We usually locked down sections since we felt it was the most
> > convenient way to go. We locked down sections in many files, and at some
> > point we locked down the "General" section of kdeglobals... and wasted
> > quite some time figuring out why many applications would not save all of
> > their settings. You would not believe how common a "General" section is.
> > 
> > Sure it is nice to be able to take advantage of this to lock-down actions
> > at
> > the desktop and/or application level, but that could also be done by first
> > looking at kdeglobals:"KDE Action Restrictions":action/${actionName} and
> > then at ${appname}rc:"KDE Action Restrictions":action/${actionName}.
> > Furthermore, since this code is specific to Kiosk, it makes sense for it
> > to
> > actively look at KConfig::isImmutable() and
> > KConfigGroup::isEntryImmutable().Thomas Lübking wrote:
> 

Thomas Lübking wrote:

> Why would the code be specific to kiosk? - You asked for an example, not
> justification.

I asked for an example, you provided one about kiosk, I answer how your kiosk 
example is actually painful.
 
> It does eg. also allow you to preconfigure the MainWindow settings of all
> (even yet unwritten) applications - w/o any requirement to immutability,
> rather explicitly allowing them to be altered per application and account
> afterwards. It does as well allow to control all immutability settings from
> only one file (unless an application doesn't IncludeGlobals when reading
> its settings)
> 
> 
> I'm pretty sure that the [General] section has widespread usage (eg. in
> gwenview ;-) But when you draw a broadsword, don't complain about the
> bloodshed ;-P (And yes: "general" in "*global*" is a broadsword - or rather
> even a scythe)> 
> Now, I don't want to defend the behavior of KConfig, but your arguments so 
far have been:
>    a) developers not aware of the behavior (ie. using KConfig w/o ever
>    looking at the API doc) and b) admins using a system w/o understanding
>    its design (for I will not assume that, had you known that the General
>    group from kdeglobals was merged into all General groups of all
>    applications, you had immuted it)
>
> b) Is actually not relevant at all, as even if FullConfig had to be
> explicitly passed, it would happen nevertheless - and then some
> applications could have stored their generals and others could not. Doesn't
> seem any simpler to track.
> 
> About a):
> I assume if the API was new, one might make the parameter w/o default -
> enforcing developers awareness and informed choice. Nevertheless, using an
> API by cnp w/o wasting a glimpse at the docu is just wrong. Happens, yes. I
> do sometimes, yes. - But it's still wrong.

I disagree. It is wrong for developers to copy things without understanding 
them, like we did back in the days by cargo-culting autotools files back and 
praying it would work.

It is OK to learn by reading code. 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 is much less common to have two apps foo and bar reading 
their config respectively from /etc/foorc, ~/.foobarglobals, then ~/.foorc and 
/etc/barrc, ~/.foobarglobals then ~/.barrc.

This is a violation of the principle of least surprise.

> You certainly have a point on the name collision (so on't use background in
> [General]...), but usually the local context has precedence, thus the worst
> thing to happen was that the "vanilla" default value isn't the one you used
> in the code (until the user stores the desired value once).

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.
 
> Eventually the default actually should have been CascadeOnly (because
> IncludeGlobals seems mostly interesting to libs only).

I agree, especially because I assume all the code which benefits from 
inheriting from kdeglobals has been written with reading config from 
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.

This cannot be changed in kdelibs4, but would it make sense to change it in 
KF5?

> => I'd suggest to bring this up at an appropriate place w/ an appropriate
> subject line for KF5. My opinion? - Changing the behviour has to make the
> parameter mandatory, ie. break compilation to enforce a developer choice.

I agree.

Aurélien