ToolInstance id problem restoring session

[goddard@…]

The following bug report has been submitted:
Platform:        Darwin-18.6.0-x86_64-i386-64bit
ChimeraX Version: 0.91 (2019-06-24)
Description
Tools.restore_snapshot()  updates Tools._tool_instances[id] = tool using the id values from when the session was saved.  But the ToolInstance.__init__() has already added the ToolInstance by calling Tools.add([self]) assigning it a new id.  This can result in a tool getting two entries in the Tools._tool_instances dictionary or an existing (session enduring) tool in _tool_instances being replaced by the restore_snapshot() code.

The duplicate tool case happened in my port of Segger restoring a session with the Segment Map tool.

A solution might be that the Tools.restore_snapshot() simply does not need to restore the id since restoring each ToolInstance assigns a new id.  But I don't know if there are other things in the session that reference the old tool id.


Log:
UCSF ChimeraX version: 0.91 (2019-06-24)  
© 2016-2019 Regents of the University of California. All rights reserved.  
How to cite UCSF ChimeraX  




OpenGL version: 4.1 ATI-2.9.26
OpenGL renderer: AMD Radeon Pro 580 OpenGL Engine
OpenGL vendor: ATI Technologies Inc.

[Tom Goddard]

This needs a fix soon since Segger session restore fails because of this bug and I will be showing that a the Stanford cryoEM workshop. I have to create the tutorial for that workshop this week.

[Greg Couch]

The only code that uses the integer id is blastprotein so users can refer to specific instances. And the unused active tools tool. Eric has a different way of referring to sequence tools that is more descriptive. Perhaps these can be techniques can be merged.

[Tom Goddard]

I made Tools not attempt to restore tool id numbers -- instead new tool id numbers are assigned.

[Greg Couch]

blastprotein should use its own id space like alignments do instead of the tool id.

[Greg Couch]

Removed ToolInstance.id since it no longer needed.