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

Fixes an issue that causes linux applications to crash on Gtk 3. #3296

Merged
merged 4 commits into from
Mar 28, 2025

Conversation

LunaMeadows
Copy link
Contributor

@LunaMeadows LunaMeadows commented Mar 27, 2025

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:

  • All new features have been tested
  • All new features have been documented
  • I have read the CONTRIBUTING.md file
  • I will abide by the code of conduct

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.
@LunaMeadows
Copy link
Contributor Author

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?

@HalfWhitt
Copy link
Member

You're right, the errors in CI are from missing code coverage in the else you added. The testbed isn't currently run on Gtk 4, so that branch is never executed; adding # pragma: no cover to the end of line 41 should fix that.

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?

@LunaMeadows
Copy link
Contributor Author

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.

application_id=self.interface.app_id,
flags=Gio.ApplicationFlags.DEFAULT_FLAGS,
)
if GTK_VERSION < (4, 0, 0):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if GTK_VERSION < (4, 0, 0):
if GTK_VERSION < (4, 0, 0): # pragma: no-cover-if-gtk4

application_id=self.interface.app_id,
flags=Gio.ApplicationFlags.FLAGS_NONE,
)
else:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
else:
else: # pragma: no-cover-if-gtk3

@freakboy3742
Copy link
Member

Your diagnosis that this is GIO version dependent definitely checks out. DEFAULT_FLAGS has been historically working under CI, but that's only testing Ubuntu 24.04. If FLAGS_NONE is "more compatible", then it's definitely worth making the special case for GTK<3.

All I know for certain is the new flag argument causes gtk applications to not run at all on my system.

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.

You're right, the errors in CI are from missing code coverage in the else you added. The testbed isn't currently run on Gtk 4, so that branch is never executed; adding # pragma: no cover to the end of line 41 should fix that.

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 # pragma: no-cover-if-gtk3 to line 41, and corresponding # pragma: no-cover-if-gtk4 on line 36. That tells coverage (strictly, the conditional-coverage plugin) the conditions under which it's OK to accept coverage gaps. There are analogous conditional coverage #pragmas for Python versions, OS versions, etc, all defined in pyproject.toml.

@LunaMeadows
Copy link
Contributor Author

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.

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?

@freakboy3742
Copy link
Member

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.

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.

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.

Since it is a Gio issue and not just a gtk issue, would it be better to check against the Gio version?

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).

Copy link
Member

@freakboy3742 freakboy3742 left a 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!

@freakboy3742 freakboy3742 merged commit e1376f3 into beeware:main Mar 28, 2025
51 of 52 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants