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

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qgis-developer
Subject:    Re: [Qgis-developer] A common set of functions for QGIS plugins
From:       John Layt <jlayt () kde ! org>
Date:       2015-11-02 13:11:08
Message-ID: CAM1DM6m8v=ZAQs0frW4APcvvZXwd1+sk_87-yfHHdqvnNT24Dw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

On 2 November 2015 at 12:52, Victor Olaya <volayaf@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.

[Attachment #5 (text/html)]

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 2 November 2015 \
at 12:52, Victor Olaya <span dir="ltr">&lt;<a href="mailto:volayaf@gmail.com" \
target="_blank">volayaf@gmail.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Hi all,<br> <br>
We have discussed sometimes in here about the need of having some<br>
common functions for plugin developers, to avoid all plugins having to<br>
reimplement those functions, sometimes not in the most correct way. It<br>
will also bring some homogeneity to plugins, which I think it is a<br>
good thing.<br>
<br>
With the changes that will be coming to QGIS soon, I think this is a<br>
good idea to work on, and I have started a small project here to<br>
create a set of Python modules with those common functions.<br>
<br>
<a href="https://github.com/volaya/qgiscommons" rel="noreferrer" \
target="_blank">https://github.com/volaya/qgiscommons</a><br> <br>
Not much yet, but I plan to work on that and make it grow during this<br>
week. With the Hackfest coming, I think it is a good time to ask other<br>
devs to contribute...</blockquote><div>  </div><div>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 <a \
href="https://github.com/lparchaeology/libarkqgis">https://github.com/lparchaeology/libarkqgis</a>.<br><br>I&#39;m \
in two minds as to whether it would be a good thing to have an &#39;official&#39; \
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&#39;m not sure I&#39;d \
want to rely on a library that doesn&#39;t have an API guarantee, and if you&#39;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.<br><br></div><div>John.<br><br></div><div><br><br></div></div><br></div></div>

[Attachment #6 (text/plain)]

_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[prev in list] [next in list] [prev in thread] [next in thread] 