Hi Guys.
How can a non C/C++ programmer help porting wxpython to python 3?
I’m beginning with python/wxpython and I’d love to see wxpython running on python3.
Hi Guys.
How can a non C/C++ programmer help porting wxpython to python 3?
I’m beginning with python/wxpython and I’d love to see wxpython running on python3.
Hi,
On Tue, Mar 27, 2012 at 3:48 PM, Tomas Schertel tschertel@gmail.com wrote:
Hi Guys.
How can a non C/C++ programmer help porting wxpython to python 3?
I’m beginning with python/wxpython and I’d love to see wxpython running on python3.
Whenever Robin puts out a Phoenix build, download it and test it and find what’s broken. Report broken stuff to the this list and/or submit bug tickets (if there isn’t one already). Once the Phoenix conversion is done, then Robin will hopefully be able to tell us how we can contribute more. I work more on the documentation stuff myself via tutorial writing.
Mike Driscoll
It's going to be done as part of the Phoenix project, and I'm happy to say that the C++ parts of it are actually getting close to the top of my Phoenix ToDo list. At that point we'll want to look at migrating more of the python parts too, not only to Python 3 but also some changes that will be required for Phoenix itself. That would be a good time to get involved if you want to help out.
So IOW, although I've been saying it will be "part of the Phoenix project" for a long long time, I'm happy to be able to say now that it is getting closer and the light at the end of the tunnel is not just a little spec anymore.
On 3/27/12 1:48 PM, Tomas Schertel wrote:
Hi Guys.
How can a non C/C++ programmer help porting wxpython to python 3?
I'm beginning with python/wxpython and I'd love to see wxpython running
on python3.
--
Robin Dunn
Software Craftsman
Hi Robin.
Nice to read that.
Is there a repo from where I can try any code?
On Wed, Mar 28, 2012 at 16:10, Robin Dunn robin@alldunn.com wrote:
On 3/27/12 1:48 PM, Tomas Schertel wrote:
Hi Guys.
How can a non C/C++ programmer help porting wxpython to python 3?
I’m beginning with python/wxpython and I’d love to see wxpython running
on python3.
It’s going to be done as part of the Phoenix project, and I’m happy to say that the C++ parts of it are actually getting close to the top of my Phoenix ToDo list. At that point we’ll want to look at migrating more of the python parts too, not only to Python 3 but also some changes that will be required for Phoenix itself. That would be a good time to get involved if you want to help out.
So IOW, although I’ve been saying it will be “part of the Phoenix project” for a long long time, I’m happy to be able to say now that it is getting closer and the light at the end of the tunnel is not just a little spec anymore.
–
Robin Dunn
Software Craftsman
–
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
Hi,
Hi Robin.
Nice to read that.
Is there a repo from where I can try any code?
Try here:
http://wxpython.org/Phoenix/snapshot-builds/
That release was from November 2011, and it contains most (but not
all) the wxPython functionalities as the Classic wxPython does.
Regarding the help, I have had exactly zero (0) answers on the
documentation effort, which at the moment is a two-persons job (Robin
and myself).
There are so many good tutorials and snippet of code out there (Mike,
Chris, Werner, Cody, I am talking to you specifically), I would say
that either converting their description to ReST format or modifying
the current Sphinx docs to link to them is a relatively
straightforward way to boost the Phoenix docs and populate them with a
lot of interesting and useful snippets. Not to mention the status of
the wx.lib modules docstrings, which (in my opinion), are in a dire
need of a restructuring/reformatting to be compatible with the current
Phoenix docs.
Other than that, I can't say how easy would be to help on the C++
wrapping part. I am no expert in this area. But please remember that
there are other things making a library great, other than the pure
C++/Python code: to realize this, please do take a serious look at the
matplotlib, numpy and scipy documentation pages to see what I mean.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 28 March 2012 21:57, Tomás Acauan Schertel wrote:
Not really "most", probably not even half of the core. I think of it as more of a proof-of-concept build with a big chunk of the core classes provided so you can experiment with some simple things. We've now got some code to help automate the creation and upload of those snapshots so eventually those will be updating regularly.
In the meantime the source is in the same SVN repository as wxWidgets and wxPython. The location in the Trac browser is here: wxTrac has been migrated to GitHub Issues - wxWidgets and the actual SVN URL is https://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk/
You may also want to read these pages to get some background info, goals and guiding principles for the project: ProjectPhoenix - wxPyWiki
On 3/28/12 1:11 PM, Andrea Gavana wrote:
Hi,
On 28 March 2012 21:57, Tom�s Acauan Schertel wrote:
Hi Robin.
Nice to read that.
Is there a repo from where I can try any code?Try here:
Index of /Phoenix/snapshot-builds
That release was from November 2011, and it contains most (but not
all) the wxPython functionalities as the Classic wxPython does.
--
Robin Dunn
Software Craftsman
Regarding the help, I have had exactly zero (0) answers on the
documentation effort,
sorry -- it really is important.
which at the moment is a two-persons job (Robin
and myself).There are so many good tutorials and snippet of code out there (Mike,
Chris, Werner, Cody, I am talking to you specifically)
OK, OK --
I would say
that either converting their description to ReST format or modifying
the current Sphinx docs to link to them is a relatively
straightforward way to boost the Phoenix docs and
populate them with a
lot of interesting and useful snippets.
hmm -- I have a bunch of useful snippets, so I tink you are proposing:
1) I put them somewhere in the revision control system with the wxPython source
2) add links to them in the Sphinx docs, with some explanations
Is that right?
Finding the time for this is another matter, but if I have a specific
plan, it's more likely to happen.
Questions:
* where in the source should I put them?
- they are mostly tiny stand-alone applications that demonstrate the
use of a particular widget or concept.
* where should the docs go? I assume the sphinx source is in the VCS somewhere.
* should I make this Phoenix-specific? -- i.e. test under Phoenix, and
put the docs in the Phoenix docs.
Not to mention the status of
the wx.lib modules docstrings,
are these going to be the same in Phoenix?
-Chris
On Wed, Mar 28, 2012 at 1:11 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:
--
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
Chris.Barker@noaa.gov
Hi Chris,
Regarding the help, I have had exactly zero (0) answers on the
documentation effort,sorry -- it really is important.
which at the moment is a two-persons job (Robin
and myself).There are so many good tutorials and snippet of code out there (Mike,
Chris, Werner, Cody, I am talking to you specifically)OK, OK --
I would say
that either converting their description to ReST format or modifying
the current Sphinx docs to link to them is a relatively
straightforward way to boost the Phoenix docs and
populate them with a
lot of interesting and useful snippets.hmm -- I have a bunch of useful snippets, so I tink you are proposing:
1) I put them somewhere in the revision control system with the wxPython source
2) add links to them in the Sphinx docs, with some explanations
Is that right?
Finding the time for this is another matter, but if I have a specific
plan, it's more likely to happen.Questions:
* where in the source should I put them?
- they are mostly tiny stand-alone applications that demonstrate the
use of a particular widget or concept.* where should the docs go? I assume the sphinx source is in the VCS somewhere.
* should I make this Phoenix-specific? -- i.e. test under Phoenix, and
put the docs in the Phoenix docs.
Thanks for your answer. Actually, the tiny scripts can simply stay
standalone, they don't need any special linking or modifications to
the base Sphinx docs, *as long as they have a standardized name*,
i.e.:
If you have a tiny script demonstrating the use of wx.GraphicsContext
(for example), simply call it like this:
GraphicsContext.1.py
If you have more than one scripts demonstrating some nice feature of
wx.GraphicsContext, simply number them in ascending order, i.e.:
GraphicsContext.1.py
GraphicsContext.2.py
GraphicsContext.3.py
If you have a tiny script showing the use of wx.DC.DrawText, the
procedure is similar:
wx.DC.DrawText.1.py
And so on. The Sphinx builder I wrote will do the rest, including your
scripts as example in the appropriate place.
Not to mention the status of
the wx.lib modules docstrings,are these going to be the same in Phoenix?
As far as I know, yes. wx.lib is pure-Python, so it should be
independent of the actual wxPython implementation. My point regarding
wx.lib is that the docstrings are not standardized as ReST and Sphinx
will most likely fail to correctly render them (not to mention the
modules for which there are little to no docstrings).
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 28 March 2012 23:10, Chris Barker wrote:
On Wed, Mar 28, 2012 at 1:11 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:
On Wed, Mar 28, 2012 at 2:19 PM, Andrea Gavana
Thanks for your answer. Actually, the tiny scripts can
well, they are all small, not all tiny...
(24 to 743 lines of code)
simply stay
standalone, they don't need any special linking or
modifications to
the base Sphinx docs, *as long as they have a
standardized name*,
If you have a tiny script demonstrating the use of wx.GraphicsContext
(for example), simply call it like this:GraphicsContext.1.py
very cool!
OK, so I have some re-naming to do.
Where do I put them?
And then I want to figure out what do do with a few of the large
samples, but one thing at a time.
-Chris
If you have more than one scripts demonstrating some nice feature of
wx.GraphicsContext, simply number them in ascending order, i.e.:GraphicsContext.1.py
GraphicsContext.2.py
GraphicsContext.3.pyIf you have a tiny script showing the use of wx.DC.DrawText, the
procedure is similar:wx.DC.DrawText.1.py
And so on. The Sphinx builder I wrote will do the rest, including your
scripts as example in the appropriate place.Not to mention the status of
the wx.lib modules docstrings,are these going to be the same in Phoenix?
As far as I know, yes. wx.lib is pure-Python, so it should be
independent of the actual wxPython implementation. My point regarding
wx.lib is that the docstrings are not standardized as ReST and Sphinx
will most likely fail to correctly render them (not to mention the
modules for which there are little to no docstrings).Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/--
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en
--
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
Chris.Barker@noaa.gov
Hi Chris,
On Wed, Mar 28, 2012 at 2:19 PM, Andrea Gavana
Thanks for your answer. Actually, the tiny scripts can
well, they are all small, not all tiny...
(24 to 743 lines of code)simply stay
standalone, they don't need any special linking or
modifications to
the base Sphinx docs, *as long as they have a
standardized name*,If you have a tiny script demonstrating the use of wx.GraphicsContext
(for example), simply call it like this:GraphicsContext.1.py
very cool!
OK, so I have some re-naming to do.
Where do I put them?
As you have committing rights to the wxPython SVN tree, the best
location is the following:
You will see that this folder already contains a bunch of small
scripts (not standalone), directly translated from the wxWidgets
documentation. The scripts need not be standalone and runnable, they
just need to show how to use a particular method/class. So, if you
wish, you can get away with the wx.App(0)/app.MainLoop() and other
initialization stuff.
And then I want to figure out what do do with a few of the large
samples, but one thing at a time.
I would say these can go into the widgets overviews, which are stored here:
http://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk/docs/sphinx/rest_substitutions/overviews/
But I'll leave the big boss to comment on this.
In any case, if you don't want to commit the changes to the Phoenix
trunk, you can always send the snippets to me and I'll try and build
the Sphinx docs locally; if everything goes fine I'll upload the final
results in the SVN repository.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 28 March 2012 23:28, Chris Barker wrote:
I'm not sure yet if that will be completely possible, as there are some incompatibilities being introduced that could cause problems trying to keep the same code for both Classic and Phoenix, (like dropping the renamed version of the C++ overloaded methods, since we can handle overloads properly now, etc.) Hopefully they'll be minor enough that it won't be too much of a hassle to conditionalize the code where needed.
OTOH, there will be deprecation warnings for some old-style things that I felt were commonly enough used that they should still be present in Phoenix for a while, and it would be kind of a bad example to set if the wx.lib code was spewing DeprecationWarnings all over the place.
On 3/28/12 2:19 PM, Andrea Gavana wrote:
Not to mention the status of
the wx.lib modules docstrings,are these going to be the same in Phoenix?
As far as I know, yes. wx.lib is pure-Python, so it should be
independent of the actual wxPython implementation.
--
Robin Dunn
Software Craftsman
I think that would be okay, although as an overview they should have some tutorial style text and markup to go with them. Do you also automatically add links those docs from the appropriate places in the rest of the documentation or do they need to be explicitly linked to?
On 3/28/12 2:38 PM, Andrea Gavana wrote:
And then I want to figure out what do do with a few of the large
samples, but one thing at a time.I would say these can go into the widgets overviews, which are stored here:
http://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk/docs/sphinx/rest_substitutions/overviews/
But I'll leave the big boss to comment on this.
--
Robin Dunn
Software Craftsman
Hi Robin,
Not to mention the status of
the wx.lib modules docstrings,are these going to be the same in Phoenix?
As far as I know, yes. wx.lib is pure-Python, so it should be
independent of the actual wxPython implementation.I'm not sure yet if that will be completely possible, as there are some incompatibilities being introduced that could cause problems trying to keep the same code for both Classic and Phoenix, (like dropping the renamed version of the C++ overloaded methods, since we can handle overloads properly now, etc.) Hopefully they'll be minor enough that it won't be too much of a hassle to conditionalize the code where needed.
OTOH, there will be deprecation warnings for some old-style things that I felt were commonly enough used that they should still be present in Phoenix for a while, and it would be kind of a bad example to set if the wx.lib code was spewing DeprecationWarnings all over the place.
I think it'd be better if wx.lib were somehow shared among Classic and Phoenix. It would be good to get the DeprecationWarnings out of the way first, but wx.lib is pure Python, and wxPython is open source, so hopefully those DeprecationWarnings will annoy someone enough that they'll start submitting fixes. Similarly for Python 3 compatibility in wx.lib. The faster we get these things in people's hands, the faster the likelihood of getting those sorts of fixes submitted IMHO.
Thanks,
Kevin
On Mar 28, 2012, at 3:29 PM, Robin Dunn wrote:
On 3/28/12 2:19 PM, Andrea Gavana wrote:
--
Robin Dunn
Software Craftsman
http://wxPython.org--
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en
Yes, that's probably true.
On 3/28/12 3:47 PM, Kevin Ollivier wrote:
Hi Robin,
On Mar 28, 2012, at 3:29 PM, Robin Dunn wrote:
On 3/28/12 2:19 PM, Andrea Gavana wrote:
Not to mention the status of
the wx.lib modules docstrings,are these going to be the same in Phoenix?
As far as I know, yes. wx.lib is pure-Python, so it should be
independent of the actual wxPython implementation.I'm not sure yet if that will be completely possible, as there are some incompatibilities being introduced that could cause problems trying to keep the same code for both Classic and Phoenix, (like dropping the renamed version of the C++ overloaded methods, since we can handle overloads properly now, etc.) Hopefully they'll be minor enough that it won't be too much of a hassle to conditionalize the code where needed.
OTOH, there will be deprecation warnings for some old-style things that I felt were commonly enough used that they should still be present in Phoenix for a while, and it would be kind of a bad example to set if the wx.lib code was spewing DeprecationWarnings all over the place.
I think it'd be better if wx.lib were somehow shared among Classic and Phoenix. It would be good to get the DeprecationWarnings out of the way first, but wx.lib is pure Python, and wxPython is open source, so hopefully those DeprecationWarnings will annoy someone enough that they'll start submitting fixes. Similarly for Python 3 compatibility in wx.lib. The faster we get these things in people's hands, the faster the likelihood of getting those sorts of fixes submitted IMHO.
--
Robin Dunn
Software Craftsman
They are automatically linked in the documentation; the Sphinx
generator looks for inline links in the XML code for the wxWidgets
docs and, if it refers to an overview, the overview is automatically
included. As far as I can see, all of them are properly handled in the
docs (although the overview for internationalization and wx.ListCtrl
are simply empty stub pages at the moment).
I order to include arbitrary (i.e., not derived from the wxWidgets C++
docs) overviews and tutorials, we simply need to decide on a
standardized naming convention for them (i.e., overview_treectrl.rst,
tutorial_treectrl.rst or whatever we like best). Once this is place,
linking these new overviews/tutorials to the Sphinx docs would be
relatively easy.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 29 March 2012 00:29, Robin Dunn wrote:
On 3/28/12 2:38 PM, Andrea Gavana wrote:
And then I want to figure out what do do with a few of the large
samples, but one thing at a time.I would say these can go into the widgets overviews, which are stored
here:http://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk/docs/sphinx/rest_substitutions/overviews/
But I'll leave the big boss to comment on this.
I think that would be okay, although as an overview they should have some
tutorial style text and markup to go with them. Do you also automatically
add links those docs from the appropriate places in the rest of the
documentation or do they need to be explicitly linked to?
OK, still not there also I sent it last night. Some problem with my free.fr account and google groups?!
Lets see if this makes it if I use my gmail account - sorry for the noise if it makes it twice.
Hi Andrea,
Lets see if this gets to the list, my posts to the user list of today do not make it - very strange.
On 28/03/2012 23:10, Chris Barker wrote:
On Wed, Mar 28, 2012 at 1:11 PM, Andrea Gavana<andrea.gavana@gmail.com> wrote:
Regarding the help, I have had exactly zero (0) answers on the
documentation effort,sorry -- it really is important.
which at the moment is a two-persons job (Robin
and myself).There are so many good tutorials and snippet of code out there (Mike,
Chris, Werner, Cody, I am talking to you specifically)OK, OK --
Me too, heard you the first time but I am not quit ready yet. Was thinking of getting into the updating of the doc strings.
Werner
The message got tagged as possible spam. Since you've already sent this other reply I'll go ahead and remove it from the queue. Looks like it tagged mine as spam too, so maybe there was some combination of words in there it didn't like.
On 3/29/12 4:08 AM, Werner F. Bruhin wrote:
OK, still not there also I sent it last night. Some problem with my
free.fr account and google groups?!
--
Robin Dunn
Software Craftsman
Easy enough -- here are two samples -- small, and not a big deal, but
ones that were easy to simply re-name, so we can give the system a try
with them.
It turns out that quite a few of my examples require more than just
the one file -- quite a few require some image files, etc (like a demo
of how to change the image in a StaticBitmap), so we need to think a
bit about where to put support files like that.
-Chris
GridBagSizer.1.py (1.14 KB)
GridBagSizer.2.py (1.02 KB)
On Wed, Mar 28, 2012 at 2:38 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:
In any case, if you don't want to commit the changes to the Phoenix
trunk, you can always send the snippets to me and I'll try and build
the Sphinx docs locally; if everything goes fine I'll upload the final
results in the SVN repository.
--
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
Chris.Barker@noaa.gov