20100113 Test build available

Hi All,

I've made another test build which includes fixes for most of the issues that were reported with the previous build.

http://wxpython.wxcommunity.com/preview/20100113/

···

--
Robin Dunn
Software Craftsman
http://wxPython.org

Windows 7, Python 2.6.4

Installation -> ok.

Question.

When I uninstalled the 20100111 build, the (un)installer ask me if
I wish to remove unicows.dll located in c:\Python26.

This is somehow meaning, wxPython-unicode is supposed to work
on win98 (< win2k).

Is it worth maintaining this?, knowing

- that Python's > 2.5 do not support Windows < win2k and
- that win98/Python25/wxPython/unicows was problematic.

Jean-Michel Fauth

···

On 15 jan, 02:48, Robin Dunn <ro...@alldunn.com> wrote:

Hi All,

I've made another test build which includes fixes for most of the issues
that were reported with the previous build.

NameBright - Coming Soon

--
Robin Dunn
Software Craftsmanhttp://wxPython.org

No, we've already removed support for it from the build so it should be removed from the installer too. Thanks for noticing this.

···

On 1/15/10 1:24 AM, jmfauth wrote:

Question.

When I uninstalled the 20100111 build, the (un)installer ask me if
I wish to remove unicows.dll located in c:\Python26.

This is somehow meaning, wxPython-unicode is supposed to work
on win98 (< win2k).

Is it worth maintaining this?, knowing

- that Python's> 2.5 do not support Windows< win2k and
- that win98/Python25/wxPython/unicows was problematic.

--
Robin Dunn
Software Craftsman

Hi,
Thanks a lot for your work.

The following code segfaults on Mac OS X 10.4 :

import wx
App = wx.App(redirect=False)
Dial = wx.MessageDialog(None, "Test")
Dial.ShowModal()
Dial.Destroy() # <=== crash here

Fixed.

···

On 1/15/10 8:06 AM, cptnwillard wrote:

Hi,
Thanks a lot for your work.

The following code segfaults on Mac OS X 10.4 :

import wx
App = wx.App(redirect=False)
Dial = wx.MessageDialog(None, "Test")
Dial.ShowModal()
Dial.Destroy() #<=== crash here

--
Robin Dunn
Software Craftsman

Looking forward to some of the new stuff in 2.9/3.0!

Here's what I found on Linux/GTK, python 2.6:

1) Created a custom user with home directory /data2/home, and its own
python build in /data2/home/bin/python. Built wxpython with:

python build-wxpython.py --build_dir=../bld --install --prefix=/data2/home

thinking it should install the binaries and libraries in
/data2/home/bin and /data2/home/lib and wxpython in
/data2/home/lib/python2.6/site-packages, but instead installed into
/data2/home/wxpython2.9/[bin|lib] and
/data2/home/wxpython2.9/lib/site-packages. I wasn't expecting the
extra "wxpython2.9" path component to appear, but maybe that's by
design for the test release.

2) Starting the demo, 20 or so rows of pixels are cut off of the
bottom of the splash screen

3) The font size calculations seem to be off in RenderNative,
PlateButton. This could be something in my setup, although the wx
2.8.10 demo works fine

4) SplitterWindow has some border drawing artifact on the left panel
when changing the splitter position. Same issue appears in the
MultiSplitterWindow

5) The StatusBar demo incorrectly determines the size of the toggle
control button, and doesn't expand the three items to the full width
of the window.

6) The ToolBar demo has a grey box covering the tops of some of the
icons, but mousing over the icons redraws the icons correctly.

7) The ToolBook doesn't display the tool icons at all; all you see is
the main window

8) The initial view of the ListBox (and CheckListBox) don't include
the first highlighted item as they do in the 2.8.10 demo

9) There are various issues with the AGW widgets, but I don't know if
that's a result of being on GTK or 2.9

10) The CustomDragAndDrop demo doesn't display anything in the left
panel (i.e. no draw/drag radio buttons)

