Re: [Qgis-developer] Vector buffer commitChanges (was Interaction between QGis and ArcGis)

2013-04-21 Thread Martin Dobias
Hi Radim

On Sat, Apr 20, 2013 at 8:39 AM, Radim Blazek radim.bla...@gmail.com wrote:
 On Fri, Apr 19, 2013 at 12:07 PM, JVerholle julien.verho...@eaurmc.fr wrote:
 Hi all,

 If I want to open the same shapefile in both softwares at the same time, the
 file is locked in ArcGis (even if the edition mode isn't used in QGis).

 QGIS opens layers (files) in update mode (r+) if possible (file
 permission + OGR driver support). It may (but also may not) be a
 problem also for #6448 (slow shp over network) I am currently
 struggling with. In general, I think that it is bad to open files
 always in update mode even if in most cases they are not going to be
 edited.

Agreed.


 Currently there are no QgsVectorDataProvider::startEditing() and
 commitChanges() which may also be a problem for database providers
 because QgsVectorLayerEditBuffer::commitChanges() calls more provider
 methods changing
 data (deleteAttributes, addAttributes, deleteFeatures,
 addFeatures...).  The commitChanges() should do everything in one
 transaction IMO.

 My proposal is to:
 1) Add QgsVectorDataProvider::startEditing() and
 QgsVectorDataProvider::commitChanges()
 2) In OGR provider try to open layer in update mode only to get
 capabilities (get info if it can be modified when the provider is
 constructed) but then to reopen in read only mode.
 3) Call QgsVectorDataProvider::startEditing() from
 QgsVectorLayer::startEditing() to be sure that the layer is still
 editable (permissions could change or it was opened by another
 application for editing since the layer was opened) and to reopen
 files in update mode (files based) or to start transaction (DB based).
 4) Call QgsVectorDataProvider::commitChanges() from
 QgsVectorLayer::commitChanges()
 4) In QgsOgrProvider::startEditing() reopen the layer in update mode
 5) In QgsOgrProvider::commitChanges() reopen the layer in read only mode

When would be startEditing() called - when user starts editing in GUI
or when user is going to commit the changes, just before issuing
provider editing functions?
Maybe beginTransaction() and endTransaction() or commitTransaction()
would be better names? It would be practical to have also another
method to detect whether the provider is in editing mode.

What about legacy code that directly makes changes to
QgsVectorDataProvider? Will it need to wrap the editing functions with
these two additional calls? It would be good if that would not be
necessary and the provider would start and stop the transaction
automatically if not in editing mode.

Regarding 2) is it necessary to open layer in update mode in order to
get editing capabilities?


 We don't really have to implement startEditing() and commitChanges()
 in all providers for 2.0, but it should be in the vector API.

Agreed.

Regards
Martin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Header files order

2013-04-21 Thread Martin Dobias
On Sat, Apr 20, 2013 at 10:18 AM, Radim Blazek radim.bla...@gmail.com wrote:
 do you agree with that order (least specific - most specific) extend
 for system etc (each section sorted lexically):

 * system headers
 * standard libraries headers
 * qt headers
 * other 3rd party libraries headers
 * qgis headers

Personally I do not care so much about the order of the sections. I
would say we should just:
1. #include the corresponding header file first (e.g. for abc.cpp the
first include should be #include abc.h) to ensure that the header
file does not have some hidden include dependencies
2. keep each section sorted

Anyway the least specific - most specific order makes more sense than
the opposite order.

Martin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Vector buffer commitChanges (was Interaction between QGis and ArcGis)

2013-04-21 Thread Radim Blazek
On Sat, Apr 20, 2013 at 9:03 PM, Olivier Dalang
olivier.dal...@gmail.com wrote:
 Is this a solution for http://hub.qgis.org/issues/7540 ?

Probably.

