[wxPython] wxPython/wxWindows Product Status

wxPython Users
1

In trawling through the mail list archives (a
necessary daily activity for someone new to the
product) I cannot help but note that the 2.2.X stream
of wxWindows is considered stable and the 2.3.X stream
development only. However, the 2.3.X stream of
wxPython seems to be considered the default release,
and is the standard deliverable from the download
site. OTOH, whilst I haven't been able to determine
the first release dates of the two streams, the HUGE
variance in features between the two would suggest
that there's a very long time between stable releases.
From a users (ie. programmers) point of view it would
seem that the differences between 2.3.1 and 2.3.2
would be enough to justify a major release. Now, I
don't want to criticise the development group's
release policies (I recognise that creeping featurism
is a harder to manage problem in an Open Development
context) but would like to get some clarification on:
(1) Which stream of wxPython is considered
"recommended for development use" and (2) What the
target stable release frequency is, if indeed there is
a target.

John

···

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

2

In trawling through the mail list archives (a
necessary daily activity for someone new to the
product) I cannot help but note that the 2.2.X stream
of wxWindows is considered stable and the 2.3.X stream
development only.

Specifically, the CVS WX_2_2_BRANCH (2.2.x) allows no API changes in the
wxWindows core library code, only bug fixes. The CVS HEAD (2.3.x) allows
API changes and is where all new features show up. It does not mean that it
is neccesarily unstable (bug-wise) only that the API is not frozen. I don't
strictly follow that rule in wxPython since I am building on top of an
established code-base, and since "binary compatibility" between your
programs (.py) and my libraries (.pyd or .so) doesn't have the same meaning
as when your programs are C++.

However, the 2.3.X stream of
wxPython seems to be considered the default release,
and is the standard deliverable from the download
site.

Since there is only one of me and I can only keep one version of wxPython in
my head at a time along with my work projects, I spend all my time these
days on the 2.3 branch. Since that is what I am most familiar with and am
best able to support then that is what I consider the default (and
recommended) release.

OTOH, whilst I haven't been able to determine
the first release dates of the two streams, the HUGE
variance in features between the two would suggest
that there's a very long time between stable releases.
From a users (ie. programmers) point of view it would
seem that the differences between 2.3.1 and 2.3.2
would be enough to justify a major release.

Just because there were a lot of new features in wxPython does not mean that
there were a lot of new things in wxWindows. Most of them were already
there, just not wrapped in wxPython yet.

I keep wxPython release numbers syncronized with wxWindows release numbers.
When I was doing it separately (which in some ways made a lot more sense)
then it caused a lot of insanity for people trying to know which version of
wxWindows to build to go long with which version of wxPython. (Some people
still don't get it, but I can't hold everybody's hand all the time...)

Now, I
don't want to criticise the development group's
release policies (I recognise that creeping featurism
is a harder to manage problem in an Open Development
context) but would like to get some clarification on:
(1) Which stream of wxPython is considered
"recommended for development use" and

2.3.x, just be prepared for occasional API changes between releases
(although I usually am able to minimize them in the wrappers.) I don't make
any release unless my gut feel is that it is at least as "stable" (bug-wise)
as the previous, new features not included. (Although sometimes I am wrong,
such as with 2.3.1 <grumble>)

(2) What the
target stable release frequency is, if indeed there is
a target.

Whenever it is deemed necessary. Read wx-dev for more details.

···

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

3

My difficult grids are finally working fairly well.
The problem is that there are five synchronized grids
that all needs to be refilled with data from underlying
objects when one of them is changed. For instance when
I move an item in one of the cells.

This is a bit slow. I'm doing things the simple way now,
updating all cell in all five grids. If I was very elaborate
I mights get away with updating a limited number of cells
in only two or three grids on every change. My present
solution is simple and robust though. The more elaborate
I make it the more code we'll have to maintain, understand
and debug... I'm fond of keeping bug and row count low... :slight_smile:

My direct question is if there is any quick way to speed
up a series of screen updates. My thought goes to Excel where
you can turn off screen updating while you are calculating
and turn it on again when you are done. Is there a parallel
in wxPython? Although it's not really flickering a lot, so
perhaps this is nothing to hope for?

I tested what happened if I did
panel.Show(false)
for grid in grids:
     grid.refill()
panel.Show(true)

This didn't seem to make it quicker.

/Magnus

···

--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

4

My direct question is if there is any quick way to speed
up a series of screen updates. My thought goes to Excel where
you can turn off screen updating while you are calculating
and turn it on again when you are done. Is there a parallel
in wxPython?

wxGrid has BeginBatch/EndBatch, and wxWindow has Freeze/Thaw but it isn't
implemented on all platforms or for all window types yet...

···

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

5

Robin Dunn wrote:

My direct question is if there is any quick way to speed
up a series of screen updates. My thought goes to Excel where
you can turn off screen updating while you are calculating
and turn it on again when you are done. Is there a parallel
in wxPython?

wxGrid has BeginBatch/EndBatch, and wxWindow has Freeze/Thaw but it isn't
implemented on all platforms or for all window types yet...

And maybe not wrapped for Python?

Niki Spahiev

6

Robin Dunn wrote:

>>My direct question is if there is any quick way to speed
>>up a series of screen updates. My thought goes to Excel where
>>you can turn off screen updating while you are calculating
>>and turn it on again when you are done. Is there a parallel
>>in wxPython?
>>
>
> wxGrid has BeginBatch/EndBatch, and wxWindow has Freeze/Thaw but it

isn't

> implemented on all platforms or for all window types yet...

And maybe not wrapped for Python?

They are in 2.3.2, if not before.

···

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