On Saturday, March 26, 2016 10:30:18 PM Shaheed Haque wrote: > Hi all, > > I've given up on trying to get the twine2 PyKDE bindings generator > working [1] because not only is the code there broken, but it seems a > Sysiphusian task to maintain a C++ parser. Instead, a few evenings > with clang 3.9 have yielded what I hope is the basis of a way forward: > about 800 lines of Python code [2] which can already create 684 .sip > files [3]. > > What I hope is important about the new tool is that it is documented, > and has a rule-driven approach to adding the SIP annotations which > should ensure that the bindings are easier to maintain once we > actually get them working. > > The current status is: > > #1 I have not tried to actually run the SIP compiler :-). > > #2 I have not checked whether the tool is failing to process some > .h files (i.e. I have not checked whether I have all the relevant .h > headers, or whether the new tool is failing on some .h files). > > #3 I have toyed with, but not mounted a full attack on, the SIP > annotations problem (see below) > > #4 I have not tried to map the KDE5 module naming scheme to > anything in Python. > > #5 No integration with CMake and the rest of the KDE build system. > > On the annotations problem, looking at PyKDE4 as my guide, I frankly > don't understand when to use /Transfer/ instead of /TransferThis/, or > why some references parameters have a /In/ and others a /Out/ or > whatever. If anybody can actually explain, that would be great. In any > event, I am hopeful that the structure of the rules engine [4] will > make this tractable, but I'd really prefer not to blindly match what I > see in PyKDE4!!!
This is great. I did take a run at using twine2 and never got anywhere with it either. Due to the Kf5, Plasma, Applications split, I would strongly recommend not calling what you're doing PyKDE5 as KDE5 is not a thing. I'd suggest starting with binding the Kf5 modules and calling that PyKf5. Scott K
