<div dir="ltr">Hey Victor and Gray,<div><br></div><div>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.</div><div><br></div><div>Thoughts? </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 5, 2015 at 5:45 PM, Victor Olaya <span dir="ltr"><<a href="mailto:volayaf@gmail.com" target="_blank">volayaf@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Gary!<br>
<br>
I had a similar function to that one (actually coming from the<br>
Processing code...), so it's good to see that we had the same idea.<br>
That means other people out there might have something like that as<br>
well, so the library definitely makes sense<br>
<br>
I am seeing also that the problem might not be in the lack of such<br>
code itself, but in the lack of documentation. For instance, I<br>
recently found out about the QgsMapLayerComboBox and QgsFieldComboBox<br>
widgets. I am pretty sure most people ignore those widgets and dont<br>
use them in plugins. I myself wrote classes to do exactly that in this<br>
library...before I discovered that they existed already in the core of<br>
QGIS.<br>
<br>
Improving the documentation will clearly help to avoid this redundancies.<br>
<br>
Cheers!<br>
<div class="HOEnZb"><div class="h5"><br>
2015-11-04 18:10 GMT+01:00 Gary Sherman <<a href="mailto:gsherman@geoapt.com">gsherman@geoapt.com</a>>:<br>
> On 11/2/15 4:29 AM, Nathan Woodrow wrote:<br>
>><br>
>> Hey Victor,<br>
>><br>
>> Working on the same kind of thing over here:<br>
>> <a href="https://github.com/NathanW2/parfait" rel="noreferrer" target="_blank">https://github.com/NathanW2/parfait</a><br>
>><br>
> Hi,<br>
><br>
> I wrote a few wrappers for the PyQGIS Programmer's guide that you might take<br>
> a look at: <a href="http://locatepress.com/ppg/data_code" rel="noreferrer" target="_blank">http://locatepress.com/ppg/data_code</a><br>
><br>
> Includes a generic add layer function that takes determines whether it is a<br>
> vector or raster and calls the appropriate supporting function.<br>
><br>
> Nothing earth-shattering; was meant as an example to get folks thinking in<br>
> that direction.<br>
><br>
> I'm definitely interested in this project...<br>
><br>
> -gary<br>
><br>
>> IMO I would rather see a new module and not put it in qgis.utils.<br>
>> Something like qgis.py or qgis.wrappers or something like that that.<br>
>><br>
>> - Nathan<br>
>><br>
>> On Mon, Nov 2, 2015 at 11:20 PM, Victor Olaya <<a href="mailto:volayaf@gmail.com">volayaf@gmail.com</a><br>
>> <mailto:<a href="mailto:volayaf@gmail.com">volayaf@gmail.com</a>>> wrote:<br>
>><br>
>> ><br>
>> > I'm in two minds as to whether it would be a good thing to have an<br>
>> > 'official' one. While I can see the use, surely if these things are<br>
>> useful<br>
>> > then they should be included in the mainline API with proper API<br>
>> guarantees?<br>
>> > I'm not sure I'd want to rely on a library that doesn't have an API<br>
>> > guarantee, and if you're making the guarantee then why not in core?<br>
>> If they<br>
>> > are *required* for a plugin to be accepted, then they must be in<br>
>> core and<br>
>> > have an API guarantee.<br>
>> ><br>
>><br>
>> My ideas is definitely to put this into core (that's what I wrote in<br>
>> my email when i detailed the plans that i have for this), but I have<br>
>> started it as a separate repo to make it easier to collaborate and to<br>
>> start moving ASAP.<br>
>><br>
>> I could write a QEP with this idea, get it approved, throw a bunch of<br>
>> empty py modules in qgis.utils and then start working, but I like to<br>
>> first do some work, get people into it, and then do the bureucracy to<br>
>> pass this to core (I am sure no one will say no to this once a nice<br>
>> collection of functions is ready)<br>
>><br>
>> I will wait for other people to voice their opinion, and if most<br>
>> people agree on going taht other way, I have nothing against it<br>
>> _______________________________________________<br>
>> Qgis-developer mailing list<br>
>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a> <mailto:<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Qgis-developer mailing list<br>
>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>><br>
><br>
> --<br>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=<br>
> Gary Sherman<br>
><br>
> Founder, QGIS Project<br>
> Consulting: <a href="http://geoapt.com" rel="noreferrer" target="_blank">geoapt.com</a><br>
> Publishing: <a href="http://locatepress.com" rel="noreferrer" target="_blank">locatepress.com</a><br>
><br>
> We work virtually anywhere<br>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=<br>
</div></div></blockquote></div><br></div>