Shifting to 4.1 (Yes, really!)

Now that 4.0.5/6 are released I'm going to finally try (again) to shift my focus to be mostly on wxWidgets 3.1 and wxPython 4.1.

As part of that transition the snapshot builds will be watching and pulling code from the master branch, and will start having 4.1.x version numbers.

As mentioned in the other message, I plan on dropping Python 3.4 support. With 3.8 on the horizon it seems like a good time to trim one off the list. Depending on timing I expect to have at least one official release of 4.1 that still supports Python 2.7, probably more if 4.1 gets into a releasable state soon. But I hope to not keep it hanging around for much longer after 2.7 reaches its end of life.

Also, while I have your attention, I've seen a few messages lately where people are answering questions and such and are still sharing links to the Phoenix docs using the snapshots build of the docs, like https://wxpython.org/Phoenix/docs/html/. I would prefer that the official release documentation site be shared instead, like https://docs.wxpython.org/. That will help future-proof the locations if the Phoenix development things ever get moved or reorganized. Thanks!

···

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

Now that 4.0.5/6 are released I’m going to finally try (again) to shift
my focus to be mostly on wxWidgets 3.1 and wxPython 4.1.

As part of that transition the snapshot builds will be watching and
pulling code from the master branch, and will start having 4.1.x version
numbers.

That’s good news, but no ddl-s in win.whl-s.

Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 23 2018, 23:31:17) [MSC v.1916 32 bit

(Intel)] on win32

Type “help”, “copyright”, “credits” or “license” for more information.

import wx

Traceback (most recent call last):

File “”, line 1, in

File “D:\Python36\lib\site-packages\wx_init_.py”, line 17, in

from wx.core import *

File “D:\Python36\lib\site-packages\wx\core.py”, line 12, in

from ._core import *

ImportError: DLL load failed: The specified module could not be found.

Thanks Robin !

woss

Please use DependencyWalker on D:\Python36\lib\site-packages\wx_core.pyd to see what DLLs it is not able to load.

···

On Saturday, May 25, 2019 at 11:28:59 AM UTC-7, woss wrote:

Now that 4.0.5/6 are released I’m going to finally try (again) to shift
my focus to be mostly on wxWidgets 3.1 and wxPython 4.1.

As part of that transition the snapshot builds will be watching and
pulling code from the master branch, and will start having 4.1.x version
numbers.

That’s good news, but no ddl-s in win.whl-s.

Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 23 2018, 23:31:17) [MSC v.1916 32 bit

(Intel)] on win32

Type “help”, “copyright”, “credits” or “license” for more information.

import wx

Traceback (most recent call last):

File “”, line 1, in

File “D:\Python36\lib\site-packages\wx_init_.py”, line 17, in

from wx.core import *

File “D:\Python36\lib\site-packages\wx\core.py”, line 12, in

from ._core import *

ImportError: DLL load failed: The specified module could not be found.

Robin

  1. május 26., vasárnap 2:27:54 UTC+2 időpontban Robin Dunn a következőt írta:

Now that 4.0.5/6 are released I’m going to finally try (again) to shift
my focus to be mostly on wxWidgets 3.1 and wxPython 4.1.

As part of that transition the snapshot builds will be watching and
pulling code from the master branch, and will start having 4.1.x version
numbers.

That’s good news, but no ddl-s in win.whl-s.

Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 23 2018, 23:31:17) [MSC v.1916 32 bit

(Intel)] on win32

Type “help”, “copyright”, “credits” or “license” for more information.

import wx

Traceback (most recent call last):

File “”, line 1, in

File “D:\Python36\lib\site-packages\wx_init_.py”, line 17, in

from wx.core import *

File “D:\Python36\lib\site-packages\wx\core.py”, line 12, in

from ._core import *

ImportError: DLL load failed: The specified module could not be found.

Please use DependencyWalker on D:\Python36\lib\site-packages\wx_core.pyd to see what DLLs it is not able to load.

Robin

The result:

DependencyWalker_result.JPG

Missing WXBASE313U_VC140.DLL, WXBASE313U_NET_VC140.DLL, WXMSW313U_CORE_VC140.DLL.

Miss all WXBASE*, WXMSW* DLL file from wxPython-4.1.0a1.dev4069+849c70b0-cp36-cp36m-win32.whl. (and from another too).

woss

···

On Saturday, May 25, 2019 at 11:28:59 AM UTC-7, woss wrote:

