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

[Nathan Woodrow]

Hey all,

The logo comp has now moved into the final rounds and we have to pick at
winner out the designers left. The designs there are not final yet and I
will be giving feedback to the designers to iterate their designs into
something that we like. I have updated the design brief to include the
community aspect and that it must also work as a desktop icon.

I have just sent of an email to 99designs to get the final round extended
by another 7 days in order to collect more designs and have time for people
to view and comment.   If there are any variations of the designs. or a new
direction, please post it here and I will update the comp with those
details.

The round with the designs is here
http://99designs.com.au/logo-design/contests/qgis-needs-logo-210397.

REMEMBER: These designs are not final until the last minute so we must get
feedback to the designers if we would like to see something different.

Regards,
Nathan


On Sun, Apr 21, 2013 at 6:11 AM, Tim Sutton  wrote:

> Hi
>
>
> On Sat, Apr 20, 2013 at 11:41 PM, Anita Graser  wrote:
>
>> Hi,
>>
>> http://99designs.com/logo-**design/contests/qgis-needs-**
>> logo-210397/entries/267
>>
>> is a little too similar to
>>
>> http://www.laudontech.com/
>
>
> Hmm you are right. Its a pity as that was my favourite.
>
> T
>
>
>>
>>
>> for my taste.
>>
>> Best wishes,
>> Anita
>>
>> __**_
>> Qgis-psc mailing list
>> qgis-...@lists.osgeo.org
>> http://lists.osgeo.org/**mailman/listinfo/qgis-psc
>>
>
>
>
> --
> Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
> ==
> Visit http://linfiniti.com to find out about:
>  * QGIS programming services
>  * GeoDjango web development
>  * FOSS Consulting Services
> Skype: timlinux Irc: timlinux on #qgis at freenode.net
> ==
>
> ___
> Qgis-psc mailing list
> qgis-...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Make QGIS interact with LibreCAD.

[Bernhard Ströbl]

Hi all,

I personally would prefer two plugins, one with CAD-like functions 
(constructing, snap to middle of line etc.) and one with more GIS-like 
editing functions (clip, fill holes and the like). If you look at the 
current CAD-Tools plugin it is already pretty crowded but we are talking 
about at least the double amount of functions.
Implementing the plugins in Python could create more support in 
programming from the community (I have no idea about performance, though).


my 2ct

Bernhard

Am 24.04.2013 16:37, schrieb Antonio Locandro:

Would it be possible as a first interaction if all the CAD/Drawing tools
be merged into a single plugin so the plugin library be less crowded and
we knew exactly what tools are available?

I disagree that some users wont be interested in this tools, some users
are just doing analysis and that is fine but to be able to perform
analysis and models you sometimes have to create the data, having the
tools to create the data is part of every COTS GIS software and it
should be part of QGIS. Of course if a user is just doing analysis he
would just hide the tools

**Antonio Locandro

From: olivier.dal...@gmail.com
Date: Wed, 24 Apr 2013 12:57:03 +
To: a.neum...@carto.net
CC: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Make QGIS interact with LibreCAD.

2013/4/22 Andreas Neumann mailto:a.neum...@carto.net>>

I would prefer if most of the editing tools would be available in core
- - and if possible - implemented in C++.


I'm not sure if I agree with that : getting a snapping engine that works
smoothly will require a lot of tweaking, which is a pain in C++ compared
to python.

Also, some user will be interested in adapting the snapping engine to
suit their particular habits, which is easy when working with python
plugins. And some other users won't be interested at all in this kind of
tools.

About the problem of installing multiple plugins : it would of course be
much more elegant if all the CAD-drawing related tools were neatly
packed in one plugin, which could then even be preinstalled or "featured".



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


__ Information from ESET Mail Security, version of virus
signature database 8262 (20130424) __

The message was checked by ESET Mail Security.
http://www.eset.com


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



__ Information from ESET Mail Security, version of virus signature 
database 8262 (20130424) __

The message was checked by ESET Mail Security.
http://www.eset.com




__ Information from ESET Mail Security, version of virus signature 
database 8263 (20130424) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

Re: [Qgis-developer] valuetool plugin but with average value by radius ?

[Denis Rouzaud]

It is already ;)

http://plugins.qgis.org/plugins/landit/

But it's for QGIS >= 1.9

Right now it's only working for one band raster. I needed it and could 
not spend much more time on it.

I might push a new version handling multi band rasters.

Cheers,

Denis


On 04/24/2013 07:46 PM, Paolo Cavallini wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 24/04/2013 14:43, Denis Rouzaud ha scritto:


I have done something similar for landit plugin (DTM values).

There is three methods: nearest, linear and bicubic interpolations.

You can found the the code here
https://github.com/3nids/landit/blob/master/elevationdialog.py#L120

Quite nice, thanks! Why not adding it to plugins.qgis.org?
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/

iEYEARECAAYFAlF4GoQACgkQ/NedwLUzIr7+8wCaAjMUYnDRxJOfLO0avLhGV2k6
f5AAoKpX+5WyZq8QN67fXxv1JYGk3uDw
=3+vN
-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] Sextante test drive

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 25/04/2013 04:07, William Kyngesburye ha scritto:

> Simplicity for me and ease of use for users.

Agreed: for "real" users, installing >1 package, having to deal with paths, 
different
versions, and possible incompatibilities, can be a significant hindrance, often 
a
blocker.
The easier the better.
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/

iEYEARECAAYFAlF4wEIACgkQ/NedwLUzIr6AKACdF67kJ40aPF+/uW8nTkGY5kdZ
8DYAn0O4VYzG9ANatX0yc3k5t9wiX+Xl
=JGTG
-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

[William Kyngesburye]

On Apr 24, 2013, at 1:31 PM, Larry Shaffer wrote:

> Hi William,
> 
> On Sat, Apr 20, 2013 at 9:24 AM, William Kyngesburye  
> wrote:
> Just a note: I'll be bundling OTB and SAGA in the OS X package.  I already 
> have code in sextante to automatically find the bundled copies.
> 
> Why bundle instead of having a separate installer (like is done with the base 
> GDAL frameworks, etc.)? Same question for the osg/earth frameworks.
> 
Simplicity for me and ease of use for users.  My general plan has been separate 
packages for stuff (GDAL & co.) needed by multiple other end-user packages 
(GRASS, Mapserver, QGIS).  And maybe for tools useful on their own (python 
modules, and yes, could be SAGA, OTB, TauDEM), if I have time.  And a little 
bit of whatever I feel like doing factors in there also ;)

I did consider an OSG/earth package, but never got around to it.  QGIS is the 
only thing I use that needs it, though I was briefly interested in OSSIM, and 
there were small build issues early on (now sorted out).

> Also, when you get things situated for the release and you have time, I would 
> appreciate any build notes, so I can add such support to the nightly build.
> 
The main thing is a user bundling cmake script for SAGA, OTB and TauDEM.

Do you need any build info for those?  OTB isn't hard, just a simple patch.  
SAGA is a bit of work because of missing autotools in the latest Xcode, and it 
needs wxWidgets.  TauDEM needs some work, a few of us are in communication with 
the developer to fix it up.


> Regards,
> 
> Larry
> 
>  
> Maybe I'll look again at Taudem.  I think when I looked at it a year ago I 
> was put off by Windows/Arc-centric nature of it.  ... ugh, just a quick 
> browse of the source doesn't look good - mix of windows and unix line endings 
> in some files needs to be fixed (maybe the compiler doesn't care, but it's 
> hard to read), and assumption of available headers/libraries, like MPI.  This 
> may not be an option for OS X, at least in the near future.  It's also 
> disappointing that the author didn't use libtiff, so that taudem could 
> support lzw compression and bigtiff.
> 

-
William Kyngesburye 
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect


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

Re: [Qgis-developer] 'File' versus 'Project'

[Ramon Andiñach]

On 25/04/2013, at 02:59 , John C. Tull wrote:

> Hi Larry,
> 
> On Apr 24, 2013, at 10:09 AM, Larry Shaffer  wrote:
> 
>> Hi,
>> 
>> On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull  wrote:
>> Hi Antonio,
>> 
>> I think it is more about having consistency for the platform than anything 
>> else. We want the user to find the application familiar. The death-knell of 
>> many an OS X application on review sites is how non-Mac-like the application 
>> feels. Users expect the menubar to exist and to provide a means of 
>> navigating standard application operations.
>> 
>> Developers will provide their own customization in different formats. 
>> Microsoft Office has their "ribbon" interface that provides "organized" 
>> drop-downs and formatting elements outside of the menubar, but you are able 
>> to do most of the same stuff by navigating the menus and options therein.
>> http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png
>> 
>> I think we can achieve the customization desired while maintaining the HIG 
>> for OSX.
>> 
>> Ignoring the other suggestions for a moment, changing the File menu name to 
>> Project (or Composer) does not go against the HIG for OS X (the initial 
>> discussion of this thread). This has be established. It does affect user 
>> expectations, however.
>> 
> 
> 
> I think this is debatable. Per our irc conversation yesterday, there are 
> semantics to what constitutes a document-basis for a program versus a 
> non-document basis. My understanding of the exception in the HIG is that a 
> program that does not have a document that the program operates on can 
> consider removing or renaming the File menu item. From the HIG [0]:
> 
> "In general, each command in the File menu applies to a single file (most 
> commonly, a user-created document). If your app is not document-based, you 
> can rename the File menu to something more appropriate or eliminate it."
> 
> I consider a map project to be a document, whether it is based off of a 
> physical file, *.qgs, as it currently does or whether it is a record in a db, 
> a possible feature for the future of QGIS. I don't see the wiggle room on the 
> HIG for QGIS consequently.

True enough.
It'll look a little odd.
It's not going to be quite expected.

I'll even agree that a project file is a document of a sort.

But GIS programmes, particularly the way QGIS thinks about things use at least 
3 different sorts of documents. In this case, Project files, vector files, 
raster files, then arguably database files and web service files. The menu has 
them lumped up as File (or Project) and Layers[1].

I think while it will be odd for about 30 seconds, it will make sense and most 
people will be happy.

-ramon.
(with apologies for side tracking everyone)

[1] I suppose I've always felt a bit odd about the use of File in QGIS's menus 
because I might touch that once a session, but the vast majority of the files 
(documents) I use come in through the Layers menu. Doesn't make a great deal of 
sense to me but such is life.
If we're allowed to rename it to something that better reflects the content, 
then shouldn't that happen?
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Decorations on the View Menu

[Antonio Locandro]

Ok I see the use cases, Thanks for the reply 
 
Ing. Antonio Locandro

 > From: li...@linfiniti.com
