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

Marco Hugentobler marco.hugentobler at sourcepole.ch
Wed May 25 05:18:50 EDT 2011 

Hi Giuseppe

> 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.

Reuse existing gui components sounds good to me.

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

See above, gui components can be reusable too. Furthermore, we don't know now 
what will be reusable in the future.
I'm not against python at all. I just think that if there are not strong 
arguments for doing it in python, we should do it in C++ (not the other way 
round). You have more flexibility in future to reuse your code.

> 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.

+1. However, it is very hard to motivate people to port code.


Regards,
Marco




Am Mittwoch, 25. Mai 2011, 10.39:24 schrieb Giuseppe Sucameli:
> 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


-- 
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

More information about the Qgis-developer mailing list