KConfig::readPathEntry() vs. kde3 (Re: KConfig and $HOME)

[Oswald Buddenhagen]

[breaking the thread to regain some wider attention.]

the basic problem is that kde3 writePathEntry() creates config entries
that need to be $-expanded but does not write a respective [$e] marker.
consequently, readPathEntry() simply implies [$e].

this makes the config files inconsistent and is thus major crap:
- if you edit a file manually you have to know whether an entry is
  actually treated as a path and thus $-expanded or you might screw up.
- tools (config editor?) have a much harder time (hello heuristics).
- it messes up the new and shiny kconfig code itself.

my favored solution is fixing this and upgrading the config files like
this:
> we could have some logic in kconf_update (hard-wired or generalized
> into a scriptable solution) that automatically converts everyhing in
> .kde/share/config/ that looks like a path entry on first start. this
> has the downside of a) corrupting entries that only *look* like path
> entries and b) will miss entries outside config/. a) is pretty
> unlikely, given strict enough rules. b) could be remedied by falling
> back on the manual solution for "exotic" cases.

however,
> as thiago pointed out, some files are (supposed to be) shared between
> kde3 and kde4, so backwards compat is the only option - provided any
> of the relevant entries are path entries.
> 
nb: a one-time upgrade by kde4 won't break kde3. however, a later write
by kde3 would break kde4 again and we cannot upgrade the entries over
and over.

now it occurred to me, that we can actually do the right thing: fix not
only kde4, but also kde3 and make an upgraded kdelibs a requirement for
sharing kde3 and kde4 configs. given the other deps of kde4 this isn't
too much to ask for, i think.
what do you think, particularly the kde3 release dude?

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.