Radim

 2013/4/20 Radim Blazek radim.bla...@gmail.com

 On Fri, Apr 19, 2013 at 12:07 PM, JVerholle julien.verho...@eaurmc.fr
 wrote:
  Hi all,
 
  If I want to open the same shapefile in both softwares at the same time,
  the
  file is locked in ArcGis (even if the edition mode isn't used in QGis).

 QGIS opens layers (files) in update mode (r+) if possible (file
 permission + OGR driver support). It may (but also may not) be a
 problem also for #6448 (slow shp over network) I am currently
 struggling with. In general, I think that it is bad to open files
 always in update mode even if in most cases they are not going to be
 edited.

 Currently there are no QgsVectorDataProvider::startEditing() and
 commitChanges() which may also be a problem for database providers
 because QgsVectorLayerEditBuffer::commitChanges() calls more provider
 methods changing
 data (deleteAttributes, addAttributes, deleteFeatures,
 addFeatures...).  The commitChanges() should do everything in one
 transaction IMO.

 My proposal is to:
 1) Add QgsVectorDataProvider::startEditing() and
 QgsVectorDataProvider::commitChanges()
 2) In OGR provider try to open layer in update mode only to get
 capabilities (get info if it can be modified when the provider is
 constructed) but then to reopen in read only mode.
 3) Call QgsVectorDataProvider::startEditing() from
 QgsVectorLayer::startEditing() to be sure that the layer is still
 editable (permissions could change or it was opened by another
 application for editing since the layer was opened) and to reopen
 files in update mode (files based) or to start transaction (DB based).
 4) Call QgsVectorDataProvider::commitChanges() from
 QgsVectorLayer::commitChanges()
 4) In QgsOgrProvider::startEditing() reopen the layer in update mode
 5) In QgsOgrProvider::commitChanges() reopen the layer in read only mode

 I am not sure if reopening of layers in OGR provider may be a
 performance problem, but I hope that it should not be.

 We don't really have to implement startEditing() and commitChanges()
 in all providers for 2.0, but it should be in the vector API.

 Radim

 PS: Unfortunately, according to my current knowledge, this is not full
 solution for #6448.

  ArcGis is enable to recognize the feature's type (we can see a ?
  instead
  of polylign, polygon or point).
  This issue has been only noticed on Windows (and with ArcMap 9.2).
 
  Someone has already seen this problem ? Is it due to QGis or Gdal ?
 
  Thanks.
 
  Julien
 
 
 
  --
  View this message in context:
  http://osgeo-org.1560.x6.nabble.com/Interaction-between-QGis-and-ArcGis-tp5048256.html
  Sent from the Quantum GIS - Developer mailing list archive at
  Nabble.com.
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Vector buffer commitChanges (was Interaction between QGis and ArcGis)

2013-04-21 Thread Radim Blazek
On Sun, Apr 21, 2013 at 9:34 AM, Martin Dobias wonder...@gmail.com wrote:
 Hi Radim

 On Sat, Apr 20, 2013 at 8:39 AM, Radim Blazek radim.bla...@gmail.com wrote:
 On Fri, Apr 19, 2013 at 12:07 PM, JVerholle julien.verho...@eaurmc.fr 
 wrote:
 Hi all,

 If I want to open the same shapefile in both softwares at the same time, the
 file is locked in ArcGis (even if the edition mode isn't used in QGis).

 QGIS opens layers (files) in update mode (r+) if possible (file
 permission + OGR driver support). It may (but also may not) be a
 problem also for #6448 (slow shp over network) I am currently
 struggling with. In general, I think that it is bad to open files
 always in update mode even if in most cases they are not going to be
 edited.

 Agreed.

 Currently there are no QgsVectorDataProvider::startEditing() and
 commitChanges() which may also be a problem for database providers
 because QgsVectorLayerEditBuffer::commitChanges() calls more provider
 methods changing
 data (deleteAttributes, addAttributes, deleteFeatures,
 addFeatures...).  The commitChanges() should do everything in one
 transaction IMO.

 My proposal is to:
 1) Add QgsVectorDataProvider::startEditing() and
 QgsVectorDataProvider::commitChanges()
 2) In OGR provider try to open layer in update mode only to get
 capabilities (get info if it can be modified when the provider is
 constructed) but then to reopen in read only mode.
 3) Call QgsVectorDataProvider::startEditing() from
 QgsVectorLayer::startEditing() to be sure that the layer is still
 editable (permissions could change or it was opened by another
 application for editing since the layer was opened) and to reopen
 files in update mode (files based) or to start transaction (DB based).
 4) Call QgsVectorDataProvider::commitChanges() from
 QgsVectorLayer::commitChanges()
 4) In QgsOgrProvider::startEditing() reopen the layer in update mode
 5) In QgsOgrProvider::commitChanges() reopen the layer in read only mode

 When would be startEditing() called - when user starts editing in GUI
 or when user is going to commit the changes, just before issuing
 provider editing functions?

