[wxPython] 2.3.3 preview

I've uploaded a win32 preview of wxPython 2.3.3 to the project files area on
Sourceforge. You can get it at:

http://prdownloads.sourceforge.net/wxpython/wxPython-2.3.3pre2-Py22-hybrid.e
xe

If you are not on Windows you can get the sources for this preview from CVS
with the wxPy_2_3_3_pre tag. This time I remembered to tag the whole tree
(including wxWindows.)

There are still a few known issues, and several more things I still wish to
add or fix for the final, but I thought that you would appreciate being able
to get a taste of what's to come.

To all contributors, please double check your contributions and send me
patches for things that need changed/fixed. Or if you have any new contribs
that need added, this is the time to send them to me.

BTW, there are a few API changes to watch out for that I wasn't able to
cleanly implement in a backwards compatible way. Probably the most annoying
will be that the 'checkable' parameter in the wxMenu.Append method has
changed its name to 'kind' and takes one of the wxITEM_* values instead of a
boolean.

···

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

Note that the 'checkable' parameter that Robin mentions below will cause
some PythonCard samples to fail to startup. You'll need to run from the
command-line to see the error to know for sure. The exception will be thrown
in line 769 of wxPython\windows.py, in Append

Robin, can you at least suggest a workaround, so perhaps we can add a
specific check for 2.3.3 or do a try/except block to implement checkable?

I noticed that standalone PyCrust included with the new wxPython, labeled as
version 0.7.1 did work, but that the PyCrust in cvs does not. You must have
made a workaround that Patrick didn't check into cvs?

The code in question suggests this kind of solution in the short term.

try:
    # 2.3.2.1 and earlier
    m.Append(ID_AUTOCOMP_SHOW, 'Show Auto Completion', \
             'Show auto completion during dot syntax', \
             checkable=1)
except:
    # 2.3.3
    m.Append(ID_AUTOCOMP_SHOW, 'Show Auto Completion', \
             'Show auto completion during dot syntax', \
             kind=wxITEM_CHECK)

Any other menu init or methods to worry about?

ka

···

-----Original Message-----
From: wxpython-users-admin@lists.wxwindows.org
[mailto:wxpython-users-admin@lists.wxwindows.org]On Behalf Of Robin Dunn
Sent: Friday, April 05, 2002 2:47 PM
To: wxPython-users
Subject: [wxPython] 2.3.3 preview

I've uploaded a win32 preview of wxPython 2.3.3 to the project
files area on
Sourceforge. You can get it at:

wxPython - Browse Files at SourceForge.net
2-hybrid.e
xe

If you are not on Windows you can get the sources for this
preview from CVS
with the wxPy_2_3_3_pre tag. This time I remembered to tag the whole tree
(including wxWindows.)

There are still a few known issues, and several more things I
still wish to
add or fix for the final, but I thought that you would appreciate
being able
to get a taste of what's to come.

To all contributors, please double check your contributions and send me
patches for things that need changed/fixed. Or if you have any
new contribs
that need added, this is the time to send them to me.

BTW, there are a few API changes to watch out for that I wasn't able to
cleanly implement in a backwards compatible way. Probably the
most annoying
will be that the 'checkable' parameter in the wxMenu.Append method has
changed its name to 'kind' and takes one of the wxITEM_* values
instead of a
boolean.

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

Robin, can you at least suggest a workaround, so perhaps we can add a
specific check for 2.3.3 or do a try/except block to implement checkable?

The change was designed to be backwards compatible at the C++ level. (It is
the introduction of keyword args in wxPython that messes things up.) If you
don't use the keyword arg names then it works with either version:

    m.Append(ID_AUTOCOMP_SHOW, 'Show Auto Completion',
             'Show auto completion during dot syntax',
             1)

···

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

Okay, thanks Robin. I've updated PythonCard in cvs to not use the checkable
keyword arg, so PythonCard should work with 2.3.2.1 and 2.3.3.

ka

···

-----Original Message-----
From: wxpython-users-admin@lists.wxwindows.org
[mailto:wxpython-users-admin@lists.wxwindows.org]On Behalf Of Robin Dunn
Sent: Monday, April 08, 2002 2:21 PM
To: wxpython-users@lists.wxwindows.org
Subject: Re: [wxPython] 2.3.3 preview

