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.
Cheers
Matthias
On 01/07/2014 09:09 AM, Paolo Cavallini wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlLLtk8ACgkQ/NedwLUzIr4mtwCfSyoFXQ3Dfc0OdgwVeSHRc61w
DBkAn2OgJocEBCi869XEG+Yz59PUFuG1
=A0P6
-----END PGP SIGNATURE-----
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
