Hi Radim, <br><br><div class="gmail_quote">On Tue, May 24, 2011 at 7:46 AM, Radim Blazek <span dir="ltr"><<a href="mailto:radim.blazek@gmail.com" target="_blank">radim.blazek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
First of all, IMO, the DBManager has to be implemented in QGIS core,<br>
not as a plugin for two main reasons: </blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
1) it is core functionality<br></blockquote><div>I not agree, it's a GUI functionality. We can implement all the core stuff in the <br>qgis core creating API for reuse of code (I think about connections, as it was done <br>
in WMS provider) and then accessing that from the plugin, but I don't like the idea <br>to have DBManager in C++.<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">
2) connection factories MUST go to providers, otherwise you start to<br>
create a set of plugins for each DB, parallel to providers.<br></blockquote><div>I agree with you about this point, as you can see I added yesterday the <br>QgsDataItem section to the wiki.<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">
>From UI point of view, I would prefer to have everything in one place,<br>
that means in QBrowser. We can rename QBrowser to QManager and<br>
suddenly it sounds more logical. </blockquote><div>QBrowser is a standalone application, a C++ application, I think the manager should <br>be easily maintainable and IMHO python code is the best solution.<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">
Having everything in one tree will<br>
allow in future to easily drag-and-drop for example Shapefile to<br>
PostGIS and so on. </blockquote><div>That is not a problem, that feature could be implemented in providers, an import <br>method which take a QgsMapLayer (this was in my gsoc proposal yet), but have <br>everything in core without any real and strong reason could make the core code <br>
hard to maintain.<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">We have to add support for other providers to<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></blockquote><div>QBrowser it's implemented as a C++ standalone application to browse files and <br>show information about layers, but those are the same infos you can get using QGis.<br><br>The manager would make easy the use of databases in QGis, but not for QGis use <br>
only. Ok, we can show preview, load a layer in canvas, but also run queries, <br>create/edit/drop tables and views, ... pretty different from the QBrowser aim!<br>
<br>I think all the qgis-devs should say their opinion about this question raised by Radim. <br><br>I attended the GSoC 2009 for a different FOSS project and after I started to work <br>on my _accepted_ project all devs said me that they didn't like my project, so my <br>
code was set aside and left on a branch and my GSoC was set as failed even if I had <br>ended coding = no gsoc shirt :'( and no money for the second coding period :(<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></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
QgsDataItem probably is not the best place where db connections should<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>
<div><div></div><div><br>
<br>
On Mon, May 23, 2011 at 5:21 PM, Giuseppe Sucameli<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 the<br>
> QGis wiki<br>
> containing ideas I wrote in the past few days. I will add weekly reports to<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>
</div></div>> _______________________________________________<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>
</blockquote></div><br><br clear="all"><br>-- <br>Giuseppe Sucameli<br>