Re: [Qgis-developer] PostGIS plugins
Hi Giuseppe On Tue, Oct 26, 2010 at 4:35 PM, Giuseppe Sucameli sucam...@faunalia.it wrote: coming back to the PostGIS plugins, I think Wroclaw would be also good place to merge some of them (e.g. improving PostGis Manager by adding the RT Sql Layer capabilities). Yes, agreed. To think big, we can refactor the pg_manager creating a new manager which manages both postgis and spatialite. In this manner we wouldn't have a lot of duplicated code for the spatialite_manager and we can easily extend it to manage others spatial dbs. Sure. In the very first stage they could merged into one plugin with just small changes (e.g. each plugin in one subdirectory, with some glue). The next stages would incrementally remove duplicate code. I think the first step is using the QtSql module instead of the psycopg2 one within pg_manager. I don't know if there are some limitations in this moment, but I see it's on the pg_manager's TODO list. I don't think switching to QtSql has a priority. It's on the todo list because someone suggested it once, but I never investigated pros and cons of the transition. Currently I don't see any reason for rewriting that code. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins
Il 30/10/2010 10:57, Martin Dobias ha scritto: Sure. In the very first stage they could merged into one plugin with just small changes (e.g. each plugin in one subdirectory, with some glue). The next stages would incrementally remove duplicate code. Very well. So this will be one of our priorities for the hackfest. BTW, what other PostGIS plugin writes think about this? Any chance of having as much unification, or at least standardization, and removal of duplicated functions, as possible? I mean e.g.: PgQuery for QGIS PostGIS SQL Query editor it is very difficult for an user understand and decide which one to use, and the respective differences and advantages. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins
Am Dienstag, 26. Oktober 2010, um 00.07:56 schrieb Paolo Cavallini: Il 25/10/2010 23:29, Martin Dobias ha scritto: On Thu, Oct 21, 2010 at 8:34 AM, Paolo Cavallinicavall...@faunalia.it wrote: How does this sound? This sounds good. Thanks. So we go back to the question: - svn or git? - on osgeo or elsewhere? - trac, redmine, or other? I think it would be good to act now, so in Wroklaw we'll have all the pieces in place, and we can start hacking around it. All the best. Hi Paolo, I understand that you want to go on. But I think that the decision for a plugin development infrastructure should happen in Wroclaw, with many devs involved. We can show there the different approaches and help the attending people setting up new software (like git), if needed. A discussion about pros and cons of such a decision takes quite some time, especially when discussed by mail. Time, which many devs do not have during their daily work. The result of a hasty decision is usually: let's stay with the old tools we already know. Pirmin -- Pirmin Kalberer Sourcepole - Linux Open Source Solutions http://www.sourcepole.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins
Il 26/10/2010 09:01, Pirmin Kalberer ha scritto: I understand that you want to go on. But I think that the decision for a plugin development infrastructure should happen in Wroclaw, with many devs involved. We can show there the different approaches and help the attending people setting up new software (like git), if needed. A discussion about pros and cons of such a decision takes quite some time, especially when discussed by mail. Time, which many devs do not have during their daily work. The result of a hasty decision is usually: let's stay with the old tools we already know. You are right. I would have liked to use the time during the hackfest for starting doing the real work on the new infrastructure, but if we do not reach a consensus it's better wait. Thanks. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins
On Tue, Oct 26, 2010 at 9:01 AM, Pirmin Kalberer pi...@sourcepole.com wrote: Am Dienstag, 26. Oktober 2010, um 00.07:56 schrieb Paolo Cavallini: Thanks. So we go back to the question: - svn or git? - on osgeo or elsewhere? - trac, redmine, or other? I think it would be good to act now, so in Wroklaw we'll have all the pieces in place, and we can start hacking around it. All the best. Hi Paolo, I understand that you want to go on. But I think that the decision for a plugin development infrastructure should happen in Wroclaw, with many devs involved. We can show there the different approaches and help the attending people setting up new software (like git), if needed. A discussion about pros and cons of such a decision takes quite some time, especially when discussed by mail. Time, which many devs do not have during their daily work. The result of a hasty decision is usually: let's stay with the old tools we already know. I completely agree that making decisions for the infrastructure shouldn't be too hasty... Wroclaw hackfest looks like a good place to try to resolve the current situation - also regarding the management of installed plugins, plugin UI guidelines etc. Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins
Hi Martin, On Tue, Oct 26, 2010 at 9:21 AM, Martin Dobias wonder...@gmail.com wrote: On Tue, Oct 26, 2010 at 9:01 AM, Pirmin Kalberer pi...@sourcepole.com wrote: I understand that you want to go on. But I think that the decision for a plugin development infrastructure should happen in Wroclaw, with many devs involved. We can show there the different approaches and help the attending people setting up new software (like git), if needed. A discussion about pros and cons of such a decision takes quite some time, especially when discussed by mail. Time, which many devs do not have during their daily work. The result of a hasty decision is usually: let's stay with the old tools we already know. I completely agree that making decisions for the infrastructure shouldn't be too hasty... Wroclaw hackfest looks like a good place to try to resolve the current situation - also regarding the management of installed plugins, plugin UI guidelines etc. coming back to the PostGIS plugins, I think Wroclaw would be also good place to merge some of them (e.g. improving PostGis Manager by adding the RT Sql Layer capabilities). To think big, we can refactor the pg_manager creating a new manager which manages both postgis and spatialite. In this manner we wouldn't have a lot of duplicated code for the spatialite_manager and we can easily extend it to manage others spatial dbs. I think the first step is using the QtSql module instead of the psycopg2 one within pg_manager. I don't know if there are some limitations in this moment, but I see it's on the pg_manager's TODO list. What's your opinion? Cheers. -- Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins
Il 21/10/2010 00:14, Martin Dobias ha scritto: I would agree to include PostGIS plugins to trunk, but IMHO it makes much more sense to have only one PostGIS plugin to do all management tasks. I think some effort should be done to integrate the plugins into one prior to inclusion to the trunk... It's hard to force people to do this kind of boring work once the code is included in repository. Hi Martin. I agree that it is better either to integrate all tools into one or, perhaps even better, to have a modular approach, so it will be easier to add new tools. I also agree that it is better to do this work before putting it into trunk, but I think we need a collaborative platform (a plugin SVN) where several devs can cooperate (see the other mail). So my suggestion could be rephrased as: let's put our plugins on an svn, and start merging them. Afterwards they can be moved to trunk. How does this sound? All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins
+1 for getting them into trunk We would use them for teaching Postgis as a way to visualize the queries. Or for myself for quick visualizations while testing SQL commands. I wonder what is the best way to organize all those Postgis plugins. Would they get their own toolbar or menu? Andreas On Wed, October 20, 2010 12:34 pm, Paolo Cavallini wrote: Hi all. We (Faunalia, for Regione Toscana) have developed a couple of plugins: RT SQL layer, to build arbitrary select queries and load results on the canvas, and RT PostGIS extractor, to export large amounts of data cut by another vector (in PostGIS or drawn by hand. Thy are in production now, and we feel they are mature enough for being of general (even if specialized) use. We request therefore their inclusion in trunk. We are committed to their maintenance. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Andreas Neumann http://www.carto.net/neumann/ http://www.svgopen.org/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins
Hi I think it would be great if this new 'database' section could be made to work with spatialite as well as with postgis. Maybe the creation of a general manager for spatial databases that could integrate the 'Postgis manager', 'Spatialite manager', 'RT SQL layer' and the rest of the functionality of the other plugins that are related. I guess this would need some kind of abstraction layer, and some (probably a lot of) extra work. This could maybe become a solid base for other people to develop more specialized plugins to deal with database queries and analysis. Maybe I'm being too ambitious and starting with the incorporation of Faunalia's tools is good enough ;) On Wed, Oct 20, 2010 at 4:00 PM, Paolo Cavallini cavall...@faunalia.it wrote: Il 20/10/2010 16:30, Andreas Neumann ha scritto: I wonder what is the best way to organize all those Postgis plugins. Would they get their own toolbar or menu? I think we should have a Database dropdown close by the sister dropdowns Vector (AKA fTools) and Raster (AKA GDALTools). All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- ___ ___ __ Ricardo Garcia Silva ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins
On 10/20/2010 12:34 PM, Paolo Cavallini wrote: Hi all. We (Faunalia, for Regione Toscana) have developed a couple of plugins: RT SQL layer, to build arbitrary select queries and load results on the canvas, and RT PostGIS extractor, to export large amounts of data cut by another vector (in PostGIS or drawn by hand. Thy are in production now, and we feel they are mature enough for being of general (even if specialized) use. We request therefore their inclusion in trunk. We are committed to their maintenance. All the best. Hi, when trying to run RT PostGIS Extractor on Debian Lenny (Qt 4.4.3) it is crashing with following error: Traceback (most recent call last): File /home/ivo/.qgis/python/plugins/rt_postgres_extractor/ManagerPlugin.py, line 37, in run self.dlg = Wizard(self.iface.mainWindow(), self.iface) File /home/ivo/.qgis/python/plugins/rt_postgres_extractor/Wizard.py, line 25, in __init__ self.setupUi() File /home/ivo/.qgis/python/plugins/rt_postgres_extractor/Wizard.py, line 58, in setupUi exec( wizPage = %s( self.iface, self.wizState ) % p ) File , line 1, in File /home/ivo/.qgis/python/plugins/rt_postgres_extractor/WizPage5.py, line 27, in __init__ self.setupUi(self) File /home/ivo/.qgis/python/plugins/rt_postgres_extractor/ui/WizPage5_ui.py, line 55, in setupUi self.progressBar.setProperty(value, 24) TypeError: argument 2 of QObject.setProperty() has an invalid type We where already solving similar problem in Table Manager. 'self.progressBar.setProperty(value,QtCore.QVariant(0))' was fixing the problem. Ivan -- Ivan Mincik, Gista s.r.o. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins
Il 20/10/2010 17:29, Ricardo Filipe Soares Garcia da ha scritto: I think it would be great if this new 'database' section could be made to work with spatialite as well as with postgis. Maybe the creation of a general manager for spatial databases that could integrate the 'Postgis manager', 'Spatialite manager', 'RT SQL layer' and the rest of the functionality of the other plugins that are related. Yes, this is also our project in the longer term. Of course we'll need help. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins menu
Hi all,
On Wed, Aug 18, 2010 at 10:05 PM, Martin Dobias wonder...@gmail.com wrote:
Hi Borys
On Sun, Aug 15, 2010 at 11:59 AM, Borys Jurgiel borysia...@aster.pl
wrote:
My suggestion for now is to put everything to a PostGIS submenu within
the
Plugins menu:
self.iface.addPluginToMenu('PostGIS', actionBlahBlah)
Right. I will do that for postgis manager in the next release.
I moved all my 2 PostGis plugins (rt_sql-layer e rt_postgres-extractor)
to the PostGIS menu:
self.iface.addPluginToMenu('PostGIS', self.action)
Then we can modify the QgsInterface.addPluginToMenu method to put each
submenu either to the Plugins branch or to the main menu, so each user
can
configure which plugin sumbenus are at hand. It's a five-minuts-fix to
read
it from QSettings (still without any GUI for configuring it, but it's a
step
forward).
The third step is the GUI. I started refactoring the Installer (just
three
hours per month, so it's why no changes are commited) and with Martin and
Anne we plan to put it as a second tab of the manager. What about a third
tab menus and toolbars, when an user can be able to:
1. Select whether given submenu (e.g. PostGIS) goes to the main menu or
the
Plugins menu
2. Select whether given submenu creates its own toolbar or goes to the
main
Plugin toolbar.
3. Compose own toolbar(s) with a set of individual plugin buttons. It
allows
to hide the native plugin toolbar and enable personalized ones, like
Monday's tasks, Tools useful for X-files processing etc
4. Save/load profiles (at least sets of plugins to be loaded - now I
often
have to use --noplugins option to make qgis faster)
What do you think? The first two steps can be done in a moment.
I like this idea of giving the users a chance to override the default
placement. I would like to go even further - to allow user to
manipulate individual actions created by the plugins - but that would
probably need an addition to interface API (otherwise the
identification of actions would depend on their name in current
translation). I think of showing a tree widget to the user where nodes
would be menus and submenus, the leafs would be individual actions.
The user would be able to modify the tree in any way he likes: add new
top level menus with some actions or just reorganize the 'Plugins'
menu.
If we end up updating the plugin interface, we could also proceed with
defining the categories as we have discussed at the hackfests. Each
plugin would be _strongly_ advised to suggest a category where it
belongs, so ideally the users will not have to organize the plugins
manually.
+1, would be great!
Cheers
--
Giuseppe Sucameli
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PostGIS plugins menu
Il 15/08/2010 11:13, MORREALE Jean Roc ha scritto: Adding an item to the top menu bar should be avoided, if it is done for each extension (like cadtools or manageR already do) or group of extensions (the same reasonning could be applied for R, etc.) this bar will soon become too long to be seen on a 17 or a netbook. In the end it'll just move the mess from a menu list to the main menu toolbar. Hi Jaean Roc. In principle I agree, but I see PostGIS (or perhaps even better: Database) as a general menu, just like Vector and Raster. In the Vienna hackmeeting we agreed in lumping plugins in categories, and I think Database should be one of these. In any case, we have to group plugins somehow, currently even for a moderate installation it is impossible to see all the icons. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