11) If I click on the AnimateCtrl demo then on BitmapFromBuffer, the
upper left image gets picked up from some of the images in the
AnimateCtrl! It's not consistent as to which data gets placed used;
in the example I included it's all from the hula-hoop guy, but
repeating the trial yields different results or combinations of
images. Very strange.

Rob

example4a.png

example4b.png

example5.png

···

On Thu, Jan 14, 2010 at 5:48 PM, Robin Dunn <robin@alldunn.com> wrote:

Hi All,

I've made another test build which includes fixes for most of the issues
that were reported with the previous build.

NameBright - Coming Soon

Hi,

Hi All,

I've made another test build which includes fixes for most of the issues that were reported with the previous build.

NameBright - Coming Soon

Tried installing both the python 2.5 and 2.6 versions on OSX 10.5 and get the following error when trying to run anything

Traceback (most recent call last):
   File "demo.py", line 3, in <module>
     import Main
   File "/Users/codyprecord/Desktop/wxPython-2.9.0.1.pre20100113/demo/Main.py", line 56, in <module>
     import wx
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.6/site-packages/wx-2.9.0-osx_carbon-unicode/wx/__init__.py", line 45, in <module>
     from wx._core import *
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.6/site-packages/wx-2.9.0-osx_carbon-unicode/wx/_core.py", line 4, in <module>
     import _core_
ImportError: dlopen(/usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.6/site-packages/wx-2.9.0-osx_carbon-unicode/wx/_core_.so, 2): Library not loaded: /BUILD/install-root/usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/i386/lib/libwx_osx_carbonud-2.9.dylib
   Referenced from: /usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.6/site-packages/wx-2.9.0-osx_carbon-unicode/wx/_core_.so
   Reason: image not found

Cody

···

On Jan 14, 2010, at 7:48 PM, Robin Dunn wrote:

[...]

Referenced from: /usr/local/lib/wxPython-
unicode-2.9.0.1.pre20100113/lib/python2.6/site-packages/wx-2.9.0-
osx_carbon-unicode/wx/_core_.so
Reason: image not found

Cody

I had the same error on OS X 10.4 PPC. Rebuilding wxPython from
scratch solved the problem. Maybe the reason why _core_.so cannot be
used from Python is that it was not built with the same version of
GCC ?

···

On Jan 16, 6:03 pm, Cody Precord <codyprec...@gmail.com> wrote:

The following code also segfaults or creates a malloc error in Python
(Mac OS X 10.4 PPC):

    import wx
    import wx.grid

    App = wx.App(redirect=False)
    Frame = wx.Frame(None)
    Grid = wx.grid.Grid(Frame)
    for _ in [None]:
        GridTarget = wx.PyDropTarget()
    Grid.SetDropTarget(GridTarget)
    for T in [Grid.GetTargetWindow()]:
        T.SetDropTarget(wx.PyDropTarget())
    GridTarget.SetDataObject(wx.DataObjectComposite())
    GridTarget.SetDataObject(wx.DataObjectComposite())
    GridTarget.SetDataObject(wx.DataObjectComposite())

The structure of the code may seem weird, but when I remove the for
loops, then the error does not appear anymore. You may have to play a
bit with it to have the same error on your computer...

Until I get the build fixed you can work around this one by setting DYLD_LIBRARY_PATH to /usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib

···

On 1/16/10 9:03 AM, Cody Precord wrote:

Hi,

On Jan 14, 2010, at 7:48 PM, Robin Dunn wrote:

Hi All,

I've made another test build which includes fixes for most of the
issues that were reported with the previous build.

NameBright - Coming Soon

Tried installing both the python 2.5 and 2.6 versions on OSX 10.5 and
get the following error when trying to run anything

