Discussion:
[Bitpim-devel] wxPython 2.5
Roger Binns
2004-04-20 03:11:55 UTC
Permalink
I just spent some quality time seeing how much effort is involved
in moving to wxPython 2.5. Because we already use the new wx
namespace, there was very little issue there. There were also
some items manually imported from random bits of the wxPython
namespace as they weren't correctly exposed in the 2.4 wx
namespace. Those are all trivial to deal with (took me about
3 minutes :-)

However there are a large number of wx object methods where
parameters have changed, typically from individual parameters
into tuples. There is no way to write the code so that it
works on both wx 2.4 and 2.5 in one line. It would have to
look like this instead:

if wx.VERSION>=(2,5):
sizer.Add( (10,10), 0, wx.EXPAND)
else:
sizer.Add( 10, 10, 0, wx.EXPAND)

Needless to say, it is a royal pain going through all the
code where these changes need to be made since it is a lot
of different methods. I soon got bored.

My earlier instinct was to only support one version of wxPython
and that still remains the case. There have been enough
bug reports about 2.5 that we will wait till the next release
and then do the switch.

Roger
Steven Palm
2004-04-20 03:42:54 UTC
Permalink
Post by Roger Binns
However there are a large number of wx object methods where
parameters have changed, typically from individual parameters
into tuples. There is no way to write the code so that it
works on both wx 2.4 and 2.5 in one line. It would have to
sizer.Add( (10,10), 0, wx.EXPAND)
sizer.Add( 10, 10, 0, wx.EXPAND)
...Interesting. I did read through the migration docs, and even asked
about it specifically on the mailing list. The answer I got was:

[QUOTED REPLY]
Post by Roger Binns
For my own application, the only change I needed to make when moving
to 2.5 was to use tuples instead of two separate arguments when adding
empty space to a sizer, and that change was backwards compatible with
2.4 so the updated code works on both versions without any
version-specific code. It's a few thousand lines of code so it's a
sizable app. Of course, YMMV, so I would recommend you read the
Migration Guide to see if any of the backwards-incompatible changes
are an issue for you first.
So, in his case it seemed as though changing to use tuples did not
break 2.4... Did you try this in the instances you were looking at? I
haven't toyed with it at all, so I thought I'd ask first. No, Roger,
I'm not assuming you're an idiot and didn't try it, I'm just asking.
:-)

All in all, I'm not in any hurry (any longer) to move to 2.5, and I'm
working on setting up both sets of libraries/includes here with scripts
to move me back and forth between them. The project I was working on
that *required* 2.5 is on a back back burner now, so I could care less
when we move. ;-)

Just my $0.02.
Roger Binns
2004-04-20 04:43:33 UTC
Permalink
Post by Steven Palm
So, in his case it seemed as though changing to use tuples did not
break 2.4... Did you try this in the instances you were looking at?
Only a short piece of code uses space in sizers. The other areas
I was looking at all involved drawing in DC's. The 2.4 methods
are like this:

DC.DrawBitmap(bmp, x, y)

In 2.5, you have to do one of the following:

DC.DrawBitmap(bmp, (x,y) )

or

DC.DrawBitmapXY(bmp, x, y)

So there is no way to have the same line of code work with both,
which means versioned if statements all over the place.
Post by Steven Palm
that *required* 2.5 is on a back back burner now, so I could care less
when we move. ;-)
I would like to move for things like selectable HTML, toolbar icon
now available for GTK, CHM help on all platforms, zillions of bug
fixes, and because Robin has hidden the 2.4 releases.

Roger
Steven Palm
2004-04-20 13:37:51 UTC
Permalink
Post by Roger Binns
I would like to move for things like selectable HTML, toolbar icon
now available for GTK, CHM help on all platforms, zillions of bug
fixes, and because Robin has hidden the 2.4 releases.
Hmmmm.... ;-) Maybe Robin's trying to tell us something. LoL

The one good thing about the 2.5 series is the recent invigoration in
the wxMac project. They started a contribution drive to expedite
development and get it up to the same level as the other ports, and
work is moving at an incredible pace. My employer uses a software
product (currently character based on UNIX terminals for the most part)
whose next revision will have a GUI designed using wxWidgets. They are
using wxPerl (unfortunately, but they won't listen to reason :-) for
the project. I talked them into make a decent donation to the wxMac
development fund as a gesture of good faith. ;-)

So, from the Mac perspective, 2.5 is all good because it's being
overhauled in a major way with bug fixes and refinements.

Loading...