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!
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.
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.
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:
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.
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.