> Date: Thu, 25 Apr 2013 00:37:51 +0400
> Subject: Re: [Qgis-developer] Decorations on the View Menu
> To: antoniolocan...@hotmail.com
> CC: qgis-developer@lists.osgeo.org
> 
> Hi
> 
> On Wed, Apr 24, 2013 at 8:16 PM, Antonio Locandro
>  wrote:
> > I just tried this feature and my impression is why is this enabled on the
> > canvas view? This features are more suitable for the composer and having two
> > ways to achieve something is not always a good thing. You can control in a
> > better way how things look in the composer anyway. For me it doesn't make
> > sense to have this enabled in the Canvas
> 
> Having scale (scalebar) and distance (via grid) is handy when panning
> around in the map view, taking application screenshots, screencasts,
> exporting the canvas as an image etc. These features are disabled by
> default so they should not cause you any interference if you don't
> want to use them. The copyright decoration functionality could
> probably be replaced by current map annotations implementation I
> guess...
> 
> Regards
> 
> Tim
> 
> >
> >  Ing. Antonio Locandro
> > Tegucigalpa, Honduras
> >
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> 
> 
> 
> --
> Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
> ==
> Please do not email me off-list with technical
> support questions. Using the lists will gain
> more exposure for your issues and the knowledge
> surrounding your issue will be shared with all.
> 
> Visit http://linfiniti.com to find out about:
>  * QGIS programming and support services
>  * Mapserver and PostGIS based hosting plans
>  * FOSS Consulting Services
> Skype: timlinux
> Irc: timlinux on #qgis at freenode.net
> ==
  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 'File' versus 'Project'

[Nathan Woodrow]

As much as HIGs are good they are guidelines at best, they are not meant to
tell everyone what to do in every case all the time. Apple, MS, etc don't
even follow their own HIGs. If I was proposing to change the colour and
style of all the whole interface to red with pink borders and use fully
custom widgets then I would say sure follow the HIG and scrap the idea.
However changing File -> Project was like changing File -> Composer in the
print composer,  it was a bit of a "ohh there is no file menu" but people
handled it fine and no one complained.  I would say the composer even feels
better now from a UX point of view because that first menu is named after
the thing it takes action against.

I ran a workshop the other day with some new users, and lots of existing
users, all who had only just installed 2.0 for the first time and none
freaked out.  The menu will only take people two seconds to see and notice
that it's the same stuff that is in File and move on with their work.

Regards,
Nathan


On Thu, Apr 25, 2013 at 4:59 AM, John C. Tull  wrote:

> Hi Larry,
>
> On Apr 24, 2013, at 10:09 AM, Larry Shaffer 
> wrote:
>
> Hi,
>
> On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull  wrote:
>
>> Hi Antonio,
>>
>> I think it is more about having consistency for the platform than
>> anything else. We want the user to find the application familiar. The
>> death-knell of many an OS X application on review sites is how non-Mac-like
>> the application feels. Users expect the menubar to exist and to provide a
>> means of navigating standard application operations.
>>
>> Developers will provide their own customization in different formats.
>> Microsoft Office has their "ribbon" interface that provides "organized"
>> drop-downs and formatting elements outside of the menubar, but you are able
>> to do most of the same stuff by navigating the menus and options therein.
>>
>> http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png
>>
>> I think we can achieve the customization desired while maintaining the
>> HIG for OSX.
>>
>
> Ignoring the other suggestions for a moment, changing the File menu name
> to Project (or Composer) does not go against the HIG for OS X (the initial
> discussion of this thread). This has be established. It does affect user
> expectations, however.
>
>
>
> I think this is debatable. Per our irc conversation yesterday, there are
> semantics to what constitutes a document-basis for a program versus a
> non-document basis. My understanding of the exception in the HIG is that a
> program that does not have a document that the program operates on can
> consider removing or renaming the File menu item. From the HIG [0]:
>
> "In general, each command in the File menu applies to a single file (most
> commonly, a user-created document). If your app is not document-based, you
> can rename the File menu to something more appropriate or eliminate it."
>
> I consider a map project to be a document, whether it is based off of a
> physical file, *.qgs, as it currently does or whether it is a record in a
> db, a possible feature for the future of QGIS. I don't see the wiggle room
> on the HIG for QGIS consequently.
>
> Regards,
> John
>
> [0]
> https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Menus/Menus.html#//apple_ref/doc/uid/TP3356-TP6
>
> ___
> 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] Decorations on the View Menu

[Tim Sutton]

Hi

On Wed, Apr 24, 2013 at 8:16 PM, Antonio Locandro
 wrote:
> I just tried this feature and my impression is why is this enabled on the
> canvas view? This features are more suitable for the composer and having two
> ways to achieve something is not always a good thing. You can control in a
> better way how things look in the composer anyway. For me it doesn't make
> sense to have this enabled in the Canvas

Having scale (scalebar) and distance (via grid) is handy when panning
around in the map view, taking application screenshots, screencasts,
exporting the canvas as an image etc. These features are disabled by
default so they should not cause you any interference if you don't
want to use them. The copyright decoration functionality could
probably be replaced by current map annotations implementation I
guess...

Regards

Tim

>
>  Ing. Antonio Locandro
> Tegucigalpa, Honduras
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



--
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Visit http://linfiniti.com to find out about:
 * QGIS programming and support services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
==
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 'File' versus 'Project'

[John C. Tull]

Hi Larry,

On Apr 24, 2013, at 10:09 AM, Larry Shaffer  wrote:

> Hi,
> 
> On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull  wrote:
> Hi Antonio,
> 
> I think it is more about having consistency for the platform than anything 
> else. We want the user to find the application familiar. The death-knell of 
> many an OS X application on review sites is how non-Mac-like the application 
> feels. Users expect the menubar to exist and to provide a means of navigating 
> standard application operations.
> 
> Developers will provide their own customization in different formats. 
> Microsoft Office has their "ribbon" interface that provides "organized" 
> drop-downs and formatting elements outside of the menubar, but you are able 
> to do most of the same stuff by navigating the menus and options therein.
> http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png
> 
> I think we can achieve the customization desired while maintaining the HIG 
> for OSX.
> 
> Ignoring the other suggestions for a moment, changing the File menu name to 
> Project (or Composer) does not go against the HIG for OS X (the initial 
> discussion of this thread). This has be established. It does affect user 
> expectations, however.
> 


I think this is debatable. Per our irc conversation yesterday, there are 
semantics to what constitutes a document-basis for a program versus a 
non-document basis. My understanding of the exception in the HIG is that a 
program that does not have a document that the program operates on can consider 
removing or renaming the File menu item. From the HIG [0]:

"In general, each command in the File menu applies to a single file (most 
commonly, a user-created document). If your app is not document-based, you can 
rename the File menu to something more appropriate or eliminate it."

I consider a map project to be a document, whether it is based off of a 
physical file, *.qgs, as it currently does or whether it is a record in a db, a 
possible feature for the future of QGIS. I don't see the wiggle room on the HIG 
for QGIS consequently.

Regards,
John

[0] 
https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Menus/Menus.html#//apple_ref/doc/uid/TP3356-TP6___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Sextante test drive

[Larry Shaffer]

Hi William,

On Sat, Apr 20, 2013 at 9:24 AM, William Kyngesburye
wrote:

> Just a note: I'll be bundling OTB and SAGA in the OS X package.  I already
> have code in sextante to automatically find the bundled copies.
>

Why bundle instead of having a separate installer (like is done with the
base GDAL frameworks, etc.)? Same question for the osg/earth frameworks.

Also, when you get things situated for the release and you have time, I
would appreciate any build notes, so I can add such support to the nightly
build.

Regards,

Larry



> Maybe I'll look again at Taudem.  I think when I looked at it a year ago I
> was put off by Windows/Arc-centric nature of it.  ... ugh, just a quick
> browse of the source doesn't look good - mix of windows and unix line
> endings in some files needs to be fixed (maybe the compiler doesn't care,
> but it's hard to read), and assumption of available headers/libraries, like
> MPI.  This may not be an option for OS X, at least in the near future.
>  It's also disappointing that the author didn't use libtiff, so that taudem
> could support lzw compression and bigtiff.
>
> On Apr 20, 2013, at 3:52 AM, Victor Olaya wrote:
>
> >> * 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
> >
> > I have been thinking about changing all the options dialog. Doesn't
> > look hard to do, so you can count on having this ready soon
> >
> >> * 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
> >
> > It's limited now for two reasons:
> >   1) The classification of algorithms is done manually...and it is
> > boring to do :-) SAGA and QGIS ones are already done, but I have
> > to do the GRASS ones. However I am not sure about including GRASS, it
> > is more complex to use. You can use a SAGA algorithm without knowing
> > what SAGA is, but to use a GRASS one, you need to understand some
> > GRASS ideas, so it is an advanced process, and the simplified
> > algorithm classification shouldn't assume that. You can always change
> > to the advanced view to use GRASS (now you can change directly from
> > the toolbox, no need to go to the config dialog)
> >   2) I would like to have in that list, only those algorithms that
> > need no extra configuration, to make that the default and have it
> > working out-of the box. That's why R and OTB, for instance, are not in
> > there.
> >
> >> * 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
> >
> > good idea. If OTB goes into osgeo4w, I could add the OTB algorithms to
> > the simplified list of algorithms
> >
> > I still have to send Jurgen the SAGA package as we discussed it in the
> > Hackfest. We can put both SAGA and OTB, and taht would really give a
> > lot of power to SEXTANTE
> >
> > Thanks for your ideas!
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
>
> "History is an illusion caused by the passage of time, and time is an
> illusion caused by the passage of history."
>
> - Hitchhiker's Guide to the Galaxy
>
>
> ___
> 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] 'File' versus 'Project'

[Tim Sutton]

Hi


On Wed, Apr 24, 2013 at 8:10 PM, Antonio Locandro <
antoniolocan...@hotmail.com> wrote:

> I am having a second look at the menus and can I ask why would you want to
> crowd the menus with the same actions you already have icons for in
> toolbars?
>
> e.g.
>
> Edit menu has all the same tools as the Advanced Editing Toolbar (I highly
> doubt users doing serious editing would use menus instead of icons)
> Layer menu has all this add layer types the same as Manage Layer Toolbar
> (would look better with just an icon that opens a file dialog to whatever
> data you need, an universal add data button type)
>
> IMHO it seems a waste of space and makes things crowded
>
>
This is frowned apon by HIG folks - all tool buttons etc should be
accessible by menus as far as possible - a user may have disabled a
toolbar, may have accessibility software that uses the menu system to
activate functionality etc. In short adding a toolbar button should never
be an excuse for removing a menu item.

Regards

Tim


