[PyKDE] Re: Scalar types in KConfigSkeleton

[Jim Bublitz]

On Tuesday 10 January 2006 12:55, Jim Bublitz wrote:
> On Tuesday 10 January 2006 11:11, Andrey Golovizin wrote:
> > On Tuesday 22 November 2005 (Вт) 22:54 Jim Bublitz wrote:
> > > On Saturday 19 November 2005 17:40, Akos Polster wrote:
> > > > Hi, is this fixed in any Riverbank snapshots? I seem to have the same
> > > > problem with 20050829.
> > >
> > > No - it'll probably get picked up in the next snapshot, probably after
> > > Thanksgiving (this Thursday).
> > >
> > > Jim
> >
> > I just wonder, are scalar types in KConfigSkeleton working ATM?
>
> Not yet - I'll try to get it in the snapshot that should be available by
> the end of the week.

Actually, I lied. After finally getting around to really looking at this, I 
realized that anything I'd do with this via sip is better implemented in 
Python directly - you can parse KDE *rc files pretty easily, and for your own 
config files it's easier (and much prettier) to subclass 'dict' and add 
read/write methods in KDE format or whatever format you prefer.

The KDE *rc files don't contain any type info about params, so you have to 
write that into your own code anyway - no loss of functionality rolling your 
own.

My opinion at the moment (until someone convinces me otherwise) is just to 
drop KConfigSkeleton from PyKDE altogether - it doesn't work as is, a working 
implementation will be incredibly ugly from my point of view, and it's a 
nasty file to generate code from automatically (the last being not that good 
a reason, I realize). I'll leave it in if someone has code that needs it, but 
"as is" - be sure to speak up if that's the case.

If someone wants to write a Python version of KConfigSkeleton, I'll happily 
include with the PyKDE distribution (in a standalone .py file). If enough 
people request it (1 < enough <= 3), I'll provide it myself eventually.

Comments, criticisms, curses, etc. are welcome.

The only thing I feel really bad about is not getting to this (and not really 
understanding the problem with the present implementation) sooner.

Jim