Traceback (most recent call last):
File "demo.py", line 3, in <module>
import Main
File
"/Users/codyprecord/Desktop/wxPython-2.9.0.1.pre20100113/demo/Main.py",
line 56, in <module>
import wx
File
"//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.6/site-packages/wx-2.9.0-osx_carbon-unicode/wx/__init__.py",
line 45, in <module>
from wx._core import *
File
"//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.6/site-packages/wx-2.9.0-osx_carbon-unicode/wx/_core.py",
line 4, in <module>
import _core_
ImportError:
dlopen(/usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.6/site-packages/wx-2.9.0-osx_carbon-unicode/wx/_core_.so,
2): Library not loaded:
/BUILD/install-root/usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/i386/lib/libwx_osx_carbonud-2.9.dylib

Referenced from:
/usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.6/site-packages/wx-2.9.0-osx_carbon-unicode/wx/_core_.so

Reason: image not found

--
Robin Dunn
Software Craftsman

Hi,

Until I get the build fixed you can work around this one by setting DYLD_LIBRARY_PATH to /usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib

Thanks that got me running.

OSX 10.5 (intel)
Python 2.5.4

Issues first pass:

1) Trying to initialize or set the items in a choice control with an empty string [''] causes a crash.

     self._chFiles = wx.Choice(ctrlbar, wx.ID_ANY, choices=[''])
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/_controls.py", line 494, in __init__
     _controls_.Choice_swiginit(self,_controls_.new_Choice(*args, **kwargs))
PyAssertionError: C++ assertion "Assert failure" failed at /BUILD/wxPython-src-2.9.0.1.pre20100113/src/common/stockitem.cpp(202) in wxGetStockLabel(): invalid stock item ID

2) Showing the popup autocomp window for the stc in the demo causes this

Traceback (most recent call last):
   File "StyledTextCtrl_2.py", line 225, in OnKeyPressed
     self.AutoCompShow(0, " ".join(kw))
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/stc.py", line 2516, in AutoCompShow
     return _stc.StyledTextCtrl_AutoCompShow(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "Assert failure" failed at /BUILD/wxPython-src-2.9.0.1.pre20100113/src/osx/carbon/graphics.cpp(1623) in EnsureIsValid(): Cannot nest wxDCs on the same window

The popup list box does show afterwards and the images in it are clipped on the right side. The listbox looks like a different variant than the one is shown in 2.8 (everything looks a little bigger).

3) The scrolling performance in the stc samples in the demo is really bad. Scrolling with the mouse wheel barely moves it at all.

4) The AntiAliasing seems to be turned off by default in the STC, there also appears to be text drawing issues in the stc related to this, see bold text in any of the code views.

5) Dragging a window out in the agw aui demo causes this

Traceback (most recent call last):
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/lib/agw/aui/framemanager.py", line 8906, in OnMotion
     self.OnMotion_ClickCaption(event)
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/lib/agw/aui/framemanager.py", line 9099, in OnMotion_ClickCaption
     self.OnMotion_DragFloatingPane(event)
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/lib/agw/aui/framemanager.py", line 9317, in OnMotion_DragFloatingPane
     self.UpdateDockingGuides(paneInfo)
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/lib/agw/aui/framemanager.py", line 6497, in UpdateDockingGuides
     self.CreateGuideWindows()
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/lib/agw/aui/framemanager.py", line 4369, in CreateGuideWindows
     Host(AuiCenterDockingGuide(self._frame)))
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/lib/agw/aui/framemanager.py", line 2349, in __init__
     self.CreateShapesWithStyle()
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/lib/agw/aui/framemanager.py", line 2426, in CreateShapesWithStyle
     region.UnionRegion(wx.RegionFromPoints(tld))
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/_gdi.py", line 1617, in RegionFromPoints
     val = _gdi_.new_RegionFromPoints(*args, **kwargs)
TypeError: new_RegionFromPoints() takes at least 2 arguments (1 given)

6) Hovering the mouse back and forth over the zoom bar demo produced this

Traceback (most recent call last):
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/lib/agw/zoombar.py", line 1127, in OnPaint
     self.DrawButtons(dc)
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/lib/agw/zoombar.py", line 1141, in DrawButtons
     bitmap = button.GetBitmap()
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/lib/agw/zoombar.py", line 428, in GetBitmap
     return self._cachedBitmaps[self._width]
KeyError: -7

7) Go to any of the dialog samples in the demo, run and close one of the dialogs then try selecting something else in the tree.

Thread 0 Crashed:
0 libwx_osx_carbonud-2.9.dylib 0x0220032c wxTopLevelWindowMac::Destroy() + 16
1 _core_.so 0x0184deb5 _wrap_Window_Destroy + 79 (_core_wrap.cpp:37828)
2 org.python.python 0x003fadac PyObject_Call + 45 (abstract.c:1861)
3 org.python.python 0x004846e1 PyEval_EvalFrameEx + 14836 (ceval.c:3892)
4 org.python.python 0x0048771d PyEval_EvalCodeEx + 1819 (ceval.c:2875)
5 org.python.python 0x00484d9e PyEval_EvalFrameEx + 16561 (ceval.c:3708)
6 org.python.python 0x0048771d PyEval_EvalCodeEx + 1819 (ceval.c:2875)
7 org.python.python 0x0041c103 function_call + 220 (funcobject.c:517)
8 org.python.python 0x003fadac PyObject_Call + 45 (abstract.c:1861)
9 org.python.python 0x00402aa7 instancemethod_call + 401 (classobject.c:2519)
10 org.python.python 0x003fadac PyObject_Call + 45 (abstract.c:1861)
11 org.python.python 0x0047fe63 PyEval_CallObjectWithKeywords + 112 (ceval.c:3481)

8) Trying to run the ToolBar sample generates this

Traceback (most recent call last):
   File "ToolBar.py", line 201, in OnButton
     win = TestToolBar(self, self.log)
   File "ToolBar.py", line 132, in __init__
     size=(150,-1), style=wx.CB_DROPDOWN
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/_controls.py", line 590, in __init__
     _controls_.ComboBox_swiginit(self,_controls_.new_ComboBox(*args, **kwargs))
wx._core.PyAssertionError: C++ assertion "Assert failure" failed at /BUILD/wxPython-src-2.9.0.1.pre20100113/src/common/stockitem.cpp(202) in wxGetStockLabel(): invalid stock item ID

9) The Pickers sample shows some issues with displaying the ColourPicker control

10) The Mask sample causes the following

