kconfig and kde global config files

[Aaron J. Seigo]

On Monday 06 March 2006 16:13, Adam Sterling wrote:
>  Interestingly enough, that happens to be exactly the scope of what I'm
>  planning on doing to KConfig.
>
>  I'm an employee of Net Integration Technologies (see open.nit.ca), and I'm
>  currently being paid to rewrite KConfig to use UniConf (
>  http://open.nit.ca/wiki/index.php?page=UniConf) in some form.

>  > we could provide some sort of config daemon that all config read/write
>  > happens
>  > through. done right this requires atomic commits and transactions.
>  > that's quite a bit to do.
>
>  Already done in UniConf.
>
>  we could also have a daemon that simply coordinates writing: writes still

and slower than anything we could implement nativelly

>  > to this app". wouldn't take care of the "two apps writing
>  > simultaneously" issue.
>
>  Notifications are already handled by UniConf, though there are many
> possible ways to make use of UniConf's notifications for KConfig.

it makes zero sense to do kconfig -> uniconf -> INI in my opinion. to be 
perfectly honest, uniconf is exactly the wrong solution for cross desktop 
issue and exactly the right solution for legacy.

>  UniConf could simply be used to pass notifications about key changes, or
> it could be directly checked (instead of a QMap) to get information about
> groups/keys.

please look at kconfig and consider the need for multiple backends. come back 
then and comment.

>  For example, you could permanently store all the info from the ini files
>  after they are first loaded by a KConfig, and perform all the sync and
>  reparseConfigs in a seperate thread. Then, all  future operations on a
>  KConfig object (including the construction) will be ridiculously fast

except the overhead for sharing! we're already fairly fast in this case.

>  Anyways, right now my only design requirement is that I use UniConf (It's
>  why I'm getting paid to do this :) ) to improve KConfig.

then ffs get involved with:

branches/work/kde4/playground/libs/kconfig

you want to create a kdeconfigbackedn subclass ...

>  Essentially, my job is to do whatever it takes to convince you guys that
>  UniConf is the future of KConfig.

my job is to do what is best for kde. and in that scope, uniconf is not the 
future of kconfig. it is a future enhancement to it.

>  If you don't believe it is, I'd love to hear why :), 

performance, flexibility, performance and the ability to decide our own fate.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060307/fa483aaf/attachment.sig>