#12669 closed enhancement (fixed)
Disable upload and save buttons when not needed
Reported by: | openstreetmap.org-user-d1g | Owned by: | Don-vip |
---|---|---|---|
Priority: | normal | Milestone: | 19.10 |
Component: | Core | Version: | |
Keywords: | disableditems upload save | Cc: | Klumbumbus |
Description
No point in showing "No changes to upload" error.
If there no data in layer or if command stack is empty, then simply suppress 0 upload.
Attachments (0)
Change History (11)
comment:1 by , 9 years ago
Cc: | added |
---|
comment:2 by , 9 years ago
Keywords: | disableditems added |
---|
comment:3 by , 6 years ago
Keywords: | upload save added |
---|---|
Priority: | trivial → normal |
Summary: | Disable "upload" button - similar to undo/redo → Disable upload and save buttons when not needed |
comment:4 by , 6 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 6 years ago
Milestone: | → 19.10 |
---|
comment:6 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:7 by , 6 years ago
Thats great! I'm just wondering in which situation the save button is disabled?
follow-up: 9 comment:8 by , 6 years ago
When the .osm layer is associated to a file which has not been modified. So right after you load an existing .osm file, or right after you save .osm data to an osm file. If you find some situations were it does not behave correctly, let me know.
comment:9 by , 6 years ago
Replying to Don-vip:
When the .osm layer is associated to a file which has not been modified. So right after you load an existing .osm file, or right after you save .osm data to an osm file.
Indeed.
If you find some situations were it does not behave correctly, let me know.
Hm it seems to be a bit fishy when doing undo redo. I faced different strange situation but was not able to properly reproduce them.
comment:10 by , 6 years ago
I made a few undo/redo tests before committing and noticed no problem. But I only tested common cases (node movement, object creation/deletion, tag deletion).
In 15404/josm: