2. Contexts

A context represents a group of plugins working together. A context is constituted of a main window acting as the parent of all other plugin forms. When this main window is closed, the context is closed with all plugins contained therein. In a given context, plugins defined as singleton (such as OrsBasicManipulate) may have a single instance only.

The WorkingContext defines a dictionary of entities independent for each context. For instance, the selection in a context is completely independent of the selection in another context. It is the case also for the current global state. Most of the WorkingContext methods used to query and/or modify the entities require a plugin instance to determine in what context the information should be taken from or be set in.

Note

Each context is independent of all other contexts in the use of plugin and entities, but they share the same database of objects (datasets, ROIs, annotations, …). It is the responsibility of each context to manage what objects are presented in the workflow.

The organization of plugins in a context may be quite free (as in the main Dragonfly context), where most plugins may be started and closed, moved, docked or floating. Some contexts may be created to guide a specific set of tasks. In such contexts, the most relevant plugins are opened and put in a specific location. Contexts may define also a set of forbidden actions and states to restrict the workflow and tools that can be used. A more specialized kind of context is wizards, where the workflow is broken in a set of pages (named wizard pages).

Some contexts are defined as modal. When such a context is opened, the interactions of the user are limited to that context only until that context is closed.

2.1. Architecture

To define a new context, a new class inheriting :class:ORSServiceClass.OrsPlugin.orsMainPluginContext.OrsMainPluginContext has to be generated.

Because this class inherits from :class:ORSServiceClass.OrsPlugin.orsPlugin.OrsPlugin, the new class will have all the features of a plugin, including the possibility to define interface methods, menu items, actions, states, interests and forms (UI).

This class will be known as the definition of the main plugin in context.

Note

A general design rule is that each plugin must be independent. It means that:

• all modules of a plugin should never import any module of another plugin;
• the functionality of a plugin should never rely on the presence (instantiation) of another plugin.

However, for the main plugin in context, this rule is not applicable as it is in charge of the specific workflow. That class is allowed to know the definitions of other plugins. It has also a right to instantiate and deleted instances of these plugins (those alive in his context). Moreover, it has a right to put the forms of the plugins at a specific location in his layout (form).

At the instantiation of that plugin, a new context will be created. A call to setup the context should then be done to:

• instantiate all required plugins;
• define context restrictions (actions, states, …);
• open the main window with the mainform of the main plugin in context and all plugin forms;
• initialize the menu (if wanted);
• perform any other task to initialize the context (views, text presenters, …).