[Qgis-developer] A common set of functions for QGIS plugins

John Layt jlayt at kde.org
Mon Nov 2 05:11:08 PST 2015


On 2 November 2015 at 12:52, Victor Olaya <volayaf at gmail.com> wrote:

> Hi all,
>
> We have discussed sometimes in here about the need of having some
> common functions for plugin developers, to avoid all plugins having to
> reimplement those functions, sometimes not in the most correct way. It
> will also bring some homogeneity to plugins, which I think it is a
> good thing.
>
> With the changes that will be coming to QGIS soon, I think this is a
> good idea to work on, and I have started a small project here to
> create a set of Python modules with those common functions.
>
> https://github.com/volaya/qgiscommons
>
> Not much yet, but I plan to work on that and make it grow during this
> week. With the Hackfest coming, I think it is a good time to ask other
> devs to contribute...


We have a similar library for our internal company plugins (some soon to be
made public) that we include as a git submodule to save code duplication.
Lots of simple stuff, but also some obvious missing API and functions, like
map tools that snap (am I ever glad to see that as public api in 2.12!).
See https://github.com/lparchaeology/libarkqgis.

I'm in two minds as to whether it would be a good thing to have an
'official' one. While I can see the use, surely if these things are useful
then they should be included in the mainline API with proper API
guarantees? I'm not sure I'd want to rely on a library that doesn't have an
API guarantee, and if you're making the guarantee then why not in core? If
they are *required* for a plugin to be accepted, then they must be in core
and have an API guarantee.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151102/69abc236/attachment.html>


More information about the Qgis-developer mailing list