Hi Nitro,
Sorry for the delay in responding, I've been busy with other things for a while and am now trying to get caught up on everything.
Hello Robin,
I'd like to release floatcanvas2, so it finally gets a bit more testing.
If you are ok with that, I've got a few questions left:
Before I answer the questions, I have one of my own, as it will affect my answers. Is it intended that FC2 will replace FC, or will both continue to exist for a while? For my answers below I'll assume both will continue to exist.
1) What do I have to do so the SOC2008_FloatCanvas branch in 3rdparty can
be merged into trunk?
We'll want to keep it in the 3rdParty folder and then use svn:external properties to hook it into the main wxPython SVN tree at the right places. If you take a look at wxPython/3rdParty/AGW you'll see a good way to organize it for library packages. In that folder there are just 2 sub folders. One will become a sub folder of wx/lib folder in the wxPython source tree(s) using svn:external and the other will become a sub folder of main demo folder. I'd like you to follow this same pattern. You can have other sub folders there if needed, but they probably won't be linked into the main source tree anywhere.
2) Is it you or me who has to do the merging?
You can copy from the SOC branch to the wxPython/3rdParty/FloatCanvas2 folder (or whatever you want to name it) with floatcanvas2 and demo subfolders. Be sure to use svn copy so the history is maintained between the old location and the new.
I'll add the svn:external properties in the main source tree once you've got things set up in their new location.
3) How do you/I go about writing the build/packaging scripts which pull
the neccessary stuff from 3rdparty into wx.lib?
There are a few files that will need to be edited and made aware of the new folders and files to be included in the builds. Be sure to do it in both the wxPython trunk and the WX_2_8_BRANCH since the 2.8 branch is not fully closed yet.
1. setup.py (in the root of the wxPython source tree): At least the WX_PKGLIST will need edited, adding the new package dirs that need to be installed. If there are any files in those dirs that are not *.py files that also need to be installed then they will need to be mentioned in the DATA_FILES list.
2. distrib/DIRLIST: This file contains a list of all folders, relative to the wxPython root, that need to be copied into the source tarball. Anything that is needed for the build or install needs to go into this list.
3. distrib/make_installer.py: This script is used to build and run the InnoSetup installer script for the Windows installers. You'll need to mention all the files, again relative to the wxPython root, that need to be installed on Windows in the [Files] section. (To make it easier you can just specify the files by wildcard for each folder, but don't use something like *.* because then all the .pyc files that happen to be in the build dir would be included too.) You'll also need to add entries to the [UninstallDelete] section for files that should be deleted on uninstall that may not have been installed by the installer, like the *.pyc files. Also note that there are two templates in this file, one for the main installer and one for the docs/demos.
4) For the wxPython demo, does it suffice to just spawn the FC2 demo from
the wxPython demo?
That would be okay to start with, but eventually I'd like for it to be integrated into the main demo like AGW is. To do that you can put a __demo__.py file in your main demo directory that provides info for the main demo to be able to build up its tree of samples and to know what modules to run. See AGW/demo/__demo__.py.
Since you have lots and lots of items in the FC2 demo then perhaps you could choose some of them to integrate into the wxPython demo using the __demo__.py mechanism, and then have the last item in the list be something like See More Samples that launches your demo application.
···
On 11/30/09 10:52 AM, Nitro wrote:
--
Robin Dunn
Software Craftsman