> **
> **
> *Ing. Antonio Locandro*
> Tegucigalpa, Honduras
> +504 9503 5747
> Need a GPS map for Central America, Asia or South America / Necesitas un
> mapa GPS para Centro America, Asia o Sur 
> America
>  
>
>
>
> --
> From: madman...@gmail.com
> Date: Wed, 24 Apr 2013 21:07:58 +1000
> To: cust...@westnet.com.au
>
> CC: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] 'File' versus 'Project'
>
> Ramon,
>
> I would agree with those points. In fact I think the menu structure as is
> doesn't make much sense and the Edit menu should be renamed to Feature/s.
>
> What does Edit mean:
>
>  - Edit Layer
>  - Edit Feature
>  - Edit Project
>
> If you look at all the tools in the Edit menu they are all related to the
> current feature or features.  The undo and redo actions should be moved to
> the layer menu.
>
> Here are my thoughts on the Layer menu:
>
> http://i.imgur.com/oYO55Qz.png
>
> Moving the Add xxx Layer to the project menu would mean you follow these
> actions when creating a new project:
>
> Project -> New
> Project -> Add xxx Layer
>
> Change the style
>
> Layer -> Properties
>
> That is a more logical flow IMO then currently what is there.
>
> Thoughts?
>
> - Nathan
>
>
> On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach wrote:
>
>
> On 24/04/2013, at 05:55 , Ramon Andiñach wrote:
>
> >
> > On 24/04/2013, at 04:28 , John C. Tull wrote:
> >
> >> Hi all,
> >>
> >> I was having some discussion on IRC today with Tim and Larry about the
> recent change to the menu in trunk. Before, the menu used "File" and that
> was changed to "Project". My position is that it does not seem Mac-like,
> whether or not a QGIS document resides in the filesystem as a .qgs file or
> if your "Project" is fed from a database, something apparently planned for
> the future of QGIS.
> >>
> >> I'd be interested in feedback from other Mac users on this. I'm
> flexible to the change, but wanted to vet this and see if anyone else had a
> strong opinion one way or the other. Please make it clear if you are a Mac
> OS X user or not.
> >>
> >> Thanks,
> >> John
> >
> > Interesting. I'd say this is going to look as odd at home on my mac as
> at work on their windows box. No file menu - that's going to look very
> unfamiliar.
> >
> > That said, it's a good name. It does describe what's in there - those
> commands work on the project-file not a layer-file.
> >
> > -ramon.
>
> Ok. I've been standing at the bottom of a large-ish hole today, so if this
> sounds like a dumb idea that's my excuse.
>
> Could we move Layer across next to Project?
>
>
> Some reasoning.
> 1. If we're abandoning File in favour of Project, then there's possibly no
> reason to retain Edit next to it either. Other than historical ones.
> 2. Project and Layer are largely about opening, closing, saving (and other
> similar things) files. Project files in one menu and Layers (vectors,
> rasters, DB, etc) in the other.
> 3. Then you have a more logical progression from left to right about how
> to use QGIS. (Open stuff, change stuff)
>
> -ramon.
> (OK, 1. is not so good, but it does open the door to ask questions!)
>
> ___
> 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
>
>


-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for

Re: [Qgis-developer] valuetool plugin but with average value by radius ?

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 24/04/2013 14:43, Denis Rouzaud ha scritto:

> I have done something similar for landit plugin (DTM values).
> 
> There is three methods: nearest, linear and bicubic interpolations.
> 
> You can found the the code here
> https://github.com/3nids/landit/blob/master/elevationdialog.py#L120

Quite nice, thanks! Why not adding it to plugins.qgis.org?
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/

iEYEARECAAYFAlF4GoQACgkQ/NedwLUzIr7+8wCaAjMUYnDRxJOfLO0avLhGV2k6
f5AAoKpX+5WyZq8QN67fXxv1JYGk3uDw
=3+vN
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 'File' versus 'Project'

[Larry Shaffer]

Hi,

On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull  wrote:

> Hi Antonio,
>
> I think it is more about having consistency for the platform than anything
> else. We want the user to find the application familiar. The death-knell of
> many an OS X application on review sites is how non-Mac-like the
> application feels. Users expect the menubar to exist and to provide a means
> of navigating standard application operations.
>
> Developers will provide their own customization in different formats.
> Microsoft Office has their "ribbon" interface that provides "organized"
> drop-downs and formatting elements outside of the menubar, but you are able
> to do most of the same stuff by navigating the menus and options therein.
>
> http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png
>
> I think we can achieve the customization desired while maintaining the HIG
> for OSX.
>

Ignoring the other suggestions for a moment, changing the File menu name to
Project (or Composer) does not go against the HIG for OS X (the initial
discussion of this thread). This has be established. It does affect user
expectations, however.


> Cheers,
> John
>
> snip ---8< -
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 'File' versus 'Project'

[John C. Tull]

Hi Larry,

On Apr 24, 2013, at 9:46 AM, Larry Shaffer  wrote:

> As a separate suggestion: if we wanted to minimize our menus better and 
> prepare for unknown future functionality grouping and expansion, we could 
> create a Tools main menu, which could have Vector, Raster, Database and 
> Analysis submenus. This would make room for a Feature main menu, for example, 
> and allow future growth within Tools without forcing yet more horizontal 
> growth of the menubar. Downside is that it adds an extra layer of submenu 
> mousing to get to commonly used actions.
> 

+1

This would help with the problem of the Analysis menu item showing up between 
the Window and Help menu items. I've often felt that a more consolidated 
approach like you describe would be much better. And we have the ability to 
customize all menu item functionality with custom shortcuts, so those that 
don't like the extra clicks can work around that by creating shortcuts.

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

Re: [Qgis-developer] 'File' versus 'Project'

[John C. Tull]

Hi Antonio,

I think it is more about having consistency for the platform than anything 
else. We want the user to find the application familiar. The death-knell of 
many an OS X application on review sites is how non-Mac-like the application 
feels. Users expect the menubar to exist and to provide a means of navigating 
standard application operations.

Developers will provide their own customization in different formats. Microsoft 
Office has their "ribbon" interface that provides "organized" drop-downs and 
formatting elements outside of the menubar, but you are able to do most of the 
same stuff by navigating the menus and options therein.
http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png

I think we can achieve the customization desired while maintaining the HIG for 
OSX.

Cheers,
John

On Apr 24, 2013, at 9:10 AM, Antonio Locandro  
wrote:

> I am having a second look at the menus and can I ask why would you want to 
> crowd the menus with the same actions you already have icons for in toolbars?
>  
> e.g. 
>  
> Edit menu has all the same tools as the Advanced Editing Toolbar (I highly 
> doubt users doing serious editing would use menus instead of icons)
> Layer menu has all this add layer types the same as Manage Layer Toolbar 
> (would look better with just an icon that opens a file dialog to whatever 
> data you need, an universal add data button type)
>  
> IMHO it seems a waste of space and makes things crowded 
> 
>  
>  
> Ing. Antonio Locandro
> Tegucigalpa, Honduras
> +504 9503 5747
> Need a GPS map for Central America, Asia or South America / Necesitas un mapa 
> GPS para Centro America, Asia o Sur America
> 
> 
> 
>  
> From: madman...@gmail.com
> Date: Wed, 24 Apr 2013 21:07:58 +1000
> To: cust...@westnet.com.au
> CC: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] 'File' versus 'Project'
> 
> Ramon,
> 
> I would agree with those points. In fact I think the menu structure as is 
> doesn't make much sense and the Edit menu should be renamed to Feature/s.  
> 
> What does Edit mean:
> 
>  - Edit Layer
>  - Edit Feature
>  - Edit Project
> 
> If you look at all the tools in the Edit menu they are all related to the 
> current feature or features.  The undo and redo actions should be moved to 
> the layer menu.
> 
> Here are my thoughts on the Layer menu:
> 
> http://i.imgur.com/oYO55Qz.png
> 
> Moving the Add xxx Layer to the project menu would mean you follow these 
> actions when creating a new project:
> 
> Project -> New
> Project -> Add xxx Layer
> 
> Change the style
> 
> Layer -> Properties
> 
> That is a more logical flow IMO then currently what is there.
> 
> Thoughts?
> 
> - Nathan
> 
> 
> On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach  
> wrote:
> 
> On 24/04/2013, at 05:55 , Ramon Andiñach wrote:
> 
> >
> > On 24/04/2013, at 04:28 , John C. Tull wrote:
> >
> >> Hi all,
> >>
> >> I was having some discussion on IRC today with Tim and Larry about the 
> >> recent change to the menu in trunk. Before, the menu used "File" and that 
> >> was changed to "Project". My position is that it does not seem Mac-like, 
> >> whether or not a QGIS document resides in the filesystem as a .qgs file or 
> >> if your "Project" is fed from a database, something apparently planned for 
> >> the future of QGIS.
> >>
> >> I'd be interested in feedback from other Mac users on this. I'm flexible 
> >> to the change, but wanted to vet this and see if anyone else had a strong 
> >> opinion one way or the other. Please make it clear if you are a Mac OS X 
> >> user or not.
> >>
> >> Thanks,
> >> John
> >
> > Interesting. I'd say this is going to look as odd at home on my mac as at 
> > work on their windows box. No file menu - that's going to look very 
> > unfamiliar.
> >
> > That said, it's a good name. It does describe what's in there - those 
> > commands work on the project-file not a layer-file.
> >
> > -ramon.
> 
> Ok. I've been standing at the bottom of a large-ish hole today, so if this 
> sounds like a dumb idea that's my excuse.
> 
> Could we move Layer across next to Project?
> 
> 
> Some reasoning.
> 1. If we're abandoning File in favour of Project, then there's possibly no 
> reason to retain Edit next to it either. Other than historical ones.
> 2. Project and Layer are largely about opening, closing, saving (and other 
> similar things) files. Project files in one menu and Layers (vectors, 
> rasters, DB, etc) in the other.
> 3. Then you have a more logical progression from left to right about how to 
> use QGIS. (Open stuff, change stuff)
> 
> -ramon.
> (OK, 1. is not so good, but it does open the door to ask questions!)
> 
> ___
> 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/mai

Re: [Qgis-developer] 'File' versus 'Project'

[Larry Shaffer]

Oops,

links for last post:

[0]
https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/art/mn_dualtoggleditems.jpg
[1] http://drive.dakotacarto.com/qgis/layer_datasource_submenu.png

Larry

On Wed, Apr 24, 2013 at 10:46 AM, Larry Shaffer wrote:

