[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: KDE/kdelibs/kdecore/config
From:       kde.braxton () gmail ! com
Date:       2008-01-28 10:15:12
Message-ID: 928c3f1b0801280215p59c825ddt187efe2a10e426c3 () mail ! gmail ! com
[Download RAW message or body]

On 1/28/08, Oswald Buddenhagen <ossi@kde.org> wrote:
> On Sun, Jan 27, 2008 at 08:38:01PM -0600, Thomas Braxton wrote:
> > On 1/27/08, Oswald Buddenhagen <ossi@kde.org> wrote:
> > > - possibly: selective multi-level master diversion - this is to
> > > support roaming profiles that have machine/user/etc. specific
> > > settings
> >
> > I'm not sure I understand what you want to accomplish with all this,
> >
> imaginge a user who is using several machines (desktop, laptop, thin
> client) in a network. he might want to have some settings being global
> and some per box.
> to be honest, the whole concept is probably too complicated and not even
> suitable for this exact task. but it is an interesting technical
> exercise and maybe somebody can even think of a useful application. :-D
>
> > but I think most of it is already handled in the cascading code.
> >
> yes
>
> > we would just need a way for KStandardDirs::findAllResources() to look
> > in more directories for files to read.
> >
> uhm, no. the cascading is entriely solved by KDEDIRS already. this
> extension would merely "cut off the top of the cascade". sort of blur
> the border between KDEHOME (rw) and KDEDIRS (ro).
that's what I meant. a way to add other directories in-between KDEHOME
& KDEDIRS, then everything would just work :) actually I think the way
to make this work is mostly already there, iirc there is a way to add
directories and set the priority in KStandardDirs? or isn't there a
way to have other config dirs? i know there is code in KConfig to
re-read the configs if custom config directories are added, how can
those custom config dirs be added?

> > >  - make entrymap truly hierarchical [...]
> > this looks like it would add a lot more complexity for how much gain?
> > I think we should keep the entrymap as simple/fast as possible.
> >
> the current implementation is anything but simple and fast. the
> special-casing of group headers in the map is just ugly, as the
> extraction of key ranges for a group is. and the construction of
> canonical keys for every access is dog slow.
would having possibly dozens of maps with only a few entries each for
one config file really be any better?
[prev in list] [next in list] [prev in thread] [next in thread]