<br><br><div><span class="gmail_quote">On 10/13/07, <b class="gmail_sendername">Oswald Buddenhagen</b> <<a href="mailto:ossi@kde.org">ossi@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

ok, i read some kde3 source instead of relying on hear-say, incorrect<br>memory and speculation. ;)<br>i have to correct my statement:<br><br>On Fri, Oct 12, 2007 at 06:23:59PM +0200, Oswald Buddenhagen wrote:<br>> 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.

<br>> we are talking exclusively about {read,write}PathEntry(), for which<br>> $HOME/ at the beginning is sort of a magic token. i don't think it<br>> makes much sense to change that behavior in any way.<br>>

<br>in fact, variables *were* just expanded - by readPathEntry(), from the<br>day the roaming user profile stuff was added in mid 2003.<br>sorry for the extra confusion i caused. :}<br>and helge should be shot. ;)<br><br>

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.

<br>  i hate it, though.<br>- write oodles of kconf_update scripts, based on allen's centralized<br>  converter. sort of the cleanest solution, but needs an incredible<br>  (read: unrealistic) amount of work.<br>- we could have some logic in kconf_update (hard-wired or generalized

<br>  into a scriptable solution) that automatically converts everyhing in<br>  .kde/share/config/ that looks like a path entry on first start. this<br>  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.

<br>  you know what? i like this approach ...<br><br>as thiago pointed out, some files are (supposed to be) shared between<br>kde3 and kde4, so backwards compat is the only option - provided any of<br>the relevant entries are path entries. that doesn't preclude my favorite

<br>approach, though: KConfig can take a flag to enable backwards-compat<br>mode and the auto-converter can have an exclusion list.<br><br>note that while the missing consistency through implicit [$e] is Ugly<br>(TM), it isn't something that *must* be fixed for 

4.0, so no pressure<br>here. in fact, if we wait till 4.2, we can just ignore the conversion at<br>all, as KConfig will surely have fixed all path entries and "nobody" is<br>going to upgrade from 3.x to 4.2, right? :)

<br><br>On Sat, Oct 13, 2007 at 09:55:56AM -0500, Thomas Braxton wrote:<br>> here's a patch that fixes readPathEntry,<br>><br>scratch it. go with allen's suggestion.</blockquote><div><br class="webkit-block-placeholder">

</div><div>which suggestion? to read env variables with or without [$e]?  and if yes, shouldn't readPathList behave the same way?</div><div><br class="webkit-block-placeholder"></div></div><br>