[SoC] Re: [Qgis-developer] DBManager plugin for QuantumGIS (GSoC 2001)

Tue May 24 12:05:46 EDT 2011

Hi Marco,

On Tue, May 24, 2011 at 5:05 PM, Marco Hugentobler <
marco.hugentobler at sourcepole.ch> 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 <radim.blazek at gmail.com
> >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
> > >
> > > <brush.tyler at gmail.com> 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
> > > > Qgis-developer at lists.osgeo.org
> > > > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>

-- 
Giuseppe Sucameli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/soc/attachments/20110524/30981f72/attachment.html