Skip to content

Conversation

@bigsby-exe
Copy link

This PR adds a warning message for descriptions over 80 chars this is due to an issue packaging on Windows where the icon was getting truncated.

This is part of 3 PRs to update both the Windows app template and VisualStudio template to truncate descriptions over 256 chars & add a warning to briefcase
beeware/briefcase-windows-VisualStudio-template#68
beeware/briefcase-windows-app-template#72

This resolves issue: #2465

Unsure if I am doing something wrong but I can't get all the tests to pass even on a clean clone of the main repo.
I have managed to reduce some of the failures by adding tests for the extra checks I have added

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

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.

Thanks for the PR.

Regarding the test failures - the test failure is exactly what it says on the tin. The test is looking for a specific piece of text - and that text doesn't occur in the actual output. It's almost there... but there's a missing period.

However, in this case, I think the implementation isn't in quite the right place. As flagged inline, the current wording is a hard error, not a soft warning. The AppConfig object is a good place for hard errors - i.e., you can't use a config at all unless the version number is valid, for example. In this case, we can proceed - but we need to warn the user that the description will result in potentially unexpected behavior.

I'd suggest a better approach would be to use the finalize_app_config step - that's a step that will be run once, in a context where you have access to the console, so you can output a warning, rather than a hard error.

Comment on lines 43 to 45
def is_valid_description(description):
"""Determine if the description is not longer than 80 characters."""
return len(description) <= 80
Copy link
Member

Choose a reason for hiding this comment

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

As there's only one place where this logic is needed, and the logic is fundamentally pretty simple, factoring this out as a method is slightly overkill.

f"The description is {len(self.description)} characters long.\n"
"Longer descriptions should use the 'long_description' field.\n"
"On some platforms, descriptions may be truncated to fit platform limitations.",
)
Copy link
Member

Choose a reason for hiding this comment

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

There's a slight discrepancy here between the message and the way it's handled. The message suggests the content "may" be truncated; however, it will be impossible to reach that point, because any description over 80 characters will raise a hard error.

@bigsby-exe
Copy link
Author

Thanks for the feedback, I shall try and re-implement

@bigsby-exe
Copy link
Author

@freakboy3742 is this a better implementation?

@freakboy3742
Copy link
Member

@freakboy3742 is this a better implementation?

The approach is good; however, I'd be inclined to make it a check on the create command that applies for all platforms, rather than something specific to the Windows backend. While it only has immediate consequences for Windows, someone who is writing an app for Linux/macOS/whatever should be warned that future ports to Windows might be a problem.

As a heads up - the test failure isn't of your making; overnight, OpenSUSE has made a change to their repository that has broken Linux app support. We're still investigating the cause to see if it's something we need to work around, or if it's a case where they've messed up an update (which is something that happens way more often than it should with OpenSUSE).

@mhsmith
Copy link
Member

mhsmith commented Oct 1, 2025

The OpenSUSE issue has now been resolved.

@bigsby-exe
Copy link
Author

@freakboy3742 is this a better implementation?

The approach is good; however, I'd be inclined to make it a check on the create command that applies for all platforms, rather than something specific to the Windows backend. While it only has immediate consequences for Windows, someone who is writing an app for Linux/macOS/whatever should be warned that future ports to Windows might be a problem.

As a heads up - the test failure isn't of your making; overnight, OpenSUSE has made a change to their repository that has broken Linux app support. We're still investigating the cause to see if it's something we need to work around, or if it's a case where they've messed up an update (which is something that happens way more often than it should with OpenSUSE).

Thanks again for the feedback. That all makes sense so I will try and implement it on create for all platforms.
Also thanks for the note on the failing test, that did catch me off guard 🤣

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