Hi Marco, <br><br><div class="gmail_quote">On Tue, May 24, 2011 at 5:05 PM, Marco Hugentobler <span dir="ltr"><<a href="mailto:marco.hugentobler@sourcepole.ch" target="_blank">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">
Similar to Radim, I'd prefer to have an integration with QBrowser and its<br>
model.<br></blockquote><div><br>as I wrote, it's ok for me to use the QgsBrowserModel and QgsDataItem to 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 allow to <br>
move/copy layers between different providers and I had wrote that to my proposal.<br><br>What I don't like it's to create DBManager as a C++ plugin or just as a QBrowser <br>
extension. Python code is easily maintainable, furthermore the QBrowser/DBManager <br>won't do heavy computation, so is there a good reason to develop it using C++ <br> instead of python?<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">
Since the browser classes are in the source tree, they are easy to 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>
<div><div></div><div>> Hi Radim,<br>
><br>
> On Tue, May 24, 2011 at 7:46 AM, Radim Blazek <<a href="mailto:radim.blazek@gmail.com" target="_blank">radim.blazek@gmail.com</a>>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 stuff<br>
> in the<br>
> qgis core creating API for reuse of code (I think about connections, as it<br>
> was done<br>
> in WMS provider) and then accessing that from the plugin, but I don't like<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, an<br>
> 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 core<br>
> 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 QBrowser<br>
> > is a stand alone application but it will be integrated also to QGIS<br>
> > main application.<br>
><br>
> QBrowser it's implemented as a C++ standalone application to browse files<br>
> 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 QGis<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 QBrowser<br>
> 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 started<br>
> to work<br>
> on my _accepted_ project all devs said me that they didn't like my project,<br>
> so my<br>
> code was set aside and left on a branch and my GSoC was set as failed even<br>
> if I had<br>
> ended coding = no gsoc shirt :'( and no money for the second coding 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 all<br>
> > the methods you list on [2]. Then a single QgsDatabaseItem (which<br>
> > would inherit from QgsDataItem) could represent any DB provider,<br>
> > taking as parameter a QgsDatabase child for specific 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" target="_blank">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 page 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" target="_blank">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>
--<br>
</div></div>Dr. Marco Hugentobler<br>
Sourcepole - Linux & Open Source Solutions<br>
Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland<br>
<font color="#888888"><a href="mailto:marco.hugentobler@sourcepole.ch" target="_blank">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>
</font></blockquote></div><br><br clear="all"><br>-- <br>Giuseppe Sucameli<br>