| Home >> All >> org >> eclipse >> pde |
| • | org.eclipse.pde.ant.* (1) | • | org.eclipse.pde.core.* (40) | • | org.eclipse.pde.internal.* (805) |
| • | org.eclipse.pde.ui.* (28) |
Package Samples:
• org.eclipse.pde.ui.internal.samples
• org.eclipse.pde.ui.templates
• org.eclipse.pde.ui
• org.eclipse.pde.internal.ui.model.plugin
• org.eclipse.pde.internal.ui.model.bundle
• org.eclipse.pde.internal.ui.model.build
• org.eclipse.pde.internal.ui.model
• org.eclipse.pde.internal.ui.wizards.tools
• org.eclipse.pde.internal.ui.wizards.templates
• org.eclipse.pde.internal.ui.wizards.site
• org.eclipse.pde.internal.ui.wizards.plugin
• org.eclipse.pde.internal.ui.wizards.imports
• org.eclipse.pde.internal.ui.wizards.feature
• org.eclipse.pde.internal.ui.wizards.extension
• org.eclipse.pde.internal.ui.wizards.exports
• org.eclipse.pde.internal.ui.wizards
• org.eclipse.pde.internal.ui.view
• org.eclipse.pde.internal.ui.util
• org.eclipse.pde.internal.ui.search
• org.eclipse.pde.internal.ui.properties
Classes:
• IPluginContentWizard: Classes that implement this interface are contributed via the extension point org.eclipse.pde.ui.pluginContent . The expectation is that classes also extend JFace Wizard class. The role of this wizard is to provide additional plug-in content after the project and the critical plug-in project files have been created. The wizard is nested in the overall 'New' wizard and can contribute one or more pages that allow users to configure how this content will be generated. A typical implementation of this interface would be a template wizard that populates the plug-in project with content that can be useful ...
• IModelUndoManager: Classes that implement this interface provide undo/redo capability linked to changes reported by model change providers. Model change events carry sufficient data to be used in an undo/redo stack and reverted to or reapplied after the change. Model undo manager adds itself as a change listener after being connected to the provider. It is expected to stop listening to change events after being disconnected. Changes reported while being connected are kept in the operation stack whose size can be controlled. The part that uses the undo manager is responsible for supplying Undo and Redo action objects ...
• ISharedPluginModel: This type of model is created by parsing the manifest file. It serves as a base interface for both plug-in and fragment models by holding data common to both. If the file is a workspace resource, it will be available as the underlying resource of the model. The model may be read-only or editable. It will also make a reference to the build.properties model when created. The reference will be of the same type as the model itself: if the model is editable, it will attempt to obtain an exclusive editable copy of build.properties model. The plug-in model can be disabled. Disabling the model will not ...
• IPluginModelBase: This type of model is created by parsing the manifest file. It serves as a base interface for both plug-in and fragment models by holding data common to both. If the file is a workspace resource, it will be available as the underlying resource of the model. The model may be read-only or editable. It will also make a reference to the build.properties model when created. The reference will be of the same type as the model itself: if the model is editable, it will attempt to obtain an exclusive editable copy of build.properties model. The plug-in model can be disabled. Disabling the model will not ...
• IExtensionsModel: This type of model is created by parsing the manifest file. It serves as a base interface for both plug-in and fragment models by holding data common to both. If the file is a workspace resource, it will be available as the underlying resource of the model. The model may be read-only or editable. It will also make a reference to the build.properties model when created. The reference will be of the same type as the model itself: if the model is editable, it will attempt to obtain an exclusive editable copy of build.properties model. The plug-in model can be disabled. Disabling the model will not ...
• IFragmentModel: This type of model is created by parsing the fragment.xml file. If the file is a workspace resource, it will be available as the underlying resource of the model. The model may be read-only or editable. It will also make a reference to the plugin.jars model when created. The reference will be of the same type as the model itself: if the model is editable, it will attempt to obtain an exclusive editable copy of plugin.jars model. The fragment model can be disabled. Disabling the model will not change its data. Users of the model will have to decide if the disabled state if of any importance to them ...
• IPluginModel: This type of model is created by parsing the plugin.xml file. If the file is a workspace resource, it will be available as the underlying resource of the model. The model may be read-only or editable. It will also make a reference to the plugin.jars model when created. The reference will be of the same type as the model itself: if the model is editable, it will attempt to obtain an exclusive editable copy of plugin.jars model. The plug-in model can be disabled. Disabling the model will not change its data. Users of the model will have to decide if the disabled state if of any importance to them ...
• IModelProvider: Classes that implement this interface are responsible for holding a table of models associated with the underlying objects. They have several responsibilities: To hold model objects in one place To allow requesters to connect to the models or to disconnect from them. To maintain reference count of model users. To ensure "one writer/many readers" access to the model so that only one requester can get an editable copy of the model at any time. To notify interested parties when models are added and removed. Model providers are responsible for listening to the workspace, updating models whose underlying ...
• ISchema: Objects of this class encapsulate data loaded from the XML Schema file that defines an Eclipse extension point. These files are used for three reasons: To provide grammar that can be used by validation parsers to validate extensions that plug into this extension point To provide additional metadata about this extension point that can be used by PDE to provide user assistence in plug-in development To provide enough material that can be used by tools to compose a reference HTML documentation about this extension point. Objects of this class can be changed if editable. Other classes can register ...
• NewExtensionTemplateWizard: This wizard should be used as a base class for wizards that provide new plug-in templates. These wizards are loaded during new plug-in or fragment creation and are used to provide initial content (Java classes, directory structure and extensions). The wizard provides a common first page that will initialize the plug-in itself. This plug-in will be passed on to the templates to generate additional content. After all templates have executed, the wizard will use the collected list of required plug-ins to set up Java buildpath so that all the generated Java classes can be resolved during the build ...
• ITemplateSection: This interface represents a section of the template wizard that generates a new extension or plug-in. Typically, it maps to one wizard page, but more complex sections may span several pages. Also note that in the very simple cases it may not contribute any wizard pages. If a section generates extensions, it should be written in such a way to be used both in the 'New Extension' wizard and as a part of a new plug-in project wizard. When used as part of the new plug-in project wizard, it may appear alongside other templates and therefore should not do anything that prevents it.
• IDocumentSection: Document section is portion of the extension point schema definition that will be taken and built into the final reference HTML document. There are several predefined document sections that PDE recognizes: MARKUP - will be used for "Markup" section EXAMPLES - will be used for "Examples" section API_INFO - will be used for "API information" section IMPLEMENTATION - will be used for "Supplied Implementation" section Text that objects of this class carry can contain HTML tags that will be copied into the target document as-is.
• OptionTemplateSection: This class adds some conventions to the class it is based on. For example, it expects to find the template content in the following location: [install location]/[templateDirectory]/[sectionId] where templateDirectory is expected to be 'templates_3.0' (to distinguish from template designed for earlier Eclipse versions), and sectionId is the unique identifier as reported by the template section. It also assumes that all wizard pages associated with this template will be based on OptionWizardTemplatePage .
• BaseOptionTemplateSection: This class adds a notion of options to the default template section implementation. Options have values and visual presence that allows users to change them. When a section is configured with a number of options, they become available to the code generator and can take part in conditional code emitting. This class is typically used in conjunction with OptionTemplateWizardPage . The later is capable of creating UI based on the list of options it was given, thus simplifying new template section creation.
• ISchemaRepeatable: Classes that implement this interface store information about objects that carry cardinality information. In DTDs, cardinality is defined using special characters ('?' for "0 to 1", '+' for "1 or more" and '*' for "0 or more". XML Schema allows precise definition of the cardinality by using minimum and maximum of occurences in the instance document. This is one of the reasons why it is not possible to create exact DTD representation of XML Schema grammar.
• NewPluginTemplateWizard: This wizard should be used as a base class for wizards that generate plug-in content using a closed set of templates. These wizards are loaded during new plug-in or fragment creation and are used to provide initial content (Java classes, directories/files and extensions). The list of templates is fixed. It must be known in advance so that the required wizard pages can be created. Upon finish, the template sections are executed in the order of creation.
• TemplateField: The base class for all the template option fields. Template option is a single editable option that is exposed to the users in the wizard pages associated with templates. Although the field is associated with the template section, there is no 1/1 mapping between the field and the substitution value that can be used in the template files. In general, a subclass of this class can generate any SWT control in the provided composite.
• LinkSection: This class can be used to show a standard section with an array of links. Links are objects from editor pages, and each one will select the owning page and reveal the element in it. If the number of objects from the content provider is greated than the preset limit, only the first 'limit' number of links will be shown, and a 'More...' button will show up (this is a change from 2.1 where 'More...' was visible all the time).
• IProjectProvider: This interface is used to insulate the client's wizards from the master wizard that is responsible for creating the new project. Clients use this interface to ask for the new project's name (without forcing the project creation) and the project handle itself. Content wizards can use the project name to construct default values for other name properties before the project resource is being created.
• IModel: A generic model. Classes that implement this interface are expected to be able to: Load from an input stream Reload (reset, load, fire 'world change') Dispose (clear all the data and reset) Be associated with a resource (optional) If a model is not created from a workspace resource file, its underlying resource will be null .
• IBundlePluginModelProvider: Models that implement this interface can provide a reference of the bundle plug-in model that owns the model in question. This interface allows objects of these models to reach up to the parent adapter without making too many assumptions about the nature of the parent. Models that don't have bundle plug-in model parent are required to return null .
• SearchablePluginsManager: This class manages the ability of external plug-ins in the model manager to take part in the Java search. It manages a proxy Java projects and for each external plug-in added to Java search, it adds its Java libraries as external JARs to the proxy project. This makes the libraries visible to the Java model, and they can take part in various Java searches.
• IBuildModel: This model is created from the "plugin.jars" file that defines what source folders in the plug-in are to be used to build require plug-in Jars. If this model is editable, isEditable() will return true and the model instance will implement IEditable interface. The model is capable of providing change notification for the registered listeners.
• IEditable: Models that implement this interface indicate that they can be changed. When a model is changed, it becomes 'dirty'. This state can either be reset (in case of a 'false alarm' or naturally set to false as a result of saving the changes. Models that implement this interface are expected to be able to save in ASCII file format (e.g. XML).
• FormEntry: The helper class for creating entry fields with label and text. Optionally, a button can be added after the text. The attached listener reacts to all the events. Entring new text makes the entry 'dirty', but only when 'commit' is called is 'valueChanged' method called (and only if 'dirty' flag is set). This allows delayed commit.
| Home | Contact Us | Privacy Policy | Terms of Service |