[PyKDE] Re: Scalar types in KConfigSkeleton

[Akos Polster]

Jim, I agree with all your worries but

- don't we have a patch already making scalars types work? All we are
asking for is to include it in the official release (assuming you can
live with its quality)

- dropping KConfigSkeleton means dropping the whole
KConfigDialogManager framework.

I'd prefer to have this ugly thing released for now and deprecate it
when a better Python-based solution emerges.

 ~ Akos.


On 11/01/06, Jim Bublitz <jbublitz at nwinternet.com> wrote:
> 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
>
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
>


--
Akos Polster
http://akos.pipacs.com
mailto:akos at pipacs.com