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

[Anita Graser]

Yes there is a processing provider option. Haven't tried it yet though.

Best wishes
Anita
On Feb 25, 2016 8:53 PM, "Victor Olaya"  wrote:

> If I am not wrong, Pirmin worked on that and it is already available
> in Plugin Builder... I remember he showed it to me att FOSS4G last
> year, and I guess it will be already in the latest version...
>
> 2016-02-25 17:57 GMT+01:00 Spencer Gardner :
> > Given that there seems to be interest in encouraging plugin developers to
> > tailor their plugins for Processing, would it be possible to add an
> option
> > to Plugin Builder that creates the basic framework for a Processing
> plugin?
> >
> > Regards,
> > Spencer
> >
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

If I am not wrong, Pirmin worked on that and it is already available
in Plugin Builder... I remember he showed it to me att FOSS4G last
year, and I guess it will be already in the latest version...

2016-02-25 17:57 GMT+01:00 Spencer Gardner :
> Given that there seems to be interest in encouraging plugin developers to
> tailor their plugins for Processing, would it be possible to add an option
> to Plugin Builder that creates the basic framework for a Processing plugin?
>
> Regards,
> Spencer
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Spencer Gardner]

Given that there seems to be interest in encouraging plugin developers to
tailor their plugins for Processing, would it be possible to add an option
to Plugin Builder that creates the basic framework for a Processing plugin?

Regards,
Spencer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Luigi Pirelli]

+1 tnx Nyall
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**


On 24 February 2016 at 02:56, Nyall Dawson  wrote:
> On 21 February 2016 at 04:59, Luigi Pirelli  wrote:
>> I agree... I discovered them casually browsing the code, and then I
>> browsed all stuff named Qgs...Widget
>
> FYI - to try to address this in future I've added a new entry to the
> changelog detailing all the new PyQGIS classes added in 2.14 with a
> bit of description for each (and link to API docs). Hopefully this
> gives some more exposure to any newly added widgets/classes/etc.
>
> Nyall
>
>
>
>> Luigi Pirelli
>>
>> **
>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
>> * LinkedIn: https://www.linkedin.com/in/luigipirelli
>> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
>> * GitHub: https://github.com/luipir
>> * Mastering QGIS:
>> https://www.packtpub.com/application-development/mastering-qgis
>> **
>>
>>
>> On 19 February 2016 at 13:28, Victor Olaya  wrote:
>>> +1 to promote the custom widgets. I dont think that many plugin
>>> developers are aware of them, since there is no documentation about
>>> them AFAIK
>>>
>>> 2016-02-19 13:24 GMT+01:00 Neumann, Andreas :
 Hi,

 The upcoming user conference in Girona may be a good opportunity to present
 and advertise about both the common set of Python functions, but also about
 the standard and custom widgets.

 The CfP is still running and they are looking for more submissions. Maybe
 someone could do a presentation for Python plugin authors to make them
 aware?

 Andreas

 On 2016-02-19 11:36, Denis Rouzaud wrote:



 On 02/19/2016 11:29 AM, Nyall Dawson wrote:


 On 19 Feb 2016 19:35, "Etienne Trimaille" 
 wrote:
>
> I'm discovering that 'old' topic.
> Yes, I really like the idea, but I wasn't aware about that.
> I think the UI should be more uniform between plugins and QGIS, for
> instance to have :
> - the same combobox about layers (using the symbol for the geometry type
> and the EPSG if the checkbox is checked in the Processing settings)
> - the same combobox for table fields (symbol with the kind of field :
> integer, char ...)
> - the same output field with the menu (save to temp file, save to vector
> file, save to ...) like in processing.

 Just a little advice - we need to push people toward the standard widgets
 for these, eg QgsFieldComboBox, QgsMapLayerComboBox. Reimplementing then
 with new Python versions isn't a good idea, since it breaks consistency 
 with
 core (and is also a lot of extra work!)


 I would say, we even need to advertise the custom widgets.
 All these widgets are availble in Qt Designer, it's quite easy to use them
 from there.



 Nyall

> - ...
> So I will try to use that and contribute to these wrappers if I can.
>
> By the way, is it possible to recommend on the pyqgis cookbook (or the
> qgis documentation) to use the processing framework more often ? A lot of
> plugins are useful but we can't use them in batch mode or in complex
> workflow. Moreover, they often produce only shapefile.
> There are some very nice settings in Processing like "use selected
> features", default output format for vector and raster ... I think plugins
> should try to more compliant with these settings.
>
>
>
>
>
> 2016-02-19 8:55 GMT+01:00 Paolo Cavallini :
>>
>> Il 19/02/2016 08:53, Victor Olaya ha scritto:
>> > I dont think it wil hurt to add it to the main repo. While we develop,
>> > and the methods are not used yet, it will be just a bunch of files
>> > with dead code, so it is not risky, and maybe it is easier to engage
>> > people that way
>>
>> I'd vote for it.
>> Thanks, Victor.
>>
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> 

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

[Nyall Dawson]

On 21 February 2016 at 04:59, Luigi Pirelli  wrote:
> I agree... I discovered them casually browsing the code, and then I
> browsed all stuff named Qgs...Widget

FYI - to try to address this in future I've added a new entry to the
changelog detailing all the new PyQGIS classes added in 2.14 with a
bit of description for each (and link to API docs). Hopefully this
gives some more exposure to any newly added widgets/classes/etc.

Nyall



> Luigi Pirelli
>
> **
> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> * GitHub: https://github.com/luipir
> * Mastering QGIS:
> https://www.packtpub.com/application-development/mastering-qgis
> **
>
>
> On 19 February 2016 at 13:28, Victor Olaya  wrote:
>> +1 to promote the custom widgets. I dont think that many plugin
>> developers are aware of them, since there is no documentation about
>> them AFAIK
>>
>> 2016-02-19 13:24 GMT+01:00 Neumann, Andreas :
>>> Hi,
>>>
>>> The upcoming user conference in Girona may be a good opportunity to present
>>> and advertise about both the common set of Python functions, but also about
>>> the standard and custom widgets.
>>>
>>> The CfP is still running and they are looking for more submissions. Maybe
>>> someone could do a presentation for Python plugin authors to make them
>>> aware?
>>>
>>> Andreas
>>>
>>> On 2016-02-19 11:36, Denis Rouzaud wrote:
>>>
>>>
>>>
>>> On 02/19/2016 11:29 AM, Nyall Dawson wrote:
>>>
>>>
>>> On 19 Feb 2016 19:35, "Etienne Trimaille" 
>>> wrote:

 I'm discovering that 'old' topic.
 Yes, I really like the idea, but I wasn't aware about that.
 I think the UI should be more uniform between plugins and QGIS, for
 instance to have :
 - the same combobox about layers (using the symbol for the geometry type
 and the EPSG if the checkbox is checked in the Processing settings)
 - the same combobox for table fields (symbol with the kind of field :
 integer, char ...)
 - the same output field with the menu (save to temp file, save to vector
 file, save to ...) like in processing.
