On Tue, May 24, 2011 at 8:50 PM, Giuseppe Sucameli <brush.ty...@gmail.com> wrote: > Allowing to run queries on database requires a lot of code in the provider > and also > out of them, I should export methods to call the query, to get results, a > class to > map results, exceptions. Furthermore IMHO it's not good to implement this > into providers as they was thought to work with layers.
You are right, that this should not be implemented in providers but that does not imply that it could not be implemented in QBrowser. Or better, that QBrowser could not use a GUI classes which can do that. > I couldn't use the QtSql module because its drivers are not in sync with > database APIs used in providers. Interesting problem, but you have to face it anyway, Python cannot help IMO. > So, how do you think I can achieve this? I don't know, you have to invent something, you have all the summer. Is it really problem? Should not the QGIS DB providers use QtSql then? > In python instead pyspatialite is compiled againist the same sqlite version > used by QGis. I don't know if it's the same for psycopg2, but anyway > postgres API is enough stable. You cannot rely on this. If it is really a problem, then the libraries must be distinguished by name or rpath must be used, i think. Once a library is loaded to an application, it will be used also by python, if it was linked to a library with the same name, I believe. > AFAICS looking at the code, in this moment would be easier to merge together > QBrowser, RT_Sql_layer, SL_manager and PG_manager in this order, instead > of merge them in the opposite way. So, you do agree, that we are talking about the same thing which can be called either browser or manager? The only question is, if it should be written in C++ or in Python. I believe that because it implements core functionality, it should be in C++, until we decide that the whole QGIS GUI should be in Python. > Will it able to do the coffee?? :) I don't think that coffee is somehow directly related to GIS. It should be able however, to print DEM layers directly to 3D printer (http://reprap.org) for example, if you are thinking about a connection with real world. On Wed, May 25, 2011 at 10:39 AM, Giuseppe Sucameli <brush.ty...@gmail.com> wrote: > However we should consider to integrate useful python plugins in qgis code, > porting > their base functions to C++ if necessary. So why to write another important plugin in Python, with perspective that it has to be ported later to C++? Radim _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
