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

[sailmcm]

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 <brush.tyler at gmail.com> wrote:

>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
>_______________________________________________
>Qgis-developer mailing list
>Qgis-developer at lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/qgis-developer