>>>
>>> Just a little advice - we need to push people toward the standard widgets
>>> for these, eg QgsFieldComboBox, QgsMapLayerComboBox. Reimplementing then
>>> with new Python versions isn't a good idea, since it breaks consistency with
>>> core (and is also a lot of extra work!)
>>>
>>>
>>> I would say, we even need to advertise the custom widgets.
>>> All these widgets are availble in Qt Designer, it's quite easy to use them
>>> from there.
>>>
>>>
>>>
>>> Nyall
>>>
 - ...
 So I will try to use that and contribute to these wrappers if I can.

 By the way, is it possible to recommend on the pyqgis cookbook (or the
 qgis documentation) to use the processing framework more often ? A lot of
 plugins are useful but we can't use them in batch mode or in complex
 workflow. Moreover, they often produce only shapefile.
 There are some very nice settings in Processing like "use selected
 features", default output format for vector and raster ... I think plugins
 should try to more compliant with these settings.





 2016-02-19 8:55 GMT+01:00 Paolo Cavallini :
>
> Il 19/02/2016 08:53, Victor Olaya ha scritto:
> > I dont think it wil hurt to add it to the main repo. While we develop,
> > and the methods are not used yet, it will be just a bunch of files
> > with dead code, so it is not risky, and maybe it is easier to engage
> > people that way
>
> I'd vote for it.
> Thanks, Victor.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer



 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
 Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>>
>>>
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>>
>>>
>>> 

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

[Luigi Pirelli]

I agree... I discovered them casually browsing the code, and then I
browsed all stuff named Qgs...Widget
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**


On 19 February 2016 at 13:28, Victor Olaya  wrote:
> +1 to promote the custom widgets. I dont think that many plugin
> developers are aware of them, since there is no documentation about
> them AFAIK
>
> 2016-02-19 13:24 GMT+01:00 Neumann, Andreas :
>> Hi,
>>
>> The upcoming user conference in Girona may be a good opportunity to present
>> and advertise about both the common set of Python functions, but also about
>> the standard and custom widgets.
>>
>> The CfP is still running and they are looking for more submissions. Maybe
>> someone could do a presentation for Python plugin authors to make them
>> aware?
>>
>> Andreas
>>
>> On 2016-02-19 11:36, Denis Rouzaud wrote:
>>
>>
>>
>> On 02/19/2016 11:29 AM, Nyall Dawson wrote:
>>
>>
>> On 19 Feb 2016 19:35, "Etienne Trimaille" 
>> wrote:
>>>
>>> I'm discovering that 'old' topic.
>>> Yes, I really like the idea, but I wasn't aware about that.
>>> I think the UI should be more uniform between plugins and QGIS, for
>>> instance to have :
>>> - the same combobox about layers (using the symbol for the geometry type
>>> and the EPSG if the checkbox is checked in the Processing settings)
>>> - the same combobox for table fields (symbol with the kind of field :
>>> integer, char ...)
>>> - the same output field with the menu (save to temp file, save to vector
>>> file, save to ...) like in processing.
>>
>> Just a little advice - we need to push people toward the standard widgets
>> for these, eg QgsFieldComboBox, QgsMapLayerComboBox. Reimplementing then
>> with new Python versions isn't a good idea, since it breaks consistency with
>> core (and is also a lot of extra work!)
>>
>>
>> I would say, we even need to advertise the custom widgets.
>> All these widgets are availble in Qt Designer, it's quite easy to use them
>> from there.
>>
>>
>>
>> Nyall
>>
>>> - ...
>>> So I will try to use that and contribute to these wrappers if I can.
>>>
>>> By the way, is it possible to recommend on the pyqgis cookbook (or the
>>> qgis documentation) to use the processing framework more often ? A lot of
>>> plugins are useful but we can't use them in batch mode or in complex
>>> workflow. Moreover, they often produce only shapefile.
>>> There are some very nice settings in Processing like "use selected
>>> features", default output format for vector and raster ... I think plugins
>>> should try to more compliant with these settings.
>>>
>>>
>>>
>>>
>>>
>>> 2016-02-19 8:55 GMT+01:00 Paolo Cavallini :

 Il 19/02/2016 08:53, Victor Olaya ha scritto:
 > I dont think it wil hurt to add it to the main repo. While we develop,
 > and the methods are not used yet, it will be just a bunch of files
 > with dead code, so it is not risky, and maybe it is easier to engage
 > people that way

 I'd vote for it.
 Thanks, Victor.

 --
 Paolo Cavallini - www.faunalia.eu
 QGIS & PostGIS courses: http://www.faunalia.eu/training.html
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
 Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>>
>>>
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: 

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

[Paolo Cavallini]

On 2016-02-19 17:28, Stefan Keller wrote:


I support Etienne's proposal regarding UI guidelines.
I'm sproradically collecting these here [1],
like the "File open..." dialog which remembers the directory,
or preferring GeoPackage over Shapefiles for storing.
There are quite some more things which to my mind when thingking of 
UI.

Eventually it could also help to point to "good" plugins?


Hi all,
I think giving guidelines and coding standards is of crucial importnace 
to keep the plugin ecosystem thriving, especially in view of the 
upcoming migration to Py3 and Qt5.

IMHO the best ways of doing this should be:
* improving Plugin builder, adding all we think is necessary
* writing a Plugin dev howto, pointing to specific cases, recommended 
styles, etc.

Any taker?
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Stefan Keller]

Hi,

I support Etienne's proposal regarding UI guidelines.
I'm sproradically collecting these here [1],
like the "File open..." dialog which remembers the directory,
or preferring GeoPackage over Shapefiles for storing.
There are quite some more things which to my mind when thingking of UI.
Eventually it could also help to point to "good" plugins?

:Stefan

[1] http://giswiki.hsr.ch/QGIS_for_Devs#Guidelines

