[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bindings
Subject: Re: [Kde-bindings] Hacking moc-generated code
From: Eric Jardim <ericjardim () gmail ! com>
Date: 2005-09-09 14:34:51
Message-ID: 432ec6c50509090734310c6d93 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
2005/9/9, Richard Dale <Richard_Dale@tipitina.demon.co.uk>:
>
> Yes, that looks familiar. To emit signals from python you need to
> dynamically
> add python methods for each signal, which in turn call
> QMetaObject::activated() once they have converted their python args to
> C++.
Well, this is not necessary, but this is the more natural way. We can create
a single "emit" method. But we need to somehow register the signal on the
MetaObject, so there might be a "registerSignal" method too.
Different from SIP/PyQt, there is no distinction from Python and C++
signals. This is very good.
I read about Boost::Python, and I'm not sure if the approach of manually
> defining wrapper code for every method and class will scale for a library
> the
> size of Qt/KDE with about 10000 classes and over 25000 methods.
10000!?! I taught that it was 400 from Qt and a few other from KDE ;) But
you are not obligated to do it manually. I prefer doing it manually to
understand each the nuances of the bind.
Manually, at the end, you get a more "pythonic" bind of the Qt (and so KDE)
library. Actually, there is a tool called Pyste, that you write Python code
that will wrap the C++ classes. But it is not 100% automatic.
But after I got enough "know-how", it will be possible to create some
scripts to extract the interface. But Pyste itself is not enough the get the
result that I want. Probably I will need to tweak it and create my custom
Pyste.
I think you
> might find you need to autogenerate the boost python wrapper code, at
> which
> point it might have been better to start from scratch with a Qt specific
> tool
> which knew about Qt memory management policies and calling conventions.
Sure, that's just what I said.
It will be interesting to compare with the python/SIP with Boost::Python,
> and
>
with perl/ruby Smoke approaches being using at the moment.
>
I don't understand what is Smoke. Sorry, I am new at this KDE bindings ;)
But if it give us a standard infra-structure to bind the Qt/KDE, we could
even interoperate between bindings languages!
That's it,
[Eric Jardim]
[Attachment #5 (text/html)]
2005/9/9, Richard Dale <<a \
href="mailto:Richard_Dale@tipitina.demon.co.uk">Richard_Dale@tipitina.demon.co.uk</a>>:<div><span \
class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Yes, that \
looks familiar. To emit signals from python you need to dynamically<br>add python \
methods for each signal, which in turn call<br>QMetaObject::activated() once they \
have converted their python args to C++.</blockquote> <div><br>
Well, this is not necessary, but this is the more natural way. We can
create a single "emit" method. But we need to somehow register the
signal on the MetaObject, so there might be a "registerSignal" method
too.<br>
<br>
Different from SIP/PyQt, there is no distinction from Python and C++ signals. This is \
very good.<br> </div><br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I read about Boost::Python, and I'm \
not sure if the approach of manually<br>defining wrapper code for every method and \
class will scale for a library the <br>size of Qt/KDE with about 10000 classes and \
over 25000 methods. </blockquote><div><br> 10000!?! I taught that it was 400 from Qt \
and a few other from KDE ;) But you are not obligated to do it manually. I prefer \
doing it manually to understand each the nuances of the bind. <br>
<br>
Manually, at the end, you get a more "pythonic" bind of the Qt (and so
KDE) library. Actually, there is a tool called Pyste, that you write
Python code that will wrap the C++ classes. But it is not 100%
automatic.<br>
<br>
But after I got enough "know-how", it will be possible to create some
scripts to extract the interface. But Pyste itself is not enough the
get the result that I want. Probably I will need to tweak it and create
my custom Pyste.<br>
</div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think you<br>might find you need to \
autogenerate the boost python wrapper code, at which<br> point it might have been \
better to start from scratch with a Qt specific tool<br>which knew about Qt memory \
management policies and calling conventions.</blockquote><div><br> Sure, that's just \
what I said. </div><br><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It will be \
interesting to compare with the python/SIP with Boost::Python, and <br>
</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">with perl/ruby Smoke \
approaches being using at the moment.<br></blockquote></div> <br>
I don't understand what is Smoke. Sorry, I am new at this KDE bindings ;) <br>
<br>
But if it give us a standard infra-structure to bind the Qt/KDE, we could even \
interoperate between bindings languages!<br> <br>
That's it,<br>
<br>
[Eric Jardim]<br>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic