Plugin registration

Reading the code, there are two ways to register plugins (files *

  • “verbose”
plg = newplugin()
plg.<property> = <value>
  • “concise”
register(<property>=<value>, …)

Function register internally calls newplugin and does the conversion between both forms.

About half plugins use the “verbose” declaration and the other half the “concise” declaration. The “concise” one is labelled a convenience function in a comment.

Which one is recommended for preferential use?
What is the advantage of one over the other as they are strictly equivalent in their effect?

There was some discussion of making registration more flexible… the possibility of allowing an add-on with a higher version to supersede an outdated built-in.

And expanding to support registration of a few properties universally across plugin types (like the help_url) to expand plugin manager UI &UX options.

Probably irrelevant to this specific question. But it might also change the baseline for concise and verbose.

A recent thread with a new user involved troubleshooting masse install of add-ons, related to prerequisites for an “advanced user” add-on that was of no use in his setup.

Could a prerequisites list be added to the registration items?

And perhaps a flag for those that require configuration after installing? (Like the Place Cleanup addon that requires signing up for a GeoNames webservice and adding its password to the add-on configuration.)

This would allow the Plugin Manager to filter out Plugins that offer too many complications for basic users.

An “advanced user” flag might also be nice. Most users have no need to see alternate database engines or the Cairo Clock developer sample code.

This would be useful, the last changed gramplet has a hard dependency on the statistics service and I think something else in the common card view code.

Aftering experimenting with the Gramplet flavored file and looking through the Gramplets authoring wiki article and API docs, some questions remain.

From the wiki:

If the help_url starts with http:// then that fully qualified URL will be used as is. Otherwise, the paths will be interpreted as relative to base URL. The base URL will be prepended to the help_url and may get a language extension (such as /nl ) appended at the end, if the operating language is one of nl fr sq mk de fi ru sk. You should not use the _( ) translate function around the help_url string, unless you specifically intend to create web pages named with the translated string.

Is there a way to point the help to a .md markdown document in the Gramplet’s current User Directory subfolder?

If so, could my Gramplet updates freshen user docs through the Plugin Manager in the same way as the plug-in code?

see also
Discourse threads: