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