When user starts editing (Toggle Editing), that should ensure
possibility of later commit (provider will keep files in update mode
after startEditing()). startEditing() may also fail (if permissions
changed), it would be bad to let user do editing which could not be
commited. Opening a transaction in DB should ensure that commit will
be done on the same data which were edited.

 Maybe beginTransaction() and endTransaction() or commitTransaction()
 would be better names?

Maybe better, but we are already using startEditing() and
commitChanges() in vector layer so I would prefer to use the same.

endTransaction() for rollback?

 It would be practical to have also another
 method to detect whether the provider is in editing mode.

Yes and startEditing() should return false it a transaction is already opened.

 What about legacy code that directly makes changes to
 QgsVectorDataProvider? Will it need to wrap the editing functions with
 these two additional calls? It would be good if that would not be
 necessary and the provider would start and stop the transaction
 automatically if not in editing mode.

It can probably start automatically but when it should commit? It
should not commit changes automatically in destructor, not commited
changes should be lost if supported by provider (DB providers) . File
based providers will do changes immediately, no rollback on provider
level,  but still there will be rollback on layer level.

 Regarding 2) is it necessary to open layer in update mode in order to
 get editing capabilities?

I think so, OGR_L_TestCapability works with opened layer and
OGR_DS_TestCapability can only test ODsCCreateLayer and
ODsCDeleteLayer.

Radim

 We don't really have to implement startEditing() and commitChanges()
 in all providers for 2.0, but it should be in the vector API.

 Agreed.

 Regards
 Martin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


[Qgis-developer] Make QGIS interact with LibreCAD.

2013-04-21 Thread Diego Gnesi Bartolani
Hi,

Yesterday I posted in a wrong thread, so I'm opening a new one. I'll
copy and paste the previous message and add some notes. Sorry for the
mess!

Original post:

