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

[Andreas Pakulat]

On 19.10.07 14:21:19, Oswald Buddenhagen wrote:
> [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?

Well, the problem with that is that KDE 3.5.8 has just been released, so
this will end up in 3.5.9 (if that will happen) whose release date is
not yet known. So while the solution is a good idea I'm not sure it'll
work, at least not for KDE 4.0. Or we have to require distro's to fetch
the apropriate patch from svn and add it to their kde3.5.8 packages.

Andreas

-- 
Troubled day for virgins over 16 who are beautiful and wealthy and live
in eucalyptus trees.