Opened 3 years ago
Closed 22 months ago
#21886 closed defect (fixed)
[patch] Download Dialog incorrectly reports note area rejection
Reported by: | gaben | Owned by: | team |
---|---|---|---|
Priority: | minor | Milestone: | 23.05 |
Component: | Core | Version: | |
Keywords: | template_report download note area reject | Cc: |
Description
What steps will reproduce the problem?
- Open download dialog
- Play with the bounding box while only the OSM data download checked
- Repeat step 2 with notes checked only
What is the expected result?
For note download the allowed bounding box is 100x greater than data, so the message should reflect that.
What happens instead?
The note's allowed bounding box size (25) ignored, the data restrictions (0.25) used instead.
Please provide any additional information below. Attach a screenshot if possible.
This patch fixes the issue, but the existing code not working as expected. See the comment.
-
src/org/openstreetmap/josm/gui/download/OSMDownloadSource.java
340 340 } 341 341 342 342 displaySizeCheckResult(DOWNLOAD_SOURCES.stream() 343 // this line doesn't work, but should: .filter(IDownloadSourceType::isEnabled) 344 .filter(type -> type.getCheckBox().isSelected()) //this works 343 345 .anyMatch(type -> type.isDownloadAreaTooLarge(bbox))); 344 346 } 345 347 … … 414 416 @Override 415 417 public boolean isDownloadAreaTooLarge(Bounds bound) { 416 418 // see max_request_area in 417 // https://github.com/openstreetmap/openstreetmap-website/blob/master/config/ example.application.yml419 // https://github.com/openstreetmap/openstreetmap-website/blob/master/config/settings.yml 418 420 return bound.getArea() > Config.getPref().getDouble("osm-server.max-request-area", 0.25); 419 421 } 420 422 } … … 492 494 @Override 493 495 public boolean isDownloadAreaTooLarge(Bounds bound) { 494 496 // see max_note_request_area in 495 // https://github.com/openstreetmap/openstreetmap-website/blob/master/config/ example.application.yml497 // https://github.com/openstreetmap/openstreetmap-website/blob/master/config/settings.yml 496 498 return bound.getArea() > Config.getPref().getDouble("osm-server.max-request-area-notes", 25); 497 499 } 498 500 }
Attachments (1)
Change History (18)
comment:1 by , 3 years ago
Keywords: | download note area reject added |
---|
comment:2 by , 3 years ago
Summary: | Download Dialog incorrectly reports note area rejection → [WIP patch] Download Dialog incorrectly reports note area rejection |
---|
comment:3 by , 3 years ago
comment:4 by , 3 years ago
It looks like it is due to the preferences not being updated when the checkbox state changes.
isEnabled()
calls getBooleanProperty().get()
.
EDIT: And the answer is in the javadoc
Determines the last state of the download type
comment:5 by , 3 years ago
Is it desired? Because we are now dealing with two states. One for live and the other for stored checkbox (BooleanProperty) state.
For this reason, the javadoc is misleading.
comment:6 by , 3 years ago
I cannot remember exactly why I did that, but most likely due to having a Cancel
button (AKA don't persist changed state when user has canceled), which would kind of argue against live updates to the property.
comment:7 by , 3 years ago
follow-up: 12 comment:8 by , 3 years ago
In that case, we might as well add a new checkbox listener that updates the preferences. Which means we can remove the call in rememberSettings. But only if we notify plugins that use it.
comment:9 by , 3 years ago
I'm not familiar with Java GUI programming, but I see listeners for download source checkboxes e.g. here.
comment:12 by , 2 years ago
Replying to taylor.smock:
In that case, we might as well add a new checkbox listener that updates the preferences. Which means we can remove the call in rememberSettings. But only if we notify plugins that use it.
How can I check which plugins are using the rememberSettings()
function?
comment:13 by , 2 years ago
I'd probably start by doing a grep
in a JOSM svn checkout (the one with core plugins).
Beyond that, we have a (currently broken) check-plugins
ant target, which someone should probably fix.
I had a script for checking plugins using GitLab CI, but I don't know if it still works. It used japi.
comment:14 by , 23 months ago
I found three usages so far:
- plugins/wikipedia/src/main/java/org/wikipedia/gui/SophoxDownloadReader.java:240
- plugins/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/download/CadastreDownloadSourcePanel.java:181
- plugins/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/download/CadastreDownloadSourcePanel.java:125
Don't know how to proceed :(
by , 23 months ago
Attachment: | josm_21886.patch added |
---|
comment:15 by , 23 months ago
Milestone: | → 23.04 |
---|---|
Summary: | [WIP patch] Download Dialog incorrectly reports note area rejection → [patch] Download Dialog incorrectly reports note area rejection |
The attached patch should not break plugins.
Ping/up/whatever. I have no idea why
IDownloadSourceType::isEnabled
isn't working.