I am an Italian archaeologist and an enthusiastic QGIS user. I do what
I can to spread the knowledge about QGIS and other open source
softwares to my university students (I am a contract professor at the
Basilicata University and some days ago I've become contract professor
at the Specialization School of Archeology of Udin, Venice and
Trieste). The main difficulty I have with open source GIS is the
advanced editing of vector layers. QGIS doesn't offer too much support
for digitizing, the CAD Tools plugin has some useful functions but is
far from being complete and the kind of interaction that it proposes
is not very productive and time-saving (it's not a critic: CAD Tools
saved my life a lot of time, and I want to thank the developers and
maintainers). Many times, I had to convert my vector layers to dxf and
back in order to perform some complex tasks (with all kind of
conversion problems, like the preservation of the attributes values,
etc.).
I have some experience in programming (about ten years of
developement, mainly in C# with the .NET Framework, before I switched
to Linux), and I would like to try (only try, without promising
anything!!) to implement complete CAD tools and functions (If there
isn't and analogous project already active; in that case, nevermind!).

I think that developing a CAD plugin from scratch is very hard to me
and maybe not the better way to get good results, so I'm oriented to
try to augment the interaction between QGIS and an existing CAD
software (I'm thinking to LibreCAD). I thought to two possible
strategies:

1. Use the LibreCAD library and source code to develop a C++ QGIS plugin;
2. Create a shapefile/spatialite/postgis driver for LibreCAD in order
to edit those formats inside LibreCAD.
3. Convert some layers of the QGIS project in a dxf file and back
(each QGIS layer in a different layer of the final dxf file).

I'm asking your opinion about which of those ways could be the faster
or the better to implement, or which one is impossible to undertake
according to your knowledge of the QGIS API.

My doubts are:

Strategy #1: Probably the ideal one, but does the implementation of
complex snaps or constraints against the features of other layers
(i.e. midpoint, parallels, etc.) require changes to the QGIS API, or
all these operations can be contained on a plugin? Is it better to
work directly on QGIS vector layers or to create a plugin layer, edit
it and then commit the changes to the vector layer? The conversion
could help me to manage geometries in the way LibreCAD wants. Is it
possible in your opinion to have an interactive shell (i.e. draw the
first point, and then inserting the coordinates of the second point)?

Strategy #2: Probably the easier, but I should find a way to disable
some LibreCAD functions (i.e. the drawing of splines, or the drawing
of points on a line layer) without disseminating my changes all over
LibreCAD's source files. For this kind of solution I'll ask to the
developers of LibreCAD.

Strategy #3: The problem is on committing the changes of the dxf file
to the original layer: how to specify that a line in the dxf file must
replace the geometry of and existing record of the original spatialite
layer? Maybe it's impossible, it doesn't seem to me that I can put on
a dxf file the necessary metadata to preserve a link to the original
features.

What do you think? And what do you actually do when you have to draw
complex shapes on shapefiles or other vector layers?

NEW COMMENTS:

- Antonio Locandro is compiling a list of required CAD features. It
would be very useful, so please Antonio, get me a link to this list
when it's finished.
- The more I explore QGIS and LibreCAD source codes, the more I'm
convincing that integrating LibreCAD's tools on QGIS is very
difficult, and it would be easier to develop those tools from scratch.
To get the best results in a short amount of time, I think that I
could work to make shapefiles and other vector layers editable in
LibreCAD (using GDAL). This solution has the issue that it doesn't
allow to snap to other QGIS layers, nevertheless it could be of great
help and available in a reasonable amount of time. Then, when I have
more practice with QGIS and LibreCAD APIs, I'll try to do something
better (i.e. develop a QGIS driver for LibreCAD in order to open the
whole QGIS project in LibreCAD, organized by layers).
I'm waiting for the answers to an analogous thread in LibreCAD's mailing list:

http://forum.librecad.org/Using-LibreCAD-s-tools-on-GIS-vector-layers-td5707930.html

I think that I'm going to work on this project in a few weeks.

Let me know what do you think and if you have suggestions.

Diego Gnesi
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org

Re: [Qgis-developer] [Qgis-user] [Qgis-psc] Logo

2013-04-21 Thread Alister Hood
Hi,

 Date: Sat, 20 Apr 2013 14:47:39 +1000
 From: Nathan Woodrow madman...@gmail.com
 To: Marco Bernasocchi ma...@bernawebdesign.ch
 Cc: qgis-developer qgis-developer@lists.osgeo.org,qgis-user
 qgis-u...@lists.osgeo.org
 Subject: Re: [Qgis-developer] [Qgis-user]  [Qgis-psc] Logo
 Message-ID:
 CAAi8Yg88oqQCHZnu=5P=ptm=js1pmrvve_x7bg1emhij1hq...@mail.gmail.com
 Content-Type: text/plain; charset=iso-8859-1
 
 Hi all,
 
 There is now another poll with some more designs:
 
 http://99designs.com.au/logo-design/vote-9qwk3a
 
 All polls can be found at:
 
 http://99designs.com.au/logo-design/contests/qgis-needs-logo-210397/polls

In case you've added any more polls, note that this page is not visible without 
a logon.

 - Nathan

FWIW, I think that #336 is really good, but it was probably added to late to be 
really noticed.

A couple of people said they like the other variations of it, by I think the 
one which has the triangle on the Q in a different colour is no good because it 
isn't clear enough that it is a Q.  Even in #336 I guess it might not be clear 
enough, but the triangle does seem cool compared to a regular stroke on the Q...

Of course, I'm still not convinced it is better than the proposal here:
http://hub.qgis.org/issues/6688
;)
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Sextante test drive

2013-04-21 Thread Victor Olaya
Paolo, I have changed the configuration dialog with your suggestions
(thanks!). Everything you suggested is there, except making the param
name not editable, which seems a bit harder to get...

Also, now there are autoconfig paths for SAGA, GRASS and OTB in
Windows, so if a user installs QGIS with the OSGeo4W installer, there
should nbe no need for extra configuration, and  he could start using
all algorithms directly in an out-of-the-box QGIS install.

thanks!
Victor


2013/4/20 Paolo Cavallini cavall...@faunalia.it:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi all.
 Yesterday I have shown Sextante in an advanced course. Here my conclusions:

 * in Sextante options, General entry should always be the first, Modeler 
 second, and
 Script third
 * the name of the settings is an editable field, which seems inappropriate
 * the Settings column should be wider, at the expense of the Value column;
 alternatively, text should be wrapped
 * when activating the new Use categories to classify..., only a few 
 algorithms are
 shown; I understand the need to simplify things, but I'm still unsure if it's
 appropriate to limit users' choice
 * IMHO OTB is a big plus for Sextante, as it brings many brand new functions,
 unavailable in most other desktop GIS; so I suggest to:

   * include OTB in the standalone win package (easy, as it is already in 
 osgeo4w)
   * add its default path according to the running distro; for users, adding 
 it by
 hand can be difficult
   * I noticed that the Mean shift segmentation produces a vector with the Y 
 axis inverted

 * Saga seems the first choice for many analyses; it is therefore essential to 
 have it
 easily available by default in all major distro (at least deb and ubuntu) and 
 in
 standalone packages (win, osx); any blockers for this?

 * Taudem should be added to OSGeo4w, possibly also to the standalone package.

 Overall, there is great excitation, and users are looking forward for 2.0, 
 with
 Sextante in bright light!

 All the best, and thanks.
 - --
 Paolo Cavallini - Faunalia
 www.faunalia.eu
 Full contact details at www.faunalia.eu/pc
 Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlFyKXUACgkQ/NedwLUzIr463QCfZy+vP6e57ARO/wKbOjFqcskZ
 6QoAoJYJLPBtDa3FQ17l6y7K7iskC/xP
 =YYCi
 -END PGP SIGNATURE-
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Website about the activities at the developer meeting in Valmiera

2013-04-21 Thread Yves Jacolin
Thanks all for your feedback and photos. It is interesting to follow the 
hackfest when we couldn't be there.

Y.
Le vendredi 19 avril 2013 10:29:47 Pēteris Brūns a écrit :
 Hi All,
 
 here are some photos from our side
 https://plus.google.com/photos/103928023213007211291/albums/5868447575897675
 969
 
 Regards,
 
 On 2013.04.16. 15:36, Paolo Cavallini wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  Il 16/04/2013 12:30, Otto Dassau ha scritto:
  Dear Community,
  
  as you can see from the comments on the mailing lists, the ninth
  hackfest in Valmiera was a great success and very well organized by
  the latvian team from SuGIS - Maris Nartiss, Peteris Bruns and
  Raitis Berzins.
  
  Hi all,
  agreed fully; in spite of the logistical challenges of the venue
  (Valmiera is the most remote place we had an hf in), everything went
  very smoothly, and the meeting was by all means a succes - and a real
  pleasure!
  Thanks again Maris, Peteris, and Raitis!
  All the best.
  - --
  Paolo Cavallini - Faunalia
  www.faunalia.eu
  Full contact details at www.faunalia.eu/pc
  Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.12 (GNU/Linux)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
  
  iEYEARECAAYFAlFtReIACgkQ/NedwLUzIr5auACfYCzy3wi06J+65tYMldp2xKYz
  nQQAoKH1I9zny40+piUqw6mwTwcfx2K5
  =J6+z
  -END PGP SIGNATURE-
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer
-- 
Yves Jacolin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


[Qgis-developer] Context help styling

2013-04-21 Thread Chris Crook
Hi

I'm wanting to tidy up some context help, and can't quite figure out where some 
of the styling is coming from, and where would be a good place to put styling 
information if I wanted to.  It looks like it comes from the code

QString myStyle = QgsApplication::reportStyleSheet();
helpContents = headstyle + myStyle + /style/headbody + 
helpContents + /body;
webView-setHtml( helpContents );

The reportStyleSheet() function returns CSS styling for h1 to h5 header levels, 
but not much else.  I replicated this into an external CSS file, and wrote a 
little python script to display the help text in a QWebView.

But it doesn't come out quite the same.  For example the spacing in a pre 
/pre block is different.

So I'm wondering if there is some more styling coming from somewhere I've 
missed, and that I could maybe use?  And if I did want to have some styles for 
spans or paragraphs (eg for code), where should I put them

Thanks
Chris

eg
Python script

#!/usr/bin/python
from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *

with open('context.css') as fcss:
css=fcss.read()
with open('QgsDelimitedTextSourceSelect-en_US') as fhtml:
content=fhtml.read()

html = 'headstyle type=text/css'+css+'/style/headbody'+content
+'/body'

app=QApplication([])
main = QWebView()
main.pageAction(QWebPage.Reload).triggered.connect(reload)
main.setHtml(html)
main.show()
app.exec_()


CSS from QgsApplication

p.glossy{ background-color: qlineargradient(x1:0, y1:0, x2:0, y2:1,
stop: 0
stop: 0.1
stop: 0.5
stop: 0.9
stop: 1 );
color: white;
padding-left: 4px;
padding-top: 20px;
padding-bottom: 8px;
border: 1px solid #6c6c6c;
}
th.glossy{ background-color: qlineargradient(x1:0, y1:0, x2:0, y2:1,
stop: 0
stop: 0.1
stop: 0.5
stop: 0.9
stop: 1 );
color: white;
border: 1px solid #6c6c6c;
}
.overview{ font: 1.82em; font-weight: bold;}
body{  background: white;
  color: black;
  font-family: arial,sans-serif;
}
h1{  background-color: #F6F6F6;
  color: #8FB171;
  font-size: x-large;
  font-weight: normal;
  font-family: luxi serif, georgia, times new roman, times, serif;
  background: none;
  padding: 0.75em 0 0;
  margin: 0;
  line-height: 3em;
}
h2{  background-color: #F6F6F6;
  color: #8FB171;
  font-size: medium;
  font-weight: normal;
  font-family: luxi serif, georgia, times new roman, times, serif;
  background: none;
  padding: 0.75em 0 0;
  margin: 0;
  line-height: 1.1em;
}
h3{  background-color: #F6F6F6;
  color: #729FCF;
  font-family: luxi serif, georgia, times new roman, times, serif;
  font-weight: bold;
  font-size: large;
  text-align: right;
  border-bottom: 5px solid #DCEB5C;
}
h4{  background-color: #F6F6F6;
  color: #729FCF;
  font-family: luxi serif, georgia, times new roman, times, serif;
  font-weight: bold;
  font-size: medium;
  text-align: right;
}
h5{background-color: #F6F6F6;
   color: #729FCF;
   font-family: luxi serif, georgia, times new roman, times, serif;
   font-weight: bold;
   font-size: small;
   text-align: right;
}
a{  color: #729FCF;
  font-family: arial,sans-serif;
  font-size: small;
}
label{  background-color: #CC;
  border: 1px solid black;
  margin: 1px;
  padding: 0px 3px;
  font-size: small;
}






This message contains information, which is confidential and may be subject to 
legal privilege. If you are not the intended recipient, you must not peruse, 
use, disseminate, distribute or copy this message. If you have received this 
message in error, please notify us immediately (Phone 0800 665 463 or 
i...@linz.govt.nz) and destroy the original message. LINZ accepts no 
responsibility for changes to this email, or for any attachments, after its 
transmission from LINZ. Thank You.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


[Qgis-developer] Updating core plugins

2013-04-21 Thread Victor Olaya
Hi all

Having SEXTANTE as a core plugin in QGIS is really great, but I am
worried about how that will affect users when 2.0 is released. My two
main concerns are:

- People currently using SEXTANTE as a non-core plugin will have 2
versions of SEXTANTE installed when they install 2.0. This is likely
to cause strange behaviour, and, as some users have reported on the
mailing list, it seems that the non-core plugin (in this case, the
older version), will override the other one. Not a nice thing... The
solution is to manually uninstall it, but that is going to cause a lot
of confusion...

- I have a few features that will not be ready for 2.0, but I would
like to release them later, just releasing a new versino of SEXTATE
independently. However, I think that core plugins cannot be updated.
Installing the new one separately will cause two version to be
installed...

Any ideas on that? I see that the easiest solution would be to have
something in the plugin manager that, in case of having two versions
of a plugin, would use just the most recent one.

Thanks in advance!
Victor
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Updating core plugins

2013-04-21 Thread Borys Jurgiel
Dnia niedziela, 21 kwietnia 2013 o 23:24:49 Victor Olaya napisał(a):
 Hi all
 
 Having SEXTANTE as a core plugin in QGIS is really great, but I am
 worried about how that will affect users when 2.0 is released. My two
 main concerns are:
 
 - People currently using SEXTANTE as a non-core plugin will have 2
 versions of SEXTANTE installed when they install 2.0. This is likely
 to cause strange behaviour, and, as some users have reported on the
 mailing list, it seems that the non-core plugin (in this case, the
 older version), will override the other one. Not a nice thing... The
 solution is to manually uninstall it, but that is going to cause a lot
 of confusion...

Yes, non-core plugin overrides the core one (just because of the Python path 
order), so the only thing you can do is to make the core SEXTANTE version 
higher - at least QGIS will warn about the override and suggest manual 
uninstall.

But we use the new .qgis2 directory, so I guess we just should tell users to 
not copy the .qgis to .qgis2 thoughtlessly...

In addition, we could prevent QGIS 2.0 from loading uncompatible plugins. The 
repository and the installer assume, that plugins with qgisMinimumVersion==1.x 
are only compatible with 1.x unless it's strictly set by an optional tag 
qgisMaximumVersion (= 2.0). The same behaviour could be implemented for 
loading plugins.

 - I have a few features that will not be ready for 2.0, but I would
 like to release them later, just releasing a new versino of SEXTATE
 independently. However, I think that core plugins cannot be updated.
 Installing the new one separately will cause two version to be
 installed...

Exactly, the base version in core and updates in user directory. The problem 
will be when you release a new version with QGIS 2.1, the updates for 2.0 will 
override the new version. But we can improve the override detection procedure 
for 2.1 (for example, the installer could uninstall the overriding version 
instead of only warning)

 Any ideas on that? I see that the easiest solution would be to have
 something in the plugin manager that, in case of having two versions
 of a plugin, would use just the most recent one.

Or uninstall the overriding plugin, if older. It would be probably more 
elegant solution...


 Thanks in advance!
 Victor
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


[Qgis-developer] sextante: missing GRASS pan sharpening function (i.fusion.brovey)

2013-04-21 Thread Mathieu Pellerin
Victor,

Would it be possible for you to add GRASS' pan sharpening function
(i.fusion.brovey) to sextante? I'm sure that'll make more than one guy
happy :)

