Plugin description file

Plugin meta-data is a .plugin file that contains plugin information. Every plugin should have exactly one meta-data file. This file is used by plugin manager to identify the plugin and know the details prior to activation. Because there are some fields which require translation, a .plugin.in file is written instead, from which the .plugin file will be derived after necessary translation.

Fields used in .plugin.in file are:

Group name

The first group should always be [Anjuta Plugin]. This group contains plugin details and will be used by plugin manager.

Location

Describes where the plugin is located. It is of the form libname:classname . libname is the shared library name without the 'lib' prefix and '.so' suffix. classname is the plugin class defined in the library.

Interfaces

Primary interfaces implemented by the plugin.

Interfaces

Comma separated list of all interfaces that this plugin depends on. Plugin implementing these interfaces will be activated before activating this plugin. This field is optional. If there is no dependencies, it may not present.

Icon

Icon file name in .png format.

_Name

Translatable plugin name. Notice the '_' before the key name. It means the field is translatable.

_Description

Brief translatable description. Notice the '_' before the key name. It means the field is translatable.

Language

Name of loader necessary to load the plugin, by default the C plugin loader included in libanjuta is used. This name must be equal to the value of the key SupportedLanguage in the group [Plugin Loader] of the loader plugin.

Dependencies

Name of other plugins needed by this one. These other plugins will be loaded before. It can be useful to be sure that a menu item has been created.

UserActivatable

Set to "no", if the plugin cannot be loaded by the user. Such plugins are loaded automatically by Anjuta when needed. It is the case for plugin providing support for some file types by example. By default a plugin can be loaded by the user.

ExcludeFromSession

Set to "yes", if the plugin is not saved in the user session. Such plugin must be non user activatable too. This is the case for project manager plugin. When activated it loads a new session, so it does not belong to the first session and should not be saved inside. By default all plugins are saved in the current user session.

Here is a typical plugin meta-data file (anjuta-document-manager.plugin.in):

[Anjuta Plugin]
Location=anjuta-editor:EditorPlugin
Interfaces=IAnjutaDocumentManager
Dependencies=IAnjutaLauncher,IAnjutaMessageManager
Icon=anjuta-document-manager.png
_Name=Document Manager
_Description=Provides document management capabilities.

In addition to mandatory [Anjuta Plugin] group, the meta-data file can also contain other groups, which a plugin can read using AnjutaPluginDescription methods. plugin manager simply ignores these additional groups, but plugins can use them on their own.

A typical example would be using an extra group (e.g [Supported Mime Types]) for a anjuta-open-file plugin to identify plugins supporting mime-types. It could then activate the correct plugin to open a particular file based on its mime-type (in addition to requiring that the opener plugin support a generic interface, such as IAnjutaStream or IAnjutaFile)

To install the meta-data and icon files, add the following code in Makefile.am:

plugin_in_files = anjuta-plugin-name.plugin.in
%.plugin: %.plugin.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*po) ; \
	$(INTLTOOL_MERGE) $(top_srcdir)/po $< $@ -d -u \ \
		-c $(top_builddir)/po/.intltool-merge-cache

anjuta_plugindir = $(libdir)/anjuta
anjuta_plugin_DATA = $(plugin_in_files:.plugin.in=.plugin)

plugin_icondir = $(datadir)/pixmaps/anjuta
plugin_icon_DATA = anjuta-plugin-name.png

The $(datadir) variable should exactly match with installed Anjuta's datadir. In case it is different, use the command "pkg-config --variable=prefix libanjuta" in configure.in to determine the installed prefix of Anjuta.