id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	blockedby	blocking	notify_on_close	platform	project
1661	Support adding state managers from bundles	Conrad Huang	Conrad Huang	"Session state managers are useful mechanisms that provide a centralized resource (found via the session) for both managing features (e.g., presets) and for saving state in sessions.  Currently, most state managers are initialized by the core (the alignment state manager is initialized from a bundle via {{{custom_init}}}).  It would be nice to formalize the process for using bundles to implement state managers and their managed resources because it would help (a) limit number of changes to the core, and (b) allow more frequent updates via the toolshed.

The proposed changes are:

- Add {{{<Manager>}}} and {{{<Providers>}}} tag to {{{bundle_info.xml}}} schema.  These tags translate to ChimeraX classifiers in the generated {{{setup.py}}} file and will ultimately end up as metadata for the toolshed to read.
- Modify the toolshed to track ""generic"" state managers and providers in bundles and to initialize managers ""at the appropriate time.""
  * The {{{Bundle}}} API will need at least two new method: {{{manager_init}}} (for initializing a state manager) and {{{provider_run}}} (for invoking a particular provider, which may be lazily registered to delay importing a bundle package).  Other potential methods that may be added as needed include {{{manager_reset}}} and {{{provider_init}}}.
  * The {{{manager_init}}} method is called with the state name (e.g., ""presets"") to create the state manager instance, which is expected to query to toolshed for providers with the same name.  The state manager instance is returned so that the toolshed can register the state manager in the session.
  * The toolshed will treat bundles that define {{{manager_init}}} similarly to those that define {{{custom_init}}}.  The bundle package will be imported and the methods called **after all bundles have been read in** (this is ""the appropriate time"" for now, although it may be possible to support init-on-demand later).  This order is needed to guarantee that the toolshed ""knows"" all the providers for a state manager before trying to create the state manager.  {{{custom_init}}} will be called first, followed by {{{manager_init}}}.
  * Toolshed needs to support **run-time** ordering of bundles to make sure that ""provider"" bundles with {{{custom_init}}} methods are called **after** their state manager has been created.  This will require adding another tag to {{{bundle_info.xml}}}.
  * Before ""provider"" or ""manager"" bundles are unloaded, methods should be called to notify affected state manager instances.  When ""manager"" bundles are installed, the state manager instances should be created.  When ""provider"" bundles are installed, their state manager instances should be notified."	enhancement	closed	major	0.9	Tool Shed		fixed						all	ChimeraX