KConfig and $HOME

[Oswald Buddenhagen]

ok, i read some kde3 source instead of relying on hear-say, incorrect
memory and speculation. ;)
i have to correct my statement:

On Fri, Oct 12, 2007 at 06:23:59PM +0200, Oswald Buddenhagen wrote:
> On Fri, Oct 12, 2007 at 11:50:30AM -0400, Allen Winter wrote:
> > 1) support reading environment variables with or without the [$e]
> > 2) support writing environment variables only with the [$e]
> >
> most definitely not. variables were never just expanded.
> we are talking exclusively about {read,write}PathEntry(), for which
> $HOME/ at the beginning is sort of a magic token. i don't think it
> makes much sense to change that behavior in any way.
>
in fact, variables *were* just expanded - by readPathEntry(), from the
day the roaming user profile stuff was added in mid 2003.
sorry for the extra confusion i caused. :}
and helge should be shot. ;)

so 1)/with and 2) from allen's proposal are pretty much sane when
applied exclusively to readPath*Entry().
for 1)/without, there are basically three options:
- use 1)/without verbatim, i.e., have backwards compatible code.
  i hate it, though.
- write oodles of kconf_update scripts, based on allen's centralized
  converter. sort of the cleanest solution, but needs an incredible
  (read: unrealistic) amount of work.
- 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 (it might turn up some bugs where
  readEntry is used instead of readPathEntry, though). b) could be
  remedied by falling back on the manual solution for "exotic" cases.
  you know what? i like this approach ...

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. that doesn't preclude my favorite
approach, though: KConfig can take a flag to enable backwards-compat
mode and the auto-converter can have an exclusion list.

note that while the missing consistency through implicit [$e] is Ugly
(TM), it isn't something that *must* be fixed for 4.0, so no pressure
here. in fact, if we wait till 4.2, we can just ignore the conversion at
all, as KConfig will surely have fixed all path entries and "nobody" is
going to upgrade from 3.x to 4.2, right? :)

On Sat, Oct 13, 2007 at 09:55:56AM -0500, Thomas Braxton wrote:
> here's a patch that fixes readPathEntry,
>
scratch it. go with allen's suggestion.

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