>
> Robin, can you at least suggest a workaround, so perhaps we can add a
> specific check for 2.3.3 or do a try/except block to implement
checkable?

The change was designed to be backwards compatible at the C++
level. (It is
the introduction of keyword args in wxPython that messes things
up.) If you
don't use the keyword arg names then it works with either version:

    m.Append(ID_AUTOCOMP_SHOW, 'Show Auto Completion',
             'Show auto completion during dot syntax',
             1)

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

[Kevin Altis]

I noticed that standalone PyCrust included with the new wxPython,
labeled as
version 0.7.1 did work, but that the PyCrust in cvs does not. You
must have
made a workaround that Patrick didn't check into cvs?

I just checked in changes that fix this. So the version in CVS, PyCrust
0.7.2, is the one that should accompany the final release of wxPython 2.3.3.

···

---
Patrick K. O'Brien
Orbtech

[Kevin Altis]
> I noticed that standalone PyCrust included with the new wxPython,
> labeled as
> version 0.7.1 did work, but that the PyCrust in cvs does not. You
> must have
> made a workaround that Patrick didn't check into cvs?

I just checked in changes that fix this. So the version in CVS, PyCrust
0.7.2, is the one that should accompany the final release of wxPython

2.3.3.

Got it. Thanks.

···

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

Robin Dunn wrote:

I've uploaded a win32 preview of wxPython 2.3.3 to the project
files area on Sourceforge.

[wxPython-2.3.3pre3-Py22-hybrid + Python 2.2 on Win98]

In a project of mine I've been using a class derived from
wxSplitterWindow, and to my astonishment I've found that
SetSashPosition() no longer works when called from the __init__
method. It does work when you call it from somwhere else (e.g. an
idle event handler). It's not really an issue, as you can set the
initial sash position from SplitVertically() or SplitHorizontally()
directly, but it does break some code.

And now for something completely different, to coin a phrase. I've
noticed that the old flickering-when-resizing is back again. It
would seem that wxWindows developers have given up on the
wxCLIP_CHILDREN style altogether. This really annoys me, because
I've been working on a widget which was able to use this style
succesfully to avoid nearly all of the flicker. And now it flickers
again...

Preventing the sub-windows from damaging each other when moving them
proved to be pretty simple in my particular case, but in the more
general case - usually when sizers are involved - this can be
impossible, and at the very least unwieldy. But what _could_ be done
is have sizers check if moving a window would damage another window,
and mark that second window for re-painting. In the worst case
scenario, that certainly wouldn't make the flickering any worse, and
in the more common cases would prevent most of it.

Robert Amesz

[wxPython-2.3.3pre3-Py22-hybrid + Python 2.2 on Win98]

In a project of mine I've been using a class derived from
wxSplitterWindow, and to my astonishment I've found that
SetSashPosition() no longer works when called from the __init__
method. It does work when you call it from somwhere else (e.g. an
idle event handler). It's not really an issue, as you can set the
initial sash position from SplitVertically() or SplitHorizontally()
directly, but it does break some code.

Changes were made to wxSplitterWindow to make it behave better when it is
split but the window is not yet large enough to be split at the requested
position.

And now for something completely different, to coin a phrase. I've
noticed that the old flickering-when-resizing is back again. It
would seem that wxWindows developers have given up on the
wxCLIP_CHILDREN style altogether. This really annoys me, because
I've been working on a widget which was able to use this style
succesfully to avoid nearly all of the flicker. And now it flickers
again...

Preventing the sub-windows from damaging each other when moving them
proved to be pretty simple in my particular case, but in the more
general case - usually when sizers are involved - this can be
impossible, and at the very least unwieldy. But what _could_ be done
is have sizers check if moving a window would damage another window,
and mark that second window for re-painting. In the worst case
scenario, that certainly wouldn't make the flickering any worse, and
in the more common cases would prevent most of it.

If you have suggestions or solutions for this please bring it up on the
wx-dev list.

···

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