2016-02-19 13:59 GMT+01:00 Etienne Trimaille :
> 2016-02-19 13:28 GMT+01:00 Victor Olaya :
>>
>> I dont think that many plugin developers are aware of them
>
>
> Yes, exactly. I've heard of them one time.
> Maybe we could add them into the plugin builder as an example. Developers
> will see them in the code.
>
>> I will be happy to provide guidance to any plugin authors that want to
>> convert their plugins into Processing providers
>
> Is there a list of the public API of Processing ?
> For plugins developpers, there are many classes in Processing but a lot of
> them shouldn’t be used outside of Processing I guess, right ?
> I can see : tools/vector, tools/raster, core/GeoAlgorithm, core/parameters
> ...
>
>
>> 2016-02-19 13:24 GMT+01:00 Neumann, Andreas :
>> > Hi,
>> >
>> > The upcoming user conference in Girona may be a good opportunity to
>> > present
>> > and advertise about both the common set of Python functions, but also
>> > about
>> > the standard and custom widgets.
>> >
>> > The CfP is still running and they are looking for more submissions.
>> > Maybe
>> > someone could do a presentation for Python plugin authors to make them
>> > aware?
>> >
>> > Andreas
>> >
>> > On 2016-02-19 11:36, Denis Rouzaud wrote:
>> >
>> >
>> >
>> > On 02/19/2016 11:29 AM, Nyall Dawson wrote:
>> >
>> >
>> > On 19 Feb 2016 19:35, "Etienne Trimaille" 
>> > wrote:
>> >>
>> >> I'm discovering that 'old' topic.
>> >> Yes, I really like the idea, but I wasn't aware about that.
>> >> I think the UI should be more uniform between plugins and QGIS, for
>> >> instance to have :
>> >> - the same combobox about layers (using the symbol for the geometry
>> >> type
>> >> and the EPSG if the checkbox is checked in the Processing settings)
>> >> - the same combobox for table fields (symbol with the kind of field :
>> >> integer, char ...)
>> >> - the same output field with the menu (save to temp file, save to
>> >> vector
>> >> file, save to ...) like in processing.
>> >
>> > Just a little advice - we need to push people toward the standard
>> > widgets
>> > for these, eg QgsFieldComboBox, QgsMapLayerComboBox. Reimplementing then
>> > with new Python versions isn't a good idea, since it breaks consistency
>> > with
>> > core (and is also a lot of extra work!)
>> >
>> >
>> > I would say, we even need to advertise the custom widgets.
>> > All these widgets are availble in Qt Designer, it's quite easy to use
>> > them
>> > from there.
>> >
>> >
>> >
>> > Nyall
>> >
>> >> - ...
>> >> So I will try to use that and contribute to these wrappers if I can.
>> >>
>> >> By the way, is it possible to recommend on the pyqgis cookbook (or the
>> >> qgis documentation) to use the processing framework more often ? A lot
>> >> of
>> >> plugins are useful but we can't use them in batch mode or in complex
>> >> workflow. Moreover, they often produce only shapefile.
>> >> There are some very nice settings in Processing like "use selected
>> >> features", default output format for vector and raster ... I think
>> >> plugins
>> >> should try to more compliant with these settings.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> 2016-02-19 8:55 GMT+01:00 Paolo Cavallini :
>> >>>
>> >>> Il 19/02/2016 08:53, Victor Olaya ha scritto:
>> >>> > I dont think it wil hurt to add it to the main repo. While we
>> >>> > develop,
>> >>> > and the methods are not used yet, it will be just a bunch of files
>> >>> > with dead code, so it is not risky, and maybe it is easier to engage
>> >>> > people that way
>> >>>
>> >>> I'd vote for it.
>> >>> Thanks, Victor.
>> >>>
>> >>> --
>> >>> Paolo Cavallini - www.faunalia.eu
>> >>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> >>> ___
>> >>> Qgis-developer mailing list
>> >>> Qgis-developer@lists.osgeo.org
>> >>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >>
>> >>
>> >>
>> >> ___
>> >> Qgis-developer mailing list
>> >> Qgis-developer@lists.osgeo.org
>> >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >
>> >
>> >
>> > ___
>> > Qgis-developer mailing list
>> > Qgis-developer@lists.osgeo.org
>> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > 

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

[Victor Olaya]

+1 to promote the custom widgets. I dont think that many plugin
developers are aware of them, since there is no documentation about
them AFAIK

2016-02-19 13:24 GMT+01:00 Neumann, Andreas :
> Hi,
>
> The upcoming user conference in Girona may be a good opportunity to present
> and advertise about both the common set of Python functions, but also about
> the standard and custom widgets.
>
> The CfP is still running and they are looking for more submissions. Maybe
> someone could do a presentation for Python plugin authors to make them
> aware?
>
> Andreas
>
> On 2016-02-19 11:36, Denis Rouzaud wrote:
>
>
>
> On 02/19/2016 11:29 AM, Nyall Dawson wrote:
>
>
> On 19 Feb 2016 19:35, "Etienne Trimaille" 
> wrote:
>>
>> I'm discovering that 'old' topic.
>> Yes, I really like the idea, but I wasn't aware about that.
>> I think the UI should be more uniform between plugins and QGIS, for
>> instance to have :
>> - the same combobox about layers (using the symbol for the geometry type
>> and the EPSG if the checkbox is checked in the Processing settings)
>> - the same combobox for table fields (symbol with the kind of field :
>> integer, char ...)
>> - the same output field with the menu (save to temp file, save to vector
>> file, save to ...) like in processing.
>
> Just a little advice - we need to push people toward the standard widgets
> for these, eg QgsFieldComboBox, QgsMapLayerComboBox. Reimplementing then
> with new Python versions isn't a good idea, since it breaks consistency with
> core (and is also a lot of extra work!)
>
>
> I would say, we even need to advertise the custom widgets.
> All these widgets are availble in Qt Designer, it's quite easy to use them
> from there.
>
>
>
> Nyall
>
>> - ...
>> So I will try to use that and contribute to these wrappers if I can.
>>
>> By the way, is it possible to recommend on the pyqgis cookbook (or the
>> qgis documentation) to use the processing framework more often ? A lot of
>> plugins are useful but we can't use them in batch mode or in complex
>> workflow. Moreover, they often produce only shapefile.
>> There are some very nice settings in Processing like "use selected
>> features", default output format for vector and raster ... I think plugins
>> should try to more compliant with these settings.
>>
>>
>>
>>
>>
>> 2016-02-19 8:55 GMT+01:00 Paolo Cavallini :
>>>
>>> Il 19/02/2016 08:53, Victor Olaya ha scritto:
>>> > I dont think it wil hurt to add it to the main repo. While we develop,
>>> > and the methods are not used yet, it will be just a bunch of files
>>> > with dead code, so it is not risky, and maybe it is easier to engage
>>> > people that way
>>>
>>> I'd vote for it.
>>> Thanks, Victor.
>>>
>>> --
>>> Paolo Cavallini - www.faunalia.eu
>>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Neumann, Andreas]

Hi, 

The upcoming user conference in Girona may be a good opportunity to
present and advertise about both the common set of Python functions, but
also about the standard and custom widgets. 

The CfP is still running and they are looking for more submissions.
Maybe someone could do a presentation for Python plugin authors to make
them aware? 

Andreas 

On 2016-02-19 11:36, Denis Rouzaud wrote:

> On 02/19/2016 11:29 AM, Nyall Dawson wrote: 
> 
>> On 19 Feb 2016 19:35, "Etienne Trimaille"  
>> wrote:
>>> 
>>> I'm discovering that 'old' topic.
>>> Yes, I really like the idea, but I wasn't aware about that.
>>> I think the UI should be more uniform between plugins and QGIS, for 
>>> instance to have : 
>>> - the same combobox about layers (using the symbol for the geometry type 
>>> and the EPSG if the checkbox is checked in the Processing settings)
>>> - the same combobox for table fields (symbol with the kind of field : 
>>> integer, char ...)
>>> - the same output field with the menu (save to temp file, save to vector 
>>> file, save to ...) like in processing. 
>> 
>> Just a little advice - we need to push people toward the standard widgets 
>> for these, eg QgsFieldComboBox, QgsMapLayerComboBox. Reimplementing then 
>> with new Python versions isn't a good idea, since it breaks consistency with 
>> core (and is also a lot of extra work!)
> 
> I would say, we even need to advertise the custom widgets.
> All these widgets are availble in Qt Designer, it's quite easy to use them 
> from there.
> 
>> Nyall 
>> 
>>> - ...
>>> So I will try to use that and contribute to these wrappers if I can. 
>>> 
>>> By the way, is it possible to recommend on the pyqgis cookbook (or the qgis 
>>> documentation) to use the processing framework more often ? A lot of 
>>> plugins are useful but we can't use them in batch mode or in complex 
>>> workflow. Moreover, they often produce only shapefile.
>>> There are some very nice settings in Processing like "use selected 
>>> features", default output format for vector and raster ... I think plugins 
>>> should try to more compliant with these settings.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 2016-02-19 8:55 GMT+01:00 Paolo Cavallini :
 
 Il 19/02/2016 08:53, Victor Olaya ha scritto:
> I dont think it wil hurt to add it to the main repo. While we develop,
> and the methods are not used yet, it will be just a bunch of files
> with dead code, so it is not risky, and maybe it is easier to engage
> people that way
 
 I'd vote for it.
 Thanks, Victor.
 
 --
 Paolo Cavallini - www.faunalia.eu [1]
 QGIS & PostGIS courses: http://www.faunalia.eu/training.html
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
 Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> 
>>> 
>>> 
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer 
>> 
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

  

Links:
--
[1] http://www.faunalia.eu
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Denis Rouzaud]

On 02/19/2016 11:29 AM, Nyall Dawson wrote:



On 19 Feb 2016 19:35, "Etienne Trimaille" > wrote:

>
> I'm discovering that 'old' topic.
> Yes, I really like the idea, but I wasn't aware about that.
> I think the UI should be more uniform between plugins and QGIS, for 
instance to have :
> - the same combobox about layers (using the symbol for the geometry 
type and the EPSG if the checkbox is checked in the Processing settings)
> - the same combobox for table fields (symbol with the kind of field 
: integer, char ...)
> - the same output field with the menu (save to temp file, save to 
vector file, save to ...) like in processing.


Just a little advice - we need to push people toward the standard 
widgets for these, eg QgsFieldComboBox, QgsMapLayerComboBox. 
Reimplementing then with new Python versions isn't a good idea, since 
it breaks consistency with core (and is also a lot of extra work!)




I would say, we even need to advertise the custom widgets.
All these widgets are availble in Qt Designer, it's quite easy to use 
them from there.





Nyall

> - ...
> So I will try to use that and contribute to these wrappers if I can.
>
> By the way, is it possible to recommend on the pyqgis cookbook (or 
the qgis documentation) to use the processing framework more often ? A 
lot of plugins are useful but we can't use them in batch mode or in 
complex workflow. Moreover, they often produce only shapefile.
> There are some very nice settings in Processing like "use selected 
features", default output format for vector and raster ... I think 
plugins should try to more compliant with these settings.

>
>
>
>
>
> 2016-02-19 8:55 GMT+01:00 Paolo Cavallini >:

>>
>> Il 19/02/2016 08:53, Victor Olaya ha scritto:
>> > I dont think it wil hurt to add it to the main repo. While we 
develop,

>> > and the methods are not used yet, it will be just a bunch of files
>> > with dead code, so it is not risky, and maybe it is easier to engage
>> > people that way
>>
>> I'd vote for it.
>> Thanks, Victor.
>>
>> --
>> Paolo Cavallini - www.faunalia.eu 
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org 
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org 
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nathan Woodrow]

On Fri, Feb 19, 2016 at 8:29 PM, Nyall Dawson 
wrote:

> Just a little advice - we need to push people toward the standard widgets
> for these, eg QgsFieldComboBox, QgsMapLayerComboBox. Reimplementing then
> with new Python versions isn't a good idea, since it breaks consistency
> with core


+1 for that.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nyall Dawson]

On 19 Feb 2016 19:35, "Etienne Trimaille" 
wrote:
>
> I'm discovering that 'old' topic.
> Yes, I really like the idea, but I wasn't aware about that.
> I think the UI should be more uniform between plugins and QGIS, for
instance to have :
> - the same combobox about layers (using the symbol for the geometry type
and the EPSG if the checkbox is checked in the Processing settings)
> - the same combobox for table fields (symbol with the kind of field :
integer, char ...)
> - the same output field with the menu (save to temp file, save to vector
file, save to ...) like in processing.

Just a little advice - we need to push people toward the standard widgets
for these, eg QgsFieldComboBox, QgsMapLayerComboBox. Reimplementing then
with new Python versions isn't a good idea, since it breaks consistency
with core (and is also a lot of extra work!)

Nyall

> - ...
> So I will try to use that and contribute to these wrappers if I can.
>
> By the way, is it possible to recommend on the pyqgis cookbook (or the
qgis documentation) to use the processing framework more often ? A lot of
plugins are useful but we can't use them in batch mode or in complex
workflow. Moreover, they often produce only shapefile.
> There are some very nice settings in Processing like "use selected
features", default output format for vector and raster ... I think plugins
should try to more compliant with these settings.
>
>
>
>
>
> 2016-02-19 8:55 GMT+01:00 Paolo Cavallini :
>>
>> Il 19/02/2016 08:53, Victor Olaya ha scritto:
>> > I dont think it wil hurt to add it to the main repo. While we develop,
>> > and the methods are not used yet, it will be just a bunch of files
>> > with dead code, so it is not risky, and maybe it is easier to engage
>> > people that way
>>
>> I'd vote for it.
>> Thanks, Victor.
>>
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

>
> By the way, is it possible to recommend on the pyqgis cookbook (or the qgis
> documentation) to use the processing framework more often ? A lot of plugins
> are useful but we can't use them in batch mode or in complex workflow.
> Moreover, they often produce only shapefile.
> There are some very nice settings in Processing like "use selected
> features", default output format for vector and raster ... I think plugins
> should try to more compliant with these settings.
>
>

I try to convince people of that. If you are writing an analysis
plugin, don't do it without Processing, since it will be harder and
you dont get all those advantages. However, I dont want to sound too
strong on that, since i dont want it to sound like i want impose that
on developers, but it might be worth at least mentioning that to
plugin authors when they upload their plugins and we accept them...

I will be happy to provide guidance to any plugin authors that want to
convert their plugins into Processing providers

Cheers
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nathan Woodrow]

Given that we have 3.0 on the cards and that has a planned API break and
refactor I think this stuff is better planned for that so we can all focus
effort on making that good.

Thoughts?



On Fri, Feb 19, 2016 at 6:35 PM, Etienne Trimaille <
etienne.trimai...@gmail.com> wrote:

> I'm discovering that 'old' topic.
> Yes, I really like the idea, but I wasn't aware about that.
> I think the UI should be more uniform between plugins and QGIS, for
> instance to have :
> - the same combobox about layers (using the symbol for the geometry type
> and the EPSG if the checkbox is checked in the Processing settings)
> - the same combobox for table fields (symbol with the kind of field :
> integer, char ...)
> - the same output field with the menu (save to temp file, save to vector
> file, save to ...) like in processing.
> - ...
> So I will try to use that and contribute to these wrappers if I can.
>
> By the way, is it possible to recommend on the pyqgis cookbook (or the
> qgis documentation) to use the processing framework more often ? A lot of
> plugins are useful but we can't use them in batch mode or in complex
> workflow. Moreover, they often produce only shapefile.
> There are some very nice settings in Processing like "use selected
> features", default output format for vector and raster ... I think plugins
> should try to more compliant with these settings.
>
>
>
>
>
> 2016-02-19 8:55 GMT+01:00 Paolo Cavallini :
>
>> Il 19/02/2016 08:53, Victor Olaya ha scritto:
>> > I dont think it wil hurt to add it to the main repo. While we develop,
>> > and the methods are not used yet, it will be just a bunch of files
>> > with dead code, so it is not risky, and maybe it is easier to engage
>> > people that way
>>
>> I'd vote for it.
>> Thanks, Victor.
>>
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Etienne Trimaille]

