<div dir="ltr"><div><div>Steve,<br><br></div>I've still not yet had a chance to catch up with all your good works, but I have just pushed what I consider usable %MethodCode injection [1]. This includes a naive forward port of the PyKDE4 %MethodCode fragments. The documentation is updated too. With luck this should provide a good template for other forms of code injection. %TypeCode is the obvious next target, and with that in place, I think we'll have all the logic in place to support most anything PyKDE4 could do but in a sustainable manner.<br><br></div>I'm still in a bit of a crunch time here for the next few weeks, but will try to make time to look at your fork and maybe %TypeCode.<br><div><br></div><div>FWIW, the naive forward port of the PyKDE4 fragments is more or less a simple import of the original code, and this clearly does not apply in many cases. What is there is intended more as a demonstration of the techniques of using either fixed strings, or functions to generate the custom code needed. In support of this, the sip_bulk_generator has a new option which can be used to identify rules which have not fired, and likely need to be rethought.<br></div><div><br></div><div>Thanks, Shaheed<br></div><div><br>[1] <a href="http://commits.kde.org/pykde5/86e8bdb1ac3e5245cea7c9191c8fbc09dc958066">http://commits.kde.org/pykde5/86e8bdb1ac3e5245cea7c9191c8fbc09dc958066</a><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 30 April 2016 at 14:42, Stephen Kelly <span dir="ltr"><<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Shaheed Haque wrote:<br>
<br>
> +1 for the modular CMake-based stuff.<br>
><br>
> If you can get that going without all the sip_bulk_generator stuff, then<br>
> that is great,<br>
<br>
</span>Cool. I have completed some more work on particular frameworks and I created<br>
a cmake build for convenience:<br>
<br>
<a href="https://github.com/steveire/frameworks-bindings" rel="noreferrer" target="_blank">https://github.com/steveire/frameworks-bindings</a><br>
<br>
Build it all with<br>
<br>
$ mkdir build && cd build<br>
$ cmake ..<br>
$ make<br>
<br>
$ ls prefix/lib/python3.5/dist-packages/PyKF5/<br>
__init__.py KAuth.so KCodecs.so KCompletion.so KConfigCore.so<br>
KConfigGui.so KConfigWidgets.so KCoreAddons.so KDBusAddons.so<br>
KGuiAddons.so KI18n.so KItemModels.so KJobWidgets.so KWidgetsAddons.so<br>
<br>
I still haven't written tests for the generated python modules yet. There<br>
are still some things to do before getting to that (namely integrating your<br>
MethodCode work).<br>
<span class=""><br>
> I'm more focussed on getting through the volume of errors<br>
> through automation because of the weaknesses in the Clang automation.<br>
<br>
</span>I also made some changes to how the clang cindex stuff is used in the<br>
sip_generator.py and in the rules_engine.py. I will soon integrate your work<br>
on %MethodCode injection into the extra-cmake-modules version of the code.<br>
That should actually make the bindings actually useful, because up to now I<br>
have been<br>
<br>
I encourage you to have a look at what is in the extra-cmake-modules and<br>
other repos in the mean-time. I have modularized the rules and made it<br>
possible to re-use the generic Qt5 rules in the modules, but in a bit of a<br>
hacky way. I think more refactoring should be done on the sip_generator and<br>
rules to make that kind of thing more of an integral part of the design.<br>
<br>
However, I don't want to do major refactoring of the version in the extra-<br>
cmake-modules repo while you are still changing the version in the pykde5<br>
repo.<br>
<br>
It would be better to not have divergent versions of the generator. Can I<br>
somehow convince you to continue your work with the modularized approach?<br>
That would eliminate the work created by having divergent versions, and<br>
would mean that we are creating modularized bindings, which I think we agree<br>
are desirable? It will result in shippable bindings quite quickly as far as<br>
I can see.<br>
<div class="HOEnZb"><div class="h5"><br>
Thanks,<br>
<br>
Steve.<br>
_______________________________________________<br>
Kde-bindings mailing list<br>
<a href="mailto:Kde-bindings@kde.org">Kde-bindings@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-bindings" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-bindings</a><br>
</div></div></blockquote></div><br></div>