Traceback (most recent call last):
   File "Mask.py", line 95, in OnPaint
     dc.Blit(x,y, cx,cy, mdc, 0,0, code, True)
   File "//usr/local/lib/wxPython-unicode-2.9.0.1.pre20100113/lib/python2.5/site-packages/wx-2.9.0-osx_carbon-unicode/wx/_gdi.py", line 3606, in Blit
     return _gdi_.DC_Blit(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "Assert failure" failed at /BUILD/wxPython-src-2.9.0.1.pre20100113/src/common/dcgraph.cpp(878) in DoStretchBlit(): Blitting is not supported with this logical operation.

Cody

···

On Jan 18, 2010, at 9:46 PM, Robin Dunn wrote:

I believe you can safely ignore the error I reported yesterday. The
segfaults happens, but is probably due to the tricky way I use a grid
and its "target window" as drop targets.

···

On Jan 18, 6:35 pm, cptnwillard <cptnwill...@gmail.com> wrote:

The following code also segfaults or creates a malloc error in Python
(Mac OS X 10.4 PPC):

import wx
import wx\.grid

App = wx\.App\(redirect=False\)
Frame = wx\.Frame\(None\)
Grid = wx\.grid\.Grid\(Frame\)
for \_ in \[None\]:
    GridTarget = wx\.PyDropTarget\(\)
Grid\.SetDropTarget\(GridTarget\)
for T in \[Grid\.GetTargetWindow\(\)\]:
    T\.SetDropTarget\(wx\.PyDropTarget\(\)\)
GridTarget\.SetDataObject\(wx\.DataObjectComposite\(\)\)
GridTarget\.SetDataObject\(wx\.DataObjectComposite\(\)\)
GridTarget\.SetDataObject\(wx\.DataObjectComposite\(\)\)

The structure of the code may seem weird, but when I remove the for
loops, then the error does not appear anymore. You may have to play a
bit with it to have the same error on your computer...

Some weird stuff is happening in wx.CalendarCtrl()

Platform: Windows 7
Python Version: 2.6.4
wxPython version: 20100113

Traceback (most recent call last):
  File "D:\code\LicenseGen\LicenseGenFrame.py", line 152, in
OnGenerate
    l.append(self.LicenseExpires.GetDate().Format("%Y%m%d"))
  File
"C:\Python26\lib\site-packages\wx-2.9.0-msw-unicode\wx\calendar.py",
line
283, in GetDate
    return _calendar.CalendarCtrlBase_GetDate(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "dt == m_date" failed at
..\..\src\msw\
calctrl.cpp(244) in wxCalendarCtrl::GetDate(): mismatch between data
and control

Interestingly enough, I get a very similar error if I use the style
'wx.CAL_SHOW_HOLIDAYS'

Chris.

I know this should go on the Boa Constructor list (and I will, once
you release the final version of wxPython 2.9.x). Still, I thought it
should be pointed out that this version of wxPython COMPLETELY breaks
Boa Constructor.

wx.StandardPathsBase evidently now needs a wx.App instantiated first.
and the property wx.NO_3D no longer exists.

I'm not thinking these are bugs to be fixed, but I thought this list
should be made aware of the effects of the 2.9.x branch on Boa
Constructor.

Chris.

Hi All,

I've made another test build which includes fixes for most of the issues
that were reported with the previous build.

NameBright - Coming Soon

Looking forward to some of the new stuff in 2.9/3.0!

Here's what I found on Linux/GTK, python 2.6:

1) Created a custom user with home directory /data2/home, and its own
python build in /data2/home/bin/python. Built wxpython with:

python build-wxpython.py --build_dir=../bld --install --prefix=/data2/home

thinking it should install the binaries and libraries in
/data2/home/bin and /data2/home/lib and wxpython in
/data2/home/lib/python2.6/site-packages, but instead installed into
/data2/home/wxpython2.9/[bin|lib] and
/data2/home/wxpython2.9/lib/site-packages. I wasn't expecting the
extra "wxpython2.9" path component to appear, but maybe that's by
design for the test release.

Hmm, no it probably shouldn't be doing that. I think that if --wxpy_installdir is not specified then it should try to install to the default location for the python being used for the build. I'll look into it.

2) Starting the demo, 20 or so rows of pixels are cut off of the
bottom of the splash screen

I don't see this here. Perhaps there is some offset for the frame's caption bar that is being applied incorrectly (since the caption bar is hidden.) Do you have any special config settings for your window manager that might have an effect on this?

3) The font size calculations seem to be off in RenderNative,
PlateButton. This could be something in my setup, although the wx
2.8.10 demo works fine

The RendererNative sample uses fixed positions and sizes, so if your default font size is larger than expected then it can affect the layout like that. I did notice something that may be a GTK bug, it appears that the DrawTextCtrl renderer API is clearing part of the window at (0,0). It's pretty weird since as far as I can tell the proper coordinates are passed to the gtk APIs.

PlateButton seems to be dealing with different font sizes just fine for me, so yes, it may be something to do with your desktop or X-server config. Maybe DPI settings?

4) SplitterWindow has some border drawing artifact on the left panel
when changing the splitter position. Same issue appears in the
MultiSplitterWindow

This looks like it's related to the sunken border. There was recently a commit on the trunk related to GTK borders so hopefully this is already fixed for 2.9.1.