I'm discovering that 'old' topic.
Yes, I really like the idea, but I wasn't aware about that.
I think the UI should be more uniform between plugins and QGIS, for
instance to have :
- the same combobox about layers (using the symbol for the geometry type
and the EPSG if the checkbox is checked in the Processing settings)
- the same combobox for table fields (symbol with the kind of field :
integer, char ...)
- the same output field with the menu (save to temp file, save to vector
file, save to ...) like in processing.
- ...
So I will try to use that and contribute to these wrappers if I can.

By the way, is it possible to recommend on the pyqgis cookbook (or the qgis
documentation) to use the processing framework more often ? A lot of
plugins are useful but we can't use them in batch mode or in complex
workflow. Moreover, they often produce only shapefile.
There are some very nice settings in Processing like "use selected
features", default output format for vector and raster ... I think plugins
should try to more compliant with these settings.





2016-02-19 8:55 GMT+01:00 Paolo Cavallini :

> Il 19/02/2016 08:53, Victor Olaya ha scritto:
> > I dont think it wil hurt to add it to the main repo. While we develop,
> > and the methods are not used yet, it will be just a bunch of files
> > with dead code, so it is not risky, and maybe it is easier to engage
> > people that way
>
> I'd vote for it.
> Thanks, Victor.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Paolo Cavallini]

Il 19/02/2016 08:53, Victor Olaya ha scritto:
> I dont think it wil hurt to add it to the main repo. While we develop,
> and the methods are not used yet, it will be just a bunch of files
> with dead code, so it is not risky, and maybe it is easier to engage
> people that way

I'd vote for it.
Thanks, Victor.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

I dont think it wil hurt to add it to the main repo. While we develop,
and the methods are not used yet, it will be just a bunch of files
with dead code, so it is not risky, and maybe it is easier to engage
people that way

Let me know if there is something i can do

Cheers



2016-02-19 7:50 GMT+01:00 Nathan Woodrow :
> Hi,
>
> I think for me it was mainly about timing.  It was over the christmas period
> so I tend to avoid doing too much around then, and with 3.0 planned I think
> we can have some direction now.
>
> Regards,
>
> On Fri, Feb 19, 2016 at 4:48 PM, Paolo Cavallini 
> wrote:
>>
>> Il 19/02/2016 07:19, Victor Olaya ha scritto:
>> > No, we havent' moved to the main repo. However, not much work has been
>> > done lately, and we haven't discussed about how to continue or when to
>> > move all this to the main repo.
>> >
>> > Looks like the project is not being very succesful...
>>
>> still, it seems to me quite important. Perhaps developing in a separate
>> repo brings away the attention of many.
>> Maybe we should just advertise it more aggressively, also among the
>> hiundreds of plugin developers? Please remember that many of them are
>> not on this list, so may be completely unaware of your project.
>> All the best, and thanks.
>>
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nathan Woodrow]

Hi,

I think for me it was mainly about timing.  It was over the christmas
period so I tend to avoid doing too much around then, and with 3.0 planned
I think we can have some direction now.

Regards,

On Fri, Feb 19, 2016 at 4:48 PM, Paolo Cavallini 
wrote:

> Il 19/02/2016 07:19, Victor Olaya ha scritto:
> > No, we havent' moved to the main repo. However, not much work has been
> > done lately, and we haven't discussed about how to continue or when to
> > move all this to the main repo.
> >
> > Looks like the project is not being very succesful...
>
> still, it seems to me quite important. Perhaps developing in a separate
> repo brings away the attention of many.
> Maybe we should just advertise it more aggressively, also among the
> hiundreds of plugin developers? Please remember that many of them are
> not on this list, so may be completely unaware of your project.
> All the best, and thanks.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Paolo Cavallini]

Il 19/02/2016 07:19, Victor Olaya ha scritto:
> No, we havent' moved to the main repo. However, not much work has been
> done lately, and we haven't discussed about how to continue or when to
> move all this to the main repo.
> 
> Looks like the project is not being very succesful...

still, it seems to me quite important. Perhaps developing in a separate
repo brings away the attention of many.
Maybe we should just advertise it more aggressively, also among the
hiundreds of plugin developers? Please remember that many of them are
not on this list, so may be completely unaware of your project.
All the best, and thanks.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

No, we havent' moved to the main repo. However, not much work has been done
lately, and we haven't discussed about how to continue or when to move all
this to the main repo.

Looks like the project is not being very succesful...

2016-02-18 20:03 GMT+01:00 Anita Graser :

> Hi,
> Are you still working on https://github.com/qgis/pyqgis_wrappers or have
> you moved to the main repo?
> Best wishes,
> Anita
>
> On Fri, Nov 20, 2015 at 9:57 AM, Victor Olaya  wrote:
>
>> Stefan
>>
>> We opened this repo to work in there
>>
>> https://github.com/qgis/pyqgis_wrappers
>>
>> Nathan moved his code there already. I haven't had much time, but will
>> move mine and keep working in there
>>
>>
>>
>> 2015-11-19 20:42 GMT+01:00 Stefan Keller :
>>
>>> Hi Tim, Victor[1], John [2], Nathan [3] and Gary [4]
>>>
>>> Good initiative which I also would keep in a sandbox so long.
>>> I'd like to check my plugins against (and probably contribute to) this
>>> common set of functions for QGIS Python plugins.
>>>
>>> [1] seems to be the unifid place and this has been changed since 21
>>> days.
>>> Is this the common set for now?
>>>
>>> :Stefan
>>>
>>> [1] https://github.com/volaya/qgiscommons
>>> [2] https://github.com/lparchaeology/libarkqgis.
>>> [3] https://github.com/NathanW2/parfait
>>> [4] http://locatepress.com/ppg/data_code
>>>
>>> 2015-11-08 23:21 GMT+01:00 Nathan Woodrow :
>>>
 No even really that.  Just mainly because like we said it's not
 considered stable at the moment and we don't want to be linked to the
 release cycle.  It will be good to mainly just test ideas first and then
 merge it later.

 - Nathan

 On Mon, Nov 9, 2015 at 7:55 AM, Tim Sutton  wrote:

> Hi
>
> On 05 Nov 2015, at 17:34, Paolo Cavallini 
> wrote:
>
> Il 05/11/2015 09:24, Nathan Woodrow ha scritto:
>
> Yep that is the plan.
>
>
> I see you already done it, so now it's probably pointless, but: why not
> using git submodules?
>
>
>
> Many consider submodules a PITA e.g.
>
>
> http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/
>
> Regards
>
> Tim
>
> All the best.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> —
>
>
>
>
> Tim Sutton
>
> Visit http://kartoza.com to find out about open source:
>
> * Desktop GIS programming services
> * Geospatial web development
> * GIS Training
> * Consulting Services
>
> Skype: timlinux Irc: timlinux on #qgis at freenode.net
> Tim is a member of the QGIS Project Steering Committee
>
> Kartoza is a merger between Linfiniti and Afrispatial
>
>

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

>>>
>>>
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Anita Graser]

Hi,
Are you still working on https://github.com/qgis/pyqgis_wrappers or have
you moved to the main repo?
Best wishes,
Anita

On Fri, Nov 20, 2015 at 9:57 AM, Victor Olaya  wrote:

> Stefan
>
> We opened this repo to work in there
>
> https://github.com/qgis/pyqgis_wrappers
>
> Nathan moved his code there already. I haven't had much time, but will
> move mine and keep working in there
>
>
>
> 2015-11-19 20:42 GMT+01:00 Stefan Keller :
>
>> Hi Tim, Victor[1], John [2], Nathan [3] and Gary [4]
>>
>> Good initiative which I also would keep in a sandbox so long.
>> I'd like to check my plugins against (and probably contribute to) this
>> common set of functions for QGIS Python plugins.
>>
>> [1] seems to be the unifid place and this has been changed since 21 days.
>> Is this the common set for now?
>>
>> :Stefan
>>
>> [1] https://github.com/volaya/qgiscommons
>> [2] https://github.com/lparchaeology/libarkqgis.
>> [3] https://github.com/NathanW2/parfait
>> [4] http://locatepress.com/ppg/data_code
>>
>> 2015-11-08 23:21 GMT+01:00 Nathan Woodrow :
>>
>>> No even really that.  Just mainly because like we said it's not
>>> considered stable at the moment and we don't want to be linked to the
>>> release cycle.  It will be good to mainly just test ideas first and then
>>> merge it later.
>>>
>>> - Nathan
>>>
>>> On Mon, Nov 9, 2015 at 7:55 AM, Tim Sutton  wrote:
>>>
 Hi

 On 05 Nov 2015, at 17:34, Paolo Cavallini 
 wrote:

 Il 05/11/2015 09:24, Nathan Woodrow ha scritto:

 Yep that is the plan.


 I see you already done it, so now it's probably pointless, but: why not
 using git submodules?



 Many consider submodules a PITA e.g.


 http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/

 Regards

 Tim

 All the best.

 --
 Paolo Cavallini - www.faunalia.eu
 QGIS & PostGIS courses: http://www.faunalia.eu/training.html
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


 —




 Tim Sutton

 Visit http://kartoza.com to find out about open source:

 * Desktop GIS programming services
 * Geospatial web development
 * GIS Training
 * Consulting Services

 Skype: timlinux Irc: timlinux on #qgis at freenode.net
 Tim is a member of the QGIS Project Steering Committee

 Kartoza is a merger between Linfiniti and Afrispatial


>>>
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

Stefan

We opened this repo to work in there

https://github.com/qgis/pyqgis_wrappers

Nathan moved his code there already. I haven't had much time, but will move
mine and keep working in there



2015-11-19 20:42 GMT+01:00 Stefan Keller :

> Hi Tim, Victor[1], John [2], Nathan [3] and Gary [4]
>
> Good initiative which I also would keep in a sandbox so long.
> I'd like to check my plugins against (and probably contribute to) this
> common set of functions for QGIS Python plugins.
>
> [1] seems to be the unifid place and this has been changed since 21 days.
> Is this the common set for now?
>
> :Stefan
>
> [1] https://github.com/volaya/qgiscommons
> [2] https://github.com/lparchaeology/libarkqgis.
> [3] https://github.com/NathanW2/parfait
> [4] http://locatepress.com/ppg/data_code
>
> 2015-11-08 23:21 GMT+01:00 Nathan Woodrow :
>
>> No even really that.  Just mainly because like we said it's not
>> considered stable at the moment and we don't want to be linked to the
>> release cycle.  It will be good to mainly just test ideas first and then
>> merge it later.
>>
>> - Nathan
>>
>> On Mon, Nov 9, 2015 at 7:55 AM, Tim Sutton  wrote:
>>
>>> Hi
>>>
>>> On 05 Nov 2015, at 17:34, Paolo Cavallini  wrote:
>>>
>>> Il 05/11/2015 09:24, Nathan Woodrow ha scritto:
>>>
>>> Yep that is the plan.
>>>
>>>
>>> I see you already done it, so now it's probably pointless, but: why not
>>> using git submodules?
>>>
>>>
>>>
>>> Many consider submodules a PITA e.g.
>>>
>>>
>>> http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/
>>>
>>> Regards
>>>
>>> Tim
>>>
>>> All the best.
>>>
>>> --
>>> Paolo Cavallini - www.faunalia.eu
>>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>>
>>> —
>>>
>>>
>>>
>>>
>>> Tim Sutton
>>>
>>> Visit http://kartoza.com to find out about open source:
>>>
>>> * Desktop GIS programming services
>>> * Geospatial web development
>>> * GIS Training
>>> * Consulting Services
>>>
>>> Skype: timlinux Irc: timlinux on #qgis at freenode.net
>>> Tim is a member of the QGIS Project Steering Committee
>>>
>>> Kartoza is a merger between Linfiniti and Afrispatial
>>>
>>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Stefan Keller]

Hi Tim, Victor[1], John [2], Nathan [3] and Gary [4]

Good initiative which I also would keep in a sandbox so long.
I'd like to check my plugins against (and probably contribute to) this
common set of functions for QGIS Python plugins.

[1] seems to be the unifid place and this has been changed since 21 days.
Is this the common set for now?

:Stefan

[1] https://github.com/volaya/qgiscommons
[2] https://github.com/lparchaeology/libarkqgis.
[3] https://github.com/NathanW2/parfait
[4] http://locatepress.com/ppg/data_code

2015-11-08 23:21 GMT+01:00 Nathan Woodrow :

> No even really that.  Just mainly because like we said it's not considered
> stable at the moment and we don't want to be linked to the release cycle.
> It will be good to mainly just test ideas first and then merge it later.
>
> - Nathan
>
> On Mon, Nov 9, 2015 at 7:55 AM, Tim Sutton  wrote:
>
>> Hi
>>
>> On 05 Nov 2015, at 17:34, Paolo Cavallini  wrote:
>>
>> Il 05/11/2015 09:24, Nathan Woodrow ha scritto:
>>
>> Yep that is the plan.
>>
>>
>> I see you already done it, so now it's probably pointless, but: why not
>> using git submodules?
>>
>>
>>
>> Many consider submodules a PITA e.g.
>>
>>
>> http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/
>>
>> Regards
>>
>> Tim
>>
>> All the best.
>>
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>> —
>>
>>
>>
>>
>> Tim Sutton
>>
>> Visit http://kartoza.com to find out about open source:
>>
>> * Desktop GIS programming services
>> * Geospatial web development
>> * GIS Training
>> * Consulting Services
>>
>> Skype: timlinux Irc: timlinux on #qgis at freenode.net
>> Tim is a member of the QGIS Project Steering Committee
>>
>> Kartoza is a merger between Linfiniti and Afrispatial
>>
>>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Tim Sutton]

Hi

> On 05 Nov 2015, at 17:34, Paolo Cavallini  wrote:
> 
> Il 05/11/2015 09:24, Nathan Woodrow ha scritto:
>> Yep that is the plan.
> 
> I see you already done it, so now it's probably pointless, but: why not
> using git submodules?


Many consider submodules a PITA e.g.

http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/

Regards

Tim

> All the best.
> 
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

—





Tim Sutton

Visit http://kartoza.com  to find out about open source:

* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services

Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee

Kartoza is a merger between Linfiniti and Afrispatial



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nathan Woodrow]

No even really that.  Just mainly because like we said it's not considered
stable at the moment and we don't want to be linked to the release cycle.
It will be good to mainly just test ideas first and then merge it later.

