I wrote a small code snippet to make it easy to reproduce.
It needs four 32x32 images: "edit copy.GIF", "edit cut.GIF", "edit
paste.GIF", "redo.GIF", "undo.GIF".
Code is:
In my opinion if the packaging is to stay similar to what is done now
(i.e not moving to individual installers for the tools) I think that
they do belong in wx.tools but that wx.tools does not belong with the
main runtimes and should be fully part of the Demo and Tools package,
instead of the current half and half setup where the modules are
installed with the main runtimes and the launchers/shortcuts ect.. are
installed with the demo and tools package.
Yes, I've had that idea too. The only down-side I've seen so far is that then there would have to be an Installer package on OSX for the demo and tools (to install the wx.tools package to the right place in site-packages) instead of just being able to drag items out of the disk image.
I would also like to suggest that we make some changes to the scripts
like make_installer.py to get rid of the static strings for generating
the inno installer. It is a bit of a maintenance nightmare and I know
that Editra has been broken in many of the wxPython releases since it
was added simply due to missing files that were not picked up by the
installer since the string was not updated for new directories. So I
was thinking it a good idea to modify that script to generate most of
the installer script so that new files/directories will be picked up
automatically.
Yes, that sounds like a good idea. Perhaps it could use distrib/DIRLIST, or something like it, to drive the process. That file is what is currently used to define what goes into the source tarball from the wxPython part of the source tree. Although, giving it a little more thought, I see that we will need a bit more than just a list of folders. But I expect that it would not be hard to come up with a way to have a single, easy to maintain file that could control the generator for the source tarball, the make_installer script, for the lists of packages and data files in setup.py, and whatever else could benefit from this. If anybody feels like taking this idea and running with it please do.