[Kde-bindings] PyKDE5 current status

[Simon Edwards]

[I'm moving this discussion on to the kde-bindings mailing list.]

Hi,

Well done Luca. I'm guessing that SIP has been changed recently. The 
typedefs.sip isn't a real module, it just needs to be included in many 
different places.

cheers,
Simon


On 2015-03-31 23:06, Luca wrote:
> Hi Simon,
> good news, I got it working with the original files from git:
> Attached the patch I created, now I'm able to load the library without
> problem.
> 
> I have to try with my custom .sip build, to see how to build it with 
> this
> changes included.
> 
> Regards,
> 	Luca
> 
> In data martedì, 31 marzo 2015 08.23:27, hai scritto:
>> Hi,
>> 
>> On 2015-03-30 22:28, Luca wrote:
>> > thank you, I was able to build PyKDE5 against the new framework 5.8.0
>> > I had to modify the twine2 scripts (toolbox.py) in order to make it
>> > works.
>> > I encountered lot of issues that I had to fix manually with "//ig".
>> > I tried to build kauth without success, during compiling I god some
>> > strange
>> > errors with sip.
>> > I'm new to sip and fixing them is hard for me.
>> 
>> It sounds like you are making progress. :-) Just remember that PyKDE 
>> is
>> one of the biggest (counting classes etc) bindings projects on the
>> planet.
>> 
>> > Everything fine, except the fact that I continue to have this error:
>> > <<< from PyKDE5.kcoreaddons import kaboutdata
>> >
>> > Traceback (most recent call last):
>> >   File "<stdin>", line 1, in <module>
>> >
>> > ImportError: No module named 'PyKDE5.typedefs'
>> 
>> mmm... May be something changed in later versions of SIP. What you 
>> could
>> try is to open up CMakeLists.txt and add a 'typedefs' module to the
>> build like the other normal modules. May be building a typedefs, even 
>> if
>> it is empty, is enough to get it working.
>> 
>> > What blocked you during building kauth, kconfig and kjs?
>> 
>> I can't remember about kauth. kconfig was pushed down the list mainly
>> because it is a real pain to do. IIRC, the C++ uses a ton of templates
>> etc which have to be manually translated to something reasonable. In
>> this case it might be better to think up something smarter than just
>> trying to map the C++ API 1:1.
>> 
>> I didn't see much of a use case for wrapping kjs. (Doesn't Qt have a
>> different JS engine or two?)
>> 
>> > there is other kf5 modules, do you consider them? (like ki18n, and
>> > other from
>> > https://community.kde.org/Frameworks/Building/Details)
>> 
>> I've stayed mainly with the core ones because of time really. But yes,
>> there are a heap of them around these days.
>> 
>> cheers,

-- 
Simon Edwards
simon at simonzone.com
Nijmegen, The Netherlands