I am wondering about maintenance and in my opinion if the source is C++ , it will be easier to maintain if the dbmanager is also c++.
Giuseppe Sucameli <[email protected]> wrote: >Hi Marco, > >On Tue, May 24, 2011 at 5:05 PM, Marco Hugentobler < >[email protected]> wrote: > >> Similar to Radim, I'd prefer to have an integration with QBrowser and its >> model. >> > >as I wrote, it's ok for me to use the QgsBrowserModel and QgsDataItem to >create the tree, >in fact I added it to the wiki yesterday. > >I also want to improve providers adding the import layer functionality to >allow to >move/copy layers between different providers and I had wrote that to my >proposal. > >What I don't like it's to create DBManager as a C++ plugin or just as a >QBrowser >extension. Python code is easily maintainable, furthermore the >QBrowser/DBManager >won't do heavy computation, so is there a good reason to develop it using >C++ >instead of python? > >Regards. > > Since the browser classes are in the source tree, they are easy to >> distribute >> also as C++ code. >> >> Regards, >> Marco >> >> Am Dienstag, 24. Mai 2011, 09.07:57 schrieb Giuseppe Sucameli: >> > Hi Radim, >> > >> > On Tue, May 24, 2011 at 7:46 AM, Radim Blazek <[email protected] >> >wrote: >> > > First of all, IMO, the DBManager has to be implemented in QGIS core, >> > >> > > not as a plugin for two main reasons: >> > 1) it is core functionality >> > >> > I not agree, it's a GUI functionality. We can implement all the core >> stuff >> > in the >> > qgis core creating API for reuse of code (I think about connections, as >> it >> > was done >> > in WMS provider) and then accessing that from the plugin, but I don't >> like >> > the idea >> > to have DBManager in C++. >> > >> > > 2) connection factories MUST go to providers, otherwise you start to >> > > create a set of plugins for each DB, parallel to providers. >> > >> > I agree with you about this point, as you can see I added yesterday the >> > QgsDataItem section to the wiki. >> > >> > >From UI point of view, I would prefer to have everything in one place, >> > > >> > > that means in QBrowser. We can rename QBrowser to QManager and >> > > suddenly it sounds more logical. >> > >> > QBrowser is a standalone application, a C++ application, I think the >> > manager should >> > be easily maintainable and IMHO python code is the best solution. >> > >> > Having everything in one tree will >> > >> > > allow in future to easily drag-and-drop for example Shapefile to >> > > PostGIS and so on. >> > >> > That is not a problem, that feature could be implemented in providers, an >> > import >> > method which take a QgsMapLayer (this was in my gsoc proposal yet), but >> > have >> > >> > everything in core without any real and strong reason could make the core >> > code >> > hard to maintain. >> > >> > We have to add support for other providers to >> > >> > > QBrowser anyway. It does not make sense to have another similar UI >> > > just for databases, implemented in a different way. Currently QBrowser >> > > is a stand alone application but it will be integrated also to QGIS >> > > main application. >> > >> > QBrowser it's implemented as a C++ standalone application to browse files >> > and >> > show information about layers, but those are the same infos you can get >> > using QGis. >> > >> > The manager would make easy the use of databases in QGis, but not for >> QGis >> > use >> > only. Ok, we can show preview, load a layer in canvas, but also run >> > queries, >> > >> > create/edit/drop tables and views, ... pretty different from the QBrowser >> > aim! >> > >> > I think all the qgis-devs should say their opinion about this question >> > raised by Radim. >> > >> > I attended the GSoC 2009 for a different FOSS project and after I started >> > to work >> > on my _accepted_ project all devs said me that they didn't like my >> project, >> > so my >> > code was set aside and left on a branch and my GSoC was set as failed >> even >> > if I had >> > ended coding = no gsoc shirt :'( and no money for the second coding >> period >> > >> > :( >> > >> > I don't want to work again on something that devs don't like, >> > so please devs, I need your opinion. Thanks. >> > >> > Regards. >> > >> > QgsDataItem probably is not the best place where db connections should >> > >> > > be implemented, but it is good place where they can be used to >> > > represent databases in QgsBrowserModel and thus in QBrowser. I can >> > > imagine a QgsDatabase inherited by QgsPostGis, QgsSqlite etc. with all >> > > the methods you list on [2]. Then a single QgsDatabaseItem (which >> > > would inherit from QgsDataItem) could represent any DB provider, >> > > taking as parameter a QgsDatabase child for specific provider. >> > > >> > > >> > > Radim >> > > >> > > >> > > On Mon, May 23, 2011 at 5:21 PM, Giuseppe Sucameli >> > > >> > > <[email protected]> wrote: >> > > > Hi all, >> > > > I'm starting to work on DBManager plugin for QuantumGIS. >> > > > >> > > > I've just created the repository on GitHub [1] and here's [2] a page >> on >> > > >> > > the >> > > >> > > > QGis wiki >> > > > containing ideas I wrote in the past few days. I will add weekly >> > > > reports >> > > >> > > to >> > > >> > > > that wiki page. >> > > > >> > > > Any comments and reviews are very welcome. >> > > > Regards. >> > > > >> > > > [1] http://github.com/brushtyler/db_manager >> > > > [2] http://www.qgis.org/wiki/DB_Manager_plugin_GSoC_2011 >> > > > >> > > > -- >> > > > Giuseppe Sucameli >> > > > >> > > > _______________________________________________ >> > > > Qgis-developer mailing list >> > > > [email protected] >> > > > http://lists.osgeo.org/mailman/listinfo/qgis-developer >> >> >> -- >> Dr. Marco Hugentobler >> Sourcepole - Linux & Open Source Solutions >> Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland >> [email protected] http://www.sourcepole.ch >> Technical Advisor QGIS Project Steering Committee >> > > > >-- >Giuseppe Sucameli >_______________________________________________ >Qgis-developer mailing list >[email protected] >http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
