[Qgis-developer] Plugin management [was: QEP - Proposal for QGIS 3.0 after 2.14]
delazj at gmail.com
Sat Oct 24 08:39:31 PDT 2015
I know you do that, Paolo. And I understand that it works with Tom plugin,
The thing is that, plugin dev that want his plugin to still be available
once we move to 3.0 will need to rework his plugin. Instead of letting each
one go its way, we can :
- based on the description and the tags, make a list of mergeable plugins
and let the dev know
- be more restrictive and reject new plugin that duplicates an already
approved one, unless he proves that it's better than the existing, in which
case he should have improved that one. I'm not a developer and I don't know
how they resist to rules/obligations... but we need rules to expect
consistency and coherence.
but I know that this can't be done by only Paolo and Alessandro (and I may
be available to help). This is also what a plugin dev list may be useful
for: discuss about plugins project as it's done for Core.
My thoughts about plugins are wider. I've read some remarks from people in
the survey and people complains about:
- the duplication of plugins
- no real way to know/understand in which menu the installed plugin is
(maybe, a reorganisation of menus should be done with 3.0)
- the bugs in the plugin, although QGIS project is not responsible of this
(except globe?). People should clearly know that not all plugins are done
by the QGIS project. This should be clearly added to the « Manage and
Install plugins » dialog , meaning that :
* the plugins that are Core should be clearly identified ; currently I'm
not sure they have real description and an author (I don't have QGIS right
now to check so sorry if that exists) ;
* also emphasize the individual authors but also the way people can report
issues. Instead of having on a single line links to homepage, bug tracker
and code repository we can have 3 lines with text like « homepage:», « have
issues or want new features, report it here : », « if you want to download
sources :». When you are not a programmer, the latter expressions are more
understandable than the former.
- the lack of documentation : Requesting from each plugin to have a minimal
documentation. Things are not so obvious for all of us. So, as soon as
there are options to choose from, there should be a text that explains the
choice. It can just be a dialog that pops up in QGIS but there should be
doc.Description is now mandatory and it's a good thing that helps to know
if a plugin can be useful or no but doc is needed once you begin to try it.
- the language: I know we can't have all plugins translated in all
languages but we may try to translate their description. Make translatable
the plugins.org site. I understood from Alesssandro that it will be a huge
project  but I still think that it will be a huge improvement for QGIS.
The translated descriptions will be retrieved in the « Manage and Install
plugins » and according to the level of translations, users can have
translated descriptions for all their plugins.
These are just points I put here. Thoughts?
2015-10-24 15:19 GMT+02:00 Paolo Cavallini <cavallini at faunalia.it>:
> Il 24/10/2015 14:07, Tom Chadwin ha scritto:
> > Paolo always does question new plugins if they duplicate. Is that not
> > It's the reason my plugin was created. Our is there perhaps a historical
> > issue?
> Hi all,
> in fact, Im' always gently pushing in that direction, with variable
> success. Having a more ordered structure would be very useful, but I
> doubt this can be implemented without threatening individual developer
> freedom. Junior, do you have an operative proposal on how to implement
> All the best.
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qgis-developer