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

Wed May 25 04:39:24 EDT 2011

HI Marco,

On Wed, May 25, 2011 at 9:49 AM, Marco Hugentobler <
marco.hugentobler at sourcepole.ch> wrote:

> Why not integrate the gui into QBrowser? From a user point of view, it is
> easier to manage the datasources with one application instead having one
> for
> files, one for databases, one for webservices. I'm not as deep into the
> topic
> as Martin or Radim (but you asked for the opinions of all devs).
>
I agree, just one GUI to manage everything.
But QBrowser doesn't refactor GUIs to have a more integrated interface, it
just
re-uses the QGis GUIs. So the surplus value is only the QgsBrowserModel.

 > 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?
>
> C++ is even more easily maintainable :-). We have a lot of useful functions
> in
> python plugins that would have been integrated into app/analysis/core/gui
> if
> they were written in C++.

I'm talking about GUI, not core or re-usable code which obviously it's
better have
them in C++.

However we should consider to integrate useful python plugins in qgis code,
porting
their base functions to C++ if necessary. I think we should create a todo
list and
roadmap for that.

Just my 2 cents. It's ultimately your mentor (Martin) that has to decide.
>
Martin is out in this moment, he cannot reply every day. But there's the
dev-team to help me ;)

He has to decide, but if we all discuss a better alternative he could opt
for that, or
in any case we can collect these information for directing our efforts in
future
development.
We should start to think to API for the 2.0!

Regards.

Regards,
> Marco
>
> Am Dienstag, 24. Mai 2011, 18.05:46 schrieb Giuseppe Sucameli:
> > 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
>
>
> --
> 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/qgis-developer/attachments/20110525/f0f7bc49/attachment.html