[PyKDE] Re: Scalar types in KConfigSkeleton

[Jim Bublitz]

On Wednesday 11 January 2006 21:27, Stephan Hermann wrote:
> Hi,
>
> On Thursday 12 January 2006 01:11, Akos Polster wrote:
> > On Wednesday 11 January 2006 20:36, Jim Bublitz wrote:
> > > On Wednesday 11 January 2006 06:49, Akos Polster wrote:
> > > > 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)
> > >
> > > One problem is that I don't have the patch, and the links to it no
> > > longer work. I'm assuming the patch is of sufficient quality - I just
> > > don't want to start going the route of creating things like mutable
> > > bools or ints for PyKDE.  I think if you want those things, there are
> > > languages that already implement them. Also, if I make KConfigSkeleton
> > > functional now, I'll have to live with it forever, or I'll break
> > > people's existing code.
> >
> > Somebody wrote here Ubuntu still maintains the patch, could this be it:
> > http://ubuntu.linux-server.org/python-kde3/01-configskeleton.patch ?
> >
> > But then again, that's your choice and I'd be equally happy with a
> > Python-only solution

> this patch can be easily added again, well it's not mine, but from someone
> in 2004.

I looked at the patch at the link above, and it's very well done - that might 
lead me to reconsider.

> Actually, comparing Pythong ConfParser with KConfigSkeleton is comparing
> apples and tomatoes.

Both are fruits, both are spherical, both are usually red or green or 
yellowish, both are edible, both are juiced, and in fact tomatoes are 
sometimes called "love apples" (a little archaic perhaps) in English, and 
people originally thought tomatoes were poisonous, while apples were worth 
the tradeoff of original sin - is that what you mean? :)

I realize ConfigParser is quite different in style  - it's a matter of what 
most PyKDE users really need. My guess (and it's no more accurate than that) 
is that a lot of what PyKDE gets used for isn't sufficiently complex to need 
something as powerful or complicated as KConfigXT. Some of that functionality 
isn't going to be transferable easily to Python - even the patch, as elegant 
as it is, isn't very user-extensible. I don't think you can subclass the 
existing Item* classes, for example, as the patch modifies their use 
(implicitly, not explicitly, which is non-Pythonic).

> KConfigSkeleton is one of the base classes for the KConfigXT system, which
> should be KDEs future global configuration system.
>
> And following defaults for KDE, PyQT should work as well with
> KConfigSkeleton. The patch you mentioned worked nicely, but had a different
> syntax then the C++ KDE classes.

Yep - I don't think the syntax/style of use is ever going to be comparable to 
C++ KDE. That means the PyKDE implementation should be well-documented and 
have example code available. If it gets used by more than a few fairly 
knowledgeable people, it's going to require support here too. As is, the 
patch looks like it's not a maintenance or code generation problem at all, 
but I'd wonder how it's going to evolve (wrt to related classes especially).

> So it's not a matter of "if we want it", it's a matter of fact, that PyKDE
> should be as close to KDEs C++ Classes as it can be, to offer KDE
> developers who wants to write in Python a decent compatiblity system.

I agree PyKDE should be as close to KDE as possible (and no closer) - I made a 
similar comment during the discussion of whether PyQt should be more Pythonic 
in returning char strings vs. QString. I also think that PyKDE has a 
responsibility to be as Pythonic as possible in line with KDE compatibility. 
And the fact is, KConfigSkeleton isn't going to be completely KDE compatible, 
and the higher level classes somewhat less so (for instance, where QPROPERTY 
is needed, I think).

> BTW, Kubuntu, the Ubuntu flavour with the KDE desktop,  is going more and
> more to pykde and since Kubuntu 5.10 we have sip4 pyqt and pykde even
> pykdeextensions in our main repositories and shipping them on the default
> install CDs, because some of our important distribution softwarepackages
> are depending on these frameworks.

I wasn't aware of that, and that probably has some influence on the direction 
this should go.

> Python, as you all already know, is for Ubuntu (and even for Kubuntu) the
> development and implementation language no. 1. And the KDE people shouldn't
> stand behind a good and nice GTK python implementation.

I'm not very impressed by arguments about competition or market-share - I 
don't even run my business on that basis very much. I'd make the decision to 
use sip-PyQt vs something else based on the overall quality of the 
implementations, and I'd try to make a decision about KConfigSkeleton vs 
something else (or nothing else) the same way.

Considering the patch is available and done much better than what I would have 
come up with, I'm willing to add it to PyKDE for the next snapshot (which 
will save some user-maintenance headaches down the road). If there's enough 
community support (ie somebody documents this as a Python implementation and 
writes some example code - see the DCOP stuff in PyKDE/docs and /examples), 
I'd be willing to continue to support it. If not, it's code that will only be 
useful to those who can figure out how to use it from the .sip files. In that 
case,  I'm still of the opinion that this is (in Python, not C++) an awkward 
way of accomplishing the task, and if docs and example code are needed, I'd 
sooner polish and extend something similar to what I already use, which I 
think is more Pythonic and more useful generally.

In short, if people want it, they'll support it. If not, I won't.

At the current rate of progress, a snapshot should be available next week - 
I'm still working on incorporating some new sip features and changes, which 
is taking longer than I expected.

Jim

PS: If the author of the patch is still reading the list, or someone is sure 
who it is, I'd like to credit it.