Re: [Qgis-developer] Proposal: move the Remove layer(s) button

2014-09-06 Thread aperi2007

Hi,
I guess in a GIS oriented product
Is necessary to avoid to mix the interface characteristics (the group is 
an interface object) and the data characteristics (the shapefile is not 
an interface object).


I guess more beter if add/remove dataset is separated phisically from 
add/remove a group.


The dataset is a phicical think. The shapefile is using separately from 
the qgis project.

The group is not separately from qgis project.

I guess is good question to have a remove group but avoiding to have a 
only button ADD Everything or an only button Remove everything


Also I guess is important to help to understand when we are on dataset 
(physical) and when we are on interface (logical).


Regards,

A.

Il 06/09/2014 07:10, Mathieu Pellerin ha scritto:

Greetings,

I'd like to circulate a UX proposal and see how people react.

For a very long time, QGIS' Layers toolbar has featured a Remove 
layer(s) button. I have seen two issues with the button:
- Its placement becomes really odd when plugins add button(s) to the 
Layers toolbar (for e.g. the New Memory Layer plugin as pictured here 
[ http://imgur.com/CEcIC3K,QvUzrti ])

- It can only remove vector/raster layers, won't remove groups

With the recent improvements done by Martin Dobias on the legend, and 
in particular with his addition of a layer panel embedded toolbar, I 
propose that:
- The Remove layer(s) button be moved to the layer panel embedded 
toolbar [ http://imgur.com/CEcIC3K,QvUzrti#1 ]
- The button functionally is improved so it can also deal with the 
removal of group(s)


Alternatively, we could get rid of the button altogether since layers 
and groups can be removed via right click or keyboard shortcut, but I 
suspect the touch screen based users might object.


Any objection to moving the button to the new layers toolbar?

Math


___
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] Proposal: move the Remove layer(s) button

2014-09-06 Thread Mathieu Pellerin
I don't think you should comparing adding group/dataset against deleting a
group/dataset legend layer. The latter is already unified via either a
single keyboard shortcut and a single mouse right-click - remove action.
On 6 Sep 2014 13:04, aperi2007 aperi2...@gmail.com wrote:

  Hi,
 I guess in a GIS oriented product
 Is necessary to avoid to mix the interface characteristics (the group is
 an interface object) and the data characteristics (the shapefile is not an
 interface object).

 I guess more beter if add/remove dataset is separated phisically from
 add/remove a group.

 The dataset is a phicical think. The shapefile is using separately from
 the qgis project.
 The group is not separately from qgis project.

 I guess is good question to have a remove group but avoiding to have a
 only button ADD Everything or an only button Remove everything

 Also I guess is important to help to understand when we are on dataset
 (physical) and when we are on interface (logical).

 Regards,

 A.

 Il 06/09/2014 07:10, Mathieu Pellerin ha scritto:

 Greetings,

 I'd like to circulate a UX proposal and see how people react.

  For a very long time, QGIS' Layers toolbar has featured a Remove
 layer(s) button. I have seen two issues with the button:
  - Its placement becomes really odd when plugins add button(s) to the
 Layers toolbar (for e.g. the New Memory Layer plugin as pictured here [
 http://imgur.com/CEcIC3K,QvUzrti ])
  - It can only remove vector/raster layers, won't remove groups

  With the recent improvements done by Martin Dobias on the legend, and in
 particular with his addition of a layer panel embedded toolbar, I propose
 that:
  - The Remove layer(s) button be moved to the layer panel embedded
 toolbar [ http://imgur.com/CEcIC3K,QvUzrti#1 ]
  - The button functionally is improved so it can also deal with the
 removal of group(s)

  Alternatively, we could get rid of the button altogether since layers
 and groups can be removed via right click or keyboard shortcut, but I
 suspect the touch screen based users might object.

  Any objection to moving the button to the new layers toolbar?

  Math


 ___
 Qgis-developer mailing 
 listQgis-developer@lists.osgeo.orghttp://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] Proposal: move the Remove layer(s) button

2014-09-06 Thread Mathieu Pellerin
* note: there is no keyboard shortcut to delete a group, doh. :)




On Sat, Sep 6, 2014 at 1:12 PM, Mathieu Pellerin nirvn.a...@gmail.com
wrote:

 I don't think you should comparing adding group/dataset against deleting a
 group/dataset legend layer. The latter is already unified via either a
 single keyboard shortcut and a single mouse right-click - remove action.
 On 6 Sep 2014 13:04, aperi2007 aperi2...@gmail.com wrote:

  Hi,
 I guess in a GIS oriented product
 Is necessary to avoid to mix the interface characteristics (the group is
 an interface object) and the data characteristics (the shapefile is not an
 interface object).

 I guess more beter if add/remove dataset is separated phisically from
 add/remove a group.

 The dataset is a phicical think. The shapefile is using separately from
 the qgis project.
 The group is not separately from qgis project.

 I guess is good question to have a remove group but avoiding to have a
 only button ADD Everything or an only button Remove everything

 Also I guess is important to help to understand when we are on dataset
 (physical) and when we are on interface (logical).

 Regards,

 A.

 Il 06/09/2014 07:10, Mathieu Pellerin ha scritto:

 Greetings,

 I'd like to circulate a UX proposal and see how people react.

  For a very long time, QGIS' Layers toolbar has featured a Remove
 layer(s) button. I have seen two issues with the button:
  - Its placement becomes really odd when plugins add button(s) to the
 Layers toolbar (for e.g. the New Memory Layer plugin as pictured here [
 http://imgur.com/CEcIC3K,QvUzrti ])
  - It can only remove vector/raster layers, won't remove groups

  With the recent improvements done by Martin Dobias on the legend, and in
 particular with his addition of a layer panel embedded toolbar, I propose
 that:
  - The Remove layer(s) button be moved to the layer panel embedded
 toolbar [ http://imgur.com/CEcIC3K,QvUzrti#1 ]
  - The button functionally is improved so it can also deal with the
 removal of group(s)

  Alternatively, we could get rid of the button altogether since layers
 and groups can be removed via right click or keyboard shortcut, but I
 suspect the touch screen based users might object.

  Any objection to moving the button to the new layers toolbar?

  Math


 ___
 Qgis-developer mailing 
 listQgis-developer@lists.osgeo.orghttp://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] Proposal: move the Remove layer(s) button

2014-09-06 Thread aperi2007

I know this,
but my response is enlarged to a more conceptual problem.

How avoid that an user could be confusing from when it act on a logical 
level of interface,

and when it act on a physical data.

I understand that removing mean always remove and so 1 only button is 
better than two.


But my question is :
if we remove the remove layers leaving only the remove this that is 
available in the context-menu (i dont see the new legend again).


Seem quite logical to question:
why there is a remove this only command and there is instead an add 
layer and an add group seaprated.


Why two add and one remove ?

So the next logical question is why not remove the two add ad introduce 
only an unique add here in the context-menu ?

:)

So my response was to a path that can start with the remove button and 
logically end on the add button.


Regards,

Andrea.



Il 06/09/2014 08:12, Mathieu Pellerin ha scritto:


I don't think you should comparing adding group/dataset against 
deleting a group/dataset legend layer. The latter is already unified 
via either a single keyboard shortcut and a single mouse right-click 
- remove action.


On 6 Sep 2014 13:04, aperi2007 aperi2...@gmail.com 
mailto:aperi2...@gmail.com wrote:


Hi,
I guess in a GIS oriented product
Is necessary to avoid to mix the interface characteristics (the
group is an interface object) and the data characteristics (the
shapefile is not an interface object).

I guess more beter if add/remove dataset is separated phisically
from add/remove a group.

The dataset is a phicical think. The shapefile is using separately
from the qgis project.
The group is not separately from qgis project.

I guess is good question to have a remove group but avoiding to
have a only button ADD Everything or an only button Remove
everything

Also I guess is important to help to understand when we are on
dataset (physical) and when we are on interface (logical).

Regards,

A.

Il 06/09/2014 07:10, Mathieu Pellerin ha scritto:

Greetings,

I'd like to circulate a UX proposal and see how people react.

For a very long time, QGIS' Layers toolbar has featured a Remove
layer(s) button. I have seen two issues with the button:
- Its placement becomes really odd when plugins add button(s) to
the Layers toolbar (for e.g. the New Memory Layer plugin as
pictured here [ http://imgur.com/CEcIC3K,QvUzrti ])
- It can only remove vector/raster layers, won't remove groups

With the recent improvements done by Martin Dobias on the legend,
and in particular with his addition of a layer panel embedded
toolbar, I propose that:
- The Remove layer(s) button be moved to the layer panel
embedded toolbar [ http://imgur.com/CEcIC3K,QvUzrti#1 ]
- The button functionally is improved so it can also deal with
the removal of group(s)

Alternatively, we could get rid of the button altogether since
layers and groups can be removed via right click or keyboard
shortcut, but I suspect the touch screen based users might object.

Any objection to moving the button to the new layers toolbar?

Math


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



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org mailto: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] Legend refactoring - part II - ready for merge

2014-09-06 Thread Martin Dobias
Hi Marco

On Thu, Aug 28, 2014 at 2:33 PM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
That leaves doxygen.   Why not document API breakages where the API is
documented?  Sounds like the best fit ;)

 It's fine to put it into doxygen. Can it also be available as a summarized
 list there (so not only as a comment at the method level)?

I have started API break doxygen page:
https://github.com/qgis/QGIS/blob/master/doc/api_break.dox

It is also linked from the main documentation page.

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


Re: [Qgis-developer] [QGIS-UX] Proposal: move the Remove layer(s) button

2014-09-06 Thread Nathan Woodrow
Hey Mathieu,

Yeah this makes sense to me.  It's only really used when you have the
legend open so it's good to have it close.

- Nathan


On Sat, Sep 6, 2014 at 3:10 PM, Mathieu Pellerin nirvn.a...@gmail.com
wrote:

 Greetings,

 I'd like to circulate a UX proposal and see how people react.

 For a very long time, QGIS' Layers toolbar has featured a Remove
 layer(s) button. I have seen two issues with the button:
 - Its placement becomes really odd when plugins add button(s) to the
 Layers toolbar (for e.g. the New Memory Layer plugin as pictured here [
 http://imgur.com/CEcIC3K,QvUzrti ])
 - It can only remove vector/raster layers, won't remove groups

 With the recent improvements done by Martin Dobias on the legend, and in
 particular with his addition of a layer panel embedded toolbar, I propose
 that:
 - The Remove layer(s) button be moved to the layer panel embedded
 toolbar [ http://imgur.com/CEcIC3K,QvUzrti#1 ]
 - The button functionally is improved so it can also deal with the removal
 of group(s)

 Alternatively, we could get rid of the button altogether since layers and
 groups can be removed via right click or keyboard shortcut, but I suspect
 the touch screen based users might object.

 Any objection to moving the button to the new layers toolbar?

 Math

 ___
 QGIS-UX mailing list
 qgis...@lists.osgeo.org
 http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-ux


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

Re: [Qgis-developer] lwgeom processing provider wainting for processign refactoring

2014-09-06 Thread Luigi Pirelli
ok, thank you Alexander

processinglwgeom provider released to be used also with master
processing version

regards.

Luigi Pirelli (luigi.pire...@faunalia.it - lui...@gmail.com)

On 5 September 2014 17:41, Alexander Bruy alexander.b...@gmail.com wrote:
 Hi Luigi,

 AFAIK refactoring of parameters/outputs completed.

 And we will try to avoid API breaks in future

 2014-09-05 14:12 GMT+03:00 Luigi Pirelli lui...@gmail.com:
 Hi,

 current lwgeom processing provider doesn't work with processing in
 master version due to Processing refactoring.

 Modification are trivial in this moment, but I don't know when this
 refactoring will end to fix definitive patches to the provider.

 Victor can you let me/us know refactoring roudmap?

 Thank you  Luigi Pirelli (luigi.pire...@faunalia.it - lui...@gmail.com)
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer



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


Re: [Qgis-developer] Proposal: move the Remove layer(s) button

2014-09-06 Thread Anita Graser
On Sat, Sep 6, 2014 at 7:10 AM, Mathieu Pellerin nirvn.a...@gmail.com wrote:
 For a very long time, QGIS' Layers toolbar has featured a Remove layer(s)
 button.
 Any objection to moving the button to the new layers toolbar?

Hi Mathieu,
I like the idea of moving the button. Personally, I've never used it
but I get the point that it's useful on touch screens.

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


Re: [Qgis-developer] lwgeom processing provider wainting for processign refactoring

2014-09-06 Thread Victor Olaya
The refactoring is done, but i think Luigi is talking about the changes to
keep backwards compatibility. I tried the import redirections that Nathan
suggested, but they do not seem to fix the issue and there is still a need
to adapt plugins to the API change.

Ideas are welcome. Otherwise, you can safely adapt your plugin code and, as
Alex said, we will try not to change the API again unless there is a major
need for that.

Cheers


2014-09-05 17:41 GMT+02:00 Alexander Bruy alexander.b...@gmail.com:

 Hi Luigi,

 AFAIK refactoring of parameters/outputs completed.

 And we will try to avoid API breaks in future

 2014-09-05 14:12 GMT+03:00 Luigi Pirelli lui...@gmail.com:
  Hi,
 
  current lwgeom processing provider doesn't work with processing in
  master version due to Processing refactoring.
 
  Modification are trivial in this moment, but I don't know when this
  refactoring will end to fix definitive patches to the provider.
 
  Victor can you let me/us know refactoring roudmap?
 
  Thank you  Luigi Pirelli (luigi.pire...@faunalia.it - lui...@gmail.com)
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer



 --
 Alexander Bruy
 ___
 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] layer encoding

2014-09-06 Thread Siki Zoltan


Thanks Salvatore,

Zoltan

On Fri, 5 Sep 2014, Salvatore Larosa wrote:


Hi,

Il 05/Set/2014 19:48 Siki Zoltan s...@agt.bme.hu ha scritto:


Dear List,

I can't find a way to get the encoding of a vector layer from python.
Can someone give me a tipp?


from python console:


layer = iface.activeLayer()
layer.dataProvider().encoding()


more info
http://qgis.org/api/classQgsVectorDataProvider.html#a628c5bd63c2bf0637ac4c676ecdb921e

Best Regards,
-SL



Thanks,
Zoltan
___
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] QEP: QGIS Mapserver Python Plugins

2014-09-06 Thread Martin Dobias
Hi Alessandro

Finally I had some time to look at your proposal (your mail and the
proposed QEP [1]). I am not that much involved in the QGIS server
development, but the Python word in the thread subject always draws my
attention :-)

On Thu, Aug 28, 2014 at 7:49 PM, Alessandro Pasotti apaso...@gmail.com wrote:

 The rationale behind server plugins is doublefold: first they could
 provide additional services without the need to touch the C++
 codebase, second they allow for GUI-based configuration since the
 server plugins are not separated from the desktop plugins (of course
 the environment and permissions should be carefully configured to
 allow information sharing from the desktop user to the webserver user
 ).

I understand the first reason (use python instead of c++ to extend the
server), but I am not sure I see the second reason (allow GUI-based
configuration). Actually I find that mixing of desktop and server
plugin functionality is not making things any better than having two
separate plugins, one for desktop and one for server. They are meant
to be running in two completely different environments, it may be a
good idea to treat them in such way. Still I guess having some kind of
plugin functionality also in server may be useful.

At the same time I think in many cases it would be actually better to
have the functionality in python plugin (e.g. WPS server based on
processing framework) completely separated from QGIS server and run it
through an ordinary interface for Python (WSGI). One could even employ
some Apache rewriting rules to make the impression that the service is
still handled by QGIS server.

You mention that this is just an early prototype to see where things
can go, so I understand some things are quite hacky / experimental. If
the team is happy to proceed with the concept of plugins for QGIS
server, here are some things I think need changing compared to the
current proposal/implementation:
- we need proper object-oriented approach for the plugins. Like QGIS
desktop provides QgisInterface instance for plugins, QGIS server
should also provide some kind of QgsServerInterface which would be
used by server plugins. Such interface would give the plugin access to
all data structures it needs (e.g. parsed project).
- in the server there is already QgsOWSServer interface which existing
services derive from. Plugins should be also base on that interface
(may need some further work)
- the output from plugin should be abstracted - in the server there is
already QgsRequestHandler interface for such things (may need some
further work)
- loading of plugins should be done in a very similar way to desktop
plugins - similar to classFactory(iface) entry point, there could be
serverClassFactory(iface) entry point that returns instance of
running server plugin
- I don't like the fact that plugins declare their service and
methods in metadata.txt. I think plugins should register their
QgsOWSServer implementation to server interface when they are loaded.
This is more flexible - a plugin may register more services or provide
some extra info during the registration

Cheers
Martin

[1] https://github.com/qgis/QGIS-Enhancement-Proposals/pull/3
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] SVG Export from print composer as raster?

2014-09-06 Thread Martin Dobias
Hi Andreas

On Wed, Sep 3, 2014 at 9:10 PM, Andreas Neumann a.neum...@carto.net wrote:
 Hi,

 I noticed that SVG symbols (from point and pattern symbology) from print
 composer are exported as raster when exported as part of the map and
 from the legend item. However, SVG images from the image/photo item are
 exported as vector. This in both SVG and PDF format.

It seems that raster output from pattern fill is there by design
(either line or point pattern fill). The pattern is first converted to
image which is then used in a brush for polygon fill. This is not
specific to just SVG.


 Is there anything we can do about it that legend items and maps are all
 output as vectors?

I think that would need to employ additional rendering techniques for
true vector output - instead of simple pixel-based flood fill with
texture we would need to draw vectors masked to given polygon's area.

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


Re: [Qgis-developer] QgsMapRenderer and DPI problem

2014-09-06 Thread Martin Dobias
Hi Stefan

On Tue, Sep 2, 2014 at 1:13 PM, Ziegler Stefan stefan.zieg...@bd.so.ch wrote:

 It seems that the dpi parameter in render.setOutputSize(img.size(), dpi) is 
 not respected. For any value of dpi the line width is always the same in the 
 output raster. It it respected when using map units for line widths and not 
 milimeters, though. The script was used in an older QGIS version ages ago. So 
 I'm pretty sure it worked once. Did I miss something or is it a bug?

It looks like something is wrong with the Python bindings there. In
render() method there is optional second parameter forceWidthScale
which is interpreted incorrectly and it seems to override the DPI
settings. Even if I add /In/ annotation to it, there are still some
issues. It seems it has been broken like this probably for long time.
If you want to do map rendering with different DPI settings I would
suggest one of these options:
- use QgsMapSettings / QgsMapRendererJob - if you target 2.4 and above
- use map composer

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


Re: [Qgis-developer] [QGIS-UX] Proposal: move the Remove layer(s) button

2014-09-06 Thread Alexander Bruy
Maybe also put Duplicate layer button to this new legend toolbar?

2014-09-06 12:13 GMT+03:00 Anita Graser anitagra...@gmx.at:
 On Sat, Sep 6, 2014 at 7:10 AM, Mathieu Pellerin nirvn.a...@gmail.com wrote:
 For a very long time, QGIS' Layers toolbar has featured a Remove layer(s)
 button.
 Any objection to moving the button to the new layers toolbar?

 Hi Mathieu,
 I like the idea of moving the button. Personally, I've never used it
 but I get the point that it's useful on touch screens.

 Best wishes,
 Anita
 ___
 QGIS-UX mailing list
 qgis...@lists.osgeo.org
 http://lists.osgeo.org/cgi-bin/mailman/listinfo/qgis-ux



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


[Qgis-developer] Adding modules in Processing

2014-09-06 Thread skampus
hi, i've searched for info about this topic, but i didn't find anything.

so please, is there anyone who can explain how adding some existing modules
in saga 2.1.2 into processing?

infact, in this last version of saga there are some very useful modules, in
my opinion, that could be available via Processing

thank you in advance

s.





--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Adding-modules-in-Processing-tp5160553.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Adding modules in Processing

2014-09-06 Thread Victor Olaya
You just have to add a new text file to
the processing\algs\saga\description folder

The syntax of the file is the same used for GRASS algorithms, which is
described here

https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass/grass.txt

Hope this helps


2014-09-06 21:40 GMT+02:00 skampus skam...@gmail.com:

 hi, i've searched for info about this topic, but i didn't find anything.

 so please, is there anyone who can explain how adding some existing modules
 in saga 2.1.2 into processing?

 infact, in this last version of saga there are some very useful modules, in
 my opinion, that could be available via Processing

 thank you in advance

 s.





 --
 View this message in context:
 http://osgeo-org.1560.x6.nabble.com/Adding-modules-in-Processing-tp5160553.html
 Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
 ___
 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