- Nathan

On Mon, Nov 9, 2015 at 7:55 AM, Tim Sutton  wrote:

> Hi
>
> On 05 Nov 2015, at 17:34, Paolo Cavallini  wrote:
>
> Il 05/11/2015 09:24, Nathan Woodrow ha scritto:
>
> Yep that is the plan.
>
>
> I see you already done it, so now it's probably pointless, but: why not
> using git submodules?
>
>
>
> Many consider submodules a PITA e.g.
>
>
> http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/
>
> Regards
>
> Tim
>
> All the best.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> —
>
>
>
>
> Tim Sutton
>
> Visit http://kartoza.com to find out about open source:
>
> * Desktop GIS programming services
> * Geospatial web development
> * GIS Training
> * Consulting Services
>
> Skype: timlinux Irc: timlinux on #qgis at freenode.net
> Tim is a member of the QGIS Project Steering Committee
>
> Kartoza is a merger between Linfiniti and Afrispatial
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

Nathan, that sounds like a great idea.

Having it under the QGIS organzation in github will avoid people
thinking it is an unofficial and probably unreliable project (as
someone mentioned before), and will help giving it more visibility,
even if we dont put it into core yet

Anyone with permission to do it (Gary, Tim?) can create that repo?
Which name do we use for it?



2015-11-05 8:56 GMT+01:00 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  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 :
>> > 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 > >> > 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@lists.osgeo.org
>> >> 
>> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> Qgis-developer mailing list
>> >> Qgis-developer@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
>> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Paolo Cavallini]

Hi all,

Il 05/11/2015 09:08, Victor Olaya ha scritto:
> Having it under the QGIS organzation in github will avoid people
> thinking it is an unofficial and probably unreliable project (as
> someone mentioned before), and will help giving it more visibility,
> even if we dont put it into core yet

why exactly do you want to keep it out of core?
All the best, and thanks.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nathan Woodrow]

Mainly just for more rapid dev and so that it doesn't have to be stable API
yet or fit in with release plans.

Just for now. Consider it a sandbox until stable

On Thu, 5 Nov 2015 6:15 pm Paolo Cavallini  wrote:

> Hi all,
>
> Il 05/11/2015 09:08, Victor Olaya ha scritto:
> > Having it under the QGIS organzation in github will avoid people
> > thinking it is an unofficial and probably unreliable project (as
> > someone mentioned before), and will help giving it more visibility,
> > even if we dont put it into core yet
>
> why exactly do you want to keep it out of core?
> All the best, and thanks.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

>
> why exactly do you want to keep it out of core?

Maybe to have more freedom to experiment in there...? I also think
that it will be easier to get people to collaborate in it, seeing it
as a smaller project, instead of having to do PRs agains the whole
QGIS project, which can feel more intimidating for a casual plugin
developer.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Neumann, Andreas]

 

Perhaps we can have it separate first - try it out - improve things and
then integrate it in core? 

If it is in core, it has to be stabilized - which I understand may not
be the case in the beginning. 

Andreas 

On 2015-11-05 09:14, Paolo Cavallini wrote: 

> Hi all,
> 
> Il 05/11/2015 09:08, Victor Olaya ha scritto: 
> 
>> Having it under the QGIS organzation in github will avoid people
>> thinking it is an unofficial and probably unreliable project (as
>> someone mentioned before), and will help giving it more visibility,
>> even if we dont put it into core yet
> 
> why exactly do you want to keep it out of core?
> All the best, and thanks.

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

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

[Nathan Woodrow]

Yep that is the plan.

On Thu, 5 Nov 2015 6:21 pm Neumann, Andreas  wrote:

> Perhaps we can have it separate first - try it out - improve things and
> then integrate it in core?
>
> If it is in core, it has to be stabilized - which I understand may not be
> the case in the beginning.
>
> Andreas
>
> On 2015-11-05 09:14, Paolo Cavallini wrote:
>
> Hi all,
>
> Il 05/11/2015 09:08, Victor Olaya ha scritto:
>
> Having it under the QGIS organzation in github will avoid people
> thinking it is an unofficial and probably unreliable project (as
> someone mentioned before), and will help giving it more visibility,
> even if we dont put it into core yet
>
>
> why exactly do you want to keep it out of core?
> All the best, and thanks.
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Paolo Cavallini]

Il 05/11/2015 09:24, Nathan Woodrow ha scritto:
> Yep that is the plan.

I see you already done it, so now it's probably pointless, but: why not
using git submodules?
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [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  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 :
> > 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  >> > 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@lists.osgeo.org  Qgis-developer@lists.osgeo.org>
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
> >>
> >>
> >>
> >> ___
> >> Qgis-developer mailing list
> >> Qgis-developer@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
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [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 :
> 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 > > 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@lists.osgeo.org 
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@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
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Gary Sherman]

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 > 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@lists.osgeo.org 
http://lists.osgeo.org/mailman/listinfo/qgis-developer




___
Qgis-developer mailing list
Qgis-developer@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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

>
> A definite +1 on this.
> Also maybe a parent QGISPlugin class all plugins would inherit from ?

This is a good idea, and it would be easy to modify the Plugin Builder
plugin to generate plugin skeletons using that class

>
> As a side note on plugin, but important, Hugo intends at the hackfest to
> propose and discuss having plugins be Python modules, so that we can use
> PIP to deal with module and plugins dependencies.
> This would solve this problem and let us use common Python tools, be it
> on the plugin side, or the module management side, and ease packaging
> also for the distributions.
>

Sounds good as well. In case you do a small meeting for discussing
that (and also with other meetings that might happen), could it be
possibel to participate via skype/google hangout?
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Vincent Picavet (ml)]

Hello Victor,

A definite +1 on this.
Also maybe a parent QGISPlugin class all plugins would inherit from ?

As a side note on plugin, but important, Hugo intends at the hackfest to
propose and discuss having plugins be Python modules, so that we can use
PIP to deal with module and plugins dependencies.
This would solve this problem and let us use common Python tools, be it
on the plugin side, or the module management side, and ease packaging
also for the distributions.

Vincent

On 02/11/2015 23:53, Nathan Woodrow wrote:
> Hey Victor,
> 
> Just added you with write access to my project if you want.  I don't
> really mind if you wanted to work on the same one together.  My
> motivations were the same as you in the end.  Mainly just flesh
> something out in a sandbox and then we can add it to core once we have
> it nutted out.
> 
> Regards,
> 
> On Tue, Nov 3, 2015 at 8:43 AM, Victor Olaya  > wrote:
> 
> Hey Nathan
> 
> I knew about your project...but forgot about it :-) Sorry for that.
> 
> What would you suggest doing? merging them maybe? I like that idea. In
> the end, the plan is just to have a sandbox to add those functions and
> eventually move them to core (btw, qgis.py sounds good to me...)
> 
> I can make a PR to your repo if you think it is a good idea, and we
> keep on working there.
> 
> Let me know also if you have ideas about what to add to fill those
> modules with useful stuff
> 
> Cheers!
> 
> 2015-11-02 14:29 GMT+01:00 Nathan Woodrow  >:
> > Hey Victor,
> >
> > Working on the same kind of thing over here:
> > https://github.com/NathanW2/parfait
> >
> > 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  > 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@lists.osgeo.org
> 
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> 
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

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

[Vincent Picavet (ml)]

