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 <[EMAIL PROTECTED]> 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 [email protected] > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde > -- Akos Polster http://akos.pipacs.com mailto:[EMAIL PROTECTED]
_______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