> Hi,
>
> On Wed, Apr 24, 2013 at 9:24 AM, Nathan Woodrow wrote:
>
>> William,
>>
>> I can understand the concern, it was the same thing that went though my
>> mind when I change the composer menu. In the end most people didn't care,
>> or adapted.   There are a lot of applications that don't use a file menu
>> and work quite well, I would say better in fact.
>>
>> http://i.imgur.com/t0QZeJK.png Chrome and Firefox
>>
>> http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg
>>  AutoCAD
>>
>> Regarding the Edit menu, you will notice that the tools in there are not
>> related to text or documents they only refer to the current feature, or
>> selection of features.  If you have a dialog open you can't use that menu,
>> unless the dialog is non model and in that case still doesn't help you as
>> there are no tools to use on text.
>>
>> If the Edit menu is to stay, that is fine however I would suggest a new
>> menu called Feature/s which houses all the current tools in the edit menu
>> minus the Undo/Redo and Copy/Paste Feature.
>>
>
> While the Mac HIG clearly states that changing the name of the File menu,
> or removing the File menu, is fine, the following are definitely not a good
> idea in my opinion:
>
> * Having anything except Edit to the right of File/Project
> That would not only be unconventional and confusing to users, it gains
> very little compared to the significance of the change. IMO it should
> absolutely be avoided. Clearly the Mac convention here is to have File,
> Edit, [View], [Main Component], [Lesser Component], etc. (older Mac
> conventions had View more towards right end of bar) This is shown in
> Apple's Mail program [0], where the main component is a mailbox and the
> lesser a message. In Photoshop it is: File, Edit, Image, Layer...
> Following these conventions any Feature menu should be located just right
> of the Layer menu, and the Layer menu just right of Edit or View.
>
> * Moving Layer items into Project menu
> While using almost all Mac software the File menu is visited only when
> initiating, saving, exporting, printing, or ending a work session,
> regardless of whether it is file-based in nature. While working within the
> session, almost always component menus are used. For example, a similar
> layer-based program, Photoshop, places all it layer-related actions under
> the Layer menu, not the Image menu. IMO the Layer menu actions should stay
> where they are
>
> However, the menu could be cleaned up a bit. Having a submenu for adding
> data sources, and sub-grouping by type with separators, will allow growth
> of the submenu without cluttering the main Layer menu [1].
>
> * Moving editing function out of Edit menu
> The main editing currently done in QGIS is on features, aka 'Digitizing'
> for the toolbar, so it is logical for those editing functions to be under
> the Edit menu. I agree with William in that undo/redo should always be
> located there, as well as copy/cut/paste and delete functions. Currently
> copy/cut/paste refers to only 'features,' which makes no sense if you are
> not editing features. Those should be generic and only be Copy/Cut/Paste
> and Delete or Clear, or be dynamic and change relative to what is being
> edited (that would be more work, though).
>
> So, maybe there should be a Digitizing submenu under Edit. Other items
> that programs commonly place under the Edit menu (some not currently
> implemented in QGIS) are spell-checking, text manipulations (upper, lower,
> etc.), special character inserts, select functions (currently under View),
> find/search functions, and others. So there is functionally room to grow in
> that menu, outside of just feature editing actions, i.e. Edit menu should
> not be considered for removal.
>
>
> As a separate suggestion: if we wanted to minimize our menus better and
> prepare for unknown future functionality grouping and expansion, we could
> create a Tools main menu, which could have Vector, Raster, Database and
> Analysis submenus. This would make room for a Feature main menu, for
> example, and allow future growth within Tools without forcing yet more
> horizontal growth of the menubar. Downside is that it adds an extra layer
> of submenu mousing to get to commonly used actions.
>
> Regards,
>
> Larry
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 'File' versus 'Project'

[Larry Shaffer]

Hi,

On Wed, Apr 24, 2013 at 9:24 AM, Nathan Woodrow  wrote:

> William,
>
> I can understand the concern, it was the same thing that went though my
> mind when I change the composer menu. In the end most people didn't care,
> or adapted.   There are a lot of applications that don't use a file menu
> and work quite well, I would say better in fact.
>
> http://i.imgur.com/t0QZeJK.png Chrome and Firefox
>
> http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg
>  AutoCAD
>
> Regarding the Edit menu, you will notice that the tools in there are not
> related to text or documents they only refer to the current feature, or
> selection of features.  If you have a dialog open you can't use that menu,
> unless the dialog is non model and in that case still doesn't help you as
> there are no tools to use on text.
>
> If the Edit menu is to stay, that is fine however I would suggest a new
> menu called Feature/s which houses all the current tools in the edit menu
> minus the Undo/Redo and Copy/Paste Feature.
>

While the Mac HIG clearly states that changing the name of the File menu,
or removing the File menu, is fine, the following are definitely not a good
idea in my opinion:

* Having anything except Edit to the right of File/Project
That would not only be unconventional and confusing to users, it gains very
little compared to the significance of the change. IMO it should absolutely
be avoided. Clearly the Mac convention here is to have File, Edit, [View],
[Main Component], [Lesser Component], etc. (older Mac conventions had View
more towards right end of bar) This is shown in Apple's Mail program [0],
where the main component is a mailbox and the lesser a message. In
Photoshop it is: File, Edit, Image, Layer...  Following these conventions
any Feature menu should be located just right of the Layer menu, and the
Layer menu just right of Edit or View.

* Moving Layer items into Project menu
While using almost all Mac software the File menu is visited only when
initiating, saving, exporting, printing, or ending a work session,
regardless of whether it is file-based in nature. While working within the
session, almost always component menus are used. For example, a similar
layer-based program, Photoshop, places all it layer-related actions under
the Layer menu, not the Image menu. IMO the Layer menu actions should stay
where they are

However, the menu could be cleaned up a bit. Having a submenu for adding
data sources, and sub-grouping by type with separators, will allow growth
of the submenu without cluttering the main Layer menu [1].

* Moving editing function out of Edit menu
The main editing currently done in QGIS is on features, aka 'Digitizing'
for the toolbar, so it is logical for those editing functions to be under
the Edit menu. I agree with William in that undo/redo should always be
located there, as well as copy/cut/paste and delete functions. Currently
copy/cut/paste refers to only 'features,' which makes no sense if you are
not editing features. Those should be generic and only be Copy/Cut/Paste
and Delete or Clear, or be dynamic and change relative to what is being
edited (that would be more work, though).

So, maybe there should be a Digitizing submenu under Edit. Other items that
programs commonly place under the Edit menu (some not currently implemented
in QGIS) are spell-checking, text manipulations (upper, lower, etc.),
special character inserts, select functions (currently under View),
find/search functions, and others. So there is functionally room to grow in
that menu, outside of just feature editing actions, i.e. Edit menu should
not be considered for removal.


As a separate suggestion: if we wanted to minimize our menus better and
prepare for unknown future functionality grouping and expansion, we could
create a Tools main menu, which could have Vector, Raster, Database and
Analysis submenus. This would make room for a Feature main menu, for
example, and allow future growth within Tools without forcing yet more
horizontal growth of the menubar. Downside is that it adds an extra layer
of submenu mousing to get to commonly used actions.

Regards,

Larry


Regards,
> Nathan
>
>
>
> On Thu, Apr 25, 2013 at 12:17 AM, William Kyngesburye <
> wokl...@kyngchaos.com> wrote:
>
>> Well, my original reaction when I saw the File->Project change was that
>> it's very non-standard, and may cause more cofusion than it's worth.
>>  Certainly on OS X, maybe on other systems.
>>
>> People know what the "File" menu means, even if the main object of an
>> application is a "project", or video or email or whatever.
>>
>> Same goes for the "Edit" menu.  And it's standard position is right next
>> to the File menu.  Undo, Redo, Cut, Copy and Paste are the basics for the
>> edit menu, and should work in dialog text boxes for copying and pasting
>> text, as well as whatever document editing they may do.  Do not move
>> Undo/Redo, more confusion.
>>
>> I realize that this may be Ma

[Qgis-developer] Next QGIS hackfest in Brighton

[Saber Razmjooei]

Dear all,

 

It is a bit of an advanced notice, but the next QGIS hackfest will be held
in the University of Sussex, Brighton. As it is just before FOSS4G, it will
be great if you could express your interest here, so that we can get
organised:

http://hub.qgis.org/wiki/17/10_QGIS_Developer_Meeting_in_Brighton_2013

 

 

Kind regards,

Saber

 

 

Saber Razmjooei
Lutra Consulting
  www.lutraconsulting.co.uk



 



--
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately 
by e-mail if you have received this e-mail by mistake and delete this e-mail 
from your system. If you are not the intended recipient you are notified 
that disclosing, copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited.

Whilst reasonable care has been taken to avoid virus transmission, no 
responsibility for viruses is taken and it is your responsibility to carry out 
such checks as you feel appropriate.

Saber Razmjooei and Peter Wells trading as Lutra Consulting.___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 'File' versus 'Project'

[John C. Tull]

Hi Nathan,

Here are both of your example programs on OS X. You will see that the menu 
observes the OS X HIGs with a File and Edit menu item in the main menubar of 
the OS for both of these applications.

http://imgur.com/NaxyYMi

Adding changes to Edit to the list of desired updates to the GUI takes this 
even further afield from standard interface design for OS X. I think you will 
be disenfranchising one of the supported operating systems with these changes 
and that it will make more sense to keep the File and Edit layout, in addition 
to cleaning up some of the other OS X gui issues, like having the "Analysis" 
menu item from plugins showing up between the Window and Help menu items.

Regards,
John

On Apr 24, 2013, at 8:24 AM, Nathan Woodrow  wrote:

> William,
> 
> I can understand the concern, it was the same thing that went though my mind 
> when I change the composer menu. In the end most people didn't care, or 
> adapted.   There are a lot of applications that don't use a file menu and 
> work quite well, I would say better in fact.
> 
> http://i.imgur.com/t0QZeJK.png Chrome and Firefox
> http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg
>  AutoCAD
> 
> Regarding the Edit menu, you will notice that the tools in there are not 
> related to text or documents they only refer to the current feature, or 
> selection of features.  If you have a dialog open you can't use that menu, 
> unless the dialog is non model and in that case still doesn't help you as 
> there are no tools to use on text.
> 
> If the Edit menu is to stay, that is fine however I would suggest a new menu 
> called Feature/s which houses all the current tools in the edit menu minus 
> the Undo/Redo and Copy/Paste Feature.
> 
> Regards,
> Nathan
> 
> 
> 
> On Thu, Apr 25, 2013 at 12:17 AM, William Kyngesburye  
> wrote:
> Well, my original reaction when I saw the File->Project change was that it's 
> very non-standard, and may cause more cofusion than it's worth.  Certainly on 
> OS X, maybe on other systems.
> 
> People know what the "File" menu means, even if the main object of an 
> application is a "project", or video or email or whatever.
> 
> Same goes for the "Edit" menu.  And it's standard position is right next to 
> the File menu.  Undo, Redo, Cut, Copy and Paste are the basics for the edit 
> menu, and should work in dialog text boxes for copying and pasting text, as 
> well as whatever document editing they may do.  Do not move Undo/Redo, more 
> confusion.
> 
> I realize that this may be Mac-centric, but the OS X HI Guidelines seem to be 
> generally followed or adapted on other systems, and these File and Edit menu 
> changes are a bit radical.
> 
> On Apr 24, 2013, at 6:07 AM, Nathan Woodrow wrote:
> 
> > Ramon,
> >
> > I would agree with those points. In fact I think the menu structure as is 
> > doesn't make much sense and the Edit menu should be renamed to Feature/s.
> >
> > What does Edit mean:
> >
> >  - Edit Layer
> >  - Edit Feature
> >  - Edit Project
> >
> > If you look at all the tools in the Edit menu they are all related to the 
> > current feature or features.  The undo and redo actions should be moved to 
> > the layer menu.
> >
> > Here are my thoughts on the Layer menu:
> >
> > http://i.imgur.com/oYO55Qz.png
> >
> > Moving the Add xxx Layer to the project menu would mean you follow these 
> > actions when creating a new project:
> >
> > Project -> New
> > Project -> Add xxx Layer
> >
> > Change the style
> >
> > Layer -> Properties
> >
> > That is a more logical flow IMO then currently what is there.
> >
> > Thoughts?
> >
> > - Nathan
> >
> >
> > On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach  
> > wrote:
> >
> > On 24/04/2013, at 05:55 , Ramon Andiñach wrote:
> >
> > >
> > > On 24/04/2013, at 04:28 , John C. Tull wrote:
> > >
> > >> Hi all,
> > >>
> > >> I was having some discussion on IRC today with Tim and Larry about the 
> > >> recent change to the menu in trunk. Before, the menu used "File" and 
> > >> that was changed to "Project". My position is that it does not seem 
> > >> Mac-like, whether or not a QGIS document resides in the filesystem as a 
> > >> .qgs file or if your "Project" is fed from a database, something 
> > >> apparently planned for the future of QGIS.
> > >>
> > >> I'd be interested in feedback from other Mac users on this. I'm flexible 
> > >> to the change, but wanted to vet this and see if anyone else had a 
> > >> strong opinion one way or the other. Please make it clear if you are a 
> > >> Mac OS X user or not.
> > >>
> > >> Thanks,
> > >> John
> > >
> > > Interesting. I'd say this is going to look as odd at home on my mac as at 
> > > work on their windows box. No file menu - that's going to look very 
> > > unfamiliar.
> > >
> > > That said, it's a good name. It does describe what's in there - those 
> > > commands work on the project-file not a layer-file.
> > >
> > > -ramon.
> >
> > Ok. I've been standing at the bottom of a l

[Qgis-developer] Decorations on the View Menu

[Antonio Locandro]

I just tried this feature and my impression is why is this enabled on the 
canvas view? This features are more suitable for the composer and having two 
ways to achieve something is not always a good thing. You can control in a 
better way how things look in the composer anyway. For me it doesn't make sense 
to have this enabled in the Canvas

 Ing. Antonio Locandro
Tegucigalpa, Honduras
  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 'File' versus 'Project'

[Antonio Locandro]

I am having a second look at the menus and can I ask why would you want to 
crowd the menus with the same actions you already have icons for in toolbars? 
e.g.  Edit menu has all the same tools as the Advanced Editing Toolbar (I 
highly doubt users doing serious editing would use menus instead of icons)Layer 
menu has all this add layer types the same as Manage Layer Toolbar (would look 
better with just an icon that opens a file dialog to whatever data you need, an 
universal add data button type) IMHO it seems a waste of space and makes things 
crowded 

 
 
Ing. Antonio Locandro
Tegucigalpa, Honduras
+504 9503 5747
Need a GPS map for Central America, Asia or South America / Necesitas un mapa 
GPS para Centro America, Asia o Sur America




 From: madman...@gmail.com
Date: Wed, 24 Apr 2013 21:07:58 +1000
To: cust...@westnet.com.au
CC: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] 'File' versus 'Project'

Ramon,
I would agree with those points. In fact I think the menu structure as is 
doesn't make much sense and the Edit menu should be renamed to Feature/s.  


What does Edit mean:
 - Edit Layer - Edit Feature - Edit Project
If you look at all the tools in the Edit menu they are all related to the 
current feature or features.  The undo and redo actions should be moved to the 
layer menu.


Here are my thoughts on the Layer menu:
http://i.imgur.com/oYO55Qz.png



Moving the Add xxx Layer to the project menu would mean you follow these 
actions when creating a new project:
Project -> NewProject -> Add xxx Layer


Change the style
Layer -> Properties
That is a more logical flow IMO then currently what is there.


Thoughts?
- Nathan

On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach  wrote:




On 24/04/2013, at 05:55 , Ramon Andiñach wrote:



>

> On 24/04/2013, at 04:28 , John C. Tull wrote:

>

>> Hi all,

>>

>> I was having some discussion on IRC today with Tim and Larry about the 
>> recent change to the menu in trunk. Before, the menu used "File" and that 
>> was changed to "Project". My position is that it does not seem Mac-like, 
>> whether or not a QGIS document resides in the filesystem as a .qgs file or 
>> if your "Project" is fed from a database, something apparently planned for 
>> the future of QGIS.



>>

>> I'd be interested in feedback from other Mac users on this. I'm flexible to 
>> the change, but wanted to vet this and see if anyone else had a strong 
>> opinion one way or the other. Please make it clear if you are a Mac OS X 
>> user or not.



>>

>> Thanks,

>> John

>

> Interesting. I'd say this is going to look as odd at home on my mac as at 
> work on their windows box. No file menu - that's going to look very 
> unfamiliar.

>

> That said, it's a good name. It does describe what's in there - those 
> commands work on the project-file not a layer-file.

>

> -ramon.



Ok. I've been standing at the bottom of a large-ish hole today, so if this 
sounds like a dumb idea that's my excuse.



Could we move Layer across next to Project?





Some reasoning.

1. If we're abandoning File in favour of Project, then there's possibly no 
reason to retain Edit next to it either. Other than historical ones.

2. Project and Layer are largely about opening, closing, saving (and other 
similar things) files. Project files in one menu and Layers (vectors, rasters, 
DB, etc) in the other.

3. Then you have a more logical progression from left to right about how to use 
QGIS. (Open stuff, change stuff)



-ramon.

(OK, 1. is not so good, but it does open the door to ask questions!)



___

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] 'File' versus 'Project'

[Antonio Locandro]

Ok now I see what the discussion is about. Seriously changing File for Project 
what was the rationale for that? Pretty much standard to use File and it wont 
cause any confusions. I am going with William on this issue


 
Ing. Antonio Locandro
Tegucigalpa, Honduras
+504 9503 5747
Need a GPS map for Central America, Asia or South America / Necesitas un mapa 
GPS para Centro America, Asia o Sur America




 From: madman...@gmail.com
Date: Thu, 25 Apr 2013 01:24:37 +1000
To: kyngch...@kyngchaos.com
CC: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] 'File' versus 'Project'

William,
I can understand the concern, it was the same thing that went though my mind 
when I change the composer menu. In the end most people didn't care, or 
adapted.   There are a lot of applications that don't use a file menu and work 
quite well, I would say better in fact.


http://i.imgur.com/t0QZeJK.png Chrome and Firefox
http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg
 AutoCAD



Regarding the Edit menu, you will notice that the tools in there are not 
related to text or documents they only refer to the current feature, or 
selection of features.  If you have a dialog open you can't use that menu, 
unless the dialog is non model and in that case still doesn't help you as there 
are no tools to use on text.


If the Edit menu is to stay, that is fine however I would suggest a new menu 
called Feature/s which houses all the current tools in the edit menu minus the 
Undo/Redo and Copy/Paste Feature.


Regards,
Nathan


On Thu, Apr 25, 2013 at 12:17 AM, William Kyngesburye  
wrote:


Well, my original reaction when I saw the File->Project change was that it's 
very non-standard, and may cause more cofusion than it's worth.  Certainly on 
OS X, maybe on other systems.





People know what the "File" menu means, even if the main object of an 
application is a "project", or video or email or whatever.



Same goes for the "Edit" menu.  And it's standard position is right next to the 
File menu.  Undo, Redo, Cut, Copy and Paste are the basics for the edit menu, 
and should work in dialog text boxes for copying and pasting text, as well as 
whatever document editing they may do.  Do not move Undo/Redo, more confusion.





I realize that this may be Mac-centric, but the OS X HI Guidelines seem to be 
generally followed or adapted on other systems, and these File and Edit menu 
changes are a bit radical.



On Apr 24, 2013, at 6:07 AM, Nathan Woodrow wrote:



> Ramon,

>

> I would agree with those points. In fact I think the menu structure as is 
> doesn't make much sense and the Edit menu should be renamed to Feature/s.

>

> What does Edit mean:

>

>  - Edit Layer

>  - Edit Feature

>  - Edit Project

>

> If you look at all the tools in the Edit menu they are all related to the 
> current feature or features.  The undo and redo actions should be moved to 
> the layer menu.

>

> Here are my thoughts on the Layer menu:

>

> http://i.imgur.com/oYO55Qz.png

>

> Moving the Add xxx Layer to the project menu would mean you follow these 
> actions when creating a new project:

>

> Project -> New

> Project -> Add xxx Layer

>

> Change the style

>

> Layer -> Properties

>

> That is a more logical flow IMO then currently what is there.

>

> Thoughts?

>

> - Nathan

>

>

> On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach  
> wrote:

>

> On 24/04/2013, at 05:55 , Ramon Andiñach wrote:

>

> >

> > On 24/04/2013, at 04:28 , John C. Tull wrote:

> >

> >> Hi all,

> >>

> >> I was having some discussion on IRC today with Tim and Larry about the 
> >> recent change to the menu in trunk. Before, the menu used "File" and that 
> >> was changed to "Project". My position is that it does not seem Mac-like, 
> >> whether or not a QGIS document resides in the filesystem as a .qgs file or 
> >> if your "Project" is fed from a database, something apparently planned for 
> >> the future of QGIS.



> >>

> >> I'd be interested in feedback from other Mac users on this. I'm flexible 
> >> to the change, but wanted to vet this and see if anyone else had a strong 
> >> opinion one way or the other. Please make it clear if you are a Mac OS X 
> >> user or not.



> >>

> >> Thanks,

> >> John

> >

> > Interesting. I'd say this is going to look as odd at home on my mac as at 
> > work on their windows box. No file menu - that's going to look very 
> > unfamiliar.

> >

> > That said, it's a good name. It does describe what's in there - those 
> > commands work on the project-file not a layer-file.

> >

> > -ramon.

>

> Ok. I've been standing at the bottom of a large-ish hole today, so if this 
> sounds like a dumb idea that's my excuse.

>

> Could we move Layer across next to Project?

>

>

> Some reasoning.

> 1. If we're abandoning File in favour of Project, then there's possibly no 
> reason to retain Edit next to it either. Other than historical ones.

> 2. Project and Layer are largel

Re: [Qgis-developer] Header files order

[Radim Blazek]

On Sun, Apr 21, 2013 at 9:50 AM, Martin Dobias  wrote:
> On Sat, Apr 20, 2013 at 10:18 AM, Radim Blazek  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.

I have modified the manual in this sense.

Radim

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

Re: [Qgis-developer] 'File' versus 'Project'

[Nathan Woodrow]

William,

I can understand the concern, it was the same thing that went though my
mind when I change the composer menu. In the end most people didn't care,
or adapted.   There are a lot of applications that don't use a file menu
and work quite well, I would say better in fact.

http://i.imgur.com/t0QZeJK.png Chrome and Firefox
http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg
 AutoCAD

Regarding the Edit menu, you will notice that the tools in there are not
related to text or documents they only refer to the current feature, or
selection of features.  If you have a dialog open you can't use that menu,
unless the dialog is non model and in that case still doesn't help you as
there are no tools to use on text.

If the Edit menu is to stay, that is fine however I would suggest a new
menu called Feature/s which houses all the current tools in the edit menu
minus the Undo/Redo and Copy/Paste Feature.

Regards,
Nathan



On Thu, Apr 25, 2013 at 12:17 AM, William Kyngesburye  wrote:

> Well, my original reaction when I saw the File->Project change was that
> it's very non-standard, and may cause more cofusion than it's worth.
>  Certainly on OS X, maybe on other systems.
>
> People know what the "File" menu means, even if the main object of an
> application is a "project", or video or email or whatever.
>
> Same goes for the "Edit" menu.  And it's standard position is right next
> to the File menu.  Undo, Redo, Cut, Copy and Paste are the basics for the
> edit menu, and should work in dialog text boxes for copying and pasting
> text, as well as whatever document editing they may do.  Do not move
> Undo/Redo, more confusion.
>
> I realize that this may be Mac-centric, but the OS X HI Guidelines seem to
> be generally followed or adapted on other systems, and these File and Edit
> menu changes are a bit radical.
>
> On Apr 24, 2013, at 6:07 AM, Nathan Woodrow wrote:
>
> > Ramon,
> >
> > I would agree with those points. In fact I think the menu structure as
> is doesn't make much sense and the Edit menu should be renamed to Feature/s.
> >
> > What does Edit mean:
> >
> >  - Edit Layer
> >  - Edit Feature
> >  - Edit Project
> >
> > If you look at all the tools in the Edit menu they are all related to
> the current feature or features.  The undo and redo actions should be moved
> to the layer menu.
> >
> > Here are my thoughts on the Layer menu:
> >
> > http://i.imgur.com/oYO55Qz.png
> >
> > Moving the Add xxx Layer to the project menu would mean you follow these
> actions when creating a new project:
> >
> > Project -> New
> > Project -> Add xxx Layer
> >
> > Change the style
> >
> > Layer -> Properties
> >
> > That is a more logical flow IMO then currently what is there.
> >
> > Thoughts?
> >
> > - Nathan
> >
> >
> > On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach 
> wrote:
> >
> > On 24/04/2013, at 05:55 , Ramon Andiñach wrote:
> >
> > >
> > > On 24/04/2013, at 04:28 , John C. Tull wrote:
> > >
> > >> Hi all,
> > >>
> > >> I was having some discussion on IRC today with Tim and Larry about
> the recent change to the menu in trunk. Before, the menu used "File" and
> that was changed to "Project". My position is that it does not seem
> Mac-like, whether or not a QGIS document resides in the filesystem as a
> .qgs file or if your "Project" is fed from a database, something apparently
> planned for the future of QGIS.
> > >>
> > >> I'd be interested in feedback from other Mac users on this. I'm
> flexible to the change, but wanted to vet this and see if anyone else had a
> strong opinion one way or the other. Please make it clear if you are a Mac
> OS X user or not.
> > >>
> > >> Thanks,
> > >> John
> > >
> > > Interesting. I'd say this is going to look as odd at home on my mac as
> at work on their windows box. No file menu - that's going to look very
> unfamiliar.
> > >
> > > That said, it's a good name. It does describe what's in there - those
> commands work on the project-file not a layer-file.
> > >
> > > -ramon.
> >
> > Ok. I've been standing at the bottom of a large-ish hole today, so if
> this sounds like a dumb idea that's my excuse.
> >
> > Could we move Layer across next to Project?
> >
> >
> > Some reasoning.
> > 1. If we're abandoning File in favour of Project, then there's possibly
> no reason to retain Edit next to it either. Other than historical ones.
> > 2. Project and Layer are largely about opening, closing, saving (and
> other similar things) files. Project files in one menu and Layers (vectors,
> rasters, DB, etc) in the other.
> > 3. Then you have a more logical progression from left to right about how
> to use QGIS. (Open stuff, change stuff)
> >
> > -ramon.
> > (OK, 1. is not so good, but it does open the door to ask questions!)
> >
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> > 

Re: [Qgis-developer] Make QGIS interact with LibreCAD.

[Antonio Locandro]

Would it be possible as a first interaction if all the CAD/Drawing tools be 
merged into a single plugin so the plugin library be less crowded and we knew 
exactly what tools are available? I disagree that some users wont be interested 
in this tools, some users are just doing analysis and that is fine but to be 
able to perform analysis and models you sometimes have to create the data, 
having the tools to create the data is part of every COTS GIS software and it 
should be part of QGIS. Of course if a user is just doing analysis he would 
just hide the tools

Antonio Locandro From: olivier.dal...@gmail.com
Date: Wed, 24 Apr 2013 12:57:03 +
To: a.neum...@carto.net
CC: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Make QGIS interact with LibreCAD.

2013/4/22 Andreas Neumann 




I would prefer if most of the editing tools would be available in core

- - and if possible - implemented in C++.

I'm not sure if I agree with that : getting a snapping engine that works 
smoothly will require a lot of tweaking, which is a pain in C++ compared to 
python.



Also, some user will be interested in adapting the snapping engine to suit 
their particular habits, which is easy when working with python plugins. And 
some other users won't be interested at all in this kind of tools.



About the problem of installing multiple plugins : it would of course be much 
more elegant if all the CAD-drawing related tools were neatly packed in one 
plugin, which could then even be preinstalled or "featured".






___
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] update layer list in python plugin

[Denis Rouzaud]

Hi Otto,

Not sure to understand what you mean.
But, can't you update your list by connecting signals either from the 
layer regirstry, or the legend interface ?



Denis

On 04/24/2013 04:23 PM, Otto Dassau wrote:

Hi,

how is it possible to update the list of available layers in a python plugin
automatically, when I add or remove layers from QGIS legend?

To load the layers I use QgsMapLayerRegistry

Regards
Otto
___
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] update layer list in python plugin

[Otto Dassau]

Hi,

how is it possible to update the list of available layers in a python plugin
automatically, when I add or remove layers from QGIS legend?

To load the layers I use QgsMapLayerRegistry

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

Re: [Qgis-developer] 'File' versus 'Project'

[William Kyngesburye]

Well, my original reaction when I saw the File->Project change was that it's 
very non-standard, and may cause more cofusion than it's worth.  Certainly on 
OS X, maybe on other systems.

People know what the "File" menu means, even if the main object of an 
application is a "project", or video or email or whatever.

Same goes for the "Edit" menu.  And it's standard position is right next to the 
File menu.  Undo, Redo, Cut, Copy and Paste are the basics for the edit menu, 
and should work in dialog text boxes for copying and pasting text, as well as 
whatever document editing they may do.  Do not move Undo/Redo, more confusion.

I realize that this may be Mac-centric, but the OS X HI Guidelines seem to be 
generally followed or adapted on other systems, and these File and Edit menu 
changes are a bit radical.

On Apr 24, 2013, at 6:07 AM, Nathan Woodrow wrote:

> Ramon,
> 
> I would agree with those points. In fact I think the menu structure as is 
> doesn't make much sense and the Edit menu should be renamed to Feature/s.  
> 
> What does Edit mean:
> 
>  - Edit Layer
>  - Edit Feature
>  - Edit Project
> 
> If you look at all the tools in the Edit menu they are all related to the 
> current feature or features.  The undo and redo actions should be moved to 
> the layer menu.
> 
> Here are my thoughts on the Layer menu:
> 
> http://i.imgur.com/oYO55Qz.png
> 
> Moving the Add xxx Layer to the project menu would mean you follow these 
> actions when creating a new project:
> 
> Project -> New
> Project -> Add xxx Layer
> 
> Change the style
> 
> Layer -> Properties
> 
> That is a more logical flow IMO then currently what is there.
> 
> Thoughts?
> 
> - Nathan
> 
> 
> On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach  
> wrote:
> 
> On 24/04/2013, at 05:55 , Ramon Andiñach wrote:
> 
> >
> > On 24/04/2013, at 04:28 , John C. Tull wrote:
> >
> >> Hi all,
> >>
> >> I was having some discussion on IRC today with Tim and Larry about the 
> >> recent change to the menu in trunk. Before, the menu used "File" and that 
> >> was changed to "Project". My position is that it does not seem Mac-like, 
> >> whether or not a QGIS document resides in the filesystem as a .qgs file or 
> >> if your "Project" is fed from a database, something apparently planned for 
> >> the future of QGIS.
> >>
> >> I'd be interested in feedback from other Mac users on this. I'm flexible 
> >> to the change, but wanted to vet this and see if anyone else had a strong 
> >> opinion one way or the other. Please make it clear if you are a Mac OS X 
> >> user or not.
> >>
> >> Thanks,
> >> John
> >
> > Interesting. I'd say this is going to look as odd at home on my mac as at 
> > work on their windows box. No file menu - that's going to look very 
> > unfamiliar.
> >
> > That said, it's a good name. It does describe what's in there - those 
> > commands work on the project-file not a layer-file.
> >
> > -ramon.
> 
> Ok. I've been standing at the bottom of a large-ish hole today, so if this 
> sounds like a dumb idea that's my excuse.
> 
> Could we move Layer across next to Project?
> 
> 
> Some reasoning.
> 1. If we're abandoning File in favour of Project, then there's possibly no 
> reason to retain Edit next to it either. Other than historical ones.
> 2. Project and Layer are largely about opening, closing, saving (and other 
> similar things) files. Project files in one menu and Layers (vectors, 
> rasters, DB, etc) in the other.
> 3. Then you have a more logical progression from left to right about how to 
> use QGIS. (Open stuff, change stuff)
> 
> -ramon.
> (OK, 1. is not so good, but it does open the door to ask questions!)
> 
> ___
> 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

-
William Kyngesburye 
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike.  Cheating, murdering, lying, fighting, and 
all for things that the beasts of the jungle would not deign to possess - money 
to purchase the effeminate pleasures of weaklings.  And yet withal bound down 
by silly customs that make them slaves to their unhappy lot while firm in the 
belief that they be the lords of creation enjoying the only real pleasures of 
existence

- the wisdom of Tarzan


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

Re: [Qgis-developer] OSGeo4W QGIS 1.8 Doesnt Work

[Jürgen E . Fischer]

Hi James,

On Wed, 24. Apr 2013 at 10:48:02 +, Stott James wrote:
> As suggested on the OSGeo4W mailing list
> (http://osgeo-org.1560.x6.nabble.com/ANN-Python-2-7-4-td5048404.html),
> renaming the python27.dll in windows\system32 (or syswow64) works, but it
> means ArcGIS wont.

No way around that - you can put ArcGIS' python27.dll somewhere ArcGIS will
find it first (bin?), but won't force everything else to use that particular
version.


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de
committ(ed|ing) to Quantum GIS IRC: jef on FreeNode 


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

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

Re: [Qgis-developer] today nightly build issue when geoprocessing vectors

[Giovanni Manghi]

thanks Marco and Mathias, I recompiled and the issue seems really gone.



On Wed, Apr 24, 2013 at 12:27 PM, Marco Bernasocchi
 wrote:
> Hi Giovanni, today's or yesterdays build?
> Mathias fixed sth similar to your problem [0] yesterday [1]
>
> ciao
> [0] http://irclogs.geoapt.com/qgis/%23qgis.2013-04-23.log (search
> mbernasocchi)
> [1]
> https://github.com/qgis/Quantum-GIS/commit/b98db8842b507632fef044044581a762e46527bb
>
>
>
> On 04/24/2013 12:13 PM, Giovanni Manghi wrote:
>>
>> Hi all,
>>
>> I'm the only one to have big troubles with the latest qgis master when
>> doing some kind of vector geoprocessing?
>>
>> If I use a tool in the vector menu, when I click "ok" when it asks me
>> if I want to add the result to the project, then qgis crashes (seg
>> fault).
>>
>> If I do some kind of vector geoprocessing with sextante the result is
>> added to the toc, but then zooming or just touching the toc causes
>> qgis to crash:
>>
>> Warning: QFSFileEngine::open: No file name specified
>> Segmentation fault
>>
>>
>> anyone else?
>>
>> cheers
>>
>> -- Giovanni --
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> --
> Marco Bernasocchi
> http://opengis.ch
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Make QGIS interact with LibreCAD.

[Olivier Dalang]

2013/4/22 Andreas Neumann 

> I would prefer if most of the editing tools would be available in core
> - - and if possible - implemented in C++.
>

I'm not sure if I agree with that : getting a snapping engine that works
smoothly will require a lot of tweaking, which is a pain in C++ compared to
python.

Also, some user will be interested in adapting the snapping engine to suit
their particular habits, which is easy when working with python plugins.
And some other users won't be interested at all in this kind of tools.

About the problem of installing multiple plugins : it would of course be
much more elegant if all the CAD-drawing related tools were neatly packed
in one plugin, which could then even be preinstalled or "featured".
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] valuetool plugin but with average value by radius ?

[Denis Rouzaud]

Hi Otto,

I have done something similar for landit plugin (DTM values).

There is three methods: nearest, linear and bicubic interpolations.

You can found the the code here
https://github.com/3nids/landit/blob/master/elevationdialog.py#L120


Cheers,

Denis

On 04/24/2013 02:40 PM, Otto Dassau wrote:

Hi,

I am working with the valuetool plugin and would now like to get the
average raster value around the mouse position for a given radius. Is there
already a solution in another plugin for that or does anybody has an idea how
to solve this with pyqgis?

Thanks a lot
Otto

___
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] valuetool plugin but with average value by radius ?

[Otto Dassau]

Hi,

I am working with the valuetool plugin and would now like to get the
average raster value around the mouse position for a given radius. Is there
already a solution in another plugin for that or does anybody has an idea how
to solve this with pyqgis? 

Thanks a lot
Otto

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

[Qgis-developer] GetLegendGraphic FORMAT jpeg fails with QGIS mapserver master

[Marco Lechner - FOSSGIS e.V.]

Hi,

even GetCapabilities of a QGIS mapserver WMS tells jpeg is a valid
format for GetLegendGraphic request, trying this format results in an
exception telling that GetMap does not support "jpeg" format but it
works with the not listed "jpg". Pull request #554 [1] adds jpg, jpeg,
image/jpg and image/jpeg as valid formats to GetMap and GetLegendGraphic
requests.

Marco

[1] https://github.com/qgis/Quantum-GIS/pull/554

-- 


+
FOSSGIS 2013, Die Konferenz für Open Source GIS mit OpenData und OpenStreetMap 
erstmals in der Schweiz!
12.-14. Juni, HSR, Rapperswil, http://www.fossgis.de/konferenz/2013/
+
FOSSGIS e.V.

die unabhängige Hilfe bei freier GIS-Software und freien Geodaten
http://www.fossgis.de
+

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

Re: [Qgis-developer] today nightly build issue when geoprocessing vectors

[Marco Bernasocchi]

Hi Giovanni, today's or yesterdays build?
Mathias fixed sth similar to your problem [0] yesterday [1]

ciao
[0] http://irclogs.geoapt.com/qgis/%23qgis.2013-04-23.log (search 
mbernasocchi)
[1] 
https://github.com/qgis/Quantum-GIS/commit/b98db8842b507632fef044044581a762e46527bb



On 04/24/2013 12:13 PM, Giovanni Manghi wrote:

Hi all,

I'm the only one to have big troubles with the latest qgis master when
doing some kind of vector geoprocessing?

If I use a tool in the vector menu, when I click "ok" when it asks me
if I want to add the result to the project, then qgis crashes (seg
fault).

If I do some kind of vector geoprocessing with sextante the result is
added to the toc, but then zooming or just touching the toc causes
qgis to crash:

Warning: QFSFileEngine::open: No file name specified
Segmentation fault


anyone else?

cheers

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




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

Re: [Qgis-developer] 'File' versus 'Project'

[Nathan Woodrow]

Ramon,

I would agree with those points. In fact I think the menu structure as is
doesn't make much sense and the Edit menu should be renamed to Feature/s.

What does Edit mean:

 - Edit Layer
 - Edit Feature
 - Edit Project

If you look at all the tools in the Edit menu they are all related to the
current feature or features.  The undo and redo actions should be moved to
the layer menu.

Here are my thoughts on the Layer menu:

http://i.imgur.com/oYO55Qz.png

Moving the Add xxx Layer to the project menu would mean you follow these
actions when creating a new project:

Project -> New
Project -> Add xxx Layer

Change the style

Layer -> Properties

That is a more logical flow IMO then currently what is there.

Thoughts?

- Nathan


On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach wrote:

>
> On 24/04/2013, at 05:55 , Ramon Andiñach wrote:
>
> >
> > On 24/04/2013, at 04:28 , John C. Tull wrote:
> >
> >> Hi all,
> >>
> >> I was having some discussion on IRC today with Tim and Larry about the
> recent change to the menu in trunk. Before, the menu used "File" and that
> was changed to "Project". My position is that it does not seem Mac-like,
> whether or not a QGIS document resides in the filesystem as a .qgs file or
> if your "Project" is fed from a database, something apparently planned for
> the future of QGIS.
> >>
> >> I'd be interested in feedback from other Mac users on this. I'm
> flexible to the change, but wanted to vet this and see if anyone else had a
> strong opinion one way or the other. Please make it clear if you are a Mac
> OS X user or not.
> >>
> >> Thanks,
> >> John
> >
> > Interesting. I'd say this is going to look as odd at home on my mac as
> at work on their windows box. No file menu - that's going to look very
> unfamiliar.
> >
> > That said, it's a good name. It does describe what's in there - those
> commands work on the project-file not a layer-file.
> >
> > -ramon.
>
> Ok. I've been standing at the bottom of a large-ish hole today, so if this
> sounds like a dumb idea that's my excuse.
>
> Could we move Layer across next to Project?
>
>
> Some reasoning.
> 1. If we're abandoning File in favour of Project, then there's possibly no
> reason to retain Edit next to it either. Other than historical ones.
> 2. Project and Layer are largely about opening, closing, saving (and other
> similar things) files. Project files in one menu and Layers (vectors,
> rasters, DB, etc) in the other.
> 3. Then you have a more logical progression from left to right about how
> to use QGIS. (Open stuff, change stuff)
>
> -ramon.
> (OK, 1. is not so good, but it does open the door to ask questions!)
>
> ___
> 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] OSGeo4W QGIS 1.8 Doesnt Work

[Stott James]

Thanks for the reply.

I have tried 2. QGIS opens but then complains about sip. This doesn't fix the 
command line problem.

So I am awaiting for 1. to happen :) 

As suggested on the OSGeo4W mailing list 
(http://osgeo-org.1560.x6.nabble.com/ANN-Python-2-7-4-td5048404.html), renaming 
the python27.dll in windows\system32 (or syswow64) works, but it means ArcGIS 
wont.

-Opprinnelig melding-
Fra: Ramon Andiñach [mailto:cust...@westnet.com.au] 
Sendt: 24. april 2013 12:26
Til: Stott James
Emne: Re: [Qgis-developer] OSGeo4W QGIS 1.8 Doesnt Work

I think it means that for us there are two options,

1. In a little bit they'll rebuild 1.8 and put it on the installer.

2. Find the python upgrade that just changed and run it back a version. (When 
you run the update, things that you have installed will say either the new 
version that it's about to install or Keep if there's nothing to do. If you 
click on the Keep it will cycle through a few things, one of which should be 
the last installed version) No guarantees about what will happen though - I'd 
try 1 first.

-ramon.

On 24/04/2013, at 16:25 , Stott James wrote:

> I install QGIS from the OSGeo4W installer.
> 
> Does that mean I need to wait for a rebuild of QGIS to be put out in the 
> installer?
> 
> James
> 
> -Opprinnelig melding-
> Fra: Alexander Bruy [mailto:alexander.b...@gmail.com]
> Sendt: 24. april 2013 10:13
> Til: Stott James
> Kopi: qgis-developer@lists.osgeo.org
> Emne: Re: [Qgis-developer] OSGeo4W QGIS 1.8 Doesnt Work
> 
> Hi,
> 
> seems this caused by recent Python upgrade in OSGeo4W. I think rebuilding 
> QGIS will solve this issue.
> 
> On Wed, 24 Apr 2013 08:09:45 +
> Stott James  wrote:
> 
>> Hi all,
>> 
>> I have noticed that since I updated OSGeo4W yesterday, I cannot launch QGIS 
>> 1.8. It stops loading when the splash screen gets to Loading Python.
>> 
>> I also get the following error when trying to run a python script from the 
>> OSGeo4W shell:
>> 
>> G:\>zip_data_test.py
>> Traceback (most recent call last):
>>  File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 563, in 
>>main()
>>  File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 545, in main
>>known_paths = addusersitepackages(known_paths)  File 
>> "C:\OSGeo4W\\apps\Python27\lib\site.py", line 278, in 
>> addusersitepackages
>> 
>>user_site = getusersitepackages()
>>  File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 253, in 
>> getusersitepackages
>> 
>>user_base = getuserbase() # this will also set USER_BASE  File 
>> "C:\OSGeo4W\\apps\Python27\lib\site.py", line 243, in getuserbase
>>USER_BASE = get_config_var('userbase')  File 
>> "C:\OSGeo4W\apps\Python27\lib\sysconfig.py", line 472, in get_config_var
>>return get_config_vars().get(name)  File 
>> "C:\OSGeo4W\apps\Python27\lib\sysconfig.py", line 405, in 
>> get_config_vars
>> 
>>import re
>>  File "C:\OSGeo4W\apps\Python27\lib\re.py", line 105, in 
>>import sre_compile
>>  File "C:\OSGeo4W\apps\Python27\lib\sre_compile.py", line 14, in 
>>import sre_parse
>>  File "C:\OSGeo4W\apps\Python27\lib\sre_parse.py", line 17, in 
>>from sre_constants import *
>>  File "C:\OSGeo4W\apps\Python27\lib\sre_constants.py", line 18, in 
>>from _sre import MAXREPEAT
>> ImportError: cannot import name MAXREPEAT
>> 
>> Does anyone here know how to fix this? Is this a problem for the OSGeo4W 
>> people instead?
>> 
>> Many thanks,
>> 
>> James
> 
> 
> --
> Alexander Bruy
> ___
> 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] 'File' versus 'Project'

[Ramon Andiñach]

On 24/04/2013, at 05:55 , Ramon Andiñach wrote:

> 
> On 24/04/2013, at 04:28 , John C. Tull wrote:
> 
>> Hi all,
>> 
>> I was having some discussion on IRC today with Tim and Larry about the 
>> recent change to the menu in trunk. Before, the menu used "File" and that 
>> was changed to "Project". My position is that it does not seem Mac-like, 
>> whether or not a QGIS document resides in the filesystem as a .qgs file or 
>> if your "Project" is fed from a database, something apparently planned for 
>> the future of QGIS.
>> 
>> I'd be interested in feedback from other Mac users on this. I'm flexible to 
>> the change, but wanted to vet this and see if anyone else had a strong 
>> opinion one way or the other. Please make it clear if you are a Mac OS X 
>> user or not.
>> 
>> Thanks,
>> John
> 
> Interesting. I'd say this is going to look as odd at home on my mac as at 
> work on their windows box. No file menu - that's going to look very 
> unfamiliar.
> 
> That said, it's a good name. It does describe what's in there - those 
> commands work on the project-file not a layer-file.
> 
> -ramon.

Ok. I've been standing at the bottom of a large-ish hole today, so if this 
sounds like a dumb idea that's my excuse.

Could we move Layer across next to Project?


Some reasoning.
1. If we're abandoning File in favour of Project, then there's possibly no 
reason to retain Edit next to it either. Other than historical ones.
2. Project and Layer are largely about opening, closing, saving (and other 
similar things) files. Project files in one menu and Layers (vectors, rasters, 
DB, etc) in the other.
3. Then you have a more logical progression from left to right about how to use 
QGIS. (Open stuff, change stuff)

-ramon.
(OK, 1. is not so good, but it does open the door to ask questions!)

___
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)

[Radim Blazek]

On Sun, Apr 21, 2013 at 11:41 AM, Radim Blazek  wrote:
> On Sun, Apr 21, 2013 at 9:34 AM, Martin Dobias  wrote:
>> Hi Radim
>>
>> On Sat, Apr 20, 2013 at 8:39 AM, Radim Blazek  wrote:
>>> On Fri, Apr 19, 2013 at 12:07 PM, JVerholle  
>>> 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.

Well, I have reconsidered this and it may be better to call
QgsVectorDataProvider::startEditing() from
QgsVectorLayer::commitChanges(). It is not probable that permissions
changes when the layer is opened. It is more probable that user
decides to cancel changes, this way we avoid not necessary reopening
of files.

It should not be important for API and implementation in providers
where we call it from vector layer, we can move it around in the
vector layer later.

>> 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.

I added to QgsVectorDataProvider:

virtual bool startEditing();
virtual bool rollBack();
virtual bool commitChanges();
virtual bool isEdited();
signals:
  void editingStarted();
  void editingStopped();

As I said, to keep names consistent with vector layer. Currently not
implemented nor used. It would be useful to have it implemented for
2.0 at least in ogr provider to resolve #6448 at least for reading.

Currently all editing methods in postgres provider do changes in
transactions. If we implement QgsPostgresProvider::startEditing() it
should start new transaction and all changes should be done within
that transaction. Are there any potential problems?

Should the startEditing() / commitChanges() close all iterators?

What transaction should use QgsPostgresProvider::getFeatures()? That
opened for editing or another one?

Radim

> 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 ro

[Qgis-developer] today nightly build issue when geoprocessing vectors

[Giovanni Manghi]

Hi all,

I'm the only one to have big troubles with the latest qgis master when
doing some kind of vector geoprocessing?

If I use a tool in the vector menu, when I click "ok" when it asks me
if I want to add the result to the project, then qgis crashes (seg
fault).

If I do some kind of vector geoprocessing with sextante the result is
added to the toc, but then zooming or just touching the toc causes
qgis to crash:

Warning: QFSFileEngine::open: No file name specified
Segmentation fault


anyone else?

cheers

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

Re: [Qgis-developer] New SEXTANTE modeler interface

[Andreas Neumann]

Thank you Victor - looks good (only tested with the sample models).

I still haven't really started using SEXTANTE but will for sure in the
upcoming weeks. I will try to replace some of the simpler FME workflows
with a SEXTANTE workflow.

Will report if I run into troubles or have suggestions.

Andreas

Am 24.04.2013 07:55, schrieb Victor Olaya:
> Hey guys,
> 
> I have made some changes to the interface of the modeler, taking into
> account a couple of suggestions from Tim and Andreas (thanks!). Not a
> big change, but I guess it's a nice usability improvement.
> 
> Before starting rewriting the corresponding part in the manual and
> making new screenshots, I would appreciate if those of you that use
> SEXTANTE could have a quick look and give me your opinion.
> 
> Thanks in advance!
> 
> Víctor
> ___
> 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] Version 2.0 Python API

[Alexandre Neto]

Have a look here:

http://hub.qgis.org/wiki/17/API_changes_for_version_20

Alexandre Neto

On Wed, Apr 24, 2013 at 6:20 AM, Chris Crook  wrote:

> Hi
>
> Is there anywhere a summary of the Python API changes for version 2.0, as
> a guide for porting plugins to the new version.
>
> I'm guessing that with the focus on cleaning up the API this may be a work
> in progress, but if there is something available that would be great.
>
> Thanks
> Chris
>
> 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 mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] OSGeo4W QGIS 1.8 Doesnt Work

[Stott James]

I install QGIS from the OSGeo4W installer.

Does that mean I need to wait for a rebuild of QGIS to be put out in the 
installer?

James

-Opprinnelig melding-
Fra: Alexander Bruy [mailto:alexander.b...@gmail.com] 
Sendt: 24. april 2013 10:13
Til: Stott James
Kopi: qgis-developer@lists.osgeo.org
Emne: Re: [Qgis-developer] OSGeo4W QGIS 1.8 Doesnt Work

Hi,

seems this caused by recent Python upgrade in OSGeo4W. I think rebuilding QGIS 
will solve this issue.

On Wed, 24 Apr 2013 08:09:45 +
Stott James  wrote:

> Hi all,
> 
> I have noticed that since I updated OSGeo4W yesterday, I cannot launch QGIS 
> 1.8. It stops loading when the splash screen gets to Loading Python.
> 
> I also get the following error when trying to run a python script from the 
> OSGeo4W shell:
> 
> G:\>zip_data_test.py
> Traceback (most recent call last):
>   File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 563, in 
> main()
>   File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 545, in main
> known_paths = addusersitepackages(known_paths)
>   File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 278, in 
> addusersitepackages
> 
> user_site = getusersitepackages()
>   File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 253, in 
> getusersitepackages
> 
> user_base = getuserbase() # this will also set USER_BASE
>   File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 243, in getuserbase
> USER_BASE = get_config_var('userbase')
>   File "C:\OSGeo4W\apps\Python27\lib\sysconfig.py", line 472, in 
> get_config_var
> return get_config_vars().get(name)
>   File "C:\OSGeo4W\apps\Python27\lib\sysconfig.py", line 405, in 
> get_config_vars
> 
> import re
>   File "C:\OSGeo4W\apps\Python27\lib\re.py", line 105, in 
> import sre_compile
>   File "C:\OSGeo4W\apps\Python27\lib\sre_compile.py", line 14, in 
> import sre_parse
>   File "C:\OSGeo4W\apps\Python27\lib\sre_parse.py", line 17, in 
> from sre_constants import *
>   File "C:\OSGeo4W\apps\Python27\lib\sre_constants.py", line 18, in 
> from _sre import MAXREPEAT
> ImportError: cannot import name MAXREPEAT
> 
> Does anyone here know how to fix this? Is this a problem for the OSGeo4W 
> people instead?
> 
> Many thanks,
> 
> James


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

Re: [Qgis-developer] OSGeo4W QGIS 1.8 Doesnt Work

[Alexander Bruy]

Hi,

seems this caused by recent Python upgrade in OSGeo4W. I think rebuilding QGIS 
will solve this issue.

On Wed, 24 Apr 2013 08:09:45 +
Stott James  wrote:

> Hi all,
> 
> I have noticed that since I updated OSGeo4W yesterday, I cannot launch QGIS 
> 1.8. It stops loading when the splash screen gets to Loading Python.
> 
> I also get the following error when trying to run a python script from the 
> OSGeo4W shell:
> 
> G:\>zip_data_test.py
> Traceback (most recent call last):
>   File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 563, in 
> main()
>   File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 545, in main
> known_paths = addusersitepackages(known_paths)
>   File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 278, in 
> addusersitepackages
> 
> user_site = getusersitepackages()
>   File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 253, in 
> getusersitepackages
> 
> user_base = getuserbase() # this will also set USER_BASE
>   File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 243, in getuserbase
> USER_BASE = get_config_var('userbase')
>   File "C:\OSGeo4W\apps\Python27\lib\sysconfig.py", line 472, in 
> get_config_var
> return get_config_vars().get(name)
>   File "C:\OSGeo4W\apps\Python27\lib\sysconfig.py", line 405, in 
> get_config_vars
> 
> import re
>   File "C:\OSGeo4W\apps\Python27\lib\re.py", line 105, in 
> import sre_compile
>   File "C:\OSGeo4W\apps\Python27\lib\sre_compile.py", line 14, in 
> import sre_parse
>   File "C:\OSGeo4W\apps\Python27\lib\sre_parse.py", line 17, in 
> from sre_constants import *
>   File "C:\OSGeo4W\apps\Python27\lib\sre_constants.py", line 18, in 
> from _sre import MAXREPEAT
> ImportError: cannot import name MAXREPEAT
> 
> Does anyone here know how to fix this? Is this a problem for the OSGeo4W 
> people instead?
> 
> Many thanks,
> 
> James


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

[Qgis-developer] OSGeo4W QGIS 1.8 Doesnt Work

[Stott James]

Hi all,

I have noticed that since I updated OSGeo4W yesterday, I cannot launch QGIS 
1.8. It stops loading when the splash screen gets to Loading Python.

I also get the following error when trying to run a python script from the 
OSGeo4W shell:

G:\>zip_data_test.py
Traceback (most recent call last):
  File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 563, in 
main()
  File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 545, in main
known_paths = addusersitepackages(known_paths)
  File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 278, in addusersitepackages

user_site = getusersitepackages()
  File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 253, in getusersitepackages

user_base = getuserbase() # this will also set USER_BASE
  File "C:\OSGeo4W\\apps\Python27\lib\site.py", line 243, in getuserbase
USER_BASE = get_config_var('userbase')
  File "C:\OSGeo4W\apps\Python27\lib\sysconfig.py", line 472, in get_config_var
return get_config_vars().get(name)
  File "C:\OSGeo4W\apps\Python27\lib\sysconfig.py", line 405, in get_config_vars

import re
  File "C:\OSGeo4W\apps\Python27\lib\re.py", line 105, in 
import sre_compile
  File "C:\OSGeo4W\apps\Python27\lib\sre_compile.py", line 14, in 
import sre_parse
  File "C:\OSGeo4W\apps\Python27\lib\sre_parse.py", line 17, in 
from sre_constants import *
  File "C:\OSGeo4W\apps\Python27\lib\sre_constants.py", line 18, in 
from _sre import MAXREPEAT
ImportError: cannot import name MAXREPEAT

Does anyone here know how to fix this? Is this a problem for the OSGeo4W people 
instead?

Many thanks,

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