-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
FIX: Don't let constrained_layout counter overflow #11330
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
FIX: Don't let constrained_layout counter overflow #11330
Conversation
4949b3c
to
5ebc6b0
Compare
Will this cause collisions if I create a figure, work on it for a bit, create a second figure, and then go back to working in the first figure? |
c0d2ed1
to
476b101
Compare
No, the name doesn't matter. But, if the name didn't matter, why was the name mattering? Turned out I'd hard coded the 3 digits into a few places, which was a mistake and the actual bug. |
4466bc4
to
e8f2a4d
Compare
7c2427f
to
96c4e28
Compare
96c4e28
to
b4ef275
Compare
@meeseeksdev backport to v2.2.x |
There seem to be a conflict, please backport manually |
Backport: Pull Request #11330: FIX: Don't let constrained_layout counter overflow
PR Summary
constrained_layout adds a unique number to each layout element. However, if many figures are open
this number was overflowing 1000. For some reason kiwisolver doesn't like the longer integers in the variable names (which is a bit of a mystery in itself, but kind of moot - if someone had 1000 elements in their constrained_layout I think they'd be pretty sad about how long it took to render).
This simply resets the iterator every time a new figure is made....
No test, as it requires making > 1000 elements, and it'd take quite a while (~60 s or so on my machine, though I'm doing a write as well). Also not sure how to check that the last CL is correct.
Test code:
PR Checklist