Hi Soeren On Tue, Mar 24, 2015 at 10:04 AM, Sören Gebbert <soerengebb...@googlemail.com> wrote: > 2015-03-24 9:40 GMT+01:00 Radim Blazek <radim.bla...@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 _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user