Re: [Qgis-developer] Implementing a cache for the composer attribute table

2014-04-19 Thread Nyall Dawson
On 18 April 2014 00:25, Marco Hugentobler marco.hugentob...@sourcepole.ch wrote: There is no special reason for the current non-caching behaviour. It was fast enough for my usage when I implemented it back in 2010, so there was no reason for me to do caching. I suspect the behaviour I'm

Re: [Qgis-developer] r.series in Processing

2014-04-19 Thread Paolo Cavallini
Il 18/04/2014 20:33, Vaclav Petras ha scritto: I would like to but I don't have Processing working. I have qgis from qgis.org/ubuntugis-nigthly http://qgis.org/ubuntugis-nigthly and I installed grass package but Processing report messing dependency. When I start grass from command line, it is

[Qgis-developer] FUSION integration - in slow progress

2014-04-19 Thread Niccolò Marchi
Hello devs! even if on small things, I'm quite enjoying Python! unfortunately still too many are the questions, even silly. primary issue: where can I find some material dealing with Python functions? I'm looking for info on: - how to create a checkbox (code and functioning) the question dealing

[Qgis-developer] New plugin for QGis : RasMover

2014-04-19 Thread Geo DrinX
Hello All, I created a new plugin that move all active raster, using a new temporary raster. http://plugins.qgis.org/plugins/rasmover/ This plugin is very useful to fine collimate Raster with vector layers. Please, test it and approvate it if you like. Thank you Roberto

Re: [Qgis-developer] [GRASS-dev] GRASS QGIS: the future

2014-04-19 Thread Martin Landa
2014-04-19 0:59 GMT+02:00 Glynn Clements gl...@gclements.plus.com: [...] You're misunderstanding a key point. Misunderstanding is usually a question of the point of view or level of doggedness. Especially when someone is speaking about a key point ;-) Returning from G_fatal_error() won't

Re: [Qgis-developer] [GRASS-dev] GRASS QGIS: the future

2014-04-19 Thread Jürgen E . Fischer
Hi Martin, On Fri, 18. Apr 2014 at 12:20:15 +0200, Martin Landa wrote: [...] I still think that we should provide in GRASS API function like G_set_fatal_error() with default value G_FATAL_ERROR_EXIT (current behaviour). The second option would be G_FATAL_ERROR_RETURN with big big warning in

Re: [Qgis-developer] FUSION integration - in slow progress

2014-04-19 Thread Victor Olaya
Niccolo Since you are working with Processing, here are a few recommendations. - You should not create your own GUI. Unless you really want a custom iinterface (and that's going to take you tome and it is not so easy to do it), you should just define the semantic of the algorithm and let

Re: [Qgis-developer] [GRASS-dev] GRASS QGIS: the future

2014-04-19 Thread Vaclav Petras
G_fatal_error() is too low level not only for messages but in general, for Python libraries wrapping GRASS library, it does not allow to throw an exception in case of an error. And the same applies for C++ wrappers. If you want to turn fatal errors into exceptions, the correct way to do

Re: [Qgis-developer] [GRASS-dev] GRASS QGIS: the future

2014-04-19 Thread Sören Gebbert
Hi Glynn, An RPC wrapper would move the execution of GRASS functions into a new process (i.e. a server). If the call generates a fatal error, the server dies, the client detects this and reports an error rather than a result. The main problem with this is that any error loses the entire