Hi All,<div><br></div><div>This is the vision I have for QGIS when it comes to layer handling: One unified tree that can handle both files (vector and raster) and database connections (to any database). It should be built into QGIS and live in the dock just like the layers widget. IMO the QBrowser would end up like this, just the tree part not the metadata stuff (or have it on demand), and having the DBManager part of the QBrowser would achieve my <meta http-equiv="content-type" content="text/html; charset=utf-8">unified tree vision.<br>
<br><div class="gmail_quote">At the moment how there are 10 different ways to open layers and databases is not good for usability, and the QBrowser is a good step towards fixing this issue. If the DBManager was part of QBrowser then there would only be one place to go and open any kind of the layer and would remove a lot of confusion and code. I have never seen any other GIS app get this right but I think QBrowser+DBManger integrated into QGIS as a single tree would be a great win.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Just my thoughts.</div><div class="gmail_quote"><br></div><div class="gmail_quote">- Nathan Woodrow </div><div class="gmail_quote"><br></div><div class="gmail_quote">
On Tue, May 24, 2011 at 5:07 PM, Giuseppe Sucameli <span dir="ltr"><<a href="mailto:brush.tyler@gmail.com">brush.tyler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Radim, <br><br><div class="gmail_quote"><div class="im">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><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><div class="im"><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><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><div class="im">
<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><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>
<div class="im"><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><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><div class="im"><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><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><div class="im"><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></div><br><br clear="all"><br>-- <br><font color="#888888">Giuseppe Sucameli<br>
</font><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></blockquote></div><br></div>