![[ChimeraX Issue Tracking System]](/trac/ChimeraX/chrome/site/ChimeraX-icon.svg){kind=icon}
Changes between Version 6 and Version 7 of Session2
- Timestamp:
- Oct 1, 2015, 2:02:56 PM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Session2
v6 v7 3 3 == Background == 4 4 5 From the user perspective, Chimera2 is an application with a suite of tools. In any given session, there may be some user data (e.g., molecules and volumes) and some active tool s (e.g., Reply Log and Command Line). One of the required functionality of Chimera2 is to be able to save the current state of the session, and then resume the session in the same state at the future time. This sounds simple enough, but there are some details that need to be explicitly enumerated, as not everyone will agree what consists "the state of the session".5 From the user perspective, Chimera2 is an application with a suite of tools. In any given session, there may be some user data (e.g., molecules and volumes) and some active tool GUIs (//e.g.//, Reply Log and Command Line). One of the required functionality of Chimera2 is to be able to save the current state of the session, and then resume the session in the same state at the future time. This sounds simple enough, but there are some details that need to be explicitly enumerated, as not everyone will agree what consists "the state of the session". 6 6 7 From the developer side, we can distinguish a couple different types of data. Some data are the same for all sessions; for example, start-up preferences and the list of installed tools. Some data are different for different sessions; for example, the list of _active_ tools and the currently opened data files. Let's call the former "initial data" and the latter "session data". Chimera2's "state of the session" consists only of "session data". This means that if the user (a) saves a session, and then (b) changes his start-up preference (e.g., background color) and it was not explicitly overridden in a session (e.g., by changing the background color), then (c) on resumption, the session will use the new background color. Clearly, this may be unexpected for the user. We will need to define what data normally defined by "initial data" that should always be saved as "session data" so that these surprises are minimized. (The answer is not "all of them" because clearly the list of installed tools may change, and additions and deletions cannot be ignored.)7 From the developer side, we can distinguish a couple different types of data. Some data are the same for all sessions; for example, start-up preferences and the list of installed tools. Some data are different for different sessions; for example, the list of active tool GUIs and the currently opened data files. Let's call the former "initial data" and the latter "session data". Chimera2's "state of the session" consists only of "session data". This means that if the user (a) saves a session, and then (b) changes his start-up preference (//e.g.//, background color) and it was not explicitly overridden in a session (//e.g.//, by changing the background color), then (c) on resumption, the session will use the new background color. Clearly, this may be unexpected for the user. We will need to define what data normally defined by "initial data" that should always be saved as "session data" so that these surprises are minimized. (The answer is not "all of them" because clearly the list of installed tools may change, and additions and deletions cannot be ignored.) 8 8 9 9 (Chimera2 data can be categorized as raw data, GUI data, and organizational data. Expound.) 10 11 === What is a Tool? === 12 13 The word tool is used in two different ways in Chimera2: 14 1. A chunk of functionality (code) from the tool shed 15 2. GUIs that the user can start via a menu 16 17 In this document, tool, by itself, refers to the code. 10 18 11 19 === Data Types === … … 48 56 Session attributes: 49 57 * open models 50 * open tool s58 * open tool GUIs 51 59 * running tasks 52 60 * scenes … … 55 63 * view (camera, lighting, clipping, etc.) 56 64 * selections (TODO) 65 * tool non-GUI data 57 66 58 67 Nested data: 59 * Tool GUI state68 * Tool GUI data 60 69 * molecules: atoms/bonds/residues & graphical state 61 70 * pseudobonds … … 64 73 * atom/bond annotations 65 74 66 Note that "tool" state may be in a session attribute rather than in the GUI instance. 75 The non-GUI state of a tool should be kept in a session attribute 76 or model rather than an instance of the tool's GUI class. 67 77 68 78 === Issues === 69 79 80 * Can we provide a simple state API? 81 * just hand off object 70 82 * How to give dependencies for ordering session data? 71 83 * naive data with back references are circular 72 84 * may need to give before and after dependencies 85 * how to handle dependencies between models? 73 86 * What is the granularity? 74 87 * Can we guarantee non-circular references? 75 * Can we provide a "simple" API for tools?76 88 77 89 == Possible Solution == … … 87 99 * molecular data is in a model 88 100 * session gets a model from its list of models 89 * a tool may provide a new model that depends on molecular data and tool state101 * a tool may provide a new model that depends on molecular data and tool non-GUI state 90 102 * so some models will need to saved before others 91 * so some tools may need to saved before associated model 92 * does that mean that tools are saved first? 103 * some tool non-GUI state may need to saved before associated model 104 * does that mean that tool non-GUI state is saved first? 105 * note that the tool GUI state is saved separately 93 106 94 107 How the data is organized in the session does not match the order in which the data needs to be saved. 95 96 108 97 109 === The Solution === … … 107 119 === Tool Classes === 108 120 109 * All classes exported by tools need to have a 'tool_info' attribute, a !ToolInfo instance 121 * All classes exported by tools need to have a 'tool_info' attribute, a !ToolInfo instance so the session code knows which tool is needed to reconstruct it 110 122 * !ToolInfo needs the State version in addition to the tool version 111 123 * When registering a tool's commands, it needs the !ToolInfo instance, just like starting a tool's GUI to be able set the the 'tool_info' attribute if there is no GUI 112 * The tool's module needs a 'get_class' function to return the class associated with a name. 113 * Tool classes might have an alternate initializer if attributes are not simple (like pickle) 124 * The tool's module needs a 'get_class' function to return the class associated with a name 125 * for security and allows renaming 126 * Tool classes have an alternate initializer if attributes are not simple (like pickle)
