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 pri
Hi Giuseppe
On Tue, Oct 26, 2010 at 4:35 PM, Giuseppe Sucameli 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 ref
Hi Martin,
On Tue, Oct 26, 2010 at 9:21 AM, Martin Dobias wrote:
> On Tue, Oct 26, 2010 at 9:01 AM, Pirmin Kalberer
> 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
> > involve
On Tue, Oct 26, 2010 at 9:01 AM, Pirmin Kalberer 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 w
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 so
2010/10/25 Paolo Cavallini :
> Thanks. So we go back to the question:
> - svn or git?
> - on osgeo or elsewhere?
> - trac, redmine, or other?
I'm testing redmine and it's very cool, I vote for osgeo, and it's the
same for svn and git
> All the best.
my 2 cents
Luca
_
On Tue, Oct 26, 2010 at 07:57:01AM +0200, Ivan Mincik wrote:
> On 10/26/2010 12:07 AM, Paolo Cavallini wrote:
> >Il 25/10/2010 23:29, Martin Dobias ha scritto:
> >
> >- 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
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 Cavallini
wrote:
> >> How does this sound?
> >
> > This sounds good.
>
> Thanks. So we go back to the question:
> - svn or git?
> - on
On 10/26/2010 12:07 AM, Paolo Cavallini wrote:
Il 25/10/2010 23:29, Martin Dobias ha scritto:
On Thu, Oct 21, 2010 at 8:34 AM, Paolo
Cavallini 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 oth
Hi,
> Thanks. So we go back to the question:
> - svn or git?
> - on osgeo or elsewhere?
> - trac, redmine, or other?
I am not a PSC member nor a very dedicated QGIS dev yet, but here are my 2c on
this topic, which would be a kiss approach.
The main target for this repo is qgis and qgis plugin de
Il 25/10/2010 23:29, Martin Dobias ha scritto:
On Thu, Oct 21, 2010 at 8:34 AM, Paolo Cavallini 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 W
On Thu, Oct 21, 2010 at 8:34 AM, Paolo Cavallini wrote:
>
> 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
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 trun
Hi Paolo
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 kin
Hi Ivan ,
yes, I remember the thread.
It's always the same pyuic4 bug, so I've to remove the value from the .ui
file
and set it in the class constructor by code.
Thanks for reporting it.
Cheers.
On Wed, Oct 20, 2010 at 5:45 PM, Ivan Mincik wrote:
> On 10/20/2010 12:34 PM, Paolo Cavallini wrote
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',
Il 20/10/2010 17:55, Ivan Mincik ha scritto:
> I think, it would be very good to merge all good plugins derived from
> Martin's PostGIS Manager to one General database manager. Current
> tendency of creating PostGIS plugins by copying Martin's pluging,
> leaving 90% of code as is, even if I do not
I think, it would be very good to merge all good plugins derived from
Martin's PostGIS Manager to one General database manager. Current
tendency of creating PostGIS plugins by copying Martin's pluging,
leaving 90% of code as is, even if I do not need, is not very good idea.
Or, if not merging t
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 PostG
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
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 t
+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 W
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, a
Hi
+1 to put them under a plugins->database menu
Perhaps merging some of the plugins to provide a 'super postgis'
manager plugin would also be worth thinking about?
Regards
Tim
On Thu, Aug 19, 2010 at 2:10 AM, Giuseppe Sucameli
wrote:
> Hi all,
>
> On Wed, Aug 18, 2010 at 10:05 PM, Martin Dob
Hi all,
On Wed, Aug 18, 2010 at 10:05 PM, Martin Dobias wrote:
> Hi Borys
>
> On Sun, Aug 15, 2010 at 11:59 AM, Borys Jurgiel
> wrote:
> > My suggestion for now is to put everything to a PostGIS submenu within
> the
> > Plugins menu:
> >
> > self.iface.addPluginToMenu('PostGIS', actionBlahBlah)
Hi Borys
On Sun, Aug 15, 2010 at 11:59 AM, Borys Jurgiel 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.
> Then we can mo
On Aug 15, 2010, at 2:59 AM, Borys Jurgiel wrote:
> My suggestion for now is to put everything to a PostGIS submenu within the
> Plugins menu:
> self.iface.addPluginToMenu('PostGIS', actionBlahBlah)
> Then we can modify the QgsInterface.addPluginToMenu method to put each
> submenu either to the
My suggestion for now is to put everything to a PostGIS submenu within the
Plugins menu:
self.iface.addPluginToMenu('PostGIS', actionBlahBlah)
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 config
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
Le 15/08/2010 09:08, Paolo Cavallini a écrit :
Hi all.
Can we move all the PostGIS plugins to a submenu, as we have done with fTools
and
GDAL Tools? This is easy, and will make life easier for our users. I found:
- PostGIS Manager
- PGQuery for PostGIS
- PostGIS SQL Query Editor
- RT Sql Layer
-
Hi all.
Can we move all the PostGIS plugins to a submenu, as we have done with fTools
and
GDAL Tools? This is easy, and will make life easier for our users. I found:
- PostGIS Manager
- PGQuery for PostGIS
- PostGIS SQL Query Editor
- RT Sql Layer
- RT Postgres Extractor
and eventually also Linear
31 matches
Mail list logo