Hello Victor,

A definite +1 on this.
Also maybe a parent QGISPlugin class all plugins would inherit from ?

As a side note on plugin, but important, Hugo intends at the hackfest to
propose and discuss having plugins be Python modules, so that we can use
PIP to deal with module and plugins dependencies.
This would solve this problem and let us use common Python tools, be it
on the plugin side, or the module management side, and ease packaging
also for the distributions.

Vincent

On 02/11/2015 23:53, Nathan Woodrow wrote:
> Hey Victor,
> 
> Just added you with write access to my project if you want.  I don't
> really mind if you wanted to work on the same one together.  My
> motivations were the same as you in the end.  Mainly just flesh
> something out in a sandbox and then we can add it to core once we have
> it nutted out.
> 
> Regards,
> 
> On Tue, Nov 3, 2015 at 8:43 AM, Victor Olaya  > wrote:
> 
> Hey Nathan
> 
> I knew about your project...but forgot about it :-) Sorry for that.
> 
> What would you suggest doing? merging them maybe? I like that idea. In
> the end, the plan is just to have a sandbox to add those functions and
> eventually move them to core (btw, qgis.py sounds good to me...)
> 
> I can make a PR to your repo if you think it is a good idea, and we
> keep on working there.
> 
> Let me know also if you have ideas about what to add to fill those
> modules with useful stuff
> 
> Cheers!
> 
> 2015-11-02 14:29 GMT+01:00 Nathan Woodrow  >:
> > Hey Victor,
> >
> > Working on the same kind of thing over here:
> > https://github.com/NathanW2/parfait
> >
> > 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  > 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@lists.osgeo.org
> 
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> 
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

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

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

[Geo DrinX]

Great Victor !

+1

:)



2015-11-02 13:52 GMT+01:00 Victor Olaya :

> 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...
>
> May plan of action is as follows:
>
> - Work on implementing a comprehensive set of functions and classes,
> hopefully with the help of other devs
>
> - Adapt Processing to use it and replace the current set of utilities
> that Processing (like many plugins) has.
>
> - Create a QEP to elevate this set of functions and classes to the
> qgis.utils module, so it has more visibility and it becomes a part of
> QGIS core.
>
> Following this, I believe the next steps that we could take could be:
>
> - Documenting this clearly in the PyCookbook, so all devs are aware of
> this.
>
> - Enforcing the use of common functions and classes, and even request
> it before a plugin is accepted for publishing
>
>
> Since we will be transitioning to Qt5/Python3, this set of common
> functions sounds also like a good place to add all kinds of utilities
> that might help this migration for existing plugins.
>
> Let me know your thoughts
>
> Even if you cannot contribute the code of a function to the repo, feel
> free to open an issue recommending functions that you consider should
> be in there. I will be working on this and will implement all those
> ideas if they sound interesting and useful for other people
>
>
> Thanks in advance
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nathan Woodrow]

Hey Victor,

Working on the same kind of thing over here:
https://github.com/NathanW2/parfait

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  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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Alessandro Pasotti]

2015-11-02 13:52 GMT+01:00 Victor Olaya :

> 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.
>
>
Hello Victor,

this is a brilliant idea!


> 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...
>
> May plan of action is as follows:
>
> - Work on implementing a comprehensive set of functions and classes,
> hopefully with the help of other devs
>
> - Adapt Processing to use it and replace the current set of utilities
> that Processing (like many plugins) has.
>
> - Create a QEP to elevate this set of functions and classes to the
> qgis.utils module, so it has more visibility and it becomes a part of
> QGIS core.
>
> Following this, I believe the next steps that we could take could be:
>
> - Documenting this clearly in the PyCookbook, so all devs are aware of
> this.
>
>
Yes, and also the other way round, the cookbook may already contain many
useful snippets for common patterns that could go into utils functions.



> - Enforcing the use of common functions and classes, and even request
> it before a plugin is accepted for publishing
>
>
I see this a bit more complicated, unless we don't want to review the code
of each plugin by hand, I cannot think of a way to catch the pieces of code
that DO NOT use the common utils.


>
> Since we will be transitioning to Qt5/Python3, this set of common
> functions sounds also like a good place to add all kinds of utilities
> that might help this migration for existing plugins.
>
> Let me know your thoughts
>
> Even if you cannot contribute the code of a function to the repo, feel
> free to open an issue recommending functions that you consider should
> be in there. I will be working on this and will implement all those
> ideas if they sound interesting and useful for other people
>
>

Thank you for bringing this project to the attention of the list.


-- 
Alessandro Pasotti
w3:   www.itopen.it
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[John Layt]

On 2 November 2015 at 12:52, Victor Olaya  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.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

>
> 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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nathan Woodrow]

Hey Victor,

Just added you with write access to my project if you want.  I don't really
mind if you wanted to work on the same one together.  My motivations were
the same as you in the end.  Mainly just flesh something out in a sandbox
and then we can add it to core once we have it nutted out.

Regards,

On Tue, Nov 3, 2015 at 8:43 AM, Victor Olaya  wrote:

> Hey Nathan
>
> I knew about your project...but forgot about it :-) Sorry for that.
>
> What would you suggest doing? merging them maybe? I like that idea. In
> the end, the plan is just to have a sandbox to add those functions and
> eventually move them to core (btw, qgis.py sounds good to me...)
>
> I can make a PR to your repo if you think it is a good idea, and we
> keep on working there.
>
> Let me know also if you have ideas about what to add to fill those
> modules with useful stuff
>
> Cheers!
>
> 2015-11-02 14:29 GMT+01:00 Nathan Woodrow :
> > Hey Victor,
> >
> > Working on the same kind of thing over here:
> > https://github.com/NathanW2/parfait
> >
> > 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  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@lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

Hey Nathan

I knew about your project...but forgot about it :-) Sorry for that.

What would you suggest doing? merging them maybe? I like that idea. In
the end, the plan is just to have a sandbox to add those functions and
eventually move them to core (btw, qgis.py sounds good to me...)

I can make a PR to your repo if you think it is a good idea, and we
keep on working there.

Let me know also if you have ideas about what to add to fill those
modules with useful stuff

Cheers!

2015-11-02 14:29 GMT+01:00 Nathan Woodrow :
> Hey Victor,
>
> Working on the same kind of thing over here:
> https://github.com/NathanW2/parfait
>
> 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  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@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Victor Olaya]

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

May plan of action is as follows:

- Work on implementing a comprehensive set of functions and classes,
hopefully with the help of other devs

- Adapt Processing to use it and replace the current set of utilities
that Processing (like many plugins) has.

- Create a QEP to elevate this set of functions and classes to the
qgis.utils module, so it has more visibility and it becomes a part of
QGIS core.

Following this, I believe the next steps that we could take could be:

- Documenting this clearly in the PyCookbook, so all devs are aware of this.

- Enforcing the use of common functions and classes, and even request
it before a plugin is accepted for publishing


Since we will be transitioning to Qt5/Python3, this set of common
functions sounds also like a good place to add all kinds of utilities
that might help this migration for existing plugins.

Let me know your thoughts

Even if you cannot contribute the code of a function to the repo, feel
free to open an issue recommending functions that you consider should
be in there. I will be working on this and will implement all those
ideas if they sound interesting and useful for other people


Thanks in advance
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer