-
-
Notifications
You must be signed in to change notification settings - Fork 703
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
Fixes an issue that causes linux applications to crash on Gtk 3. #3296
Conversation
Gio.ApplicationFlags.DEFAULT_FLAGS does not exist for Gtk 3 and errors out into an AttributeError failing to create the application. Reverting back to FLAGS_NONE fixes this issue.
Gio.ApplicationFlags.DEFAULT_FLAGS does not exist for Gtk 3 and errors out into an AttributeError failing to create the application. Reverting back to FLAGS_NONE fixes this issue.
I believe the fail is due to test coverage but I am not seeing a clear way to add test coverage for this. If that is correct, could I get some guidance on how to add that? |
You're right, the errors in CI are from missing code coverage in the I'm less certain about the cause of the crash you're fixing. I haven't personally touched the Linux backend, nor do I know much about it, but it is already being tested on Gtk 3 and hasn't been crashing from that. Perhaps that flag was added or removed in a minor version? |
I just stepped away from my computer for the night so I will test that tomorrow. I might of targeted the wrong part thinking on it now. The issue is the version of Gio I think. Default flags was added in 2.74 which is newer than flags none. I decided to just go with what was already present in the code as it seemed to follow the same approach for older version things. I can try and see if I can target specific Gio versions instead tomorrow instead of the gtk version. All I know for certain is the new flag argument causes gtk applications to not run at all on my system. |
gtk/src/toga_gtk/app.py
Outdated
application_id=self.interface.app_id, | ||
flags=Gio.ApplicationFlags.DEFAULT_FLAGS, | ||
) | ||
if GTK_VERSION < (4, 0, 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.
if GTK_VERSION < (4, 0, 0): | |
if GTK_VERSION < (4, 0, 0): # pragma: no-cover-if-gtk4 |
gtk/src/toga_gtk/app.py
Outdated
application_id=self.interface.app_id, | ||
flags=Gio.ApplicationFlags.FLAGS_NONE, | ||
) | ||
else: |
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.
else: | |
else: # pragma: no-cover-if-gtk3 |
Your diagnosis that this is GIO version dependent definitely checks out.
Out of interest - what system is this? Is it Debian 12 by any chance? It's useful to know - even if only informally - which user-space systems are imposing limits on upgrade strategies, and what those limits are.
Close, but not quite. We are running CI on GTK4; but obviously you can't do a single CI pass that covers both GTK3 and GTK4. So - we need to add |
I am running Ubuntu 22.04.5. I do have an issue with some package updates so not sure if this is affecting it but would still be good to consider to make sure gtk apps are supported still on older systems. Since it is a Gio issue and not just a gtk issue, would it be better to check against the Gio version? |
Ok - Ubuntu 22.04 is a Debian 12 derived release, so that explains it. We definitely want to retain support for Ubuntu 22.04 and Debian 12 for as long as we can (especially given that Debian 12 is currently the stable release of Debian). #3143 recently put that commitment to the test, but we've found a solution for that problem that is minimally disruptive. Historically, the reason we drop Ubuntu/Debian releases is because the Python version they provide is no longer supported - Ubuntu 18.04 LTS is technically still supported by Ubuntu, but we don't support Python 3.6. Based on that cadence, it would mean dropping Ubuntu 22.04 support in October next year, when Python 3.10 becomes EOL.
As noted on Discord - I'm OK with sticking with GTK as a proxy. If GTK3 has a constant that works for all versions, and it's functionally identical to the value that's only available on more recent GTK3 versions, then we might as well make the code simple and just use the "older" constant. Even if there is a minor change in behavior, the "older" constant is the value that was used historically, so it could be argued that this is just part of the "GTK4 includes upgrades" conversation. On a practical note - it also makes our testing simpler, because we can run tests on both GTK3 and GTK4, but explicitly testing on 2 versions of GIO would be a lot harder (or would at least require running 2 copies of the GTK3 test). |
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.
A minor tweak to the release note, but otherwise this looks great - thanks for the fix!
Gio.ApplicationFlags.DEFAULT_FLAGS does not exist for Gtk 3 and errors out into an AttributeError failing to create the application. Reverting back to FLAGS_NONE fixes this issue.
PR Checklist: