padre_interfaces

Plugin must declare it's Interfaces, all Padre Modules should be included, just look at some other Plug-ins to see the pattern.

Don't forget to include the following sub.

Use the version number of Padre you are developing against, as shown below.

######## Define Padre Interfaces required#######sub padre_interfaces{return(# Default, required'Padre::Plugin'=>'0.91',# used by Main, About and by Padre::Plugin::FormBuilder'Padre::Wx'=>'0.91','Padre::Wx::Main'=>'0.91','Padre::Wx::Role::Main'=>'0.91','Padre::DB'=>'0.91','Padre::Logger'=>'0.91',);}

draft 2 needs more work, in tiding up

bowtie
Padre::Plugin POD, padre_interfaces, lists Padre modules and version numbers.
1, is it upto date
2, it appairs to me you only need, 'Padre::Plugin' => 0.nn,
Alias
You need to declare everything you use
So if you use Padre::Logger, you need to declare that
If you do $plugin->main->some_method you need to do Padre::Wx::Main
etc
You declare the parts of Padre that you use
So when we break compatibility in one part of Padre, ALL the plugins that use it aren't loaded, but ONLY the plugins that use it are disabled
bowtie
but plugins still work and don't through any errors or warnings at present
Alias
You THINK they work
They MIGHT work
But you can't know that
This is about failure modes
We have a choice about how we want plugins to fail
1, Always have every plugin load, wait for each one to do something illegal in Padre and blow up,
leaving it half-loaded or in some unknown state and maybe crashing Padre
2. Disable some plugins due to "compatibility" which really will still work, just in case one was using the specific part you changed
In the first case, we have unknown and uncontrolled impact, and random side effects, any of which are potentially disastrous
In the second case, plugin authors need to check they still work, bump the plugin's dependency hash past the change,
and do a simple incremental release
The second is much more responsible, and much safer when there's no firewall between the plugins and the core
Firefox doesn't even give THAT much leeway
Every plugin is automatically disabled, until they SPECIFICALLY test they still work
We are at least doing piece-meal disable on a per class basis
Which is more cpan friendly
bowtie
ok, so the the the modules version will be that of the Padre version it was created against,
hence all module version numbers should be the same?
Alias
Usually yes
But someone might have checked that one specific class hasn't changed in the place we care about further back
Or one plugin might depend on another plugin
And so on
bowtie
I will add this to cookbook wiki then, ok
Alias
But USUALLY they will all be the same
bowtie
the POD shows diffrent versions
Alias
Well, it IS theoretically possible
bowtie
so hidden some whare in your brain is an padre-plugin api version v padre version numbers then :)
Alias
api version is the same
Padre::Plugin is just another class that the plugin "depends on"
bowtie
from POD, Padre::Plugin - Padre plug-in API 2.2
Alias
oh, that
That's mostly just a way of mentally marking time
It's not really any kind of official thing
bowtie
yes it's confuses me
Alias
Basically it just says "We've completely rewritten it twice, and made some big additions twice since then"
It's for humans, not machines
A bit like Padre::Task 2.0
bowtie
on reflection I got that, but I don't know what the padre version was then,
and if I use that version will a plugin be back compatable
Alias
You don't have to
You just say the most recent version of Padre you are SURE that the plugin works with
And Padre itself tracks compatibility for you
bowtie
ie developed against :)
Alias
our $COMPATIBLE = '0.43';
That's in Padre::Plugin
So at a guess, the last time I broke compatibility for ALL plugins was likely 2.0 landing
bowtie
POD shows 0.29
Alias
Which means 2.0 probably arrived around about 0.43
bowtie
can I do perl dev -t Class::Name, Class::Name2
Alias
Nope
bowtie
only one :(
all modules used by a Plugin that are not part of Padre core should be in sub plugin_disable
even if required
Alias
All plugin modules should be
Don't unload third party modules
You have no idea if anything else needs them
bowtie
you mean Mouse for example
Alias
right
Only unload the plugin's own modules
bowtie
ok if a Plugin over loads sub plugin_icon
Alias
You can overload pretty much anything you like
bowtie
you are so happy it must be your un-Birthday again :), thanks

plugin_enable

Some Plug-ins will require a plugin_enable method,

Why because it's using an external resource, which is not being picked up via perl (M::I).

The use of File::Which::which is OS independent, and already in Padre stack. Alias++

########## We need plugin_enable# as we have an external dependency#########sub plugin_enable{my$pdflatex_exists=0;# Tests for external file in Pathif(File::Which::which('pdflatex')){$pdflatex_exists=1;}return$pdflatex_exists;}

From Padre::Plugin::LaTeX

Padre::Plugin::SpellCheck dose not need this as it depends upon Text::Aspell which won't install with out Aspell files being present.

plugin_disable

Plugin_disable is a must so that we can load and unloaded our Plug-in repeatedly, using Tools -> Reload All Plug-ins.

Don't forget to include all the relevant sections.

Wx::Dialogs, as shown

your plugin modules, as shown,

other cpan modules that are pertinent to only your plugin, such as sockets or demons, not shown.

boot n braces, as shown, this is a new development, run SUPER plugin_disable, an Ode to before :)

Why a composed Method you ask, in Cookbook it just makes sense, if you have more than one dialog and we have more than two.

######### Composed Method clean_dialog########sub clean_dialog{my$self=shift;# Close the main dialog if it is hanging aroundif($self->{dialog}){$self->{dialog}->Hide;$self->{dialog}->Destroy;delete$self->{dialog};}return1;}

requires_from command takes a module file path, and looks for use statements with explicit module version (like use Foo::Bar 0.01 ), and from which it sets requires attributes.

CPAN

this is probably our end goal.

public repository

about dialogue

Additional documentation

or Marketing your Plug-in and Padre

trac wiki

blogg

Tickets

Please Create New Tickets with the following additional information.

start summary with Padre::Plugin::....

set component = plugins

Miscellaneous

ellipsis

Label the menu item with a trailing ellipsis ("...") only if the command requires further input from the user before it can be performed. Do not add an ellipsis to items that only present a confirmation dialog (such as Delete), or that do not require further input (such as Properties, Preferences or About). dolman+

see sample from Padre::Plugin::Patch

FormBuilder fbp

We are now suggesting that all Plug-in Dialogues should be in a single file; as Padre::Plugin::FormBuilder now supports *.fbp with multiple dialogues enclosed. This is shown below: