Plugin certification checklist - Revision history

Hall at 21:25, 2 January 2006

2006-01-02T21:25:44Z

2006-01-02T21:25:21Z

2006-01-02T21:04:02Z

‎Licensing Requirements

2006-01-02T21:02:00Z

2006-01-02T20:57:39Z

2006-01-02T20:56:28Z

2006-01-02T20:54:19Z

2006-01-02T20:51:54Z

2006-01-02T20:44:28Z

2006-01-02T20:42:24Z

@@ Line 6: / Line 6: @@
 * A plugin should display prominent action buttons ("Draw Graph", "Perform Calculation", etc).
 * Plugins should only interact with the application via built in events, no attempt to paint on other areas directly, or affect other internal system objects are allowed.
-* Plugins should avoid having tabs within their interface. Each plugin should be able to be contained within one screen so as to limit the application's interface complexity and to take advantage of the architectures modularity.
+* Plugins should avoid having tabs within their interface. Each plugin should be able to be contained within one screen so as to limit the application's interface complexity and to take advantage of the application's modularity.
 * All components must have a full help section.

@@ Line 6: / Line 6: @@
 * A plugin should display prominent action buttons ("Draw Graph", "Perform Calculation", etc).
 * Plugins should only interact with the application via built in events, no attempt to paint on other areas directly, or affect other internal system objects are allowed.
-* Plugins should avoid having tabs within their interface. Each plugin should be able to be contained within one screen so as to limit the application's interface complexity.
+* Plugins should avoid having tabs within their interface. Each plugin should be able to be contained within one screen so as to limit the application's interface complexity and to take advantage of the architectures modularity.
 * All components must have a full help section.

@@ Line 28: / Line 28: @@
 === Licensing Requirements ===
-* A plugin can only make use of code or libraries which are released under appropriate open source licenses. Currently any LGPL compatible license should be sufficient.
+* A plugin can only make use of code or libraries which are released under appropriate open source licenses. Currently any LGPL-compatible or BSD-compatible license should be sufficient.
 == Minor Items ==
 * Plugin should conform to look and feel guidelines, and should make use of standard button placements and layouts.

@@ Line 4: / Line 4: @@
 * All interface components (buttons, lists, etc.) of a plugin should always do something. Any buttons or elements that are not in use in a given situation should be disabled.
-* It should be clear to the user how to interact with the plugin just from viewing that plugin's interface. Plugins that operate on the results of other plugins should make that clear, or use sub-node datasets so that only appropriate plugins are displayed.
+* A plugin should display prominent action buttons ("Draw Graph", "Perform Calculation", etc).
 * Plugins should only interact with the application via built in events, no attempt to paint on other areas directly, or affect other internal system objects are allowed.
 * Plugins should avoid having tabs within their interface. Each plugin should be able to be contained within one screen so as to limit the application's interface complexity.
@@ Line 23: / Line 23: @@
 * Plugins should create dataset subnodes for their results so the user can see and navigate to the result.
 * Plugins should specify what datasets they can accept and process through the use of the @AcceptTypes annotation. They should only specify datasets that they can properly support and then will only be visible when relevant to the current data loaded.
 * Plugins should only generate events necessary to their function. Unnecessary event generation can seriously impact application performance.

@@ Line 3: / Line 3: @@
 === User Interface Requirements ===
-* All interface components (buttons, lists, etc.) of a plugin should be fully functional.
+* All interface components (buttons, lists, etc.) of a plugin should always do something. Any buttons or elements that are not in use in a given situation should be disabled.
 * It should be clear to the user how to interact with the plugin just from viewing that plugin's interface. Plugins that operate on the results of other plugins should make that clear, or use sub-node datasets so that only appropriate plugins are displayed.
 * Plugins should only interact with the application via built in events, no attempt to paint on other areas directly, or affect other internal system objects are allowed.

@@ Line 5: / Line 5: @@
 * All interface components (buttons, lists, etc.) of a plugin should be fully functional.
 * Plugins should only interact with the application via built in events, no attempt to paint on other areas directly, or affect other internal system objects are allowed.
 * All components must have a full help section.
-== Plugin Size ===
+=== Plugin Size ===
 * Plugins should not include large datasets or example data unless totally necessary. Large extra data should be downloaded seperately to save CVS overhead and to allow for easy plugin updates.

@@ Line 6: / Line 6: @@
 === Computation Requirements ===
-* Plugins should never initiate long running processing unless by explicit user request.
 * With any long running processing the user must be presented with a progress bar and ability to cancel operation.
 * Long running processes should always be executed in a worker thread to allow the user interface to be responsive. Helper classes will be provided to make this easy and consistent across the application.