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
