2.5.1.0p7 Preview

wxPython Dev
1

Hi guys,

It took a little longer than I hoped (having to reinstall Panther got in the way, but that's a different story...) but the 2.5.1.0p7 preview is now available. The full installers and other files that would normally be in a real release are available here:

  http://alldunn.com/wxPython/preview/2.5.1.0p7/

I think I've fixed the problem of downloading .gz files from my server with IE, but if you run into trouble, or the size of the file you downloaded doesn't match what's listed on the website then just download with something else. (The GetRight plugin for IE works great, even before my fix to the server config.)

A few notes:

* I made a small but important change in the code that aquires the Python Global Interpreter Lock to try and prevent deadlocks that can happen when there are nested attempts to aquire the GIL. I don't expect any problems, but am not 100% sure about it. Please report any deadlocks (GUI FREEZING) or any "tstate" messages or fatal error messages from Python.

* The iewin module has been updated for 2.5 and is now included. (But it's still using the old version of the wxActiveX code, eventually I'd like to update that and also expose the wxActiveX class so that (theoretically) any ActiveX control can be used with it.)

* The RPMs will now install menu items on Mandrake in Applications/Development/Tools for PyCrust, XRCed, etc. They are also installing icons and *.desktop items in the generic KDE and GNOME locations, but I don't know yet if they are resulting in menu items on non-Mandrake systems. (It didn't automatically do it on my RH-9 build box but I didn't chase it very far...) If you have ideas for how to improve the .spec file to work better and/or on more distros please send me a patch.

* The RPMs are now built on a RH-9 box, and I have tested installing them also on my main Mandrake 9.2 box. Your mileage on other distros may vary, but the SRPMS and the src tarball are available if the binaries won't install for some reason. Please report successes/failures with the binaries on other distros.

* The "apple" in the OSX disk image file name means the Apple installed Python on Panther. I still need to do a build for Jaguar, (which I will try to get done later today.) When it is done it will have "local" in the name instead of "apple". I chose those two names instead of jaguar and panther because if you do a local build of Python on Panther it will be installed much the same as on Jaguar.

* There are some big changes in the OS X disk image. The actual Installer package now *only* installs the wxMac dynlibs, wxPython extension modules and pacakges, and also the command-line tool scripts. The remaining items (demo, samples, and application bundles for the Demo, PyCrust and XRCed) are now top-level items in the disk image (.dmg file) that users can just drag and drop to where ever they want to put them. NOTE: The demo is actually there twice, first as a raw folder of .py files and such for the users to play with, and secondly a copy of the demo modules is also embedded within the "wxPython Demo.app" application bundle. I should find a way to make this more clear...

* Also, on OSX the wxMac dynlibs are now installed to /usr/lib/wxPython-$VERSION like with the RPMs. Changes to the build system embed the path to the libs in the binaries that use them, so they can be in non-standard locations without having to to set DYLD_LIBRARY_PATH. However if you do have DYLD_LIBRARY_PATH set and the wxMac libs installed to a different location (such as inside your .app bundle) then it still loads the libs from there as you would expect. This was all a very pleasant surprise! :slight_smile:

* I made a set of DC compatibility classes that have the Draw* and etc. methods that take the split parameters like in 2.4, and if you import from wxPython.wx then these classes are aliased such that they are used. In other words, if you "import wx" then you will have the real DC classes that have the new methods as described in the Migration Guide, but if you "from wxPython.wx import *" then wxClientDC (for example) will be an alias to wxClientDC_old which derives from wxClientDC and whose DrawLine method is an alias to DrawLineXY. Hopefully this will help reduce the upgrade shock that people will have...

* There have been a few docstring (and wxPython-metadata.xml) updates, but not nearly as much as I wanted to do. The C++ docs are still included.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

2

Robin Dunn wrote:

Hi guys,

It took a little longer than I hoped (having to reinstall Panther got in the way, but that's a different story...) but the 2.5.1.0p7 preview is now available. The full installers and other files that would normally be in a real release are available here:

    http://alldunn.com/wxPython/preview/2.5.1.0p7/

Oh, yeah: Please be nice to this server, it is on a slow link. Only pass this URL on to folks that are going to be testing this preview.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

3

From: Robin Dunn

* I made a set of DC compatibility classes that have the Draw* and etc.
methods that take the split parameters like in 2.4, and if you import
from wxPython.wx then these classes are aliased such that they are used.
  In other words, if you "import wx" then you will have the real DC
classes that have the new methods as described in the Migration Guide,
but if you "from wxPython.wx import *" then wxClientDC (for example)
will be an alias to wxClientDC_old which derives from wxClientDC and
whose DrawLine method is an alias to DrawLineXY. Hopefully this will
help reduce the upgrade shock that people will have...

I was unable to test my PythonCard drawing tests with previous 2.5 versions
because I hadn't converted the DC code yet, but the new aliases seem to be
working for the few tests I've done so far. The downside is that drawing is
roughly 1.5 to 3 times slower than with 2.4.2.4 on my fast Win2K box; OS X
drawing has always been slow in comparison, but I'll test that later. The
code is mostly testing the DrawPointList and DrawRectangleList methods, so
that actual number of drawing operations is pretty minimal. Drawing
individual points, lines, and rects could be much slower. Is this expected
and/or a downside to supporting alpha channels? I don't remember Chris or
anyone else with code that does extensive drawing mentioning this issue
before. I'll play around with the code some more this week including a
conversion to the 2.5 classes avoiding the aliases for at least one sample
and see if I notice a particular bottleneck.

ka

4

Kevin Altis wrote:

From: Robin Dunn

* I made a set of DC compatibility classes that have the Draw* and etc.
methods that take the split parameters like in 2.4, and if you import
from wxPython.wx then these classes are aliased such that they are used.
In other words, if you "import wx" then you will have the real DC
classes that have the new methods as described in the Migration Guide,
but if you "from wxPython.wx import *" then wxClientDC (for example)
will be an alias to wxClientDC_old which derives from wxClientDC and
whose DrawLine method is an alias to DrawLineXY. Hopefully this will
help reduce the upgrade shock that people will have...

I was unable to test my PythonCard drawing tests with previous 2.5 versions
because I hadn't converted the DC code yet, but the new aliases seem to be
working for the few tests I've done so far. The downside is that drawing is
roughly 1.5 to 3 times slower than with 2.4.2.4 on my fast Win2K box; OS X
drawing has always been slow in comparison, but I'll test that later. The
code is mostly testing the DrawPointList and DrawRectangleList methods, so
that actual number of drawing operations is pretty minimal.

The compatibility classes are not to blame here, but probably some changes internal to the DrawXXXList methods. There were some changes but I don't remember any details right now... It probably has to do with the fact that everything is new-style classes now, and it takes a couple extra steps to verify the kind of object and if it is an instance of a SWIGged class and then to extract the wrapped C++ instance.

The DC compatibility classes simply look like this:

class ClientDC_old(ClientDC):
     """DC class that has methods with 2.4 compatible parameters."""
     FloodFill = ClientDC.FloodFillXY
     GetPixel = ClientDC.GetPixelXY
     DrawLine = ClientDC.DrawLineXY
     CrossHair = ClientDC.CrossHairXY
     DrawArc = ClientDC.DrawArcXY
     DrawCheckMark = ClientDC.DrawCheckMarkXY
     DrawEllipticArc = ClientDC.DrawEllipticArcXY
     DrawPoint = ClientDC.DrawPointXY
     DrawRectangle = ClientDC.DrawRectangleXY
     DrawRoundedRectangle = ClientDC.DrawRoundedRectangleXY
     DrawCircle = ClientDC.DrawCircleXY
     DrawEllipse = ClientDC.DrawEllipseXY
     DrawIcon = ClientDC.DrawIconXY
     DrawBitmap = ClientDC.DrawBitmapXY
     DrawText = ClientDC.DrawTextXY
     DrawRotatedText = ClientDC.DrawRotatedTextXY
     Blit = ClientDC.BlitXY

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

5

Hi Robin,

Thanks for the update! Guess I don't need to help with the Panther packages anymore. =)

As for the testing, there were a few classes that crashed, mostly on startup:

- The Grid simple sample (all the rest were fine)
- Multisash
- ContextHelp (after clicking on the help button)
- HTMLWindow (!! - may be due to a mouse event - it initially loaded then crashed a couple seconds after)

- Mask crashes with this traceback:

     win = TestPanel(nb, -1)
   File "/Volumes/wxPythonOSX-2.5.1.0p7-apple-Py2.3/wxPython Demo.app/Contents/Resources/Mask.py", line 99, in __init__
     self.win = TestMaskWindow(self)
   File "/Volumes/wxPythonOSX-2.5.1.0p7-apple-Py2.3/wxPython Demo.app/Contents/Resources/Mask.py", line 43, in __init__
     self.bmp_themask = wx.BitmapFromImage(images.getTestMaskImage(), 1)
   File "//System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/wx/gdi.py", line 517, in BitmapFromImage
     val = _gdi.new_BitmapFromImage(*args, **kwargs)
wx.core.PyAssertionError: C++ assertion "wxAssertFailure" failed in ../src/mac/bitmap.cpp(724): invalid bitmap depth

MimeTypesManager also somehow appears in the background permanently after the demo is clicked. The other crashes did not provide any tracebacks, unfortunately.

I'll try and have a closer look at this in the near future, but despite the few glitches it is looking really good!

Thanks,

Kevin

···

On Jan 19, 2004, at 12:00 PM, Robin Dunn wrote:

Hi guys,

It took a little longer than I hoped (having to reinstall Panther got in the way, but that's a different story...) but the 2.5.1.0p7 preview is now available. The full installers and other files that would normally be in a real release are available here:

  http://alldunn.com/wxPython/preview/2.5.1.0p7/

I think I've fixed the problem of downloading .gz files from my server with IE, but if you run into trouble, or the size of the file you downloaded doesn't match what's listed on the website then just download with something else. (The GetRight plugin for IE works great, even before my fix to the server config.)

A few notes:

* I made a small but important change in the code that aquires the Python Global Interpreter Lock to try and prevent deadlocks that can happen when there are nested attempts to aquire the GIL. I don't expect any problems, but am not 100% sure about it. Please report any deadlocks (GUI FREEZING) or any "tstate" messages or fatal error messages from Python.

* The iewin module has been updated for 2.5 and is now included. (But it's still using the old version of the wxActiveX code, eventually I'd like to update that and also expose the wxActiveX class so that (theoretically) any ActiveX control can be used with it.)

* The RPMs will now install menu items on Mandrake in Applications/Development/Tools for PyCrust, XRCed, etc. They are also installing icons and *.desktop items in the generic KDE and GNOME locations, but I don't know yet if they are resulting in menu items on non-Mandrake systems. (It didn't automatically do it on my RH-9 build box but I didn't chase it very far...) If you have ideas for how to improve the .spec file to work better and/or on more distros please send me a patch.

* The RPMs are now built on a RH-9 box, and I have tested installing them also on my main Mandrake 9.2 box. Your mileage on other distros may vary, but the SRPMS and the src tarball are available if the binaries won't install for some reason. Please report successes/failures with the binaries on other distros.

* The "apple" in the OSX disk image file name means the Apple installed Python on Panther. I still need to do a build for Jaguar, (which I will try to get done later today.) When it is done it will have "local" in the name instead of "apple". I chose those two names instead of jaguar and panther because if you do a local build of Python on Panther it will be installed much the same as on Jaguar.

* There are some big changes in the OS X disk image. The actual Installer package now *only* installs the wxMac dynlibs, wxPython extension modules and pacakges, and also the command-line tool scripts. The remaining items (demo, samples, and application bundles for the Demo, PyCrust and XRCed) are now top-level items in the disk image (.dmg file) that users can just drag and drop to where ever they want to put them. NOTE: The demo is actually there twice, first as a raw folder of .py files and such for the users to play with, and secondly a copy of the demo modules is also embedded within the "wxPython Demo.app" application bundle. I should find a way to make this more clear...

* Also, on OSX the wxMac dynlibs are now installed to /usr/lib/wxPython-$VERSION like with the RPMs. Changes to the build system embed the path to the libs in the binaries that use them, so they can be in non-standard locations without having to to set DYLD_LIBRARY_PATH. However if you do have DYLD_LIBRARY_PATH set and the wxMac libs installed to a different location (such as inside your .app bundle) then it still loads the libs from there as you would expect. This was all a very pleasant surprise! :slight_smile:

* I made a set of DC compatibility classes that have the Draw* and etc. methods that take the split parameters like in 2.4, and if you import from wxPython.wx then these classes are aliased such that they are used. In other words, if you "import wx" then you will have the real DC classes that have the new methods as described in the Migration Guide, but if you "from wxPython.wx import *" then wxClientDC (for example) will be an alias to wxClientDC_old which derives from wxClientDC and whose DrawLine method is an alias to DrawLineXY. Hopefully this will help reduce the upgrade shock that people will have...

* There have been a few docstring (and wxPython-metadata.xml) updates, but not nearly as much as I wanted to do. The C++ docs are still included.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwindows.org

6

Kevin Altis wrote:

The
code is mostly testing the DrawPointList and DrawRectangleList methods, so
that actual number of drawing operations is pretty minimal. Drawing
individual points, lines, and rects could be much slower.

I don't remember Chris or
anyone else with code that does extensive drawing mentioning this issue
before.

I, for one, have not tested 2.5 yet...

Robin Dunn wrote:

The compatibility classes are not to blame here, but probably some changes internal to the DrawXXXList methods. There were some changes but I don't remember any details right now... It probably has to do with the fact that everything is new-style classes now, and it takes a couple extra steps to verify the kind of object and if it is an instance of a SWIGged class and then to extract the wrapped C++ instance.

hmm. I can see why this would slow down DC.DrawPoint(), for instance, but the DrawXXList methods shouldn't be noticably slower....you only have to go through those extra steps once per call, presumably.

Kevin, how many Points, Lines, whatevers where you drawing?

I'll try to test this out myself soon...

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (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

7

Chris Barker wrote:

Robin Dunn wrote:

The compatibility classes are not to blame here, but probably some changes internal to the DrawXXXList methods. There were some changes but I don't remember any details right now... It probably has to do with the fact that everything is new-style classes now, and it takes a couple extra steps to verify the kind of object and if it is an instance of a SWIGged class and then to extract the wrapped C++ instance.

hmm. I can see why this would slow down DC.DrawPoint(), for instance, but the DrawXXList methods shouldn't be noticably slower....you only have to go through those extra steps once per call, presumably.

If the list includes a pen/brush for each item then it will have to go through the extra steps for each item. Also, I just noticed another difference, the calls to wxPy*int_seq_helper will now be derefencing a pointer to get the address of the function to call, instead of making the call directly. I wouldn't have expected this to make that big of a difference, but it is something that can be changed if needed.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!