KConfigXT compiler for Python

[Richard Dale]

On Sunday, August 15, 2010 03:55:56 pm Simon Edwards wrote:
> Hello,
> 
> On 08/13/2010 12:15 AM, Dennis Malcorps wrote:
> > Since there is no such application for PyKDE I am currently writing
> > one: PyKConfigCompiler [http://gitorious.org/pykconfigcompiler]
> > 
> > PyKConfigCompiler is still in an very early state, there are no
> > comments, no unit tests, but it does work with the right input^^
> > 
> > Are the PyKDE guys actually interested in this? If yes, is it okay
> > that my program is a Python application, or do I need to rewrite it in
> > C++?
> 
> I, and I suspect other people, are certainly interested in more complete
> tooling for Python developers, and PyKConfigCompiler sounds like
> something which is needed in PyKDE.
> 
> It is not just "okay" that this kind of thing is written in Python, it
> is highly recommended, in my opinion Python related devs tools be
> written in Python.
> 
> If PyKConfigCompiler can brought up to a reasonable level of
> completeness in time I would like to see it included in PyKDE as part of
> 4.6 when it comes out at the start of next year.
> 
> On a technical note, I don't know much about the kconfig stuff, but is
> it possible to read kcfgc files directly at runtime and produce the GUI
> on the fly without having to generate .py files at build time?
To me the KConfigXT stuff is a nightmare from a language bindings perspective.

In C++ you can access instance variables directly instead of needing to go via 
setProperty()/getProperty() interface based on passing and returning 
QVariants. Also you pass references to primitive types to the KConfigXT runtime 
classes which is a pain for bindings as you need to special case stuff to 
prevent the references being garbage collected. In Plasma they have gone to 
some lengths to work round these problems in order to use KConfigXT in a 
dynamic fashion. Because the KConfigXT runtime can be bypassed and can't tell 
when instance variables have been get and set directly, it means that the code 
to emit signals when something has changed is much more complicated than it 
need by.

In my opinion we shouldn't need to have entirely seperate Ruby or Python tools 
to handle the KConfigXT classes, or hack things in Plasma, it should have been 
designed that way in the first place. It wasn't designed that way in the first 
place because nobody thought about language bindings. I don't know how to fix 
that. I'm just slightly sad that we may end up with completely different tools 
for each bindings language, instead of a relatively simple way of changing the 
way the standard kconfigcompiler generates code.

-- Richard