[Qgis-developer] Plugins approval

Matthias Kuhn matthias.kuhn at gmx.ch
Tue Jan 7 04:58:34 PST 2014

Hi Paolo and Jonathan,

Thank you for sharing your thoughts.

We should encourage plugin-authors to write a good get-started section 
in the description in their metadata. Or we could include yet another 
getstarted metadata section. I remember, I discussed another key 
"website" with Borys, which would be shown in a frame in the plugin 
description page. This could be used to show even pictures in a 
description. Or we could just embed the URL listed in homepage.

Why I think this is a better idea:

   * E.g. The processing plugin creates a new menu, this would not fit 
into the previously described scheme. (But the scheme could be adapted 
to contain an array of menu entries)
   * Plugins can have more than one menu entry (Sending them back to the 
plugins menu would totally fail to fulfill the requirements listed by you)
   * Evenmore: There may as well be plugins with no menu entry at all. 
(E.g. You could write a plugin just to add new attribute editor fields)

Optimally we should have a good guideline where we can point people to. 
And the plugin builder plugin should already help people to get this done.

So I would not say "anything to fix that" is a good approach, but a 
well-designed solution will be very welcome.

The other (technical) option which I can think of would be to define 
"access rights" or "hooks" which a plugin can acquire in the metadata 
section and then the app will be delivered with these. So a plugin could 
acquire the "Register a new toplevel menu item" or the "Register a 
vector menu item" or the "Register a new attribute editor widget" or the 
"Register a new raster pipe function" hooks. Smartphones use something 
like this for their permission management. While this offers some 
advantages (you can exactly list, what the plugin will do) it seems a 
bit over-engineered for this problem IMHO. And it would require to 
rewrite all plugins :) Therefore my preference: Solve it with human 
sense instead of technique.


On 01/07/2014 09:09 AM, Paolo Cavallini wrote:
> Hash: SHA1
> Il 07/01/2014 09:04, Matthias Kuhn ha scritto:
>> Therefore, I would propose not to implement hard rules (like specifying
>> the menu in metadata) but leave all the options to the plugin author
>> and have some intelligent soft rules, which can be considered for each
>> case individually, and eventually be discussed with the plugin author
>> in the approval process.
> Thanks for your comments.
> I'd like to keep things simple at this stage: what I think we should avoid (and this
> is easy to do) is having new plugins going to the Plugins menu, instead of the
> appropriate one. Rationale:
> * keeping a tidy interface
> * make it predictable for users where to find a command.
> I suggest to check this for each new plugin, and ask the author to chenge it if
> necessary before approval.
> All the best.
> - -- 
> Paolo Cavallini - www.faunalia.eu
> Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
> iEYEARECAAYFAlLLtk8ACgkQ/NedwLUzIr4mtwCfSyoFXQ3Dfc0OdgwVeSHRc61w
> DBkAn2OgJocEBCi869XEG+Yz59PUFuG1
> =A0P6

More information about the Qgis-developer mailing list