[Kde-bindings] KConfigXT compiler for Python

[Jaime]

Hello,

  I changed locally (In a time when I was unable to sync with the svn
head) kconfig_compiler to be able to generate code for several
languages without the need to rewrite the entire kconfig_compiler code
again.
 Unfortunatelly, the lack of free time delayed the patch
checking/sending until next week.

 In any case, I'll try to create patchs to do it (I hope to have the
time again).

What I did in the attached code (the locally modified kconfig_compiler) was:
* I created the class LazyDefaultValue to be able to evaluate the
default values when the output code is produced, not when the xml
input file is processed.
 * The virtual method evaluateLazyDefaultValue is the one that
finally puts the default value in the output syntax.
* I created the class OutputProcessor to be an interface for other
languages to implement (examples OutputProcessorCpp  and
OutputProcessorRuby ). In this part I'm not sure this is worth the
pain. Too much methods. They could be unified again in one big method
as it is today.
* I created the class ParseInput in an independient way from the
output language.
* I created the class CfgConfig to store/read the params readed from
the QSettings and global variables (less global variables)
* The std::streams were replaced by QTextStreams
* I created two clases OutputProcessorCpp and OutputProcessorRuby, to
generate output code in each language, copying/pasting and renaming
the output stream.
* Then only 3 simple functions kept:
 * createOutputProcessor (the output language factory)
 * writeCompiled (to write the resulting .cpp or .rb files)
 * main very simplified (read params, read the xml, validate xml,
writeCompiled).

Best Regards.

2010/8/15 Richard Dale <richard.dale at telefonica.net>:
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kconfig_compiler.cpp.gz
Type: application/x-gzip
Size: 23703 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100816/e826e32f/attachment.bin>