5) The StatusBar demo incorrectly determines the size of the toggle
control button, and doesn't expand the three items to the full width
of the window.

A couple tweaks to the demo takes care of this.

6) The ToolBar demo has a grey box covering the tops of some of the
icons, but mousing over the icons redraws the icons correctly.

This may be the same GTK bug I noticed in the Renderer sample. Leaving off the SearchCtrl causes it to not have the problem...

7) The ToolBook doesn't display the tool icons at all; all you see is
the main window

Weird. At least the C++ sample has the same problem so it's not my fault. :wink: I don't see anything in the revision log directly related to this so I can't make a quick fix for 2.9.0.1, but I don't think the trunk version has this problem so it may have been some other related fix... Anyway, this should be fixed in 2.9.1.

8) The initial view of the ListBox (and CheckListBox) don't include
the first highlighted item as they do in the 2.8.10 demo

I don't see this one.

9) There are various issues with the AGW widgets, but I don't know if
that's a result of being on GTK or 2.9

I'm sure Andrea would appreciate seeing some details on these issues.

10) The CustomDragAndDrop demo doesn't display anything in the left
panel (i.e. no draw/drag radio buttons)

This appears to be another example of the phantom clearing we've seen in some of the others items. The cleared area moves as the window is resized.

11) If I click on the AnimateCtrl demo then on BitmapFromBuffer, the
upper left image gets picked up from some of the images in the
AnimateCtrl! It's not consistent as to which data gets placed used;
in the example I included it's all from the hula-hoop guy, but
repeating the trial yields different results or combinations of
images. Very strange.

Looks like there's something going on with wx.BitmapFromBuffer for 24-bit RGB bitmaps. It's not writing the new data to the bitmap and it's just using what was already in that memory space.

···

On 1/16/10 8:44 AM, Rob McMullen wrote:

On Thu, Jan 14, 2010 at 5:48 PM, Robin Dunn<robin@alldunn.com> wrote:

--
Robin Dunn
Software Craftsman

1) Created a custom user with home directory /data2/home, and its own
python build in /data2/home/bin/python. Built wxpython with:

python build-wxpython.py --build_dir=../bld --install --prefix=/data2/home

thinking it should install the binaries and libraries in
/data2/home/bin and /data2/home/lib and wxpython in
/data2/home/lib/python2.6/site-packages, but instead installed into
/data2/home/wxpython2.9/[bin|lib] and
/data2/home/wxpython2.9/lib/site-packages. I wasn't expecting the
extra "wxpython2.9" path component to appear, but maybe that's by
design for the test release.

Hmm, no it probably shouldn't be doing that. I think that if
--wxpy_installdir is not specified then it should try to install to the
default location for the python being used for the build. I'll look into
it.

Updated to the 20100122 build and it does install into the correct prefix now.

2) Starting the demo, 20 or so rows of pixels are cut off of the
bottom of the splash screen

I don't see this here. Perhaps there is some offset for the frame's caption
bar that is being applied incorrectly (since the caption bar is hidden.) Do
you have any special config settings for your window manager that might have
an effect on this?

Hmmm. The 20100122 build still shows this, but it does appear to be
something in the XFCE xfwm4 window manager that's getting triggered by
2.9. If I change my .xinitrc to use the old-school twm, the problem
goes away.

Also, if I go back to 2.8.10.1, but stay with XFCE xfwm4, the problem goes away.

I have no idea what it is in my setup that's causing the problem with
2.9... I wonder if there's some window manager hint that's being
added by 2.9 that wasn't before?

3) The font size calculations seem to be off in RenderNative,
PlateButton. This could be something in my setup, although the wx
2.8.10 demo works fine

The RendererNative sample uses fixed positions and sizes, so if your default
font size is larger than expected then it can affect the layout like that.

Just like the above issue, changing to twm fixes the problem, so it's
definitely something in my setup that's being tweaked by 2.9.

