The plugin_directory_locale() method will be called by Padre to know where to look for your plug-in l10n catalog.

It defaults to $sharedir/locale (with $sharedir as defined by File::ShareDir and thus should work as is for your plug-in if you're using the install_share command of Module::Install. If you are using Module::Build version 0.36 and later, please use the share_dir new() argument.

Your plug-in catalogs should be named $plugin-$locale.po (or .mo for the compiled form) where $plugin is the class name of your plug-in with any character that are illegal in file names (on all file systems) flattened to underscores.

That is, Padre__Plugin__Vi-de.po for the German locale of Padre::Plugin::Vi.

In Padre, plug-ins are permitted to make relatively deep calls into Padre's internals. This allows a lot of freedom, but comes at the cost of allowing plug-ins to damage or crash the editor.

To help compensate for any potential problems, the Plug-in Manager expects each plug-in module to define the Padre classes that the plug-in uses, and the version of Padre that the code was originally written against (for each class).

This information will be used by the Plug-in Manager to calculate whether or not the plug-in is still compatible with Padre.

The list of interfaces should be provided as a list of class/version pairs, as shown in the example.

The padre_interfaces method will be called on the class, not on the plug-in object. By default, this method returns nothing.

In future, plug-ins that do not supply compatibility information may be disabled unless the user has specifically allowed experimental plug-ins.

The new constructor takes no parameters. When a plug-in is loaded, Padre will instantiate one plug-in object for each plug-in, to provide the plug-in with a location to store any private or working data.

A default constructor is provided that creates an empty hash-based object.

The registered_documents method can be used by a plug-in to define document types for which the plug-in provides a document class (which is used by Padre to enable functionality beyond the level of a plain text file with simple Scintilla highlighting).

This method will be called by the Plug-in Manager and the information returned will be used to populate various internal data structures and perform various other tasks. Plug-in authors are expected to provide this information without having to know how or why Padre will use it.

This (theoretically at this point) should allow Padre to keep a document open while a plug-in is being enabled or disabled, upgrading or downgrading the document in the process.

The method call is made on the plug-in object, and returns a list of MIME type to class pairs. By default the method returns a null list, which indicates that the plug-in does not provide any document types.

The registered_documents method can be used by a plug-in to define custom syntax highlighters for use with one or more MIME types.

As shown in the example above, highlighters are described as a module name and an attribute that describes a visible name for the highlighter and a reference to a list of the mime types that the highlighter should be applied to.

Defining a new syntax highlighter will automatically cause that highlighter to be used by default for the MIME type.

If implemented in a plug-in, this method will be called when a context menu is about to be displayed either because the user triggered the event right in the editor window (with a right click or Shift+F10 or the context menu key) or because the Context Menu menu entry was selected in the Window menu (Wx::CommandEvent). The context menu object was created and populated by the Editor and then possibly augmented by the Padre::Document type (see "event_on_context_menu" in Padre::Document).

Parameters retrieved are the objects for the document, the editor, the context menu (Wx::Menu) and the event.

Have a look at the implementation in Padre::Document::Perl for a more thorough example, including how to manipulate the active document.

The plugin_disable method is called by Padre for various reasons to request the plug-in do whatever tasks are necessary to shut itself down. This also provides an opportunity to save configuration information, save caches to disk, and so on.

Most often, this will be when Padre itself is shutting down. Other uses may be when the user wishes to disable the plug-in, when the plug-in is being reloaded, or if the plug-in is about to be upgraded.

If you have any private classes other than the standard Padre::Plugin::Foo, you should unload them as well as the plug-in may be in the process of upgrading and will want those classes freed up for use by the new version.

The recommended way of unloading your extra classes is using the built in unload method. Suppose you have My::Extra::Class and want to unload it, simply do this in plugin_disable:

$plugin->unload('My::Extra::Class');

The unload method takes care of all the tedious bits for you. Note that you should not unload any external CPAN dependencies, as these may be needed by other plug-ins or Padre itself. Only classes that are part of your plug-in should be unloaded.

Returns true on success, or false if the unloading process failed and your plug-in has been left in an unknown state.