Missing WXBASE313U_VC140.DLL, WXBASE313U_NET_VC140.DLL, WXMSW313U_CORE_VC140.DLL.

Miss all WXBASE*, WXMSW* DLL file from wxPython-4.1.0a1.dev4069+849c70b0-cp36-cp36m-win32.whl. (and from another too).

Ah, I didn’t realize at first that you were talking about the 4.1 snapshot builds. There are some other build problems on Windows that also need to be addressed and are on the TODO list. I’ve been working mostly on OSX first, because it is usually the most finicky and troublesome.

···

Robin

woss

  1. május 27., hétfő 6:25:43 UTC+2 időpontban Robin Dunn a következőt írta:

Missing WXBASE313U_VC140.DLL, WXBASE313U_NET_VC140.DLL, WXMSW313U_CORE_VC140.DLL.

Miss all WXBASE*, WXMSW* DLL file from wxPython-4.1.0a1.dev4069+849c70b0-cp36-cp36m-win32.whl. (and from another too).

Ah, I didn’t realize at first that you were talking about the 4.1 snapshot builds. There are some other build problems on Windows that also need to be addressed and are on the TODO list. I’ve been working mostly on OSX first, because it is usually the most finicky and troublesome.

Robin

woss

Then I will monitor it continuously.

Thanx.

woss

I expect that the next snapshot build should include everything it needs.

···

On Monday, May 27, 2019 at 12:19:55 AM UTC-7, woss wrote:

Then I will monitor it continuously.

Robin

  1. május 28., kedd 6:40:43 UTC+2 időpontban Robin Dunn a következőt írta:

Then I will monitor it continuously.

I expect that the next snapshot build should include everything it needs.

Robin

I tested fast with my project (circa 40000 lines) and basically everything works fine.

(ComboCtrl/ComboPopup, HtmlListBox, DataViewCtrl/PyDataViewModel/DataViewCustomRenderer, grid.Grid/GridTableBase/GridCellEditor/GridCellRenderer/gridmovers, RichTextCtrl, Printout/PrintPreview/PreviewFrame, SashLayoutWindow, agw.FlatNotebook, html2.WebView)

I had to change the handling of sizers because this wxwidgets version is more stricter. But these are my faults. For example:

wx._core.wxAssertionError: C++ assertion “!(flags & (wxALIGN_RIGHT | wxALIGN_CENTRE_HORIZONTAL))” failed at …\src\common\sizer.cpp(2083) in wxBoxSizer::DoInsert(): Horizontal alignment flags are ignored with wxEXPAND

or

wx._core.wxAssertionError: C++ assertion “!(flags & wxALIGN_CENTRE_HORIZONTAL)” failed at …\src\common\sizer.cpp(2100) in wxBoxSizer::DoInsert(): Horizontal alignment flags are ignored in horizontal sizers

Where I see a little changing thats the DataView Model/CustomRenderer handling. This also comes from strictering and new features.

I still have to work on this a little.

I generated executable with PyInstaller (single file option) and thats works fine too.

But at first sight everything works fine, of course the point is in the details.

Thanx Robin.

woss

P.S.:

I cannot see ‘locale’ folder in package.

···

On Monday, May 27, 2019 at 12:19:55 AM UTC-7, woss wrote:

Yes, I noticed that too. It should be fixed in the .dev4100 build.

···

On Tuesday, May 28, 2019 at 2:58:17 PM UTC-7, woss wrote:

P.S.:

I cannot see ‘locale’ folder in package.

Robin

I finally got around to testing the latest 4.1 nightly build today, and found about the same thing woss did, I had a dozen sizer parameters wrong and uncovered a bug (logged on github issues).

One that puzzled me for a bit looked like this:

gc.Clip(*self.dc.GetClippingBox())

which failed with “first parameter is bool, expected int” or something to that effect. Took me a while to figure out that GetClippingBox is no longer identical to GetClippingRect, having grown a new first return value in its output. So…

Is there a way to find the API changes, like you wrote when the Phoenix project was ongoing? That porting guide was invaluable, I just copied all the methods and class names from it, did a big grep across the source and pinpointed a lot of issues before even trying to run the code.

Eric

Unfortunately one of the advantages of the new Phoenix way of building wxPython (mostly automated wrapper generation from the wxWidgets docs) means that it’s a little too easy for little changes like this to slip through unnoticed.

I think GetClippingBox should probably keep the new return value since it’s the real wx API, but I’ll fix GetClippingRect to return just the rectangle, since it’s a wxPython addition.