Introducing Project Phoenix
Robin Dunn
As promised I've published some information about what I am calling
Project Phoenix, also known as the new way to produce the wxPython
wrappers that myself and others have been hinting about for a couple
years now. I've moved a few of my local documents about it up to the
wiki, which list some goals of the project and also a very high level
view of the methodology that I think will be the way to move forward.
I've done some work already on the tools and I will commit them to the
repository once I get an end-to-end test working, hopefully in the next
few days. For now you can read these pages to get a better feel for
what I have in mind.
http://wiki.wxpython.org/ProjectPhoenix
Comments on those pages are welcome, but I think I would prefer to have
discussions here in the mail list for detailed questions, suggestions or
answers.
--
Robin Dunn
Software Craftsman
http://wxPython.org
Aloys Baillet
Quite nice to see this work planned!
I've spent some time binding C++ code in Python, and used both SWIG, SIP and Boost::Python, and I must say I found Boost::Python to be the cleanest and easiest to use. You can link statically against the library, so wrapped types don't bleed out.
Nokia is currently using it for their own version of PyQt (PySide: http://www.pyside.org ), and Py++ uses it as well to generate bindings automatically ( http://www.language-binding.net/pyplusplus/pyplusplus.html )
Good luck with the transition!
Cheers,
Aloys
--
To unsubscribe, send email to wxPython-dev...@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en
--
Aloys Baillet
Lead Software Developer
--
Robin Dunn
> Hi,
>
> Quite nice to see this work planned!
> I've spent some time binding C++ code in Python, and used both SWIG, SIP
> and Boost::Python, and I must say I found Boost::Python to be the
> cleanest and easiest to use. You can link statically against the
> library, so wrapped types don't bleed out.
> Nokia is currently using it for their own version of PyQt (PySide:
> http://www.pyside.org ), and Py++ uses it as well to generate bindings
> automatically ( http://www.language-binding.net/pyplusplus/pyplusplus.html )
>
I've looked at Boost::Python and Py++ a little in the past, but I was a
bit put off by the heavy use of templates, and gcc-xml/pygccxml were
still fairly new and seemed a little flaky at the time. I'll take
another look however.
> Good luck with the transition!
>
Thanks.
Aloys Baillet
It also seems that Nokia gave up on Boost Python and wrote their own binding generator: http://developer.qt.nokia.com/wiki/PySide_Binding_Generator
Not sure why they did that, but maybe worth checking as well...
Cheers,
Aloys
--
To unsubscribe, send email to wxPython-dev...@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en
Jonathan Morgan
> Hi all,
>
> As promised I've published some information about what I am calling
> Project Phoenix, also known as the new way to produce the wxPython
> wrappers that myself and others have been hinting about for a couple
> years now. I've moved a few of my local documents about it up to the
> wiki, which list some goals of the project and also a very high level
> view of the methodology that I think will be the way to move forward.
> I've done some work already on the tools and I will commit them to the
> repository once I get an end-to-end test working, hopefully in the next
> few days. For now you can read these pages to get a better feel for
> what I have in mind.
>
> http://wiki.wxpython.org/ProjectPhoenix
>
> Comments on those pages are welcome, but I think I would prefer to have
> discussions here in the mail list for detailed questions, suggestions or
> answers.
After reading through the Wiki pages the main question I would have
is: What is the future for contrib packages that do not use the
documentation standards of wxWidgets? I noticed a mention of removing
gizmos (which I have never used), but I think for example that the
styled text control gets used more, and from memory is even part of
PyCrust, which I use.
I also have very, very rough bindings of wxWebConnect which are
certainly not ready for contrib at the moment, but which I think could
theoretically be useful in contrib one day iff it was well supported
for Windows, Linux and Mac (well, better than wxHTML, anyway).
Whether or not it were in contrib I would still want to build it, and
wxWebConnect doesn't have a lot in the way of header documentation.
Jon
Robin Dunn
> On Oct 27, 11:37 am, Robin Dunn<ro...@alldunn.com> wrote:
>> Hi all,
>>
>> As promised I've published some information about what I am calling
>> Project Phoenix, also known as the new way to produce the wxPython
>> wrappers that myself and others have been hinting about for a couple
>> years now. I've moved a few of my local documents about it up to the
>> wiki, which list some goals of the project and also a very high level
>> view of the methodology that I think will be the way to move forward.
>> I've done some work already on the tools and I will commit them to the
>> repository once I get an end-to-end test working, hopefully in the next
>> few days. For now you can read these pages to get a better feel for
>> what I have in mind.
>>
>> http://wiki.wxpython.org/ProjectPhoenix
>>
>> Comments on those pages are welcome, but I think I would prefer to have
>> discussions here in the mail list for detailed questions, suggestions or
>> answers.
>
> After reading through the Wiki pages the main question I would have
> is: What is the future for contrib packages that do not use the
> documentation standards of wxWidgets? I noticed a mention of removing
> gizmos (which I have never used), but I think for example that the
> styled text control gets used more, and from memory is even part of
> PyCrust, which I use.
STC has been moved to wxWidgets core in 2.9, so it is safe. The mention
of removing gizmos is because the code itself is not maintained, not
because its documentation is substandard.
>
> I also have very, very rough bindings of wxWebConnect which are
> certainly not ready for contrib at the moment, but which I think could
> theoretically be useful in contrib one day iff it was well supported
> for Windows, Linux and Mac (well, better than wxHTML, anyway).
> Whether or not it were in contrib I would still want to build it, and
> wxWebConnect doesn't have a lot in the way of header documentation.
The new method will not prevent creating the bindings generator code by
hand, it simply automates most of the work in creating that code if the
headers are able to be run through Doxygen.
Jonathan Morgan
But presumably if you decide to switch to SIP or some other bindings generator any such hand-written bindings will need to be changed.
Jon
Robin Dunn
> But presumably if you decide to switch to SIP or some other bindings
> generator any such hand-written bindings will need to be changed.
>
Yes, although even if I stay with SWIG some changes would still have to
be made.
Christopher Barker
> As promised I've published some information about what I am calling
> Project Phoenix, also known as the new way to produce the wxPython
> wrappers that myself and others have been hinting about for a couple
> years now.
cool -- good stuff!
Some thoughts about Cython (which I am a big fan of):
1) There has been work done on auto-generating Cython code from header
files and/or XML. I don't think it's very mature, but may be worth a
look-see:
http://github.com/cournape/cython-codegen
(and there may be other efforts as well).
2) The C++ support seems to be under active development, and certainly
of interest to the core developers.
3) Cython does provide built-in support for the new buffer interface and
py3k, which should help.
What I like about Cython (and Pyrex) is that it was designed to write C
extensions, rather than specifically as a wrapping tool. What this means
is that it is easy to write interface code when that is required. wx has
a lot of special code in SWIG to handle the C++/Python conversions, that
sort of stuff should be a lot easier in Cython. With SWIG (or Ctypes),
if there is a direct map from Python to C, it works great, but when you
need some real code in the interface, it gets a lot harder to write that
so that it's efficient.
Of course, I'm really pushing Cython because a major wrapping project
like wx would really help move Cython forward to be a more mature
wrapping tool, and I's like that because I think it is already
hands-down the best way to write custom extensions.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Amaury Forgeot d'Arc
On 10/26/10 5:37 PM, Robin Dunn wrote:
>
> As promised I've published some information about what I am calling
> Project Phoenix, also known as the new way to produce the wxPython
> wrappers that myself and others have been hinting about for a couple
> years now.
About replacing SWIG, do the other wrapping tools support the
features that I like in wxPython:
1 - cross-language polymorphism:
the ability to inherit from a C++ class in Python, and implement
virtual methods in Python code.
2 - Original Object Return:
For example, in event callbacks, event.GetWindow() returns the same python
object I created earlier in my code; not a copy, not a structure containing the
same handle. All the custom attributes are still there - very important
in a derived class!
These two features allow the programmer to use objects, not IDs like with
other toolkits.
3 - separate compilation:
Sometimes it's not possible to use Python code and you need to
customize a wxWidget class in C++: for example some time ago I
subclassed wxComboBox at the time there was no owner-drawn option.
With SWIG it's possible to wrap this customized class, compile a new
extension module and obtain a new (Python) subclass of wx.ComboBox,
that you can use everywhere a combo box is expected to work.
We also implemented a complex wx.Sizer which was initially slow
in Python, and that we rewrote in C++ for performance. Of course from
Python code it was accessible and usable just like a wx.GridSizer.
I remember that this last feature was the reason why we chose the
wxPython framework - even if wxWidgets does not have some control
or some event handler, with little work you can extend the system
and have it in wxPython -- without asking Robin!
Cheers,
--
Amaury Forgeot d'Arc
Robin Dunn
> Hi,
>
> On 10/26/10 5:37 PM, Robin Dunn wrote:
>>
>> As promised I've published some information about what I am calling
>> Project Phoenix, also known as the new way to produce the wxPython
>> wrappers that myself and others have been hinting about for a couple
>> years now.
>
> About replacing SWIG, do the other wrapping tools support the
> features that I like in wxPython:
I'll answer just for SIP since that is the non-SWIG tool that I'm most
familiar with at the moment.
>
> 1 - cross-language polymorphism:
> the ability to inherit from a C++ class in Python, and implement
> virtual methods in Python code.
SIP: Yes.
When I first started making it possible to do that with wxPython, SWIG
either didn't have the "directors" feature yet, or it was still brand
new and had a bad reputation for causing more problems than it solved.
So I implemented my own hand-written code to do it, and it grew into an
ugly, wart-infested mess that is difficult to use and to maintain. With
SIP it looks like it was designed from the start to support reflecting
virtual method calls down to the Python class (if it was overridden
there) and to be efficient about it. To be fair it looks like the
directors feature in the newest SWIG is better than the last time I
looked at it and so if I stay with SWIG I will switch to using directors
in Phoenix instead of my old kludges.
>
> 2 - Original Object Return:
> For example, in event callbacks, event.GetWindow() returns the same python
> object I created earlier in my code; not a copy, not a structure containing the
> same handle. All the custom attributes are still there - very important
> in a derived class!
SIP: Yes
I still need to do some verification of this but it looks like it is a
built-in feature of SIP's runtime library and won't have to be a hack
that I add on myself like I did with SWIG. And since it's built-in we
should be able to make it work for every wrapped type and not just
windows, sizers and a few others that have a user data pointer that I'm
able to hijack.
>
> These two features allow the programmer to use objects, not IDs like with
> other toolkits.
>
> 3 - separate compilation:
> Sometimes it's not possible to use Python code and you need to
> customize a wxWidget class in C++: for example some time ago I
> subclassed wxComboBox at the time there was no owner-drawn option.
> With SWIG it's possible to wrap this customized class, compile a new
> extension module and obtain a new (Python) subclass of wx.ComboBox,
> that you can use everywhere a combo box is expected to work.
> We also implemented a complex wx.Sizer which was initially slow
> in Python, and that we rewrote in C++ for performance. Of course from
> Python code it was accessible and usable just like a wx.GridSizer.
Yes, this ability is not something that I would be willing to lose, so
no matter what is chosen it will still be possible to add other
extension modules that are able to fully integrate with the wxPython
extension modules. You may have to change how you implement the
wrappers for your C++ class, but it will be possible to do.
Luke McCarthy
deleted C++ objects. If I subclass wx.Window and the C++ object for
the window is deleted, accessing any Python attributes raises
PyDeadObjectError, even though the Python object still exists. I would
prefer it if PyDeadObjectError is only raised when calling a C++
method.
Nat Echols
Luke McCarthy
destroyed after CallAfter is called, but before the CallAfter event is
handled by the event loop. If the method does not call any wxWidgets
methods, I don't see why it shouldn't work...
Jonathan Morgan
if control:
control.Method()
Of course, you can only do this at places where you know there is an error (I don't want to do it everywhere).
Jon
Brendan
"better, stronger, faster" ... and lighter.
This may not be the most important issue for wxPython, but currently
creating a very simple app (using Py2App on OS X) generates a very
large application (> 40 MB as an app bundle, > 14 MB when distributed
in a dmg !!).
It seems the main culprits are:
21M ./myapp/Contents/Frameworks/libwx_macud-2.8.0.dylib
11M ./myapp/Contents/Resources/lib/python2.5/lib-dynload/wx/
It would be great if the libraries can be split so that only the
necessary libraries are included in py2app (and others such as py2exe,
etc).
Can Phoenix help produce lighter bundles ?? Maybe this is more a
wxWidgets or py2* issue ??
Cheers, Brendan.
Mike Driscoll
I'm all for a rebirth and a new generation of wxPython hopefully much
"better, stronger, faster" ... and lighter.
This may not be the most important issue for wxPython, but currently
creating a very simple app (using Py2App on OS X) generates a very
large application (> 40 MB as an app bundle, > 14 MB when distributed
in a dmg !!).
It seems the main culprits are:
21M ./myapp/Contents/Frameworks/libwx_macud-2.8.0.dylib
11M ./myapp/Contents/Resources/lib/python2.5/lib-dynload/wx/
It would be great if the libraries can be split so that only the
necessary libraries are included in py2app (and others such as py2exe,
etc).
Can Phoenix help produce lighter bundles ?? Maybe this is more a
wxWidgets or py2* issue ??
Cheers, Brendan.
Maybe it's just a py2app thing. My py2exe programs are never 40 MB or greater. I usually get around 14-18 MB. I wrote an article about it here: http://www.blog.pythonlibrary.org/2010/07/31/a-py2exe-tutorial-build-a-binary-series/
Mike Driscoll
Blog: http://blog.pythonlibrary.org
Christopher Barker
> On Sun, Oct 31, 2010 at 5:40 PM, Brendan <brenda...@gmail.com
> <mailto:brenda...@gmail.com>> wrote:
> It would be great if the libraries can be split so that only the
> necessary libraries are included in py2app (and others such as py2exe,
> etc).
>
> Can Phoenix help produce lighter bundles ?? Maybe this is more a
> wxWidgets or py2* issue ??
> Maybe it's just a py2app thing. My py2exe programs are never 40 MB or
> greater. I usually get around 14-18 MB.
Well, yes and no -- The current standard builds of Python and wxPython
are "universal", so they have essentially completely duplicate binaries
-- PPC and Intel (there is also the possibility of 32 and 64 bit, for 4
total!). That explains much of why py2app binaries are bigger than
Windows binaries.
But even on Windows, 14-18MB is pretty big.
This has been discussed a lot in the past, and the short version is: it
could probably be done, but it would take a fair bit of work, the "core"
parts are still pretty big, and disk space is cheap these days
(bandwidth less cheap, but still cheap), so it hasn't been worth the
work to do it.
A good idea to keep in mind while developing a new binding system
thought. Perhaps "import wx" could really call a bunch of imports of
difference sub-parts of the library, and users building bundles could
choose to import only what they are using instead.
Robin Dunn
> On 10/31/10 6:13 PM, Mike Driscoll wrote:
>> On Sun, Oct 31, 2010 at 5:40 PM, Brendan <brenda...@gmail.com
>> <mailto:brenda...@gmail.com>> wrote:
>> It would be great if the libraries can be split so that only the
>> necessary libraries are included in py2app (and others such as py2exe,
>> etc).
>>
>> Can Phoenix help produce lighter bundles ?? Maybe this is more a
>> wxWidgets or py2* issue ??
>
>> Maybe it's just a py2app thing. My py2exe programs are never 40 MB or
>> greater. I usually get around 14-18 MB.
>
> Well, yes and no -- The current standard builds of Python and wxPython
> are "universal", so they have essentially completely duplicate binaries
> -- PPC and Intel (there is also the possibility of 32 and 64 bit, for 4
> total!). That explains much of why py2app binaries are bigger than
> Windows binaries.
I'm not sure that adding in the 64-bit PPC architecture is worth it as
the potential users of that combination seems to be dwindling fast. So
that would make it 3 architectures in the fat binaries, which is what is
in the current 2.9.1.1 cocoa build. That includes the wx shared library
and all the wxPython extension modules, so for comparable numbers take
the size of the DLLs and PYDs on Windows and multiply by three and that
add on some an additional percentage due to gcc creating somewhat less
efficient code (size as well as speed) than MSVC. You end up with about
the same numbers.
>
> But even on Windows, 14-18MB is pretty big.
Agreed.
>
> This has been discussed a lot in the past, and the short version is: it
> could probably be done, but it would take a fair bit of work, the "core"
> parts are still pretty big, and disk space is cheap these days
> (bandwidth less cheap, but still cheap), so it hasn't been worth the
> work to do it.
>
> A good idea to keep in mind while developing a new binding system
> thought. Perhaps "import wx" could really call a bunch of imports of
> difference sub-parts of the library, and users building bundles could
> choose to import only what they are using instead.
This thought has crossed my mind as well, although I haven't yet devoted
much brain cycles to it. Ideally it would be nice to have some sort of
on-demand import system where the module containing a class or function
is not imported until the application code tries to use that class or
function. For example, there is a class like wx.Point that uses
floating point values instead of integers, but it is very seldom used so
it is just wasting space in the current wx._core. With an on-demand
import that code could be in a separate extension module (say
geometry.[pyd|so] to match the C++ header file) and then when the
application tries to use wx.Point2D then the equivalent of "from
geometry import *" is done in the wx namespace.
I don't know if this is possible without adding too much overhead, or if
some other project as done something like this already that we could
borrow code from. If somebody wants to spend some time researching this
and experimenting with implementations I would open to trying to use it
in Phoenix.
Robin Dunn
> This thought has crossed my mind as well, although I haven't yet devoted
> much brain cycles to it. Ideally it would be nice to have some sort of
> on-demand import system where the module containing a class or function
> is not imported until the application code tries to use that class or
> function. For example, there is a class like wx.Point that uses floating
> point values instead of integers, but it is very seldom used so it is
> just wasting space in the current wx._core. With an on-demand import
> that code could be in a separate extension module (say geometry.[pyd|so]
> to match the C++ header file) and then when the application tries to use
> wx.Point2D then the equivalent of "from geometry import *" is done in
> the wx namespace.
>
> I don't know if this is possible without adding too much overhead, or if
> some other project as done something like this already that we could
> borrow code from. If somebody wants to spend some time researching this
> and experimenting with implementations I would open to trying to use it
> in Phoenix.
I should have Googled first:
http://code.activestate.com/recipes/473888-lazy-module-imports/
It would still be nice however to have some research and evaluation done
on this or other implementations to determine overhead and feasibility.
Robin Dunn
Jonathan Morgan
The two implementations are both intended to improve startup time (which I think would also be valuable), not reduce distributable size. Would these kinds of dynamic import confuse py2exe and similar tools and make it miss imports? (I've certainly had py2exe miss imports that were done in C rather than Python, which means the app just crashes when it hits the import). Would you actually be able to reduce distributable size? How would you know which bits to include and which bits to exclude? (if it were fine grained enough, I'm not sure you would have enough information to know easily).
Jon
Const
On Oct 26, 10:13 pm, Aloys Baillet <aloys.bail...@gmail.com> wrote:
> Quite nice to see this work planned!
> I've spent some time binding C++ code in Python, and used both SWIG, SIP and
> Boost::Python, and I must say I found Boost::Python to be the cleanest and
> easiest to use. You can link statically against the library, so wrapped
> types don't bleed out.
> automatically (http://www.language-binding.net/pyplusplus/pyplusplus.html)
Nokia's PySide (PyQt like bindings for Qt) no longer uses
Boost::Python. They have since switched to there own tool called
Shiboken.
http://developer.qt.nokia.com/wiki/PySide_Binding_Generator/
Maybe their work should be considered for Phoenix.
Const
Robin Dunn
The phrases "Robin Dunn" and "a handwritten XML document" have a hard
time coexisting in the same universe and have a tendency to be mutually
exclusive on the same project. ;-)
Brendan
> > Boost::Python. They have since switched to there own tool called
> > Shiboken.
>
> >http://developer.qt.nokia.com/wiki/PySide_Binding_Generator/
>
> > Maybe their work should be considered for Phoenix.
>
> The phrases "Robin Dunn" and "a handwritten XML document" have a hard
> time coexisting in the same universe and have a tendency to be mutually
> exclusive on the same project. ;-)
bindings. Somehow that just doesn't feel right for wxPython. Should
Qt libraries be treated just like any other library ?? I would think
something that is more GUI agnostic would be more suitable.
XML is a good intermediate format, but not the best for humans to be
editing and maintaining. If the XML can be generated from a tool and
is transparent to the maintainers then it should be ok. Having XML
output can be useful for generating many wonderful outputs :)
Christopher Barker
>> The phrases "Robin Dunn" and "a handwritten XML document" have a hard
>> time coexisting in the same universe and have a tendency to be mutually
>> exclusive on the same project. ;-)
>
> It looks like PySide requires Qt libraries to be installed to generate
> bindings. Somehow that just doesn't feel right for wxPython.
That's 'cause PySide IS a binding for QT.
The tool they are using (and developing) is Shiboken, which is not
QT-dependent or specific (though I don't know if any other projects are
using it).
And Shiboken requires you to write XML to define custom behavior of the
binding generator.
Any tool is going to require SOME way of defining specialized binding
needs -- is XML really worse that SWIG .i files? I don't know, but I'm
not doing the work.
> XML is a good intermediate format, but not the best for humans to be
> editing and maintaining. If the XML can be generated from a tool and
> is transparent to the maintainers then it should be ok. Having XML
> output can be useful for generating many wonderful outputs :)
Well Shiboken appears to auto-generate XML from the C++, but it used
hand-generated XML for anything that the auto-generator can't figure
out. I think Robin is considering other XML-based solutions (like the
XML from Doxygen, for instance), but, quite understandably, would rather
not hand-write XML.
Hugo Parente Lima
> On 11/15/10 3:54 AM, Brendan wrote:
>
> >> The phrases "Robin Dunn" and "a handwritten XML document" have a hard
> >> time coexisting in the same universe and have a tendency to be mutually
> >> exclusive on the same project. ;-)
I'm a PySide developer, another PySide developer saw this thread and
told us, now I'm here to try to clarify some doubts about how our
generator could be useful to wxPython.
The basic:
- Our generator depends on Qt, but the generated code *not*, so Qt
will be just a build dependency, *not* a runtime dependency.
- We support most things you expect from a Python C++ binding, virtual
methods, type discovery, object parenting, implicity conversions,
etc.. I could explain each item in a later email if needed.
- The generated bindings will need to link to just two libraries:
libshiboken.so and the library being binded.
- libshiboken depends only from libpython.so
- Our generated bindings works on Linux (g++), Windows (msvc) and
MacOS (g++).
- libshiboken is LGPL, so you can use it even to create proprietary
bindings if you want so.
How it works?
You need two things, the headers of the library you want to bind and
a XML file telling the generator what classes and functions to create
the bindings.
The infamous handwritten XML file (typesystem)
If the class have nothing unusual, you just need a single entry to
say "Generator, bind this class and all methods found!"
Something like:
<object-type name="Foo" />
With the class list in your hands you can create a basic typesystem
file without much work. Ok, XML is not the better format in the world
and our format inherited from QtJambi generator trully isn't either,
but IMO isn't much different from a pseudo C++ header file with a lot
of strange annotations. We tought about create a tool to edit the XML
files very often but we did never had time to do a real good
typesystem editor :-/
Ah, we dropped boost::python because the generated bindings were too
large, boost::python is a tool to integrate Python scripting into a C+
+ application not a tool to create Python bindings for a entire
library, if you choose boost::python I'm sure that you will achieve a
useful result very fast but will end up dropping it like us due to the
size of the bindings and difficult to do complex things... We dropped
other options, including SWIG and Cython, due to the lack of features
needed by us.
Any questions?
Robin Dunn
> Any tool is going to require SOME way of defining specialized binding
> needs -- is XML really worse that SWIG .i files? I don't know, but I'm
> not doing the work.
One of the nice things about how Phoenix works (well, "mostly works"
currently) is that all the customization of what the back-end bindings
generator will see will be done by Python code. For example:
c = module.find('wxMouseState')
c.find('GetPosition').findOverload('int *x').ignore()
c.addProperty("x GetX SetX")
c.addProperty("y GetY SetY")
c.addProperty("leftIsDown LeftIsDown SetLeftDown")
c.addProperty("middleIsDown MiddleIsDown SetMiddleDown")
c.addProperty("rightIsDown RightIsDown SetRightDown")
c.addProperty("aux1IsDown Aux1IsDown SetAux1Down")
c.addProperty("aux2IsDown Aux2IsDown SetAux2Down")
c.addProperty("Position GetPosition SetPosition")
That is almost all I have to write for the wxMouseState class,
everything else is being done automatically.
What is produced from this could just as easily be XML as it could be
SWIG or SIP code or code for some other tool, but I'm also taking into
consideration how easy it is to verify "by hand" that output in order to
make it easy as possible to track down problems. IOW, if there is an
issue is it a problem with the back-end tool, the stuff fed to the
back-end tool by the Phoenix tools, the Phoenix tools, or the input that
is fed to Phoenix? So having something more readable and more easily
parsed by an ordinary humans than XML is IMO a positive feature. It's
not as important as what are the capabilities and quality of the
back-end generator, but IMO it's nearly there.
>
>> XML is a good intermediate format, but not the best for humans to be
>> editing and maintaining. If the XML can be generated from a tool and
>> is transparent to the maintainers then it should be ok. Having XML
>> output can be useful for generating many wonderful outputs :)
>
> Well Shiboken appears to auto-generate XML from the C++, but it used
> hand-generated XML for anything that the auto-generator can't figure
> out. I think Robin is considering other XML-based solutions (like the
> XML from Doxygen, for instance),
I've already got the code done for pulling the info we need from the
Doxygen XML. It has worked out quite well, and was lots easier than I
anticipated.
Robin Dunn
> On Nov 15, 4:54 pm, Christopher Barker<Chris.Bar...@noaa.gov> wrote:
>> On 11/15/10 3:54 AM, Brendan wrote:
>>
>>>> The phrases "Robin Dunn" and "a handwritten XML document" have a hard
>>>> time coexisting in the same universe and have a tendency to be mutually
>>>> exclusive on the same project. ;-)
>
> Hi list
>
> I'm a PySide developer, another PySide developer saw this thread and
> told us, now I'm here to try to clarify some doubts about how our
> generator could be useful to wxPython.
Thanks for the info Hugo.
>
> The basic:
>
> - Our generator depends on Qt, but the generated code *not*, so Qt
> will be just a build dependency, *not* a runtime dependency.
This is still somewhat of an unfortunate burden, at least in my opinion.
Most of my development machines do not have Qt installed and it seems
kinda silly if my only need for installing it is in order to make
bindings for a *different* UI library.
> - We support most things you expect from a Python C++ binding, virtual
> methods, type discovery, object parenting, implicity conversions,
> etc.. I could explain each item in a later email if needed.
> - The generated bindings will need to link to just two libraries:
> libshiboken.so and the library being binded.
> - libshiboken depends only from libpython.so
> - Our generated bindings works on Linux (g++), Windows (msvc) and
> MacOS (g++).
> - libshiboken is LGPL, so you can use it even to create proprietary
> bindings if you want so.
>
> How it works?
>
> You need two things, the headers of the library you want to bind and
> a XML file telling the generator what classes and functions to create
> the bindings.
One problem I have with using the library headers directly is that there
are a number of things in the wx headers that are implementation details
and not meant to be used directly by the library users, and so
preferably should not be referenced in the language bindings modules at
all. Not in the API presented to the Python programmer, nor in the C++
wrapper code. For example, given this class hierarchy:
wxEvtHandler <-- wxWindowBase <-- wxWindow <-- wxTopLevelWindowBase <--
wxTopLevelWindow <-- wxFrameBase <-- wxFrame
The bindings generator needs to be able to pretend that the hierarchy is
really like this:
wxEvtHandler <-- wxWindow <-- wxTopLevelWindow <-- wxFrame
This is actually a simpler example, there are some cases where the
actual classes named in the hierarchy are platform specific, and even in
the example above the actual wxWindow, wxTopLevelWindow and wxFrame
classes used will vary by platform and will live in different .h files
on each platform. Is Shiboken able to deal with situations like this?
Hugo Parente Lima
> On 11/17/10 1:19 PM, Hugo Parente Lima wrote:
> > On Nov 15, 4:54 pm, Christopher Barker<Chris.Bar...@noaa.gov> wrote:
> >> On 11/15/10 3:54 AM, Brendan wrote:
> >>>> The phrases "Robin Dunn" and "a handwritten XML document" have a hard
> >>>> time coexisting in the same universe and have a tendency to be
> >>>> mutually exclusive on the same project. ;-)
> >
> > Hi list
> >
> > I'm a PySide developer, another PySide developer saw this thread and
> > told us, now I'm here to try to clarify some doubts about how our
> > generator could be useful to wxPython.
>
> Thanks for the info Hugo.
>
> > The basic:
> >
> > - Our generator depends on Qt, but the generated code *not*, so Qt
> > will be just a build dependency, *not* a runtime dependency.
>
> This is still somewhat of an unfortunate burden, at least in my opinion.
> Most of my development machines do not have Qt installed and it seems
> kinda silly if my only need for installing it is in order to make
> bindings for a *different* UI library.
Well... doxygen uses Qt and *if* it's used by Phoenix Qt is already a build
dependency for you :-). so this dependency problem were already solved and
shiboken wont add any additional dependency.
Not now, because we didn't face this kind of problem with Qt, but this is not
a hard feature to implement, the type-system would be something like:
<object-type name="wxEvtHandler" />
<object-type name="wxWindow" />
<object-type name="wxTopLevelWindow" />
<object-type name="wxFrame" />
<rejection class="wxWindowBase" />
<rejection class="wxTopLevelWindowBase" />
<rejection class="wxFrameBase" />
So when the generator sees a rejected class in the class hierarchy it simply
merge the methods found in the rejected class with the methods found in the
class which inherits it, i.e.: the non virtual methods found in wxWindowBase
will be implemented in all classes inheriting wxWindowBase.
The same with the virtuals that do their first appearance in wxWindowBase.
In other words, we can implement this feature in the generator if you really
need it to get wxPython bindings done with Shiboken.
Maybe the amount of macros used by wxWindow would be a bigger problem, but I
don't have enough knowledge of wxWindow the see now what could be a problem
without do any preliminary tests.
--
Hugo Parente Lima
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hu...@jabber.org
Robin Dunn
> On Wednesday 17 November 2010 22:48:00 Robin Dunn wrote:
>> On 11/17/10 1:19 PM, Hugo Parente Lima wrote:
>>> On Nov 15, 4:54 pm, Christopher Barker<Chris.Bar...@noaa.gov> wrote:
>>>> On 11/15/10 3:54 AM, Brendan wrote:
>>>>>> The phrases "Robin Dunn" and "a handwritten XML document" have a hard
>>>>>> time coexisting in the same universe and have a tendency to be
>>>>>> mutually exclusive on the same project. ;-)
>>>
>>> Hi list
>>>
>>> I'm a PySide developer, another PySide developer saw this thread and
>>> told us, now I'm here to try to clarify some doubts about how our
>>> generator could be useful to wxPython.
>>
>> Thanks for the info Hugo.
>>
>>> The basic:
>>>
>>> - Our generator depends on Qt, but the generated code *not*, so Qt
>>> will be just a build dependency, *not* a runtime dependency.
>>
>> This is still somewhat of an unfortunate burden, at least in my opinion.
>> Most of my development machines do not have Qt installed and it seems
>> kinda silly if my only need for installing it is in order to make
>> bindings for a *different* UI library.
>
> Well... doxygen uses Qt and *if* it's used by Phoenix Qt is already a build
> dependency for you :-). so this dependency problem were already solved and
> shiboken wont add any additional dependency.
It must be an optional dependency because the Doxygen installs I use on
two different computers do not link with Qt.
>> This is actually a simpler example, there are some cases where the
>> actual classes named in the hierarchy are platform specific, and even in
>> the example above the actual wxWindow, wxTopLevelWindow and wxFrame
>> classes used will vary by platform and will live in different .h files
>> on each platform. Is Shiboken able to deal with situations like this?
>
> Not now, because we didn't face this kind of problem with Qt, but this is not
> a hard feature to implement, the type-system would be something like:
>
> <object-type name="wxEvtHandler" />
> <object-type name="wxWindow" />
> <object-type name="wxTopLevelWindow" />
> <object-type name="wxFrame" />
> <rejection class="wxWindowBase" />
> <rejection class="wxTopLevelWindowBase" />
> <rejection class="wxFrameBase" />
>
> So when the generator sees a rejected class in the class hierarchy it simply
> merge the methods found in the rejected class with the methods found in the
> class which inherits it, i.e.: the non virtual methods found in wxWindowBase
> will be implemented in all classes inheriting wxWindowBase.
>
> The same with the virtuals that do their first appearance in wxWindowBase.
>
> In other words, we can implement this feature in the generator if you really
> need it to get wxPython bindings done with Shiboken.
Ok, I'll continue evaluating features and looking at the tutorials...
>
> Maybe the amount of macros used by wxWindow would be a bigger problem,
I would not be surprised if that were the case. There is a *lot* of
macro use and conditional preprocessor directives.
Hugo Parente Lima
I checked it, in fact it's a optional dependency only necessary by doxywizard
nowadays. In the old days doxygen used Qt3 and Qt used to be a hard
dependency, I guess they dropped Qt as a hard dependency when Qt4 was born and
Qt3 marked as deprecated.
--
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia
DevPlayer
Reply and Reply to author links and other posts on this topic only
have Reply to author?
2. At the link provide in the first post of this topic:
http://wiki.wxpython.org/ProjectPhoenix
then too
http://wiki.wxpython.org/ProjectPhoenix/ProjectGoals
A bulletted item at the bottom of the page:
◦Should the getters and setters used for properties be hidden (or
renamed with a leading '_') so only the property itself will be part
of the public API? (I like the idea but this might be too much of a
compatibility break...)
I so hope you don't use the '_'. To me it's one of the most warty
Python langauge elements. And the underscore is very non WX-ish. Also
I've seen other library's override the '_' for use with multilanguage
implementation which just confuses me an what happens when name
mangling is used too? Retorical question.
3. I hope you go solely Python 3. Move forward. It will push Python 3
further into the mainstream. Encourage 3rd party libraries to move
forward (by uses who use wxPython - I mean Project Phoenix). Help you
with your goal of reducing your support workload. Reduce confusion in
discussions (found in email, wiki, forums). Why force your NEW project
to support stuff that is going away and is implemented better (in
Python 3.x) when you can still use your wxPython versions to do that?
4. What will the new wxPython be called? Phoenix? or Project Phoenix
or wxPython3k? how about wxDunn?
5. Will you create a seperate google forum group, freenode irc (sadly
very inactive now), wiki, mailing list, etc. for the new project?
(please)
6. Would a Python PEP like system help you move from a kinda-solo
maintainer to a more-multi-core project supporter?
7. Here is a big one. Will there be consideration for allowing the new
wx Package to work with Twisted, Panda3d and other packages that are
fragilely intertwined now? - i.e. the EventLoop issues
8. Will pubsub work with the new package, better, less, same, or why
you ask? (no reason really)
Hiding IDs? YEAH I'm all for it.
Issue of Docs:
One of the things I still can't get is why the hell aren't forums
which discuss a package are still so seperate from the package's
documentation. You read the docs (on one website) then you have to
search and hope to find actually how to use what is scantly posted in
the Docs. You have to read, and read, and google, and read just to
find a solution to how to use that thing your read in the DOCs, all
the issues with it, suggestions on best practices etc, all seperate.
You would think the docs would have at least some URLs on
discussions.
Hell all my code I spew out (choice words in my case) have URLs in
comments from every website I learn about for a widget or algorithm
using that widget (not to mention being at least non-plageristic and
generally curtious to people I steal idea's from).
BTW has anyone perused wxRuby's Docs? In my opinion just a lot pretty
looking. And very uniform in structure - likely autogenerated too.
When is the next MS-OS or Mac OS due out? (again rhetorical).
Something to consider when planning the release of Project Pheonix.
I don't know if it matters, but the title "Project Phoenix" is very
likely a commonly used. Infrigments? Just mentioning.
Robin Dunn
> 1. Why do some http://groups.ggole.com posts on this topic have a
> Reply and Reply to author links and other posts on this topic only
> have Reply to author?
You'll have to ask Google about that. Perhaps it has something to do
with the age of the message, or the profile of the author, or similar.
Of course if you subscribe to receive emails instead of only reading the
messages in the groups web UI then you can reply to any message however
you want.
>
> 2. At the link provide in the first post of this topic:
> http://wiki.wxpython.org/ProjectPhoenix
> then too
> http://wiki.wxpython.org/ProjectPhoenix/ProjectGoals
>
> A bulletted item at the bottom of the page:
> ◦Should the getters and setters used for properties be hidden (or
> renamed with a leading '_') so only the property itself will be part
> of the public API? (I like the idea but this might be too much of a
> compatibility break...)
>
> I so hope you don't use the '_'. To me it's one of the most warty
> Python langauge elements. And the underscore is very non WX-ish. Also
> I've seen other library's override the '_' for use with multilanguage
> implementation which just confuses me an what happens when name
> mangling is used too? Retorical question.
That wasn't a thought about using just '_" but rather changing the name
of things like GetSize and SetSize to _getSize and _setSize, and then
using them to implement a property, like the equivalent of:
Size = property(_getSize, _setSize)
But it's very unlikely that this will happen, at least how I envisioned
it when I wrote that statement, as it would be too big and too
frustrating of a change for people porting their code to the Phoenix. I
might wake up one morning and find that my throat has been cut. ;-)
>
> 3. I hope you go solely Python 3. Move forward. It will push Python 3
> further into the mainstream. Encourage 3rd party libraries to move
> forward (by uses who use wxPython - I mean Project Phoenix). Help you
> with your goal of reducing your support workload. Reduce confusion in
> discussions (found in email, wiki, forums). Why force your NEW project
> to support stuff that is going away and is implemented better (in
> Python 3.x) when you can still use your wxPython versions to do that?
Because I don't think that it is a good idea to abandon the tens of
thousands of projects that are still using Python 2, including my own
personal projects and my day-job project. I want to help enable people
to move forward at their own pace, not force them to do so before they
are ready. If the Phoenix doesn't support Python 2 then I would feel
some (partially self-induced) pressure to continue to also continue to
maintain the current wxPython branch, and that would add up to more
work, not less.
>
>
> 4. What will the new wxPython be called? Phoenix? or Project Phoenix
> or wxPython3k? how about wxDunn?
I think it will still be wxPython. I'm using the Phoenix name now just
to help keep it separate from the current wxPython, because it is not
yet complete enough to replace the current wxPython. The whole reason
for the "Phoenix" name is symbolic of the intent that the current
wxPython will die and a new and better incarnation of itself will rise
from the ashes.
>
> 5. Will you create a seperate google forum group, freenode irc (sadly
> very inactive now), wiki, mailing list, etc. for the new project?
> (please)
No, not if it will have the same name.
>
> 6. Would a Python PEP like system help you move from a kinda-solo
> maintainer to a more-multi-core project supporter?
I think that is a bit overkill at this point, but maybe in the future.
>
> 7. Here is a big one. Will there be consideration for allowing the new
> wx Package to work with Twisted, Panda3d and other packages that are
> fragilely intertwined now? - i.e. the EventLoop issues
Because of replacing the back-end code generator there is already better
access to the event loop classes, including the ability to override the
appropriate virtual methods. But I've given no thought to any benefits
that would have for 3rd-party integrations, nor if there is now
something extra that could be done to help them further.
>
> 8. Will pubsub work with the new package, better, less, same, or why
> you ask? (no reason really)
There is probably very little need for anything in pubsub to change,
since it has almost no wx-specific code.
>
> Hiding IDs? YEAH I'm all for it.
This is something that I think everybody would be happy with, until it
came time to port existing code. But I'm still considering it and may
still do it if I can think of an easy and safe way to automate the API
change.
>
> I don't know if it matters, but the title "Project Phoenix" is very
> likely a commonly used. Infrigments? Just mentioning.
It's just an internal code name to be used while in initial development
stages, so there won't be any problems.