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

[Victor Olaya]

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
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=