-
Notifications
You must be signed in to change notification settings - Fork 16
Backport 0.5.1's run_gui function #99
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with my limited knowledge of clientside I can say this looks valid
|
|
||
| def run_gui(self): | ||
| """Import kivy UI system from make_gui() and start running it as self.ui_task.""" | ||
| if hasattr(SuperContext, "make_gui"): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How did we all miss that this if statement is backwards. We're checking if the context has make_gui then running the opposite
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I read this as: If the SuperContext has make_gui (i.e., we detected that we're in 0.5.1 RC or beyond), just call the parent's run_gui instead of doing our custom run_gui stuff. Since our custom run_gui is only needed for prior to RC. RC will call our make_gui instead of run_gui and expect a UI in response, so we don't want to override the parent run_gui anymore in that case.
Then, since we initially moved our old run_gui code into make_gui, anything prior to RC will -- via this backported run_gui method -- just call our stuff in make_gui (which was previously our run_gui code) to get a UI object, then run the old run_gui async.
I haven't tested the code, though, so can't attest whether it fixes the issue or not. Just appears to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fuzzy Is correct.
If CommonContext has a make_gui, it's 0.5.1+, and we run it's run_gui.
If it doesn't have it, we run the below code, which is a copy of 0.5.1RC1's run_gui.
The reason I did it this way is so it doesn't override potential bugfixes or upgrades to the function in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Attempting to actually run this on 0.5.0 gives this error
Traceback (most recent call last):
File "multiprocessing\process.py", line 314, in _bootstrap
File "multiprocessing\process.py", line 108, in run
File "C:\ProgramData\Archipelago\custom_worlds\src.apworld\src\ManualClient.py", line 758, in launch
asyncio.run(main(args))
File "asyncio\runners.py", line 190, in run
File "asyncio\runners.py", line 118, in run
File "asyncio\base_events.py", line 653, in run_until_complete
File "C:\ProgramData\Archipelago\custom_worlds\src.apworld\src\ManualClient.py", line 734, in main
ctx.run_gui()
File "C:\ProgramData\Archipelago\custom_worlds\src.apworld\src\ManualClient.py", line 224, in run_gui
ui_class = self.make_gui()
^^^^^^^^^^^^^^^
File "C:\ProgramData\Archipelago\custom_worlds\src.apworld\src\ManualClient.py", line 229, in make_gui
ui = super().make_gui() # before the kivy imports so kvui gets loaded first
^^^^^^^^^^^^^^^^
AttributeError: 'super' object has no attribute 'make_gui'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Manual build was on source as of today
Universal Tracker is v0.1.11 - the latest build that is functional on 0.5.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. yep. That's on me for not testing well enough.
This was the easiest way to do it