KConfig and $HOME

[Thomas Braxton]

On 10/13/07, Oswald Buddenhagen <ossi at kde.org> wrote:
>
> 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.


which suggestion? to read env variables with or without [$e]?  and if yes,
shouldn't readPathList behave the same way?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071013/6b7cc60c/attachment.htm>