ginga: MultiDim unexpectedly inserts entries into ChangeHistory
Workflow to reproduce the problem:
- Start
MultiDim
local plugin. - Start
ChangeHistory
global plugin. - Load a data cube.
- With
ChangeHistory
(“History” tab) in view, click on “next slice” (double-arrow) button onMultiDim
and watch a new entry magically appears onChangeHistory
for that image. - Click on “next slice” again or “prev slice” to see another such entry.
Example screenshot:
I suspect this is caused by either block_callback('modified')
or unblock_callback('modified')
in MultiDim.py
. I just never caught this before until now because I rarely start up ChangeHistory
with data cubes, but I think this has been happening for a while.
This bug is harmless but confusing, in the sense that it does not actually change the input data cube, but merely reported that it has done so.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 15 (8 by maintainers)
Ok, after looking at the particular combination of tests, I think your modification will work. I’ll merge it and submit as a PR.
I think it may be slightly difficult, due to the fact that the
modified
callback is in only some cases tied to changes that should be recorded inChangeHistory
and then only because the user set some particular metadata in the channelinfo
for an image, prior to the change.One thing we might do is to detect that the plugin is trying to set the
reason_modified
attribute in the channelinfo
for an image, and throw up an error message then. We’d probably want to check very specifically for this attribute name, since there should be no real reason to disallow the plugin from otherwise adding arbitrary data to the info, as other plugins (e.g.Thumbs
, etc) already do.@pllim, please try this branch. You will need to update any plugins that make modification notices to follow the example in
Mosaic
.If this works for you I will submit it as a PR. I think it is cleaner than trying to guess which invocations of the ‘modified’ callback are significant.