[Kde-bindings] A new attempt on PyKDE5 binding generation

[Shaheed Haque]

I've no idea how the Ruby bindings are done and I don't plan to look
at them at this time. Presumably anybody who wants could take the same
approach I am (and maybe even the code as a starting point).

On 31 March 2016 at 22:13, Mathieu <somekool at gmail.com> wrote:
> Can we hope for a ruby-kf5?
>
> Sent with Unibox
>
>
> On Mar 27, 2016, at 10:45 AM, Scott Kitterman <kde at kitterman.com> wrote:
>
> 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
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
>
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>