8) The initial view of the ListBox (and CheckListBox) don't include
the first highlighted item as they do in the 2.8.10 demo

I don't see this one.

Even with twm, I still do see this problem.

Rob

···

On Fri, Jan 22, 2010 at 4:50 PM, Robin Dunn <robin@alldunn.com> wrote:

On 1/16/10 8:44 AM, Rob McMullen wrote:

Robin Dunn wrote:

Hi All,

I’ve made another test build which includes fixes for most of the
issues that were reported with the previous build.

There seems to have been an (intended?) API
change to wx.Boxsizer.Add().
When adding an item that is required to expand proportionally in both
directions, for example an image or bitmap, in version 2.8 it is
necessary to set the proportion parameter to (at least) 1 as
well as including wx.SHAPED in the flag parameter,
otherwise the item doesn’t expand at all. Including wx.EXPAND
in the flag has no effect (wxDesigner code sets both wx.EXPAND and
proportion=1)

In version 2.9.0.1 the proportion parameter can be zero when using
wx.SHAPED - it now does expand with a zero. If a value greater than
zero is used and wx.EXPAND is set then an assertion
error is raised:

wx._core.PyAssertionError: C++ assertion “(m_proportion==0)” failed at
…..\src\common\sizer.cpp(353) in wxSizerItem::InformFirstDirection():
Shaped item, non-zero proportion in wxSizerItem::InformFirstDirection()

File “F:\Python26-sp.V660\wx_core.py”, line 14360, in Layout

return core.Sizer_Layout(*args, **kwargs)

So for the moment, code generated by wxDesigner that requests
Proportional resize needs to be hand-modified either to remove
wx.EXPAND (actually wx.GROW) or to set proportion=0

Regards,

David Hughes

Forestfield Software

···

http://wxpython.wxcommunity.com/preview/20100113/

I haven't double checked it yet but I'm guessing that this is due to some box sizer changes that were made a while back that ended up being somewhat controversial on wx-dev. I believe that the changes have been redone in the current trunk in such a way that the old behavior was preserved in almost all cases, while still fixing the problem in a few corner cases that the original change was intended to fix. (I don't remember details about what those cases are however.)

I'll be switching wxPython to the wx trunk (2.9.1) in the near future so we can double check if the old sizer behaviors are restored.

···

On 1/26/10 11:20 AM, Robert Roebling wrote:

   Hi Robin,

Am Montag, den 25.01.2010, 09:56 +0000 schrieb David Hughes:

Robin Dunn wrote:

Hi All,

I've made another test build which includes fixes for most of the
issues that were reported with the previous build.

NameBright - Coming Soon

There seems to have been an (intended?) API change to
wx.Boxsizer.Add().

When adding an item that is required to expand proportionally in both
directions, for example an image or bitmap, in version 2.8 it is
necessary to set the proportion parameter to (at least) 1 as well as
including wx.SHAPED in the flag parameter, otherwise the item doesn't
expand at all. Including wx.EXPAND in the flag has no effect
(wxDesigner code sets both wx.EXPAND and proportion=1)

In version 2.9.0.1 the proportion parameter can be zero when using
wx.SHAPED - it now does expand with a zero. If a value greater than
zero is used and wx.EXPAND is set then an assertion error is raised:

wx._core.PyAssertionError: C++ assertion "(m_proportion==0)" failed
at ..\..\src\common\sizer.cpp(353) in
wxSizerItem::InformFirstDirection(): Shaped item, non-zero proportion
in wxSizerItem::InformFirstDirection()
.....
File "F:\Python26-sp.V660\wx\_core.py", line 14360, in Layout
   return _core_.Sizer_Layout(*args, **kwargs)

So for the moment, code generated by wxDesigner that requests
Proportional resize needs to be hand-modified either to remove
wx.EXPAND (actually wx.GROW) or to set proportion=0

I was not aware of any such changes and I wonder of breaking
code in this way was actually intended.

--
Robin Dunn
Software Craftsman