Bug #157


redesign of plugin architecture for dmanclient

Added by Matt Jones over 22 years ago. Updated almost 21 years ago.

morpho - general
Target version:
Start date:
Due date:
% Done:


Estimated time:


Need to redesign the plugin architecture for dmanclient so that it supports
dynamically added menus, toolbar items, and inter-plugin services. See the
diagram in cvs under design/plugin-services.gif for an overview of a potential

Related issues

Blocked by Morpho - Bug #200: New top-level container frameworkResolvedMatt Jones04/09/2001

Blocked by Morpho - Bug #203: new UI layout for the top-level containerResolvedMatt Jones04/09/2001

Actions #1

Updated by Matt Jones almost 22 years ago

Need to consider discussion in Santa Barbara regarding this, especially wrt
removing requirement of the hardcoded "tabbed" user interface.

Actions #2

Updated by Matt Jones almost 22 years ago

In Santa Barbara, we put the following topics under this task:
details of plug-in use, context sensitive menus, communication between plug ins,
keyboard shortcuts, etc.

Actions #3

Updated by Matt Jones almost 22 years ago

New design of plugin and services architecture has been checked into CVS under
the tag FRAMEWORK_REDESIGN_BRANCH. Now the ClientFramework finds the name of
plugins from the configuration file and loads them. This involves giving the
plugin an opportunity to register menus, toolbar items, and services, and add a
tab in the main user interface. Services are generic functions that the Plugin
will execute for other plugins, identified by name. Data is passed between
plugins using generic ServiceRequest and ServiceResponse objects. The
"morpho-design.vsd" visio file in the design module contains a UML class diagram
and a UML sequence diagram illustrating this architecture and the interactions
between plugins wrt services.

Each plugin can register a single tabbed pane that is inserted into the main
user interface. Our current plans are that there will only be one tab (for the
users data list), and that all other UI frames needed by plugins will be
implemented as independent windows. The plugin can (and should) register these
windows as they are created, at which point they become visible in the "Window"
menu that is implemented by the framework. Plugins should remove windows from
the framework when they are deleted or hidden. Dialog boxes and wizards that
are modal need not be listed in Windows menu, but generally non-modal windows
should be listed (registered) while they are visible.

Still to do:
1) Generalize menus so plugins can insert them in specific places,
not just append. (this is problematic becase determining an absolute index is
non-trivial). Add shortcut keys to menu items.
2) Generalize toolbars so that additional kinds of widgits can be inserted
(like checkboxes and textboxes) by plugins.
3) Add an API for communicating with Metacat. This will probably involve
creating a MetacatRequest object and a MetacatResponse object that can be
passed. This could possibly be implemented as a service that communicates
with Metacat, but might be simpler as direct access methods in the framework.

Actions #4

Updated by Matt Jones almost 22 years ago

Added menu placement features, so now plugins can determine the order of menus
and menu items.

Added utility routines for communicating with metacat so now plugins need not
know the network communication issues associated with sending data to metacat.
See the design/morpho-design.vsd Visio file for an overview of the API.

Actions #5

Updated by Matt Jones over 21 years ago

Redesigned to allow more flexibility in when menus and toolbars can be added.
Now they can be added by a call to ClientFramework at any time. Still need to
tweak the toolbar to allow positioning and alternative widgets.

Actions #6

Updated by Matt Jones over 21 years ago

Created new bug for the toolbar issues, so the plugin redesign is completed.

Actions #7

Updated by Redmine Admin almost 10 years ago

Original Bugzilla ID was 157


Also available in: Atom PDF