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

Verify correct use of Viewport vs. ContentSize #3455

Open
tig opened this issue May 8, 2024 · 1 comment
Open

Verify correct use of Viewport vs. ContentSize #3455

tig opened this issue May 8, 2024 · 1 comment
Labels
Milestone

Comments

@tig
Copy link
Collaborator

tig commented May 8, 2024

I think there may still be cases where built-in Views are using Viewport.Size for things where they should be using ContentSize.

This Issue should be closed once an audit is completed any issues are fixed.

Example: The Pulse function in ProgressBar

It should be possible to write an "All views" unit test that tests for these issues.

@tig tig added the bug label May 8, 2024
@dodexahedron
Copy link
Collaborator

dodexahedron commented May 9, 2024

General future commentary based on this:

An analyzer would be helpful for these situations, to catch them at design-time, in-context. Not worth it if they're super-temporary, though, usually, of course.

Otherwise, whenever there's a simple heuristic to follow for something, writing an analyzer is pretty darn simple. It's essentially the language syntax-aware, code-aware, compilation-aware, and various other context-aware bigger cousin of Edit -> Find with fancy output capabilities and optional fix proposals.

The rest1 of the story...

Just more oooh ahhh stuff

Also cool is that a unit test and an analyzer for the same purpose tend to share a lot of the same code or at least the same logic, so they're also easy to add post-hoc.

And if you configure the diagnostic from the analyzer to be an error, the problem never even gets as far as the unit tests, and doesn't need new tests to be written for code written after the test is written (unless you cheat and suppress it or turn it off in your environment, anyway).

Not that that means tests shouldn't still be written for stuff subjected to analyzers, of course - just a CodeQuality++ thing with lasting effects. 😄

And if you want code generation for something you have an analyzer for, the analyzer is already half of the generator.

Footnotes

  1. RIP, Mr Kasem

@tig tig added this to the V2 Beta milestone May 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Status: 📋 Approved - Need Owner
Development

No branches or pull requests

2 participants