HI Marco, <br><br><div class="gmail_quote">On Wed, May 25, 2011 at 9:49 AM, Marco Hugentobler <span dir="ltr"><<a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Why not integrate the gui into QBrowser? From a user point of view, it is<br>
easier to manage the datasources with one application instead having one for<br>
files, one for databases, one for webservices. I'm not as deep into the topic<br>
as Martin or Radim (but you asked for the opinions of all devs).<br></blockquote><div>I agree, just one GUI to manage everything. <br>But QBrowser doesn't refactor GUIs to have a more integrated interface, it just <br>
re-uses the QGis GUIs. So the surplus value is only the QgsBrowserModel.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> Python code is easily maintainable, furthermore the<br>
> QBrowser/DBManager<br>
> won't do heavy computation, so is there a good reason to develop it using<br>
> C++<br>
> instead of python?<br>
<br>
</div>C++ is even more easily maintainable :-). We have a lot of useful functions in<br>
python plugins that would have been integrated into app/analysis/core/gui if<br>
they were written in C++. </blockquote><div> </div><div>I'm talking about GUI, not core or re-usable code which obviously it's better have <br>them in C++.<br><br>However we should consider to integrate useful python plugins in qgis code, porting <br>
their base functions to C++ if necessary. I think we should create a todo list and <br>roadmap for that.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Just my 2 cents. It's ultimately your mentor (Martin) that has to decide.<br></blockquote><div>Martin is out in this moment, he cannot reply every day. But there's the <br>dev-team to help me ;)<br><br>He has to decide, but if we all discuss a better alternative he could opt for that, or <br>
in any case we can collect these information for directing our efforts in future <br>development. <br>We should start to think to API for the 2.0!<br><br>Regards.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Regards,<br>
Marco<br>
<br>
Am Dienstag, 24. Mai 2011, 18.05:46 schrieb Giuseppe Sucameli:<br>
<div><div></div><div class="h5">> Hi Marco,<br>
><br>
> On Tue, May 24, 2011 at 5:05 PM, Marco Hugentobler <<br>
><br>
> <a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a>> wrote:<br>
> > Similar to Radim, I'd prefer to have an integration with QBrowser and its<br>
> > model.<br>
><br>
> as I wrote, it's ok for me to use the QgsBrowserModel and QgsDataItem to<br>
> create the tree,<br>
> in fact I added it to the wiki yesterday.<br>
><br>
> I also want to improve providers adding the import layer functionality to<br>
> allow to<br>
> move/copy layers between different providers and I had wrote that to my<br>
> proposal.<br>
><br>
> What I don't like it's to create DBManager as a C++ plugin or just as a<br>
> QBrowser<br>
> extension. Python code is easily maintainable, furthermore the<br>
> QBrowser/DBManager<br>
> won't do heavy computation, so is there a good reason to develop it using<br>
> C++<br>
> instead of python?<br>
><br>
> Regards.<br>
><br>
> Since the browser classes are in the source tree, they are easy to<br>
><br>
> > distribute<br>
> > also as C++ code.<br>
> ><br>
> > Regards,<br>
> > Marco<br>
> ><br>
> > Am Dienstag, 24. Mai 2011, 09.07:57 schrieb Giuseppe Sucameli:<br>
> > > Hi Radim,<br>
> > ><br>
> > > On Tue, May 24, 2011 at 7:46 AM, Radim Blazek <<a href="mailto:radim.blazek@gmail.com">radim.blazek@gmail.com</a><br>
> > ><br>
> > >wrote:<br>
> > > > First of all, IMO, the DBManager has to be implemented in QGIS core,<br>
> > ><br>
> > > > not as a plugin for two main reasons:<br>
> > > 1) it is core functionality<br>
> > ><br>
> > > I not agree, it's a GUI functionality. We can implement all the core<br>
> ><br>
> > stuff<br>
> ><br>
> > > in the<br>
> > > qgis core creating API for reuse of code (I think about connections, as<br>
> ><br>
> > it<br>
> ><br>
> > > was done<br>
> > > in WMS provider) and then accessing that from the plugin, but I don't<br>
> ><br>
> > like<br>
> ><br>
> > > the idea<br>
> > > to have DBManager in C++.<br>
> > ><br>
> > > > 2) connection factories MUST go to providers, otherwise you start to<br>
> > > > create a set of plugins for each DB, parallel to providers.<br>
> > ><br>
> > > I agree with you about this point, as you can see I added yesterday the<br>
> > > QgsDataItem section to the wiki.<br>
> > ><br>
> > > >From UI point of view, I would prefer to have everything in one place,<br>
> > > ><br>
> > > > that means in QBrowser. We can rename QBrowser to QManager and<br>
> > > > suddenly it sounds more logical.<br>
> > ><br>
> > > QBrowser is a standalone application, a C++ application, I think the<br>
> > > manager should<br>
> > > be easily maintainable and IMHO python code is the best solution.<br>
> > ><br>
> > > Having everything in one tree will<br>
> > ><br>
> > > > allow in future to easily drag-and-drop for example Shapefile to<br>
> > > > PostGIS and so on.<br>
> > ><br>
> > > That is not a problem, that feature could be implemented in providers,<br>
> > > an import<br>
> > > method which take a QgsMapLayer (this was in my gsoc proposal yet), but<br>
> > > have<br>
> > ><br>
> > > everything in core without any real and strong reason could make the<br>
> > > core code<br>
> > > hard to maintain.<br>
> > ><br>
> > > We have to add support for other providers to<br>
> > ><br>
> > > > QBrowser anyway. It does not make sense to have another similar UI<br>
> > > > just for databases, implemented in a different way. Currently<br>
> > > > QBrowser is a stand alone application but it will be integrated also<br>
> > > > to QGIS main application.<br>
> > ><br>
> > > QBrowser it's implemented as a C++ standalone application to browse<br>
> > > files and<br>
> > > show information about layers, but those are the same infos you can get<br>
> > > using QGis.<br>
> > ><br>
> > > The manager would make easy the use of databases in QGis, but not for<br>
> ><br>
> > QGis<br>
> ><br>
> > > use<br>
> > > only. Ok, we can show preview, load a layer in canvas, but also run<br>
> > > queries,<br>
> > ><br>
> > > create/edit/drop tables and views, ... pretty different from the<br>
> > > QBrowser aim!<br>
> > ><br>
> > > I think all the qgis-devs should say their opinion about this question<br>
> > > raised by Radim.<br>
> > ><br>
> > > I attended the GSoC 2009 for a different FOSS project and after I<br>
> > > started to work<br>
> > > on my _accepted_ project all devs said me that they didn't like my<br>
> ><br>
> > project,<br>
> ><br>
> > > so my<br>
> > > code was set aside and left on a branch and my GSoC was set as failed<br>
> ><br>
> > even<br>
> ><br>
> > > if I had<br>
> > > ended coding = no gsoc shirt :'( and no money for the second coding<br>
> ><br>
> > period<br>
> ><br>
> > > :(<br>
> > ><br>
> > > I don't want to work again on something that devs don't like,<br>
> > > so please devs, I need your opinion. Thanks.<br>
> > ><br>
> > > Regards.<br>
> > ><br>
> > > QgsDataItem probably is not the best place where db connections should<br>
> > ><br>
> > > > be implemented, but it is good place where they can be used to<br>
> > > > represent databases in QgsBrowserModel and thus in QBrowser. I can<br>
> > > > imagine a QgsDatabase inherited by QgsPostGis, QgsSqlite etc. with<br>
> > > > all the methods you list on [2]. Then a single QgsDatabaseItem<br>
> > > > (which would inherit from QgsDataItem) could represent any DB<br>
> > > > provider, taking as parameter a QgsDatabase child for specific<br>
> > > > provider.<br>
> > > ><br>
> > > ><br>
> > > > Radim<br>
> > > ><br>
> > > ><br>
> > > > On Mon, May 23, 2011 at 5:21 PM, Giuseppe Sucameli<br>
> > > ><br>
> > > > <<a href="mailto:brush.tyler@gmail.com">brush.tyler@gmail.com</a>> wrote:<br>
> > > > > Hi all,<br>
> > > > > I'm starting to work on DBManager plugin for QuantumGIS.<br>
> > > > ><br>
> > > > > I've just created the repository on GitHub [1] and here's [2] a<br>
> > > > > page<br>
> ><br>
> > on<br>
> ><br>
> > > > the<br>
> > > ><br>
> > > > > QGis wiki<br>
> > > > > containing ideas I wrote in the past few days. I will add weekly<br>
> > > > > reports<br>
> > > ><br>
> > > > to<br>
> > > ><br>
> > > > > that wiki page.<br>
> > > > ><br>
> > > > > Any comments and reviews are very welcome.<br>
> > > > > Regards.<br>
> > > > ><br>
> > > > > [1] <a href="http://github.com/brushtyler/db_manager" target="_blank">http://github.com/brushtyler/db_manager</a><br>
> > > > > [2] <a href="http://www.qgis.org/wiki/DB_Manager_plugin_GSoC_2011" target="_blank">http://www.qgis.org/wiki/DB_Manager_plugin_GSoC_2011</a><br>
> > > > ><br>
> > > > > --<br>
> > > > > Giuseppe Sucameli<br>
> > > > ><br>
> > > > > _______________________________________________<br>
> > > > > Qgis-developer mailing list<br>
> > > > > <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> > > > > <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> ><br>
> > --<br>
> > Dr. Marco Hugentobler<br>
> > Sourcepole - Linux & Open Source Solutions<br>
> > Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland<br>
> > <a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a> <a href="http://www.sourcepole.ch" target="_blank">http://www.sourcepole.ch</a><br>
> > Technical Advisor QGIS Project Steering Committee<br>
<br>
<br>
--<br>
Dr. Marco Hugentobler<br>
Sourcepole - Linux & Open Source Solutions<br>
Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland<br>
<a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a> <a href="http://www.sourcepole.ch" target="_blank">http://www.sourcepole.ch</a><br>
Technical Advisor QGIS Project Steering Committee<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Giuseppe Sucameli<br>