Keep up the good work, lots of very nice tweaks to sextante lately.

Math
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] sextante: missing GRASS pan sharpening function (i.fusion.brovey)

2013-04-21 Thread Paolo Cavallini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 22/04/2013 04:31, Mathieu Pellerin ha scritto:
 Victor,
 
 Would it be possible for you to add GRASS' pan sharpening function
 (i.fusion.brovey) to sextante? I'm sure that'll make more than one guy
 happy :)
 
 Keep up the good work, lots of very nice tweaks to sextante lately.

Hi Mathieu,
please have a look to:
https://github.com/qgis/Quantum-GIS/blob/master/python/plugins/sextante/grass/grass.txt
It is reasonably easy to add command yourself. If successful, you can send the 
file
to Victor, or better issue a pull request for it.
Thanks!
- -- 
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlF0xD0ACgkQ/NedwLUzIr7eQACeNZp1Zb7N+3CqsUZmDz0YKCBG
b1QAnRZX645dJOGRIhZYwlfzPy/CU8aO
=7wPK
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Updating core plugins

2013-04-21 Thread Paolo Cavallini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 22/04/2013 00:02, Borys Jurgiel ha scritto:

 Or uninstall the overriding plugin, if older. It would be probably more 
 elegant solution...

Or notify the user, and asking Do you want to remove the older version you 
installed
previously?.
All the best.

- -- 
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlF0yAoACgkQ/NedwLUzIr7FTgCdHCG0gMGy/2+7ogar07KadEoT
YyAAnizjXyG47bjvsfAg2ppow3e9wl1w
=uTKs
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Sextante test drive

2013-04-21 Thread Paolo Cavallini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 21/04/2013 15:39, Victor Olaya ha scritto:

 Also, now there are autoconfig paths for SAGA, GRASS and OTB in
 Windows, so if a user installs QGIS with the OSGeo4W installer, there
 should nbe no need for extra configuration, and  he could start using
 all algorithms directly in an out-of-the-box QGIS install.

Thank you.
It would be nice if you could announce it to the users ML, so we could make it 
sure
this work in all local settings.
All the best.

- -- 
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlF0ywgACgkQ/NedwLUzIr40SQCfS5yB/5sl0BvZ+uq2cWsmUcwF
Bh4AoLmh+DtMU8uSKlvRy6gPOgI8X6qr
=SYDx
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer