Re: End of 2016 update on PyKF5 bindings

HI Steve,

I closed two of the reviews based on testing KDE/master. That leaves
only https://git.reviewboard.kde.org/r/129763/: this should be
non-controversial as it removes a functional no-op which just gets ion
the way of my stuff, so please take a look at it when you can.

In the meantime, I will rebase onto ECM KDE/master (I see you have
been busy!) and hopefully we can get stuff merged once I have
something for you to look at.

Thanks, Shaheed



On 15 January 2017 at 14:23, Stephen Kelly <[email protected]> wrote:
> Shaheed Haque wrote:
>
>> The three main areas I know I need to cover before I can declare the
>> rules database formats good enough that the risk of change seems small
>> are:
>>
>> - Almost arbitrary edits to all structures that clang emits.
>> - Automated support for templated types such as QMap and QHash
>> (%MappedType et. al.).
>> - See what, if anything, can be done to automate %ConvertToSubclassCode.
>>
>> The first is in very good shape as of a few days ago. The second (as
>> of this morning) produces code that can be imported by Python. The
>> third is not yet started (though Phil from PyQt-land has pointed me at
>> some sample code he has).
>
> Sounds great.
>
> Here is the state of things from my point of view:
>
>  * All of the bindings for individual frameworks repos that I had so far in
> my github are now in the kde repos.
>  * The bindings in the frameworks repos are getting released and packaged,
> which means they will get to users
>  * As far as I know, the most pressing packaging related issues are
> resolved: https://phabricator.kde.org/T5016
>
> However, some of the bindings discard certain functions because the sip
> generator in ECM is missing some features. For example, KCompletion has
> rules like
>
>  ["KCompletionBase", "keyBindingMap", ".*", ".*", ".*",
> rules_engine.function_discard],
>
> because that method uses QMap etc. So, your further work on the type
> mapping, once it is in ECM, should allow reinstating those functions.
>
> Another example is that the kconfig bindings are in, but the
> ConvertToSubclassCode stuff you mentioned above is not present, so perhaps
> the behavior on the python side is not everything a user would expect. I'm
> just guessing about that. If anything from your investigation there should
> go to ECM, then that can be done too to improve the bindings.
>
> The repo at https://github.com/steveire/frameworks-bindings is now using
> only kde clones and tests all frameworks which have bindings so far.
>
> So, with the goal of getting more bindings into users hands and making them
> more useful, I think there are two orthogonal things to do:
>
>  * Add rules to more frameworks repos as I have been doing
>  * Extend the set of features in the ECM repo to make better bindings
> possible
>
> If you have suggestions for additional frameworks repos to add bindings to,
> I'd be interested to know.
>
> Thanks,
>
> Steve.