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

Fix aspect ratio computation in QgsLayoutItemMap::zoomToExtent #54827

Merged
merged 1 commit into from
Oct 5, 2023

Conversation

strk
Copy link
Contributor

@strk strk commented Oct 4, 2023

The rectangle should be checked for not being empty, not only null, to avoid division by zero

Extrapolated from the branch associated with the rectangle-null branch in GH-54646

@strk strk added Requires Tests! Waiting on the submitter to add unit tests before eligible for merging Bug Either a bug report, or a bug fix. Let's hope for the latter! labels Oct 4, 2023
@strk strk force-pushed the layoutitemmap-aspect_ratio branch from 857c388 to f097620 Compare October 4, 2023 10:04
@strk strk force-pushed the layoutitemmap-aspect_ratio branch 2 times, most recently from d1e4819 to 3d16dbd Compare October 4, 2023 14:00
@strk strk removed the Requires Tests! Waiting on the submitter to add unit tests before eligible for merging label Oct 4, 2023
@strk strk changed the title WIP: Fix aspect ratio computation in QgsLayoutItemMap::zoomToExtent Fix aspect ratio computation in QgsLayoutItemMap::zoomToExtent Oct 4, 2023
@github-actions github-actions bot added this to the 3.34.0 milestone Oct 4, 2023
@strk strk force-pushed the layoutitemmap-aspect_ratio branch from 3d16dbd to 4420c57 Compare October 4, 2023 22:24
Comment on lines 143 to 145
QVERIFY( mi.rect().isNull() ); // is this correct to expect ?
QVERIFY( mi.extent().isNull() ); // is this correct to expect ?
QCOMPARE( mi.scale(), 0 ); // is this correct ?
Copy link
Collaborator

Choose a reason for hiding this comment

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

these tests are meaningless really, let's drop them. If the default is changed so that initial scale is 10000 in future then it's not a bug which needs a test to fail.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's important to know what to expect because the zoomToExtent functionality depends on the current extent so in order to test that I need to know what to expect as a current extent when the item map is constructed. Is it supposed to depend on the layout instance ? The constructor documentation doesn't say anything about what to expect as the initial state, is that to be considered undefined behavior ? I think it's good for tests to fail if defaults are changed, as users and other parts of the code are likely depending on defaults ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe we should change defaults now if we believe the current defaults are not good. Like, should scale default to 1 instead of 0 ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

considered undefined behavior

Yes, I think so. There's a LOT of setup you need to do to get a map item into a valid state, eg:

  • set the position and size on the page
  • set the map extent
  • set the map crs

None of these are things we can set any meaningful defaults for, and it's all properties which aren't available through the layout at time of map item creation.

Copy link
Collaborator

Choose a reason for hiding this comment

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

should scale default to 1 instead of 0 ?

Scale is derived from the combination of map size & visible extent, it's not an explicit value.

(* that said, it would be very useful if map items and map settings had some mode to calculate the visible extent based on a fixed center point + defined scale. But it's not a trivial thing to introduce.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I think so. There's a LOT of setup you need to do to get a map item into a valid state, eg:

Would it make sense to expose an isValidState() method and throw an exception from method trying to access properties that would only make sense in "valid state" ? Also I see other tests ( like ::rendere() ) using QgsLayout.initializeDefaults(), is that what currently turns the state of the ItemMap valid ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Would it make sense to expose an isValidState() method

Yes! 💯

and throw an exception from method trying to access properties that would only make sense in "valid state"

That'd be an API break -- it'd have to wait for 4.0

QgsLayout.initializeDefaults(), is that what currently turns the state of the ItemMap valid ?

"Initializes an empty layout, e.g. by adding a default page to the layout. This should be called after creating
a new layout."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok for now I've rebased against current master branch and removed the rect and scale checks from the constructor test, leaving the one for current extent, which is what I'm using in ::zoomToExtent test. The isValidState() may be better to do in a separate PR

@strk strk force-pushed the layoutitemmap-aspect_ratio branch from 4420c57 to ece0fc1 Compare October 5, 2023 07:42
@strk
Copy link
Contributor Author

strk commented Oct 5, 2023

Spellchecker is not happy with the way I spell "behavior", but doesn't tell what would make it happy.
Here's how I spelled it: https://dictionary.cambridge.org/dictionary/english/behaviour
Here's the bot complaining: https://github.com/qgis/QGIS/actions/runs/6416093737/job/17419170341?pr=54827#step:5:9

Is developers life not heavy enough that we deserve this ? :)

@strk
Copy link
Contributor Author

strk commented Oct 5, 2023

Is developers life not heavy enough that we deserve this ? :)

I run the spellchecker locally and found how to spell that word (US english)
Also I've seen that exporting QGIS_CHECK_SPELLING env variable and installing silversearcher-ag package (on Ubuntu-22.04) has the spellchecker run by the scripts/prepare_commit.sh script, which I already have symlinked as .git/hooks/pre-commit

Do not even try to retain aspect ratio of current extent when
current extent is empty, just zoom to the requested extent.

Includes unit test for both constructor and zoomToExtent
@strk strk force-pushed the layoutitemmap-aspect_ratio branch from 43483c5 to 62a610e Compare October 5, 2023 11:16
@strk strk merged commit 85e5562 into qgis:master Oct 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants