[GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

[Radim Blazek]

Hi Soeren

On Tue, Mar 24, 2015 at 10:04 AM, Sören Gebbert
<soerengebbert at googlemail.com> wrote:
> 2015-03-24 9:40 GMT+01:00 Radim Blazek <radim.blazek at gmail.com>:
>> I completely agree that Python would be better, the advantages of
>> Python are obvious and that would be definitely my choice if I had to
>> start from scratch. Un(fortunately) the GRASS plugin + qgsgrassgislib
>> have already 22500 lines of C++ so porting to Python is not an option
>> and mixing C++ in single plugin either (as far to my knowledge).
>
> Indeed, porting the C++ code to Python is a large effort. However,
> maybe you can define a stretch-goal in the crowd funding campaign? If
> this goal is met, then you have enough funds to port the C++ code to
> Python and you can add more features?

I don't have any serious estimation how much porting from C++ to
Python costs, but new line of code costs 10-50euro (according to quick
internet search). To be really very modest, say that porting would
cost 2 euro per line, i.e. 22500*2 = 45000 euro for somethings which
brings no new features to users. That is not something I would ever
propose.

> I think that using C++ and Python in a Plugin shouldn't be a big
> problem in my humble opinion. The main issue would be that the C++
> code of the data provide will be part of QGIS and the Python code that
> makes use of the GRASS data provider will be a separate GRASS Python
> QGIS plugin.

The plugin and the provider are sharing some C++ code (qgsgrass and
qgsgrasslib). To port the plugin to Python you also have to write and
maintain Python bindings for that shared classes which is just extra
work.

> Maybe this approach will allow to implement several
> independent Python plugins that make use of the GRASS data provider to
> implement specific algorithms?

That should not depend on the GRASS plugin in C++. If you write Python
bindings for the provider, you can use it (non standard)  in your
Python plugin. I believe however that plugins implementing algorithms
should be preferably provider independent.

>> Are there functions in time series implementation which need to be
>> called directly from the plugin or everything may be done just calling
>> t.rast.* modules?
>
> Most of the temporal functionality is available through the temporal
> modules. However some important algorithms (temporal re-sampling) are
> available only in the Python framework. This is needed for time series
> animation creation. Using the framework directly will speed things up,
> because the module calls, the parsing and interpretation of the module
> outputs can be avoided.

If it should be used for dynamic animation in QGIS canvas you could
consider the possibility to subclass raster renderer in Python and
insert it into raster layer pipe from Python plugin.

>>> Btw: Otto Dassau and i mentioned your crowd funding idea at the
>>> FOSSGIS in Germany two weeks ago. It is on Youtube[2] but only in
>>> German.

Thank you a lot!

Radim