[Qgis-psc] Requiring adequate plugin descriptions

[Richard Duivenvoorde]

On 22-05-17 18:01, Tim Sutton wrote:
> Hi (mainly Paolo)
> 
> 
> Just looking at the new plugin approved:
> 
> http://plugins.qgis.org/plugins/qdraw/
> 
> I wonder if we should not require / strongly request that plugin authors
> provide a detailed description of their plugins so that a user wanting
> to choose a plugin from the repo knows what they will get. From the
> above plugin description (while it may be a great plugin), it is not
> really obvious what you will get when you install it. Perhaps a
> screenshot with each would be nice too....

Yes, I've been thinking about that too...

What about forcing to answer 2 questions in the description in > 50
words or so..:
- what does this plugin do
- which problem does this plugin solve for me
(or ... whatever better guiding questions people can come up with).

Another thing I would like to make better in plugins in general, is that
they plugins should make use of QgsNetworkAccessManager instead of home
brew urllib2/requests/.... solutions, which most of the times do not
make use of proxy settings (and machinery there is already in Qt to make
sure that a kerberos-identification-proxy is working ok..). I've seen in
several bigger QGIS-install that this was giving problems as some
plugins worked and some of them not.

Screenies whould be good, BUT from where would these be served?
- unless the plugins is installed there is nothing locally know then the
info from the plugins.xml....
- so best idea I could come up with, is an image, with exact the same
name as the plugin, and that the plugin-server extracts this image from
the zip, and puts these in a (cachable) webserving place. So in the xml
you can have a image link like:
http://plugins.qgis.org/plugins/imagemap_plugin/imagemap_plugin.2.0.1.png
(including the version name, to be able to upgrade the screenie too).
NOTE: we should REALLY be able to cache these images, because the plugin
server is already under heavy load only from serving the
plugins.xml's... And somebody browsing through the 1000 plugins we know
have, firing 1000 screenie url's is not making things better.

Off course also the plugin-manager should be able to handle all this.

IF we want to create new (stricter?) rules for (a certain class of)
plugins, we should make them up NOW as now the 3.0 approved list is
still short.

Regards,

Richard Duivenvoorde