24 September 2014 meeting

Attendees

TomG, Greg, Eric, Conrad

Agenda

Discussion about how Chimera2 Tool and Session APIs.

Action Items

None

Results

Agreed to Conrad's ToolShed/ToolFactory/Tool API after some tweaks. ToolShed is used to access list of all possible tools or all installed tools. ToolFactories contain metadata about tools for use in tool menus, model panel, and command line. ToolFactories can also be used to create Tool instances. Tools offer access to the tool functionality and have methods for serializing and deserializing tool data to/from sessions and scenes.

Greg discussed the separation between Session and Application objects. It was agreed that it would be nice if logging functionality was accessible outside of session objects so that such objects would not have to be passed through to every function that might want to log information or errors. This led into a long discussion of the costs and benefits of supporting multiple sessions in the same Chimera 2 process. No conclusion was reached and it was agreed to table the discussion until Monday's meeting with the full group, to garner additional input and possibly see if someone had a compelling use case that required multiple separate sessions.

Greg suggested that tools might simply put attributes into sessions and there would be a mechanism to prevent overwrites, but Conrad wanted to see more discipline in session attributes names, e.g. volume_data rather than mav391, the idea being would know to distribute their data into these well-known names so that other tools could find them if needed. There would be some place for tools to put miscellaneous tool data.

After much discussion, we agreed to the following initialization sequence:

1. Command line parsing
2. Preserve execution environment and monkey patch Python
   • Programs included with Chimera, eg al2co, will execute with the same environment as Chimera while system programs will execute with the preserved environment
3. Setup paths
   • Chimera paths (where "system" files live)
   • Per-user paths (where user data and tools live)
4. Initialize "stdio" or UI toolkit, eg splash screen
   • Establish presence and both status and error reporting channels
5. Initialize preferences
6. Initialize core, eg molecular data, surface, triggers, etc.
7. Initialize tool shed
   • Tool shed should support "safe mode" where no tools are loaded
   • Tool shed can support, possibly in conjunction with preferences, disabling certain tools
   • Find list of "tool" (which can be Chimera-style tools, commands, data formats, libraries, shared objects, etc)
   • Each tool has attributes, eg commands, menus, buttons, that can be queried, eg by UI
   • Each tool has methods, eg "start" for creating an instance of the tool
     • This is how tools can communicate
     • "start" returns a ToolInstance that implements the actual functionality
   • ToolInstance has a different API than Tool
   • Some Tool's have a singleton ToolInstance while others may be multi-instanced
8. Initialize UI and OpenGL
9. Add tool interfaces to UI
   • App queries tool shed for list of tools and then tells UI what to do
10. Execute custom Tool initialization code
    • App queries tool shed for list of tools and use Tool API to check for init code
11. Process command line requests
    • Open files
    • Run scripts
    • Start Tools
    • Restore sessions
12. Enter event loop

Eric described his approach to replacing Qt with wx in Hydra. We decided that we need more information on the Hydra architecture in order to decide on how best to proceed with further development (eg continue Hydra code base, move components into core, etc.)