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

[Nathan Woodrow]

Hey Victor and Gray,

I have added you both to my project, however if you want maybe we can start
an official QGIS repo for it and give it a new name. Keep it away from core
but still part of the main project.

Thoughts?

On Thu, Nov 5, 2015 at 5:45 PM, Victor Olaya <volayaf at gmail.com> wrote:

> Thanks Gary!
>
> I had a similar function to that one (actually coming from the
> Processing code...), so it's good to see that we had the same idea.
> That means other people out there might have something like that as
> well, so the library definitely makes sense
>
> I am seeing also that the problem might not be in the lack of such
> code itself, but in the lack of documentation. For instance, I
> recently found out about the QgsMapLayerComboBox and QgsFieldComboBox
> widgets. I am pretty sure most people ignore those widgets and dont
> use them in plugins. I myself wrote classes to do exactly that in this
> library...before I discovered that they existed already in the core of
> QGIS.
>
> Improving the documentation will clearly help to avoid this redundancies.
>
> Cheers!
>
> 2015-11-04 18:10 GMT+01:00 Gary Sherman <gsherman at geoapt.com>:
> > On 11/2/15 4:29 AM, Nathan Woodrow wrote:
> >>
> >> Hey Victor,
> >>
> >> Working on the same kind of thing over here:
> >> https://github.com/NathanW2/parfait
> >>
> > Hi,
> >
> > I wrote a few wrappers for the PyQGIS Programmer's guide that you might
> take
> > a look at: http://locatepress.com/ppg/data_code
> >
> > Includes a generic add layer function that takes determines whether it
> is a
> > vector or raster and calls the appropriate supporting function.
> >
> > Nothing earth-shattering; was meant as an example to get folks thinking
> in
> > that direction.
> >
> > I'm definitely interested in this project...
> >
> > -gary
> >
> >> IMO I would rather see a new module and not put it in qgis.utils.
> >> Something like qgis.py or qgis.wrappers or something like that that.
> >>
> >> - Nathan
> >>
> >> On Mon, Nov 2, 2015 at 11:20 PM, Victor Olaya <volayaf at gmail.com
> >> <mailto:volayaf at gmail.com>> wrote:
> >>
> >>     >
> >>     > 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.
> >>     >
> >>
> >>     My ideas is definitely to put this into core (that's what I wrote in
> >>     my email when i detailed the plans that i have for this), but I have
> >>     started it as a separate repo to make it easier to collaborate and
> to
> >>     start moving ASAP.
> >>
> >>     I could write a QEP with this idea, get it approved, throw a bunch
> of
> >>     empty py modules in qgis.utils and then start working, but I like to
> >>     first do some work, get people into it, and then do the bureucracy
> to
> >>     pass this to core (I am sure no one will say no to this once a nice
> >>     collection of functions is ready)
> >>
> >>     I will wait for other people to voice their opinion, and if most
> >>     people agree on going taht other way, I have nothing against it
> >>     _______________________________________________
> >>     Qgis-developer mailing list
> >>     Qgis-developer at lists.osgeo.org <mailto:
> Qgis-developer at lists.osgeo.org>
> >>     http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Qgis-developer mailing list
> >> Qgis-developer at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
> >
> > --
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > Gary Sherman
> >
> > Founder, QGIS Project
> > Consulting: geoapt.com
> > Publishing: locatepress.com
> >
> > We work virtually anywhere
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151105/98456dc9/attachment.html>