'Re: [Kde-bindings] Progress report on Py*5 binding generation'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: kde-bindings
Subject: Re: [Kde-bindings] Progress report on Py*5 binding generation
From: Shaheed Haque <srhaque () theiet ! org>
Date: 2016-05-01 10:52:20
Message-ID: CAHAc2jcLgDBk47RLtv-OWm4G1ozMp_nj73Ez4y=LDPOoFaoP8A () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

BTW, I just went looking for
https://github.com/steveire/extra-cmake-modules/commits/generate-python-bindings,
but I guess I should be looking here at
https://github.com/steveire/frameworks-bindings instead, right?

On 1 May 2016 at 11:47, Stephen Kelly <steveire@gmail.com> wrote:

> Shaheed Haque wrote:
>
> > Steve,
> >
> > 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.
>
> Sounds great!
>
> >
> > 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.
>
> Cool. I don't think there's generally urgency - there has not been KF5
> bindings for years (and it surprised me to learn that actually). However,
> collaborating in one repo and one way forward would be better than two.
>
> > 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.
>
> Cool. I saw things related to KConfigSkeleton and KLocalizedString which
> are
> presumably useful to make real bindings. So far, I've just discarded those
> in the bindings I've made.
>
> I also filed
>
>  https://phabricator.kde.org/T2389
>
> for tracking by the CI team.
>
> Thanks,
>
> Steve.
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings@kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>

[Attachment #5 (text/html)]

<div dir="ltr">BTW, I just went looking for <a \
href="https://github.com/steveire/extra-cmake-modules/commits/generate-python-bindings \
">https://github.com/steveire/extra-cmake-modules/commits/generate-python-bindings</a>, \
but I guess I should be looking here at <a \
href="https://github.com/steveire/frameworks-bindings">https://github.com/steveire/frameworks-bindings</a> \
instead, right? </div><div class="gmail_extra"> <div class="gmail_quote">On 1 \
May 2016 at 11:47, Stephen Kelly &lt;<a \
href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>&gt; \
wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">Shaheed Haque wrote: 
&gt; Steve, 
&gt; 
&gt; I&#39;ve still not yet had a chance to catch up with all your good works, \
but &gt; I have just pushed what I consider usable %MethodCode injection [1]. \
This &gt; includes a naive forward port of the PyKDE4 %MethodCode fragments. \
The &gt; documentation is updated too. With luck this should provide a good 
&gt; template for other forms of code injection. %TypeCode is the obvious next 
&gt; target, and with that in place, I think we&#39;ll have all the logic in \
place &gt; to support most anything PyKDE4 could do but in a sustainable \
manner. 
Sounds great! 
 
&gt; 
&gt; I&#39;m still in a bit of a crunch time here for the next few weeks, but \
will &gt; try to make time to look at your fork and maybe %TypeCode. 
 
Cool. I don&#39;t think there&#39;s generally urgency - there has not been \
KF5 bindings for years (and it surprised me to learn that actually). However, 
collaborating in one repo and one way forward would be better than two. 
 
&gt; FWIW, the naive forward port of the PyKDE4 fragments is more or less a 
&gt; simple import of the original code, and this clearly does not apply in 
&gt; many cases. What is there is intended more as a demonstration of the 
&gt; techniques of using either fixed strings, or functions to generate the 
&gt; custom code needed. 
 
Cool. I saw things related to KConfigSkeleton and KLocalizedString which \
are presumably useful to make real bindings. So far, I&#39;ve just discarded \
those in the bindings I&#39;ve made. 
 
I also filed 
 
 <a href="https://phabricator.kde.org/T2389" rel="noreferrer" \
target="_blank">https://phabricator.kde.org/T2389</a> 
for tracking by the CI team. 
<div class="HOEnZb"><div class="h5"> 
Thanks, 
 
Steve. 
_______________________________________________ 
Kde-bindings mailing list 
<a href="mailto:Kde-bindings@kde.org">Kde-bindings@kde.org</a> 
<a href="https://mail.kde.org/mailman/listinfo/kde-bindings" rel="noreferrer" \
target="_blank">https://mail.kde.org/mailman/listinfo/kde-bindings</a> \
</div></div></blockquote></div> </div>

[Attachment #6 (text/plain)]

_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings

[prev in list] [next in list] [prev in thread] [next in thread] 