Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update wx for 2024.1 #12551

Closed
2 tasks
seanbudd opened this issue Jun 15, 2021 · 18 comments · Fixed by #15544
Closed
2 tasks

Update wx for 2024.1 #12551

seanbudd opened this issue Jun 15, 2021 · 18 comments · Fixed by #15544
Labels
api-breaking-change merge-early Merge Early in a developer cycle p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation. wxPython3
Milestone

Comments

@seanbudd
Copy link
Member

seanbudd commented Jun 15, 2021

wxPython 4.2.0 has been released. Unlike the previous release, wxPython uses a wxWidgets release (3.2.0), instead of tracking the master branch (wxWidgets 3.1.4.XX) in wxPython 4.1.1.
Based on the changes to wxPython and wxWidgets it appears that there should be no API breaking changes as a result of upgrading to 4.2.0.

@seanbudd seanbudd added this to the 2022.1 milestone Jun 15, 2021
@seanbudd seanbudd modified the milestones: 2022.1, 2023.1 Jan 10, 2022
@seanbudd seanbudd changed the title Update wx for 2022.1 Update wx for 2023.1 Aug 16, 2022
@seanbudd seanbudd added wxPython3 p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation. api-breaking-change labels Aug 16, 2022
@feerrenrut feerrenrut added the merge-early Merge Early in a developer cycle label Sep 13, 2022
@codeofdusk
Copy link
Contributor

wxWidgets/Phoenix#1950 appears not to have been merged.

@codeofdusk
Copy link
Contributor

Blocking #12064.

@josephsl
Copy link
Collaborator

josephsl commented Oct 2, 2022

Hi,

While the wxPython issue mentioned is a key blocker, I think it would be best to proceed with the workaround for now as Python 3.7 will be end of life in June 2023 (come July 2023, and I think telling people that you need to use a version of Python that's no longer supported by Python Software Foundation can send mixed signals). Also, note that 32-bit wxPython 4.2.0 was not uploaded to Python Package Index, so we need to either create a repo for hosting 32-bit wxPython wheel or let Appveyor build the binary for us.

Thanks.

@seanbudd
Copy link
Member Author

blocked by wxWidgets/Phoenix#2235, there are no 32bit wheels of wxPython 4.2.0

@seanbudd
Copy link
Member Author

seanbudd commented Oct 11, 2022

This also blocking updating python to 3.10. Without updating to wxPython 4.2.0 and self-compiling 32bit, we will have to update to Python 3.8 or 3.9.

@codeofdusk
Copy link
Contributor

We should target 3.11 (slated for late October) provided that dependancies are functional.

@dpy013
Copy link
Contributor

dpy013 commented Oct 11, 2022

hello @seanbudd
It is recommended to use python 3.11, python 3.9 does not seem to have merged the fixed libffi.

@josephsl
Copy link
Collaborator

Hi,

32-bit Python wheels posted on wxPython issue 2235 comment - please give them a try. Thanks.

@seanbudd seanbudd modified the milestones: 2023.1, 2022.4, 2024.1 Oct 21, 2022
@seanbudd seanbudd changed the title Update wx for 2023.1 Update wx for 2024.1 Oct 21, 2022
@codeofdusk
Copy link
Contributor

@seanbudd Why has the milestone been set to 2024?

@seanbudd
Copy link
Member Author

@codeofdusk this and updating python are not scheduled until 2024.1

@seanbudd
Copy link
Member Author

seanbudd commented Oct 26, 2022

In the case of this issue, there's no known improvements from updating wxPython, and without 32bit wheels on pip, to update for 2023.1, we'd have to design a new system for incorporating the wheel.
If 32bit wheels are made available on pip in time for this to be merged early to 2023.1, we can consider including the update to wxPython.

@josephsl
Copy link
Collaborator

Hi,

Actually, you can force Pip to install a wheel from a URL, and I have managed to do just that with a 32-bit wxPython 4.2.0 wheel I built for Python 3.11. If this works, I think we can:

  1. Edit requirements.txt to state that wxPython 4.2.0 32-bit wheel will be fetched from a URL until a Pip build becomes available. This means whoever is going to keep the wheels updated must build a new one when a future wxPython version (currently 4.2.1) is released, something I'd be happy to do so for the time being.
  2. Whenever NVDA versions are bumped, check Pip and see if a wheel can be fetched from Python Package Index, and if so, edit requirements.txt.

For reference, wxPython 4.2.0 32-bit wheel for Python 3.7 which I built a few days ago can be found at:

https://github.com/josephsl/wxpy32whl/releases/download/4.2.0/wxPython-4.2.0-cp37-cp37m-win32.whl

Thanks.

@seanbudd
Copy link
Member Author

If we were to use a custom wheel, we would want it to be built either by NV Access directly (or indirectly via GitHub actions).
Have you documented the build process?
That would be helpful for creating a repo to build and host the wheels.

@seanbudd
Copy link
Member Author

It looks like Bookworm would also be interested in this: josephsl/wxpy32whl#1

@seanbudd
Copy link
Member Author

It would also be ideal to just use official wheels, and avoid picking up this extra maintenance burden.
The urgency with updating to 4.2.0 is tied to updating python, which is scheduled for 2024.1.
I would hope official wheels get published by then, otherwise I'd be concerned wxPython is dropping 32bit support, which is a bigger can of worms.

@josephsl
Copy link
Collaborator

Hi,

I'll document it in the rpo, but for reference:

  1. Obtain wheel, attrdict3, and requests via Pip.
  2. Install these three dependencies first.
  3. Run Pip again and install wxPython 4.2.0/create the hweel for it.

Thanks.

@josephsl
Copy link
Collaborator

Hi,

For now 32-bit buildbots are disabled for wxPython unless Robin finds a way to restore them. Even for 64-bit wheels, Python 3.8 or later is required to obtain official wheels for 4.2.0. There is also an issue with wxPython 4.2.0 where pyd files do not have file extensions if the wheel is built with Python 3.11. In the long-term, I expect packages to drop support for 32-bit after CPython itself drops 32-bit support, and I expect that'll be the case once Windows 10 support ends (as early as 2026 unless Python core developers say 32-bit will be supported for a while longer).

Thanks.

@seanbudd
Copy link
Member Author

seanbudd commented Jun 8, 2023

This now unblocked. wxPython 4.2.1 has now been released with Windows wheels

wxWidgets/Phoenix#2246 (comment)
https://github.com/wxWidgets/Phoenix/blob/master/CHANGES.rst#421-size-matters-not-yoda

@seanbudd seanbudd closed this as completed Jun 8, 2023
@seanbudd seanbudd reopened this Jun 8, 2023
@seanbudd seanbudd mentioned this issue Sep 28, 2023
5 tasks
seanbudd added a commit that referenced this issue Nov 7, 2023
Fixes #15742
Regression from #12551

Summary of the issue:
Run NVDA with a touchscreen computer and try tapping on the screen in rapid succession (for example, when invoking an object). The touch gesture fails due to a change in wxPython, where Timer.Start expects integers only, not floats.

Description of user facing changes
No errors or issues when using touch navigation

Description of development approach
Add typing to touchTracker to better understand the cause of the issue.
Convert the touch emit timer to use an integer
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-breaking-change merge-early Merge Early in a developer cycle p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation. wxPython3
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants