Re: [Qgis-developer] TauDEM problem

[Alexander Bruy]

Hi,

as Victor already said, you need to install and configure TauDEM by
yourself. Please note,
that currently TauDEM provider supports only version 5.0.6 of TauDEM.

If you have TauDEM installed, but plugin don't work, try to execute
same command directly
in console and look if it works.

2013/5/28 marlon.calispa :
> Hi, Im really new in this community and I think its great!!
>
> I´m trying to use the TauDEM extension in the Sextante plugin in my QGIS
> master version 1.9, but when I run the module "Pit remove" I got the
> message: "Oooops! SEXTANTE could not open the following output layers: Pit
> Removed Elevation Grid:
> C:\Users\HIDROT~1\AppData\Local\Temp\sextante\taudempitremovea9b8c8b800f74ac8843709f1aab51c18.tif"
>
> I checked the folder and its empty, and in the log file there is just the
> following:
>
>
> Algorithm Pit Remove started.
> Converting Outputs.
> Loading result layers.
>
> I thought it was a data problem but i have tried with some DEM obtaining the
> same result.
>
> There is any incompatibility problem with this plugin (W7, 64 bits)?
>
> Thanks for you very appreciated help in advance.

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

Re: [Qgis-developer] QGIS 2.0 and beyond

[Marco Hugentobler]

Hi

I agree the release needs to be delayed, but not indefinitely.
My impression until now was that the feature freeze was interpreted in a 
very broad sense. Maybe we could have another period with only bug fixes 
(so no api improvements or new features coming as usability fixes).


Regards,
Marco

On 28.05.2013 06:57, Tim Sutton wrote:


Hi

On Mon, May 27, 2013 at 1:02 PM, Paolo Cavallini 
mailto:cavall...@faunalia.it>> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Il 27/05/2013 12:41, Nathan Woodrow ha scritto:
>> Hey all,
>>
>> So what is the current plans for once QGIS 2.0 is released. Are we 
planning on
>> making minor point releases, or at least weekly builds on a 
different branch for the
>> major platforms e.g 2.0.1. As 2.0 is going to be a massive release 
I have no doubt

>> there might be things that pop up after we have it out the door.
>>
>> Do we have provisions to be able to make easy 2.0.1, 2.0.2 releases?
>
> I think we should try to do it, if at all possible.
> Before that, what is the current plans for the QGIS 2.0 release?

We are waiting for the last feature from Borys to make its way into 
master and then we will be feature complete. Once that is the case I 
will put out a new timetable for getting 2.0 out the door, but you can 
expect delays from the original anticipated early June release.


> I see we have a lot of blockers, and new tickets are flocking in.

Undoubtedly we will have to release with blockers open or delay the 
release.


Tim

> 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/
>
> iEYEARECAAYFAlGjPVEACgkQ/NedwLUzIr4U2ACcDImDY9LMkKDfTOR3+ZCfh4Fo
> cb8An1hO/q7t0sMBHd/pdIdDlXh5S+Rt
> =R3jY
> -END PGP SIGNATURE-
> ___
> 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



--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

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

Re: [Qgis-developer] Updating core plugins

[Victor Olaya]

Thanks!

2013/5/29 Borys Jurgiel :
> Dnia poniedziałek, 27 maja 2013 o 20:44:01 Victor Olaya napisał(a):
>> > Yes, non-core plugin overrides the core one (just because of the Python
>> > path order), so the only thing you can do is to make the core SEXTANTE
>> > version higher - at least QGIS will warn about the override and suggest
>> > manual uninstall.
>>
>> Borys, I think this is not working. I have received reports of people
>> having SEXTANTE 1.0.9 interfering with the core 1.1 version, and I
>> tested it myself. If you have a plugin in .qgis2, it will override the
>> core one (as you mention), but no warning is produced.
>
> You're right, there is a bug. I'll fix it next week.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] setSubsetOfAttributes() doean't work?

[Nathan Woodrow]

Alex,

Seems like a bug.  I just ran into it trying to fix
http://hub.qgis.org/issues/7781

Martin do you have any idea what might be going on?

- Nathan


On Mon, May 13, 2013 at 5:50 PM, Alexander Bruy wrote:

> Hi all,
>
> I try to get features within some rectangle, and want to get only
> some attributes without geometries. So I use next code:
>
> request = QgsFeatureRequest()
> request.setFilterRect(self.extent)
> request.setFlags(QgsFeatureRequest.NoGeometry)
> request.setSubsetOfAttributes([0, 3, 6])
> f = QgsFeature()
> fit = layer.getFeatures(request)
> while fit.nextFeature(f):
>   attrs = f.attributes()
>   # process attributes
>   ...
>
> but in attrs valiable I always get *all* feature attributes. Is this
> bug or maybe I miss something?
>
> Thanks,
> --
> 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] QGIS 2.0 and beyond

[Mathieu Pellerin]

As a first step, could we all individually go to the hub and review our
blockers to possibly remove some blockers that are not crucial to a 2.0
release or dups of previous reports? That would facilitate Giovanni's job.

Also, while ideally a product should be shipped regression-free, this needs
to be balanced with a practical need to actually release a product in a
timely fashion too. People are - at least in Southeast Asia - expecting a
major update of QGIS by mid 2013, and IMO that expectation should be
matched as closely as humanly possible.

Balancing things out would mean let's not ship QGIS with 100 open blockers,
but let's not wait six more months until we reach an elusive 0 blockers :)

M


On Wed, May 29, 2013 at 5:23 AM, Tim Sutton  wrote:

> Hi
>
> On Wed, May 29, 2013 at 12:11 AM, Giovanni Manghi
>  wrote:
> > Hi Tim,
> >
> >
> >> Giovanni could you do a triage of the blocker issue queue - it seems
> >> like some could be removed (e.g. http://hub.qgis.org/issues/7619
> >> could be closed?).
> >
> >
> > yes I can, but (full time) not until later *next* week as I'm Cape
> > Verde to give an extensive QGIS training course.
> >
>
> Thanks Giovanni!
>
> Regards
>
> Tim
>
> > cheers!
>
>
>
> --
> 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
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.0 and beyond

[Tim Sutton]

Hi

On Wed, May 29, 2013 at 12:11 AM, Giovanni Manghi
 wrote:
> Hi Tim,
>
>
>> Giovanni could you do a triage of the blocker issue queue - it seems
>> like some could be removed (e.g. http://hub.qgis.org/issues/7619
>> could be closed?).
>
>
> yes I can, but (full time) not until later *next* week as I'm Cape
> Verde to give an extensive QGIS training course.
>

Thanks Giovanni!

Regards

Tim

> cheers!



--
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] Updating core plugins

[Borys Jurgiel]

Dnia poniedziałek, 27 maja 2013 o 20:44:01 Victor Olaya napisał(a):
> > Yes, non-core plugin overrides the core one (just because of the Python
> > path order), so the only thing you can do is to make the core SEXTANTE
> > version higher - at least QGIS will warn about the override and suggest
> > manual uninstall.
> 
> Borys, I think this is not working. I have received reports of people
> having SEXTANTE 1.0.9 interfering with the core 1.1 version, and I
> tested it myself. If you have a plugin in .qgis2, it will override the
> core one (as you mention), but no warning is produced.

You're right, there is a bug. I'll fix it next week.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.0 and beyond

[Giovanni Manghi]

Hi Tim,


> Giovanni could you do a triage of the blocker issue queue - it seems
> like some could be removed (e.g. http://hub.qgis.org/issues/7619
> could be closed?).


yes I can, but (full time) not until later *next* week as I'm Cape
Verde to give an extensive QGIS training course.

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

Re: [Qgis-developer] Another compiling error at 48 percent

[Pedro Venâncio]

Hi,

This problem persists. I've done tests on two machines and I know that is also 
happening to other people.

I'm using Xubuntu 12.04.

Anyone else confirm? Should I fill out a ticket?

Thanks!
Pedro






- Original Message -
From: Pedro Venâncio
To: qgis-developer
Sent: Sunday, May 26, 2013 5:56 PM
Subject: Another compiling error at 48 percent

Hi,

I'm trying to compile QGIS master and it gives me an error at 48%: 

[ 48%] Building CXX object 
src/gui/CMakeFiles/qgis_gui.dir/moc_qgsfilterlineedit.cxx.o
cd /home/pedro/sextante_github/Quantum-GIS-master/debian/build/src/gui && 
/usr/bin/c++   -Dqgis_gui_EXPORTS -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_SVG_LIB 
-DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_TEST_LIB -DQT_XML_LIB -DQT_SQL_LIB 
-DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_NO_CAST_TO_ASCII -g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security 
-D_FORTIFY_SOURCE=2 -O2  -Wall -Wextra -Wno-long-long -Wformat-security 
-Wno-strict-aliasing -fPIC -I/usr/include/qt4 -I/usr/include/qt4/QtOpenGL 
-I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtWebKit -I/usr/include/qt4/QtGui 
-I/usr/include/qt4/QtTest -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSql 
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtCore 
-I/home/pedro/sextante_github/Quantum-GIS-master/debian/build 
-I/usr/include/qt4/QtUiTools 
-I/home/pedro/sextante_github/Quantum-GIS-master/src/gui 
-I/home/pedro/sextante_github/Quantum-GIS-master/src/gui/symbology-ng
-I/home/pedro/sextante_github/Quantum-GIS-master/src/gui/attributetable 
-I/home/pedro/sextante_github/Quantum-GIS-master/src/gui/../core 
-I/home/pedro/sextante_github/Quantum-GIS-master/src/gui/../core/composer 
-I/home/pedro/sextante_github/Quantum-GIS-master/src/gui/../core/raster 
-I/home/pedro/sextante_github/Quantum-GIS-master/src/gui/../core/symbology-ng 
-I/home/pedro/sextante_github/Quantum-GIS-master/debian/build/src/gui 
-I/home/pedro/sextante_github/Quantum-GIS-master/debian/build/src/gui/../ui 
-I/usr/include/qwt-qt4 -I/usr/include/gdal    -DCORE_EXPORT= -DGUI_EXPORT= 
-DPYTHON_EXPORT= -DANALYSIS_EXPORT= -o 
CMakeFiles/qgis_gui.dir/moc_qgsfilterlineedit.cxx.o -c 
/home/pedro/sextante_github/Quantum-GIS-master/debian/build/src/gui/moc_qgsfilterlineedit.cxx
Linking CXX shared library ../../output/lib/libqgis_gui.so
cd /home/pedro/sextante_github/Quantum-GIS-master/debian/build/src/gui && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/qgis_gui.dir/link.txt 
--verbose=YES
/usr/bin/c++  -fPIC -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -O2  -Wall 
-Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing  
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--no-undefined -shared 
-Wl,-soname,libqgis_gui.so.1.9.0 -o ../../output/lib/libqgis_gui.so.1.9.0 
CMakeFiles/qgis_gui.dir/raster/qgsrasterminmaxwidget.cpp.o 
CMakeFiles/qgis_gui.dir/raster/qgsrasterrendererwidget.cpp.o 
CMakeFiles/qgis_gui.dir/raster/qgsmultibandcolorrendererwidget.cpp.o 
CMakeFiles/qgis_gui.dir/raster/qgspalettedrendererwidget.cpp.o 
CMakeFiles/qgis_gui.dir/raster/qgssinglebandgrayrendererwidget.cpp.o 
CMakeFiles/qgis_gui.dir/raster/qgssinglebandpseudocolorrendererwidget.cpp.o 
CMakeFiles/qgis_gui.dir/raster/qgsrasterhistogramwidget.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsbrushstylecombobox.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgscolorrampcombobox.cpp.o
CMakeFiles/qgis_gui.dir/symbology-ng/qgsdashspacedialog.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsdatadefinedsymboldialog.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgspenstylecombobox.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgssymbollayerv2widget.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsrendererv2widget.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgssinglesymbolrendererv2widget.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgscategorizedsymbolrendererv2widget.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsgraduatedsymbolrendererv2widget.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsrulebasedrendererv2widget.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsrendererv2propertiesdialog.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsstylev2managerdialog.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgssymbollevelsv2dialog.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgssymbolv2selectordialog.cpp.o
CMakeFiles/qgis_gui.dir/symbology-ng/qgsvectorgradientcolorrampv2dialog.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsvectorrandomcolorrampv2dialog.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsvectorcolorbrewercolorrampv2dialog.cpp.o
 CMakeFiles/qgis_gui.dir/symbology-ng/qgscptcitycolorrampv2dialog.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/characterwidget.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsstylev2exportimportdialog.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsellipsesymbollayerv2widget.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgspointdisplacementrendererwidget.cpp.o 
CMakeFiles/qgis_gui.dir/symbology-ng/qgsvectorfi

Re: [Qgis-developer] External calls to SEXTANTE?

[Victor Olaya]

Definitely that sounds interesting, and I guess that SEXTANTE is a
right choice for reimplementing your ideas.

about calling algorithms from python, if you are mainly going to use
GRASS ones, you can probably do it without SEXTANTE, but using
SEXTANTE will allow you to get more functionality.

I would suggest you to start by writing a simple SEXTANTE algorithm
that calls the algorithms needed for you model. I could help you on
that, and then we can see how to maybe take it out of the "normal"
QGIS/SEXTANTE framework to allow it to be executed without the full
QGIS GUI (I uderstand that is what you are looking for)

feel free to contact me if you need more help

2013/5/28 Martin Lacayo :
> Hi Filipe and Victor,
>
> Yes, I am part of the software team working on InVEST. I am currently
> working on transitioning the aesthetic quality (viewshed) model from
> our 2.0 ArcGIS dependent framework to a 3.0 ArcGIS independent
> framework. Part of our 3.0 framework is a standalone QT based GUI, for
> which we hope to enable command line calls (see issue 813 in our
> repository invest-natcap.googlecode.com) eventually, but it currently
> set to a medium priority. I understand that once that is working it
> would be fairly simple to add a wrapper in SEXTANTE, right? There are
> a lot of factors that go into the development decisions for InVEST, so
> while I can't say specifically that there is a plan to bring InVEST to
> QGIS, but the changes we are making should make that very possible.
>
> In the meantime, I am faced with the challenge of transitioning the
> aesthetic quality model away from ArcGIS with the hopes that SEXTANTE
> can address this and other geoalgorithms needs.
>
> Any insight or advice would be much appreciated.
>
> Thank you,
> Martin
>
> On Tue, May 28, 2013 at 1:51 PM, Filipe Dias  wrote:
>> Hi, you are working on InVest right? If so, have you considered making
>> InVest "inside" Sextante Toolbox? In CC I'm copying Victor Olaya, who is the
>> main developer of Sextante so he can help with that.
>>
>> As a QGIS user it's very exciting for me to know that you are working on
>> bringing Invest into QGIS.
>>
>> Regards
>> Filipe Dias
>>
>>
>> On Tue, May 28, 2013 at 7:43 PM, Martin Lacayo  wrote:
>>>
>>> Hello,
>>>
>>> I would like to make external calls to SEXTANTE with a Python script
>>> or via the command line. I'm interested in using all the
>>> geoalgorithms, but in particular I am interested in the GRASS
>>> geoalgorithms, and specifically in r.viewshed at this moment. Is this
>>> possible?
>>>
>>> I found this post which seems very close to answering the question:
>>>
>>>
>>> http://gis.stackexchange.com/questions/28701/how-to-run-sextante-algorithms-outside-of-qgis-python-console/60725#60725
>>>
>>> However when I try calling sextante.runalg I get an error seemingly
>>> related the fact that the code is not being run inside the QGIS Python
>>> console (qgis.utils.iface is None).
>>>
>>> Our FOSS software (naturalcapitalproject.org) is developed on Linux
>>> but packaged for Windows. Any suggestions or advice? We are hoping to
>>> reduce our development time and eliminate duplicated efforts.
>>>
>>> Thank you,
>>> Martin
>>> ___
>>> 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] QGIS 2.0 and beyond

[Tim Sutton]

Hi

On Tue, May 28, 2013 at 11:14 PM, Giovanni Manghi
 wrote:
> Hi Tim,
>
>> ALL the blockers should make QGIS really unusuable, otherwise IMHO
>> they shouldn't be blockers. Many of the items in the blocker list are
>> indeed irritations but I think the blocker list needs to be
>> aggressively pruned of items that aren't actually causing crashes /
>> data corruption or serious inability to use QGIS.
>
> as we agreed in Lyon, a blocker is a regression or a new feature that
> does not work as expected, this is the way I tried to maintain the
> tracker.
>
> I would agree to eventually downgrade a few about new features that
> are not perfect, I do not agree to downgrade any regression.
>

Once we have the last two features (new plugin manager and SIP v2 -
latter being a little bit in question still for me) in the code base
we can embark on a campaign to get the blockers (as curated by
Giovanni) closed.  However strategically we also need to accommodate
the possibility that no fixes may be forthcoming for certain issues,
and decide on some e.g. time limit or other criteria for which a
blocker can remain in the queue before it should be downgraded.

Giovanni could you do a triage of the blocker issue queue - it seems
like some could be removed (e.g. http://hub.qgis.org/issues/7619
could be closed?).

I just want to clarify that my position is not that I *want* to make a
release with blockers, but I also want to avoid that we indefinitely
delay the release without a decent plan of action in place of how to
deal with the blockers.

Regards

Tim


> Cheers!



--
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] QGIS 2.0 and beyond

[Giovanni Manghi]

Hi Tim,

> ALL the blockers should make QGIS really unusuable, otherwise IMHO
> they shouldn't be blockers. Many of the items in the blocker list are
> indeed irritations but I think the blocker list needs to be
> aggressively pruned of items that aren't actually causing crashes /
> data corruption or serious inability to use QGIS.

as we agreed in Lyon, a blocker is a regression or a new feature that
does not work as expected, this is the way I tried to maintain the
tracker.

I would agree to eventually downgrade a few about new features that
are not perfect, I do not agree to downgrade any regression.

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

Re: [Qgis-developer] External calls to SEXTANTE?

[Filipe Dias]

Hi, you are working on InVest right? If so, have you considered making
InVest "inside" Sextante Toolbox? In CC I'm copying Victor Olaya, who is
the main developer of Sextante so he can help with that.

As a QGIS user it's very exciting for me to know that you are working on
bringing Invest into QGIS.

Regards
Filipe Dias


On Tue, May 28, 2013 at 7:43 PM, Martin Lacayo  wrote:

> Hello,
>
> I would like to make external calls to SEXTANTE with a Python script
> or via the command line. I'm interested in using all the
> geoalgorithms, but in particular I am interested in the GRASS
> geoalgorithms, and specifically in r.viewshed at this moment. Is this
> possible?
>
> I found this post which seems very close to answering the question:
>
>
> http://gis.stackexchange.com/questions/28701/how-to-run-sextante-algorithms-outside-of-qgis-python-console/60725#60725
>
> However when I try calling sextante.runalg I get an error seemingly
> related the fact that the code is not being run inside the QGIS Python
> console (qgis.utils.iface is None).
>
> Our FOSS software (naturalcapitalproject.org) is developed on Linux
> but packaged for Windows. Any suggestions or advice? We are hoping to
> reduce our development time and eliminate duplicated efforts.
>
> Thank you,
> Martin
> ___
> 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] QGIS 2.0 and beyond

[Andreas Neumann]

Hi,

To me - if a feature worked in QGIS 1.8 but fails in 2.0 - esp. if we
paid for its development in QGIS 1.8 - then it is also a blocker.

How could I otherwise justify our expenses in QGIS to my boss? Well you
know - we paid for this feature to be developed - but maybe with the
next version it is broken again ...

Andreas

Am 28.05.2013 22:36, schrieb Tim Sutton:
> Hi
> 
> On Tue, May 28, 2013 at 5:37 PM, Giovanni Manghi
>  wrote:
>> Hi,
>>
>>> Undoubtedly we will have to release with blockers
>>
>> please no :)
>> It would be a huge blow to QGIS reputation as there are actually
>> blockers that make QGIS really unusable for any real life job.
> 
> ALL the blockers should make QGIS really unusuable, otherwise IMHO
> they shouldn't be blockers. Many of the items in the blocker list are
> indeed irritations but I think the blocker list needs to be
> aggressively pruned of items that aren't actually causing crashes /
> data corruption or serious inability to use QGIS.
> 
> As I said to Sandro, and as we discuss with each release, we will need
> to make compromises - including considering making a release with a
> known issues list where there are items that we have no strategy in
> place to deal with them.
> 
> Regards
> 
> Tim
> 
>>
>> cheers!
>>
>> -- Giovanni --
>> ___
>> 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
> 

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

Re: [Qgis-developer] QGIS 2.0 and beyond

[Tim Sutton]

Hi

On Tue, May 28, 2013 at 10:33 PM, Matthias Kuhn  wrote:
> For me there is mainly one thing (feature) is missing for QGIS 2.0: The
> upgrade to the new PyQt API (aka. SIP API V2) I would really not want
> to see a QGIS 2.0 without this update. I really hope, that this is
> going to be taken care of by someone.

If there is a candidate for doing the work I would be happy to delay
the release for this. In the absence of a volunteer (or sponsor dev)
to do this, I don't think we should discuss if we can reasonably delay
the release for this.

> We could also look for sponsors to make this more attractive. I
> remember Martin announced once, that he'll be looking into this again,
> but I don't know if this is still valid.
>
> Apart from this, I agree, that releasing QGIS with blockers is not a
> good idea, but also remember, that not every bug which is tagged as a
> blocker necessarily really is a blocker so we might decide to downgrade
> some.

Right that is essentially the same as releasing with blockers since we
are just reclassifying items in the blocker queue to be non-blockers
:-) But seriously yes I agree many items in the queue should not be
classified as blockers IMHO.

Regards

Tim

> ___
> 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] QGIS 2.0 and beyond

[Tim Sutton]

Hi

On Tue, May 28, 2013 at 5:37 PM, Giovanni Manghi
 wrote:
> Hi,
>
>> Undoubtedly we will have to release with blockers
>
> please no :)
> It would be a huge blow to QGIS reputation as there are actually
> blockers that make QGIS really unusable for any real life job.

ALL the blockers should make QGIS really unusuable, otherwise IMHO
they shouldn't be blockers. Many of the items in the blocker list are
indeed irritations but I think the blocker list needs to be
aggressively pruned of items that aren't actually causing crashes /
data corruption or serious inability to use QGIS.

As I said to Sandro, and as we discuss with each release, we will need
to make compromises - including considering making a release with a
known issues list where there are items that we have no strategy in
place to deal with them.

Regards

Tim

>
> cheers!
>
> -- Giovanni --
> ___
> 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] QGIS 2.0 and beyond

[Matthias Kuhn]

For me there is mainly one thing (feature) is missing for QGIS 2.0: The 
upgrade to the new PyQt API (aka. SIP API V2) I would really not want 
to see a QGIS 2.0 without this update. I really hope, that this is 
going to be taken care of by someone.
We could also look for sponsors to make this more attractive. I 
remember Martin announced once, that he'll be looking into this again, 
but I don't know if this is still valid.

Apart from this, I agree, that releasing QGIS with blockers is not a 
good idea, but also remember, that not every bug which is tagged as a 
blocker necessarily really is a blocker so we might decide to downgrade 
some.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.0 and beyond

[Tim Sutton]

Hi

On Tue, May 28, 2013 at 5:48 PM, Sandro Santilli  wrote:
> On Tue, May 28, 2013 at 04:41:24PM +0100, Filipe Dias wrote:
>> I agree with Giovanni. As an end user I'd rather wait a few more months
>> than get an imcomplete version of QGIS 2.0.
>
> +1
>
> Also note that there are currently 10 crasher tickets filed against 1.8.0,
> and even 1 against 1.7.4.
>

And over 100 blockers in the current queue...I don't want to make a
buggy release either but I also don't want to put master in perpetual
feature freeze while we wait for perfection to make itself apparent.

Regards

Tim


> --strk;
>
>> On Tue, May 28, 2013 at 4:37 PM, Giovanni Manghi <
>> giovanni.man...@faunalia.pt> wrote:
>>
>> > Hi,
>> >
>> > > Undoubtedly we will have to release with blockers
>> >
>> > please no :)
>> > It would be a huge blow to QGIS reputation as there are actually
>> > blockers that make QGIS really unusable for any real life job.
>> >
>> > cheers!
>> >
>> > -- Giovanni --
> ___
> 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

[Qgis-developer] changes to raster and vector file loading for files with sublayers

[Etienne Tourigny]

Hi,

I have just pushed a commit to fix the loading of raster and vector files
with sublayers. I have also added 2 files to test this in the testdata
folder.

This may cause some bug(s) that I have not tested for, especially regarding
non-file based data sources.

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

Re: [Qgis-developer] New Icons - difficult to "read"

[Werner Macho]

Hi!

Well I think in different places in the world different icons would be
"usual" ..
It's just about what you are "used" to have ..

Beside the really hard fact that the icons are not too colourful I think
this discussion would last forever ..
With a lot of personal different meanings ..

To speak for my own person .. I am also not satisfied with ALL the icons I
see, but Robert is doing an amazing job and spend a lot of time in creating
this icons .. And I am glad that this iconset is under active development
..
So, as long as I cannot make it better (and provide it) I am just happy
with what is there ..
Thanks to the Creator and active Maintainer of the GIS Iconset .. May it be
used in every OpenSource GIS Software so that we can have a common face to
the outside

kind regards
Werner


On Tue, May 28, 2013 at 9:25 PM, Anita Graser  wrote:

> We used to have a hand icon:
> http://www.flickr.com/photos/38241992@N06/4090679956/
> Wonder if it still exists somewhere. But I admit, it wasn't too good :)
>
> Best wishes,
> Anita
>
>
> On Tue, May 28, 2013 at 5:45 PM, Antonio Locandro <
> antoniolocan...@hotmail.com> wrote:
>
>> Just to reinforce the point raised
>>
>> The pan icon currently in Master are four arrows which are more
>> associated with moving a graphic or a nudge, I would think the most well
>> known symbol for that would be the famous little hand to pan
>>
>> Cheers
>>
>>
>> *Ing. Antonio Locandro*
>> Tegucigalpa, Honduras
>>
>> --
>> From: jonathanmou...@warwickshire.gov.uk
>> Date: Tue, 28 May 2013 15:55:17 +0100
>> To: anitagra...@gmx.at
>>
>> CC: qgis-developer@lists.osgeo.org
>> Subject: Re: [Qgis-developer] New Icons - difficult to "read"
>>
>> Hi Anita,
>>
>> I think we have to be fair and recognize that a GIS is a little more
>> complex than a web browser and will always have more buttons. Many
>> functions which have only one meaning in a simpler application can have
>> different meanings in a GIS depending on context. To simply assume the
>> context from the placement in a certain toolbar could raise other issues.
>>
>>
>> Fair point, but that's why I also compared other GIS's where I could
>> (ArcGIS, MapModeller (FME Data Inspector uses the refresh circle but
>> doesn't have a back/forward feature) and noted that they hold the same
>> convention.
>> Also, that was only one single example, there are others.
>> These days people *expect* certain icons for certain things. To use a
>> different icon throws away the years of pre-training the user will have
>> already have using other applications that stuck to the convention.
>>
>> I don't think I've ever seen a single application that had 10 icons that
>> were mostly the same before in the same that the magnifying glass ones in
>> QGIS 2.0 are.
>>
>> Regards,
>> Jonathan
>>
>> On 28 May 2013 11:11, Anita Graser  wrote:
>>
>> Hi,
>>
>> On Tue, May 28, 2013 at 11:23 AM, Jonathan Moules <
>> jonathanmou...@warwickshire.gov.uk> wrote:
>>
>> +1 for unified data adding button. From a use-perspective there's no good
>> reason that raster adding should be separate from vectors for instance
>> In depth example: take the Back, Next, and Refresh view icons. The new
>> QGIS icons all have a magnifying glass behind them (I can barely make out
>> the "refresh" circle). Why? In comparison, I have four web-browsers in
>> front of me, all have these buttons and all of them are simple
>> arrows/refresh circles. None of them have a picture of a web-page behind
>> them.
>> ArcGIS and MapModeller both use simple arrows/circles too. MapInfo
>> doesn't seem to have this functionality.
>> At this point these icons are standard conventions, but the QGIS 2.0
>> iconography makes that part only 1/6th of the actual icon, instead giving
>> prominence to a magnifying glass that's entirely unnecessary.
>>
>>
>> While I agree to some degree (+1 for unified data adding button), I think
>> we have to be fair and recognize that a GIS is a little more complex than a
>> web browser and will always have more buttons. Many functions which have
>> only one meaning in a simpler application can have different meanings in a
>> GIS depending on context. To simply assume the context from the placement
>> in a certain toolbar could raise other issues.
>>
>> Best wishes,
>> Anita
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>
>> This transmission is intended for the named addressee(s) only and may
>> contain sensitive or protectively marked material up to RESTRICTED and
>> should be handled accordingly. Unless you are the named addressee (or
>> authorised to receive it for the addressee) you may not copy or use it, or
>> disclose it to anyone else. If you have received this transmission in error
>> please notify the sender immediately. All email traffic sent to or from us,
>> including without limitation all GCSX traffi

Re: [Qgis-developer] New Icons - difficult to "read"

[Anita Graser]

We used to have a hand icon:
http://www.flickr.com/photos/38241992@N06/4090679956/
Wonder if it still exists somewhere. But I admit, it wasn't too good :)

Best wishes,
Anita


On Tue, May 28, 2013 at 5:45 PM, Antonio Locandro <
antoniolocan...@hotmail.com> wrote:

> Just to reinforce the point raised
>
> The pan icon currently in Master are four arrows which are more associated
> with moving a graphic or a nudge, I would think the most well known symbol
> for that would be the famous little hand to pan
>
> Cheers
>
>
> *Ing. Antonio Locandro*
> Tegucigalpa, Honduras
>
> --
> From: jonathanmou...@warwickshire.gov.uk
> Date: Tue, 28 May 2013 15:55:17 +0100
> To: anitagra...@gmx.at
>
> CC: qgis-developer@lists.osgeo.org
> Subject: Re: [Qgis-developer] New Icons - difficult to "read"
>
> Hi Anita,
>
> I think we have to be fair and recognize that a GIS is a little more
> complex than a web browser and will always have more buttons. Many
> functions which have only one meaning in a simpler application can have
> different meanings in a GIS depending on context. To simply assume the
> context from the placement in a certain toolbar could raise other issues.
>
>
> Fair point, but that's why I also compared other GIS's where I could
> (ArcGIS, MapModeller (FME Data Inspector uses the refresh circle but
> doesn't have a back/forward feature) and noted that they hold the same
> convention.
> Also, that was only one single example, there are others.
> These days people *expect* certain icons for certain things. To use a
> different icon throws away the years of pre-training the user will have
> already have using other applications that stuck to the convention.
>
> I don't think I've ever seen a single application that had 10 icons that
> were mostly the same before in the same that the magnifying glass ones in
> QGIS 2.0 are.
>
> Regards,
> Jonathan
>
> On 28 May 2013 11:11, Anita Graser  wrote:
>
> Hi,
>
> On Tue, May 28, 2013 at 11:23 AM, Jonathan Moules <
> jonathanmou...@warwickshire.gov.uk> wrote:
>
> +1 for unified data adding button. From a use-perspective there's no good
> reason that raster adding should be separate from vectors for instance
> In depth example: take the Back, Next, and Refresh view icons. The new
> QGIS icons all have a magnifying glass behind them (I can barely make out
> the "refresh" circle). Why? In comparison, I have four web-browsers in
> front of me, all have these buttons and all of them are simple
> arrows/refresh circles. None of them have a picture of a web-page behind
> them.
> ArcGIS and MapModeller both use simple arrows/circles too. MapInfo doesn't
> seem to have this functionality.
> At this point these icons are standard conventions, but the QGIS 2.0
> iconography makes that part only 1/6th of the actual icon, instead giving
> prominence to a magnifying glass that's entirely unnecessary.
>
>
> While I agree to some degree (+1 for unified data adding button), I think
> we have to be fair and recognize that a GIS is a little more complex than a
> web browser and will always have more buttons. Many functions which have
> only one meaning in a simpler application can have different meanings in a
> GIS depending on context. To simply assume the context from the placement
> in a certain toolbar could raise other issues.
>
> Best wishes,
> Anita
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> This transmission is intended for the named addressee(s) only and may
> contain sensitive or protectively marked material up to RESTRICTED and
> should be handled accordingly. Unless you are the named addressee (or
> authorised to receive it for the addressee) you may not copy or use it, or
> disclose it to anyone else. If you have received this transmission in error
> please notify the sender immediately. All email traffic sent to or from us,
> including without limitation all GCSX traffic, may be subject to recording
> and/or monitoring in accordance with relevant legislation.
> ___ 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] How to enable labeling tools to move labels (since last merge of Larry's work)

[Larry Shaffer]

Hi Régis and Michael,

On Mon, May 27, 2013 at 3:53 AM, Larry Shaffer wrote:

> Hi,
>
> On Mon, May 27, 2013 at 2:09 AM, kimaidou  wrote:
>
>> Hi
>>
>> 2013/5/27 HAUBOURG 
>>
>>>  Hi Larry, 
>>> Putting expression item to the bottom of list, and renaming the entries
>>> as follow should be better IMHO, since expression is more advanced:
>>>
>>> “Field types : String, Int, Double”  -> “choose Field ( enable map
>>> tools)”
>>>
>>> “Edit expression” ->” Calculate value with expression (disable map tool)”
>>> 
>>>
>>> Does that sound good?
>>>
>>
>> This sounds good to me, as I had the same problem easilly finding the way
>> to choose fields here.
>>
>
> Switching the order should help. Originally, the button's menu didn't have
> a field's submenu, and the fields were listed at the bottom of the menu (to
> allow for an unknown number of entries). That didn't work well for tables
> with lots of columns, since it often pushed access to expression menu
> actions off the screen; so I made a submenu.
>
> Changing the menu action text to long descriptions, like the proposed one
> for expression, may lead to 'missing' the entry to the submenu while
> mousing that far to the right. The text's width will dictate the total
> width of the menu. This was a problem with the expression string menu
> entry, which is now truncated.
>
> I'd prefer to just explain it better in the text below the buttons and in
> those button's description/tool tip.
>

I've made improvements today to the QgsDataDefinedButton, along the lines
of your suggestions, in commit dd60a34 [0].

Commit message:
Update QgsDataDefinedButton
- Add 'Usage info' functions; displays in description and tool tip
- Reorganize menu, adding conceptual section titles
- Add ability to paste in expression
- Add ability to clear defined expression
- Add check for non-matching data field types
- Add better truncation of expressions in tool tip and menu

Of note, I added the ability to set custom 'Usage info' for each button,
which allowed me to remove the general text "( Define attribute fields to
enable labeling map tools )" from below, and include more descriptive,
contextual information in the tool tip and description popup:

Usage:
In edit mode, layer's relevant labeling map tool is:
  Defined attribute field -> enabled
  Defined expression -> disabled

I would appreciate any further feedback on the button's new menu layout. I
consider the button's functionality to be ready for release, but there is
always room for improvement.  :^)

[0]
https://github.com/qgis/Quantum-GIS/commit/dd60a34fae326fcf28d3415d55140e3488f84d62

Regards,

Larry


> Regards,
>
> Larry
>
>
>
>>
>>> 
>>>
>>> ** **
>>>
>>> [0] https://dl.dropboxusercontent.com/u/72368800/label_dialog.png
>>>
>>> All the best
>>>
>>> Régis
>>>
>>
>>
>> Regards
>> Michael
>>
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] TauDEM problem

[Victor Olaya]

Did you install and configure TauDEM? Unlike SAGA or GRASS, it is not
automatically installed with QGIS for windows when you use the OSGeo4W
installer

2013/5/28 marlon.calispa :
> Hi, Im really new in this community and I think its great!!
>
> I´m trying to use the TauDEM extension in the Sextante plugin in my QGIS
> master version 1.9, but when I run the module "Pit remove" I got the
> message: "Oooops! SEXTANTE could not open the following output layers: Pit
> Removed Elevation Grid:
> C:\Users\HIDROT~1\AppData\Local\Temp\sextante\taudempitremovea9b8c8b800f74ac8843709f1aab51c18.tif"
>
> I checked the folder and its empty, and in the log file there is just the
> following:
>
>
> Algorithm Pit Remove started.
> Converting Outputs.
> Loading result layers.
>
> I thought it was a data problem but i have tried with some DEM obtaining the
> same result.
>
> There is any incompatibility problem with this plugin (W7, 64 bits)?
>
> Thanks for you very appreciated help in advance.
>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/TauDEM-problem-tp5056516.html
> Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] TauDEM problem

[marlon.calispa]

Hi, Im really new in this community and I think its great!!

I´m trying to use the TauDEM extension in the Sextante plugin in my QGIS
master version 1.9, but when I run the module "Pit remove" I got the
message: "Oooops! SEXTANTE could not open the following output layers: Pit
Removed Elevation Grid:
C:\Users\HIDROT~1\AppData\Local\Temp\sextante\taudempitremovea9b8c8b800f74ac8843709f1aab51c18.tif"

I checked the folder and its empty, and in the log file there is just the
following:


Algorithm Pit Remove started.
Converting Outputs.
Loading result layers.

I thought it was a data problem but i have tried with some DEM obtaining the
same result.

There is any incompatibility problem with this plugin (W7, 64 bits)? 

Thanks for you very appreciated help in advance.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/TauDEM-problem-tp5056516.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Grass algorithms doesnt appear in the sextante toolbar

[marlon.calispa]

Thanks, Victor.

I was really confused, and I made the hard stuff I mean the reinstallation,
the registry cleaning, etc, and I totally forgot to check the advanced
mode..

Regards.

Marlon.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Grass-algorithms-doesnt-appear-in-the-sextante-toolbar-tp5056442p5056511.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] External calls to SEXTANTE?

[Martin Lacayo]

Hello,

I would like to make external calls to SEXTANTE with a Python script
or via the command line. I'm interested in using all the
geoalgorithms, but in particular I am interested in the GRASS
geoalgorithms, and specifically in r.viewshed at this moment. Is this
possible?

I found this post which seems very close to answering the question:

http://gis.stackexchange.com/questions/28701/how-to-run-sextante-algorithms-outside-of-qgis-python-console/60725#60725

However when I try calling sextante.runalg I get an error seemingly
related the fact that the code is not being run inside the QGIS Python
console (qgis.utils.iface is None).

Our FOSS software (naturalcapitalproject.org) is developed on Linux
but packaged for Windows. Any suggestions or advice? We are hoping to
reduce our development time and eliminate duplicated efforts.

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

Re: [Qgis-developer] QGIS Server - GetPrint request does not respect text boxes size and position if dynamic content passed

[kimaidou]

Hi again

I reply here because I have just noticed a very cool new feature in QGIS
composer. You can add an HTML box, give a file stored in the disk
containing the HTML code to display in the box. I knew this option. What I
did not notice was the ability to let QGIS create as many pages as
necessary to dispplay the full content of the HTML file related to the box.

So instead of passing long parameter to getPrint text boxes to dynamically
replace the content (html rendered or not), I could use this feature
instead. What is missing for me right now to achieve this goal :
* be able to pass the HTML file path via a parameter. We could use the id
of the HTML item in the composer.
* be able to make it work in getPrint : I managed to create a PDF from QGIS
with the HTML content from a file, but could not via QGIS Server: the HTML
block stays empty. This is not because of X server, because I can use HTML
text for text blocks via the "fake" X server.

Any comment appreciated.

Good evening
Michael


2013/5/28 kimaidou 

>
>
> 2013/5/28 Marco Hugentobler 
>
>>  >So for me, simply removing the adjustSizeToText call would be enough.
>> Or we have to make sure this method does the job correctly, which may be a
>> bit hard to implement : we need to avoid to have >collision with other
>> composition items, etc.
>>
>> The problem is if the client provided text does not fit into the
>> predefined label box.
>>
>
> I agree, but it is better than "now", and quite logical to me : if the
> content does not fit, only the part which fits is visible. This allows the
> output PDF to be like the author wanted to, with the position and size of
> each text box as set in the Composer. And above all, text wraps correctly
> without dynamic resize. We could try to add an option "max length" for the
> text boxes which could be advertised in the getCapabilities ? This way the
> client could warn the user whenever he tries to use a text which too many
> characters ?
>
>
>> It would be good to combine dynamic resize capabilities with line breaks
>> somehow.
>>
>
> I think dynamic resize should be used only if we can use it with line
> breaks.Better respect the position and size defined by the user in QGIS
> composer than having a text item which get so long that it get out of the
> composer limits.
>
>
>
>> I'm open for suggestions.
>>
>
> Thanks, and please forgive my english which sometimes prevents me from
> souding moderate enough. I know that giving ideas is easy and developping
> features is harder !
>
> Some suggestions (I am thinking out loud...)
>
> * new option with max text length, advertised in the getCapabilities
> * linked text boxes. In softwares like Adobe Illustrator, or Scribus
> (open-source), you can link serveral text boxes, so that the text is
> written is the first box then in the linked one if the content does not fit
> the first one.
> * If "linked" text boxes is implemented, the killer feature would have to
> dynamically generate new pages with linked text boxes so that all the
> content is written in as many boxes as necessary to have the full content
> written down.
>
> Sincerely
> Michael
>
>
>
>>
>> Marco
>>
>>
>>
>> On 28.05.2013 11:53, kimaidou wrote:
>>
>> Hi
>>
>>  I just made a small test and commented the line
>> currentLabel->adjustSizeToText();
>>  Then recompile QGIS master and tested it with a classical text box (not
>> html rendered) with a long text.
>>
>>  I personnaly prefer the behaviour when this method is not called : the
>> text box keep the size set by the user in QGIS. And the text wraps when it
>> reaches the right side of the Box. I even tried with "HTML rendered" on
>> (and my fake X Server running), and it worked well too.
>>
>>  At the contrary, when adjustSizeToText is used, the box is transformed
>> in a one line box, which goes to the right of the entire composition (out
>> of it) : text does not wrap.
>>
>>  So for me, simply removing the adjustSizeToText call would be enough. Or
>> we have to make sure this method does the job correctly, which may be a bit
>> hard to implement : we need to avoid to have collision with other
>> composition items, etc.
>>
>>  Regards
>>  Michael
>>
>>
>>
>> 2013/5/28 René-Luc D'Hont 
>>
>>> Hi Marco
>>>
>>>
  I guess yes. 'adjustSizeToText()' works for text, not html. Html
 support for composer label was added recently to the composer label class.
 Please adapt the relevant lines to work with html labels too.
>>>
>>>
>>>  I'll adapt it
>>>
>>>

 >Question for Marco, Why removed label, if the request doesn't define a
 value ? Why not used the default value ?

  The idea was that the web client has the possibility to remove an
 advertised text label completely if it is not used. E.g. if a composition
 defines a text item with id 'author', the web client can simply ignore it
 if it does not want to have author's name printed. Note that the labels
 without ids are not removed as they are considered to b

Re: [Qgis-developer] Grass algorithms doesnt appear in the sextante toolbar

[Victor Olaya]

Marlon

1) Do not reinstall. That will install 1.0.9. The version shipped with
qgis-dev is the most recent. Please, remove the "sextante" folder from
.qgis2/python/plugins to make sure you remove the 1.0.9 version

2) Have you switched to the advanced mode, or are you in the simplified mode?

3) Please, refer to the corresponding SEXTANTE chapter in the QGIS
manual [1] to know more about how this works

Cheers!

[1]http://docs.qgis.org/2.0/html/en/docs/user_manual/sextante/toolbox.html

2013/5/28 marlon.calispa :
> I had some problems with some algorithms in the 1.8 version of QGIS, so I
> decided to install the 1.9 master version of QGIS. It seems to work fine but
> when I activated the sextante toolbox the Grass, Taudem and even the QGIS
> algorithms doesnt appear on it nor in the list nor in the browser.
>
> I have tried activating and deactivating them in the toolbar configuration
> but nothing happens and the algorithms still missing. I have reinstalled the
> plugin through the QGIS plugins fetcher and manually, the result the same.
>
> Could anyone help me with this issue, I need the tools for my classes.
>
> Regards,
>
> Marlon.
>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/Grass-algorithms-doesnt-appear-in-the-sextante-toolbar-tp5056443.html
> Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Python error in master

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 28/05/2013 18:39, Larry Shaffer ha scritto:

>> I just noticed you mentioned 'Packages from debian-nightly, sid,' which I 
>> assume
>> means for QGIS. If the sip.so module is not part of those packages (I would 
>> suspect
>> not), maybe just upgrading your local sip install will fix the issue.
> 
>> Larry
> 
> 
>> I 'fixed' my sip compile error by deleting my build directory's contents 
>> and
>> doing a fresh CMake configure and build.

Hi Larry,
thanks for your reply. My situation is a bit different:
* I have only Debian testing and unstable boxes, clean and up to date
*  python-sip 4.13.3-2
* I installed qgis from jef nightly repo
So I recompiled (dpkg-buildpackage) it myself, but now I get:

qgis.bin: 
/build/buildd-sip4_4.13.3-2-amd64-4XEr_m/sip4-4.13.3/siplib/siplib.c:6400:
sip_api_can_convert_to_enum: asserzione "(((td)->td_flags & 0x0007) == 0x0003)" 
non
riuscita.

Obviously there must be a problem with sip somewhere.
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/

iEYEARECAAYFAlGk6SwACgkQ/NedwLUzIr56QACeOIL08SjiKtnR8PPD2vk2okDL
n1IAoIkqBRhx8jS8sB+c/nhxl6zRluat
=DCLF
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Python error in master

[Larry Shaffer]

Hi Paolo,

On Tue, May 28, 2013 at 10:33 AM, Larry Shaffer wrote:

> Hi Paolo,
>
> On Mon, May 27, 2013 at 9:49 AM, Paolo Cavallini wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Il 27/05/2013 16:04, Paolo Cavallini ha scritto:
>>
>> > RuntimeError: the sip module implements API v8.0 to v8.1 but the
>> qgis.core module
>> > requires API v9.2
>> >
>> > Packages from debian-nightly, sid.
>> > Anything wrong?
>>
>> confirmed on another machine: am I the only one?
>>
>
> Something similar happened to me last week, just after I updated my
> version of sip (manually compiled). Guessing here, but it seems that a
> change in sip version does not trigger any rebuilds of already-built QGIS
> Python modules during subsequent compiling of source code.
>
> However, your error seems to be the reverse of that, almost like an older
> sip version is still installed somewhere on your machine, then found during
> runtime, while the built software referenced the newer version. This may be
> because during compilation, your environment is referencing a different
> version of Python (i.e. newer site-packages/sip.so) or a virtual env, than
> the one used during runtime of the app, which has an older sip.so installed.
>

I just noticed you mentioned 'Packages from debian-nightly, sid,' which I
assume means for QGIS. If the sip.so module is not part of those packages
(I would suspect not), maybe just upgrading your local sip install will fix
the issue.

Larry


> I 'fixed' my sip compile error by deleting my build directory's contents
> and doing a fresh CMake configure and build.
>
> Regards,
>
> Larry
>
>
>
>> 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/
>>
>> iEYEARECAAYFAlGjgJcACgkQ/NedwLUzIr6/JACgmIaMqCp4HIyCbXN6U68ddX5p
>> FW4AmQG0X0gAcnekbgmjqaW9Vf3MwF5C
>> =Hcms
>> -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] Python error in master

[Larry Shaffer]

Hi Paolo,

On Mon, May 27, 2013 at 9:49 AM, Paolo Cavallini wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Il 27/05/2013 16:04, Paolo Cavallini ha scritto:
>
> > RuntimeError: the sip module implements API v8.0 to v8.1 but the
> qgis.core module
> > requires API v9.2
> >
> > Packages from debian-nightly, sid.
> > Anything wrong?
>
> confirmed on another machine: am I the only one?
>

Something similar happened to me last week, just after I updated my version
of sip (manually compiled). Guessing here, but it seems that a change in
sip version does not trigger any rebuilds of already-built QGIS Python
modules during subsequent compiling of source code.

However, your error seems to be the reverse of that, almost like an older
sip version is still installed somewhere on your machine, then found during
runtime, while the built software referenced the newer version. This may be
because during compilation, your environment is referencing a different
version of Python (i.e. newer site-packages/sip.so) or a virtual env, than
the one used during runtime of the app, which has an older sip.so installed.

I 'fixed' my sip compile error by deleting my build directory's contents
and doing a fresh CMake configure and build.

Regards,

Larry



> 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/
>
> iEYEARECAAYFAlGjgJcACgkQ/NedwLUzIr6/JACgmIaMqCp4HIyCbXN6U68ddX5p
> FW4AmQG0X0gAcnekbgmjqaW9Vf3MwF5C
> =Hcms
> -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] QGIS 2.0 and beyond

[Antonio Locandro]

+1
No reason to dish out a QGIS version just to comply with deadline, IMHO its 
better to delay it a bit than to deal with lots of unsatisfied users from bugs 
and crashes
 
 
Ing. Antonio Locandro
Tegucigalpa, Honduras
Need a GPS map for Central America, Asia or South America / Necesitas un mapa 
GPS para Centro America, Asia o Sur America




> Date: Tue, 28 May 2013 17:48:28 +0200
> From: s...@keybit.net
> To: filipesd...@gmail.com
> CC: qgis-developer@lists.osgeo.org; giovanni.man...@faunalia.pt
> Subject: Re: [Qgis-developer] QGIS 2.0 and beyond
> 
> On Tue, May 28, 2013 at 04:41:24PM +0100, Filipe Dias wrote:
> > I agree with Giovanni. As an end user I'd rather wait a few more months
> > than get an imcomplete version of QGIS 2.0.
> 
> +1
> 
> Also note that there are currently 10 crasher tickets filed against 1.8.0,
> and even 1 against 1.7.4.
> 
> --strk;
> 
> > On Tue, May 28, 2013 at 4:37 PM, Giovanni Manghi <
> > giovanni.man...@faunalia.pt> wrote:
> > 
> > > Hi,
> > >
> > > > Undoubtedly we will have to release with blockers
> > >
> > > please no :)
> > > It would be a huge blow to QGIS reputation as there are actually
> > > blockers that make QGIS really unusable for any real life job.
> > >
> > > cheers!
> > >
> > > -- Giovanni --
> ___
> 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] QGIS 2.0 and beyond

[Sandro Santilli]

On Tue, May 28, 2013 at 04:41:24PM +0100, Filipe Dias wrote:
> I agree with Giovanni. As an end user I'd rather wait a few more months
> than get an imcomplete version of QGIS 2.0.

+1

Also note that there are currently 10 crasher tickets filed against 1.8.0,
and even 1 against 1.7.4.

--strk;

> On Tue, May 28, 2013 at 4:37 PM, Giovanni Manghi <
> giovanni.man...@faunalia.pt> wrote:
> 
> > Hi,
> >
> > > Undoubtedly we will have to release with blockers
> >
> > please no :)
> > It would be a huge blow to QGIS reputation as there are actually
> > blockers that make QGIS really unusable for any real life job.
> >
> > cheers!
> >
> > -- Giovanni --
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] New Icons - difficult to "read"

[Antonio Locandro]

Just to reinforce the point raised
The pan icon currently in Master are four arrows which are more associated with 
moving a graphic or a nudge, I would think the most well known symbol for that 
would be the famous little hand to pan

Cheers
 
Ing. Antonio Locandro
Tegucigalpa, Honduras

From: jonathanmou...@warwickshire.gov.uk
Date: Tue, 28 May 2013 15:55:17 +0100
To: anitagra...@gmx.at
CC: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] New Icons - difficult to "read"

Hi Anita,I think we have to be fair and recognize that a GIS is a little more 
complex than a web browser and will always have more buttons. Many functions 
which have only one meaning in a simpler application can have different 
meanings in a GIS depending on context. To simply assume the context from the 
placement in a certain toolbar could raise other issues. 


Fair point, but that's why I also compared other GIS's where I could (ArcGIS, 
MapModeller (FME Data Inspector uses the refresh circle but doesn't have a 
back/forward feature) and noted that they hold the same convention.

Also, that was only one single example, there are others.These days people 
*expect* certain icons for certain things. To use a different icon throws away 
the years of pre-training the user will have already have using other 
applications that stuck to the convention.



I don't think I've ever seen a single application that had 10 icons that were 
mostly the same before in the same that the magnifying glass ones in QGIS 2.0 
are.
Regards,

Jonathan

On 28 May 2013 11:11, Anita Graser  wrote:


Hi,

On Tue, May 28, 2013 at 11:23 AM, Jonathan Moules 
 wrote:



+1 for unified data adding button. From a use-perspective there's no good 
reason that raster adding should be separate from vectors for instance



In depth example: take the Back, Next, and Refresh view icons. The new QGIS 
icons all have a magnifying glass behind them (I can barely make out the 
"refresh" circle). Why? In comparison, I have four web-browsers in front of me, 
all have these buttons and all of them are simple arrows/refresh circles. None 
of them have a picture of a web-page behind them.




ArcGIS and MapModeller both use simple arrows/circles too. MapInfo doesn't seem 
to have this functionality. At this point these icons are standard conventions, 
but the QGIS 2.0 iconography makes that part only 1/6th of the actual icon, 
instead giving prominence to a magnifying glass that's entirely unnecessary.



While I agree to some degree (+1 for unified data adding button), I think we 
have to be fair and recognize that a GIS is a little more complex than a web 
browser and will always have more buttons. Many functions which have only one 
meaning in a simpler application can have different meanings in a GIS depending 
on context. To simply assume the context from the placement in a certain 
toolbar could raise other issues. 



Best wishes,Anita 

___

Qgis-developer mailing list

Qgis-developer@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/qgis-developer







This transmission is intended for the named addressee(s) only and may contain 
sensitive or protectively marked material up to RESTRICTED and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this transmission in error please notify the 
sender immediately. All email traffic sent to or from us, including without 
limitation all GCSX traffic, may be subject to recording and/or monitoring in 
accordance with relevant legislation.
___
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] QGIS 2.0 and beyond

[Filipe Dias]

I agree with Giovanni. As an end user I'd rather wait a few more months
than get an imcomplete version of QGIS 2.0.


On Tue, May 28, 2013 at 4:37 PM, Giovanni Manghi <
giovanni.man...@faunalia.pt> wrote:

> Hi,
>
> > Undoubtedly we will have to release with blockers
>
> please no :)
> It would be a huge blow to QGIS reputation as there are actually
> blockers that make QGIS really unusable for any real life job.
>
> cheers!
>
> -- Giovanni --
> ___
> 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] QGIS 2.0 and beyond

[Giovanni Manghi]

Hi,

> Undoubtedly we will have to release with blockers

please no :)
It would be a huge blow to QGIS reputation as there are actually
blockers that make QGIS really unusable for any real life job.

cheers!

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

Re: [Qgis-developer] New Icons - difficult to "read"

[Jonathan Moules]

Hi Anita,

> I think we have to be fair and recognize that a GIS is a little more
> complex than a web browser and will always have more buttons. Many
> functions which have only one meaning in a simpler application can have
> different meanings in a GIS depending on context. To simply assume the
> context from the placement in a certain toolbar could raise other issues.


Fair point, but that's why I also compared other GIS's where I could
(ArcGIS, MapModeller (FME Data Inspector uses the refresh circle but
doesn't have a back/forward feature) and noted that they hold the same
convention.
Also, that was only one single example, there are others.
These days people *expect* certain icons for certain things. To use a
different icon throws away the years of pre-training the user will have
already have using other applications that stuck to the convention.

I don't think I've ever seen a single application that had 10 icons that
were mostly the same before in the same that the magnifying glass ones in
QGIS 2.0 are.

Regards,
Jonathan

On 28 May 2013 11:11, Anita Graser  wrote:

> Hi,
>
> On Tue, May 28, 2013 at 11:23 AM, Jonathan Moules <
> jonathanmou...@warwickshire.gov.uk> wrote:
>
>> +1 for unified data adding button. From a use-perspective there's no good
>> reason that raster adding should be separate from vectors for instance
>> In depth example: take the Back, Next, and Refresh view icons. The new
>> QGIS icons all have a magnifying glass behind them (I can barely make out
>> the "refresh" circle). Why? In comparison, I have four web-browsers in
>> front of me, all have these buttons and all of them are simple
>> arrows/refresh circles. None of them have a picture of a web-page behind
>> them.
>> ArcGIS and MapModeller both use simple arrows/circles too. MapInfo
>> doesn't seem to have this functionality.
>> At this point these icons are standard conventions, but the QGIS 2.0
>> iconography makes that part only 1/6th of the actual icon, instead giving
>> prominence to a magnifying glass that's entirely unnecessary.
>>
>
> While I agree to some degree (+1 for unified data adding button), I think
> we have to be fair and recognize that a GIS is a little more complex than a
> web browser and will always have more buttons. Many functions which have
> only one meaning in a simpler application can have different meanings in a
> GIS depending on context. To simply assume the context from the placement
> in a certain toolbar could raise other issues.
>
> Best wishes,
> Anita
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Grass algorithms doesnt appear in the sextante toolbar

[marlon.calispa]

I had some problems with some algorithms in the 1.8 version of QGIS, so I
decided to install the 1.9 master version of QGIS. It seems to work fine but
when I activated the sextante toolbox the Grass, Taudem and even the QGIS
algorithms doesnt appear on it nor in the list nor in the browser.

I have tried activating and deactivating them in the toolbar configuration
but nothing happens and the algorithms still missing. I have reinstalled the
plugin through the QGIS plugins fetcher and manually, the result the same.

Could anyone help me with this issue, I need the tools for my classes.

Regards, 

Marlon.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Grass-algorithms-doesnt-appear-in-the-sextante-toolbar-tp5056443.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Server - GetPrint request does not respect text boxes size and position if dynamic content passed

[kimaidou]

2013/5/28 Marco Hugentobler 

>  >So for me, simply removing the adjustSizeToText call would be enough.
> Or we have to make sure this method does the job correctly, which may be a
> bit hard to implement : we need to avoid to have >collision with other
> composition items, etc.
>
> The problem is if the client provided text does not fit into the
> predefined label box.
>

I agree, but it is better than "now", and quite logical to me : if the
content does not fit, only the part which fits is visible. This allows the
output PDF to be like the author wanted to, with the position and size of
each text box as set in the Composer. And above all, text wraps correctly
without dynamic resize. We could try to add an option "max length" for the
text boxes which could be advertised in the getCapabilities ? This way the
client could warn the user whenever he tries to use a text which too many
characters ?


> It would be good to combine dynamic resize capabilities with line breaks
> somehow.
>

I think dynamic resize should be used only if we can use it with line
breaks.Better respect the position and size defined by the user in QGIS
composer than having a text item which get so long that it get out of the
composer limits.



> I'm open for suggestions.
>

Thanks, and please forgive my english which sometimes prevents me from
souding moderate enough. I know that giving ideas is easy and developping
features is harder !

Some suggestions (I am thinking out loud...)

* new option with max text length, advertised in the getCapabilities
* linked text boxes. In softwares like Adobe Illustrator, or Scribus
(open-source), you can link serveral text boxes, so that the text is
written is the first box then in the linked one if the content does not fit
the first one.
* If "linked" text boxes is implemented, the killer feature would have to
dynamically generate new pages with linked text boxes so that all the
content is written in as many boxes as necessary to have the full content
written down.

Sincerely
Michael



>
> Marco
>
>
>
> On 28.05.2013 11:53, kimaidou wrote:
>
> Hi
>
>  I just made a small test and commented the line
> currentLabel->adjustSizeToText();
>  Then recompile QGIS master and tested it with a classical text box (not
> html rendered) with a long text.
>
>  I personnaly prefer the behaviour when this method is not called : the
> text box keep the size set by the user in QGIS. And the text wraps when it
> reaches the right side of the Box. I even tried with "HTML rendered" on
> (and my fake X Server running), and it worked well too.
>
>  At the contrary, when adjustSizeToText is used, the box is transformed in
> a one line box, which goes to the right of the entire composition (out of
> it) : text does not wrap.
>
>  So for me, simply removing the adjustSizeToText call would be enough. Or
> we have to make sure this method does the job correctly, which may be a bit
> hard to implement : we need to avoid to have collision with other
> composition items, etc.
>
>  Regards
>  Michael
>
>
>
> 2013/5/28 René-Luc D'Hont 
>
>> Hi Marco
>>
>>
>>>  I guess yes. 'adjustSizeToText()' works for text, not html. Html
>>> support for composer label was added recently to the composer label class.
>>> Please adapt the relevant lines to work with html labels too.
>>
>>
>>  I'll adapt it
>>
>>
>>>
>>> >Question for Marco, Why removed label, if the request doesn't define a
>>> value ? Why not used the default value ?
>>>
>>>  The idea was that the web client has the possibility to remove an
>>> advertised text label completely if it is not used. E.g. if a composition
>>> defines a text item with id 'author', the web client can simply ignore it
>>> if it does not want to have author's name printed. Note that the labels
>>> without ids are not removed as they are considered to be fix, so not
>>> subject to client text replacement (original meaning of label id was that
>>> this text item is subject to text replacement by web client. Later, the id
>>> has been generalized as an id for every item type).
>>>
>>> Another possibility would be to remove the item only if the client gives
>>> an empty text and use the default text otherwise. What do you think?
>>>
>>
>>
>>  I prefer to remove the label only if the user gives an empty text.
>>  Can I do it ?
>>
>>
>>  Regards,
>>  René-Luc
>>
>>
>> On 27.05.2013 22 <27.05.2013%2022>:23, rldhont wrote:
>>
>>>   Hi Marco and other devs,

 In src/mapserver/qgsconfigparser.cpp:530 we can read :

   //replace label text
   foreach ( QgsComposerLabel *currentLabel, composerLabels )
   {
 QString title = parameterMap.value( currentLabel->id().toUpper() );

 if ( title.isEmpty() )
 {
   //remove exported labels not referenced in the request
   if ( !currentLabel->id().isEmpty() )
   {
 c->removeItem( currentLabel );
 delete currentLabel;
   }
   continue;
 }

 

Re: [Qgis-developer] QGIS Server - GetPrint request does not respect text boxes size and position if dynamic content passed

[Marco Hugentobler]

>So for me, simply removing the adjustSizeToText call would be enough. 
Or we have to make sure this method does the job correctly, which may be 
a bit hard to implement : we need to avoid to have >collision with other 
composition items, etc.


The problem is if the client provided text does not fit into the 
predefined label box. It would be good to combine dynamic resize 
capabilities with line breaks somehow.

I'm open for suggestions.

Marco


On 28.05.2013 11:53, kimaidou wrote:

Hi

I just made a small test and commented the line
currentLabel->adjustSizeToText();
Then recompile QGIS master and tested it with a classical text box 
(not html rendered) with a long text.


I personnaly prefer the behaviour when this method is not called : the 
text box keep the size set by the user in QGIS. And the text wraps 
when it reaches the right side of the Box. I even tried with "HTML 
rendered" on (and my fake X Server running), and it worked well too.


At the contrary, when adjustSizeToText is used, the box is transformed 
in a one line box, which goes to the right of the entire composition 
(out of it) : text does not wrap.


So for me, simply removing the adjustSizeToText call would be enough. 
Or we have to make sure this method does the job correctly, which may 
be a bit hard to implement : we need to avoid to have collision with 
other composition items, etc.


Regards
Michael



2013/5/28 René-Luc D'Hont mailto:rldh...@gmail.com>>

Hi Marco


I guess yes. 'adjustSizeToText()' works for text, not html.
Html support for composer label was added recently to the
composer label class. Please adapt the relevant lines to work
with html labels too. 



I'll adapt it


>Question for Marco, Why removed label, if the request doesn't
define a value ? Why not used the default value ?

The idea was that the web client has the possibility to remove
an advertised text label completely if it is not used. E.g. if
a composition defines a text item with id 'author', the web
client can simply ignore it if it does not want to have
author's name printed. Note that the labels without ids are
not removed as they are considered to be fix, so not subject
to client text replacement (original meaning of label id was
that this text item is subject to text replacement by web
client. Later, the id has been generalized as an id for every
item type).

Another possibility would be to remove the item only if the
client gives an empty text and use the default text otherwise.
What do you think?



I prefer to remove the label only if the user gives an empty text.
Can I do it ?


Regards,
René-Luc


On 27.05.2013 22 :23, rldhont wrote:

Hi Marco and other devs,

In src/mapserver/qgsconfigparser.cpp:530 we can read :

  //replace label text
  foreach ( QgsComposerLabel *currentLabel, composerLabels )
  {
QString title = parameterMap.value(
currentLabel->id().toUpper() );

if ( title.isEmpty() )
{
  //remove exported labels not referenced in the request
  if ( !currentLabel->id().isEmpty() )
  {
c->removeItem( currentLabel );
delete currentLabel;
  }
  continue;
}

currentLabel->setText( title );
currentLabel->adjustSizeToText();
  }

This code is used to draw composer label with value
defined by the QGIS WMS Server Request GetPrint.

The bug defined in the issues #7894
http://hub.qgis.org/issues/7894 is probably du to the
method adjustSizeToText()
Someone can confim it ?

Question for Marco, Why removed label, if the request
doesn't define a value ? Why not used the default value ?

Regards,
René-Luc D'Hont
3Liz
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Dr. Marco Hugentobler

Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch
 http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

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

http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Server - GetPrint request does not respect text boxes size and position if dynamic content passed

[Andreas Neumann]

+1 from me.

I am not using this feature for now but will in the future.

Andreas

Am 28.05.2013 15:36, schrieb Marco Hugentobler:
>>I prefer to remove the label only if the user gives an empty text.
>> Can I do it ?
> 
> No objection from me. Currently, I'm not using the text replacement
> capabilities.
> 

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

Re: [Qgis-developer] QGIS Server - GetPrint request does not respect text boxes size and position if dynamic content passed

[Marco Hugentobler]

>I prefer to remove the label only if the user gives an empty text.
> Can I do it ?

No objection from me. Currently, I'm not using the text replacement 
capabilities.


Marco

On 28.05.2013 11:34, René-Luc D'Hont wrote:

Hi Marco


I guess yes. 'adjustSizeToText()' works for text, not html. Html
support for composer label was added recently to the composer
label class. Please adapt the relevant lines to work with html
labels too. 



I'll adapt it


>Question for Marco, Why removed label, if the request doesn't
define a value ? Why not used the default value ?

The idea was that the web client has the possibility to remove an
advertised text label completely if it is not used. E.g. if a
composition defines a text item with id 'author', the web client
can simply ignore it if it does not want to have author's name
printed. Note that the labels without ids are not removed as they
are considered to be fix, so not subject to client text
replacement (original meaning of label id was that this text item
is subject to text replacement by web client. Later, the id has
been generalized as an id for every item type).

Another possibility would be to remove the item only if the client
gives an empty text and use the default text otherwise. What do
you think?



I prefer to remove the label only if the user gives an empty text.
Can I do it ?


Regards,
René-Luc


On 27.05.2013 22 :23, rldhont wrote:

Hi Marco and other devs,

In src/mapserver/qgsconfigparser.cpp:530 we can read :

  //replace label text
  foreach ( QgsComposerLabel *currentLabel, composerLabels )
  {
QString title = parameterMap.value(
currentLabel->id().toUpper() );

if ( title.isEmpty() )
{
  //remove exported labels not referenced in the request
  if ( !currentLabel->id().isEmpty() )
  {
c->removeItem( currentLabel );
delete currentLabel;
  }
  continue;
}

currentLabel->setText( title );
currentLabel->adjustSizeToText();
  }

This code is used to draw composer label with value defined by
the QGIS WMS Server Request GetPrint.

The bug defined in the issues #7894
http://hub.qgis.org/issues/7894 is probably du to the method
adjustSizeToText()
Someone can confim it ?

Question for Marco, Why removed label, if the request doesn't
define a value ? Why not used the default value ?

Regards,
René-Luc D'Hont
3Liz
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org

http://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Dr. Marco Hugentobler

Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch
 http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

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





--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

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

[Qgis-developer] Rasters: styles vs genetal

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all.
Is there a reason (other than an historical one) why raster Thumbnails, Legend, 
and
Palette are displayed in the General tab? They seem to belong to Style, rather.
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/

iEYEARECAAYFAlGkslYACgkQ/NedwLUzIr65tACfQf6zPTnM//+nmfjTwZn1Tt3K
NnoAmQGiVFeG9cp5U6BvsMn0Lm7Lg4gP
=rdvy
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Rasters in browsre

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all.
I cannot see the rasters listed in the browser: a new bug?
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/

iEYEARECAAYFAlGksbcACgkQ/NedwLUzIr6wvgCgo8S9sNc6+RwhpngS5cqtg+9Y
8hwAoI70bKCsuMHVdRcQihdPFcOv3urX
=ZZs7
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS vs. GEOS geometry validation

[Sandro Santilli]

I'm playing with editing a ~50k vertices polygon with qgis and found
that the QGIS geometry validation takes a lot lot more than the GEOS
one (Settings -> Options -> Digitizing -> Validate geometries).

Is there a reason why QGIS is the default, when GEOS is available ?

--strk;

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

Re: [Qgis-developer] Expression based diagrams ?

[kimaidou]

Hi Matthias,

2013/5/28 Matthias Kuhn 

> Hi Michael,
>
> There is also a feature request open for this
> http://hub.qgis.org/issues/6768
>

Ok, thanks for pointing it.


>
> I think this won't be an option for 2.0 but if there is a sponsor
> around, I could make it for 2.1.


Unfortunately I cannot be the one sponsoring :(


> But we should first think about what
> features this would include.
>

I totally agree. Diagrams have a lot of options, so we must focus on most
wanted options imho.



> Do you see a benefit of having data defined colors? Having the same
> class with different colors on different diagrams seems odd to me. Can
> you give an example of where this might be useful?
>

I forgot to say I would like to use this with text diagrams. I would like
to be able to choose a color (here for the printed text inside each text
diagram slice) depending on data values. For example, print
* slice 1 : temperature in green under 20°C, orange between 20 and 25, red
above 25°C.
* slice 2 : pressure with text color depending on other values
* slice 3: ..., etc.

We could also imagine to draw the "text diagrams" not in a circle, but in a
rectangle, or in honeycomb shapes, etc. The basic idea is to represent some
fields in the same order for each feature (as the text diagram does), and
to use the color (which could be the background color instead of the text
color) in order to represent the value intensity.

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

Re: [Qgis-developer] Expression based diagrams ?

[Matthias Kuhn]

Hi Michael,

There is also a feature request open for this
http://hub.qgis.org/issues/6768

I think this won't be an option for 2.0 but if there is a sponsor 
around, I could make it for 2.1. But we should first think about what 
features this would include.
Do you see a benefit of having data defined colors? Having the same 
class with different colors on different diagrams seems odd to me. Can 
you give an example of where this might be useful?

Matthias

On Die 28 Mai 2013 12:25:05 CEST, kimaidou wrote:
> Hi list
>
> Since a couple of months, a hug work has been made by some devs to
> bring the expression based feature almost everywhere (styling,
> labelling, field calculator, etc.) : a big thank for this.
>
> I would like to know how much effort would be neede to add the
> expressions in the diagrams. For example we could let the user choose
> an expression for
>
> * the value of each class
> * the color of each class.
>
> I have already talked about it on irc, but unfortunately I cannot
> remember with who (sorry...).
>
> Any chance to have it for 2.0 ? (hum hum, I know this is feature freeze )
>
> Michael
>
>
> ___
> 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] new QgsDebugCall macro

[Sandro Santilli]

I've pushed a new debugging macro for use to simplify tracing of
functions enter/exit events.

Use like this:

 void QgsMapToolNodeTool::canvasPressEvent( QMouseEvent * e )
 {
   QgsDebugCall;
   
 }

To get (with debugging builds) log messages like this:

 Debug: src/app/nodetool/qgsmaptoolnodetool.cpp: 348: (canvasPressEvent) 
Entering.
 Debug: src/app/nodetool/qgsmaptoolnodetool.cpp: 348: (canvasPressEvent) 
Leaving.

With non-debugging builds there will be no overhead.

--strk;

 http://strk.keybit.net 

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

[Qgis-developer] Expression based diagrams ?

[kimaidou]

Hi list

Since a couple of months, a hug work has been made by some devs to bring
the expression based feature almost everywhere (styling, labelling, field
calculator, etc.) : a big thank for this.

I would like to know how much effort would be neede to add the expressions
in the diagrams. For example we could let the user choose an expression for

* the value of each class
* the color of each class.

I have already talked about it on irc, but unfortunately I cannot remember
with who (sorry...).

Any chance to have it for 2.0 ? (hum hum, I know this is feature freeze )

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

Re: [Qgis-developer] New Icons - difficult to "read"

[Anita Graser]

Hi,

On Tue, May 28, 2013 at 11:23 AM, Jonathan Moules <
jonathanmou...@warwickshire.gov.uk> wrote:

> +1 for unified data adding button. From a use-perspective there's no good
> reason that raster adding should be separate from vectors for instance
> In depth example: take the Back, Next, and Refresh view icons. The new
> QGIS icons all have a magnifying glass behind them (I can barely make out
> the "refresh" circle). Why? In comparison, I have four web-browsers in
> front of me, all have these buttons and all of them are simple
> arrows/refresh circles. None of them have a picture of a web-page behind
> them.
> ArcGIS and MapModeller both use simple arrows/circles too. MapInfo doesn't
> seem to have this functionality.
> At this point these icons are standard conventions, but the QGIS 2.0
> iconography makes that part only 1/6th of the actual icon, instead giving
> prominence to a magnifying glass that's entirely unnecessary.
>

While I agree to some degree (+1 for unified data adding button), I think
we have to be fair and recognize that a GIS is a little more complex than a
web browser and will always have more buttons. Many functions which have
only one meaning in a simpler application can have different meanings in a
GIS depending on context. To simply assume the context from the placement
in a certain toolbar could raise other issues.

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

Re: [Qgis-developer] QGIS Server - GetPrint request does not respect text boxes size and position if dynamic content passed

[kimaidou]

Hi

I just made a small test and commented the line
currentLabel->adjustSizeToText();
Then recompile QGIS master and tested it with a classical text box (not
html rendered) with a long text.

I personnaly prefer the behaviour when this method is not called : the text
box keep the size set by the user in QGIS. And the text wraps when it
reaches the right side of the Box. I even tried with "HTML rendered" on
(and my fake X Server running), and it worked well too.

At the contrary, when adjustSizeToText is used, the box is transformed in a
one line box, which goes to the right of the entire composition (out of it)
: text does not wrap.

So for me, simply removing the adjustSizeToText call would be enough. Or we
have to make sure this method does the job correctly, which may be a bit
hard to implement : we need to avoid to have collision with other
composition items, etc.

Regards
Michael



2013/5/28 René-Luc D'Hont 

> Hi Marco
>
>
>> I guess yes. 'adjustSizeToText()' works for text, not html. Html support
>> for composer label was added recently to the composer label class. Please
>> adapt the relevant lines to work with html labels too.
>
>
> I'll adapt it
>
>
>>
>> >Question for Marco, Why removed label, if the request doesn't define a
>> value ? Why not used the default value ?
>>
>> The idea was that the web client has the possibility to remove an
>> advertised text label completely if it is not used. E.g. if a composition
>> defines a text item with id 'author', the web client can simply ignore it
>> if it does not want to have author's name printed. Note that the labels
>> without ids are not removed as they are considered to be fix, so not
>> subject to client text replacement (original meaning of label id was that
>> this text item is subject to text replacement by web client. Later, the id
>> has been generalized as an id for every item type).
>>
>> Another possibility would be to remove the item only if the client gives
>> an empty text and use the default text otherwise. What do you think?
>>
>
>
> I prefer to remove the label only if the user gives an empty text.
> Can I do it ?
>
>
> Regards,
> René-Luc
>
>
> On 27.05.2013 22:23, rldhont wrote:
>
>> Hi Marco and other devs,
>>>
>>> In src/mapserver/qgsconfigparser.**cpp:530 we can read :
>>>
>>>   //replace label text
>>>   foreach ( QgsComposerLabel *currentLabel, composerLabels )
>>>   {
>>> QString title = parameterMap.value( currentLabel->id().toUpper() );
>>>
>>> if ( title.isEmpty() )
>>> {
>>>   //remove exported labels not referenced in the request
>>>   if ( !currentLabel->id().isEmpty() )
>>>   {
>>> c->removeItem( currentLabel );
>>> delete currentLabel;
>>>   }
>>>   continue;
>>> }
>>>
>>> currentLabel->setText( title );
>>> currentLabel->**adjustSizeToText();
>>>   }
>>>
>>> This code is used to draw composer label with value defined by the QGIS
>>> WMS Server Request GetPrint.
>>>
>>> The bug defined in the issues #7894 
>>> http://hub.qgis.org/issues/**7894is 
>>> probably du to the method adjustSizeToText()
>>> Someone can confim it ?
>>>
>>> Question for Marco, Why removed label, if the request doesn't define a
>>> value ? Why not used the default value ?
>>>
>>> Regards,
>>> René-Luc D'Hont
>>> 3Liz
>>> __**_
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> http://lists.osgeo.org/**mailman/listinfo/qgis-**developer
>>>
>>
>>
>> --
>> Dr. Marco Hugentobler
>> Sourcepole -  Linux & Open Source Solutions
>> Weberstrasse 5, CH-8004 Zürich, Switzerland
>> marco.hugentobler@sourcepole.**ch 
>> http://www.sourcepole.ch
>> Technical Advisor QGIS Project Steering Committee
>>
>> __**_
>> 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] QGIS Server - GetPrint request does not respect text boxes size and position if dynamic content passed

[René-Luc D'Hont]

Hi Marco


> I guess yes. 'adjustSizeToText()' works for text, not html. Html support
> for composer label was added recently to the composer label class. Please
> adapt the relevant lines to work with html labels too.


I'll adapt it


>
> >Question for Marco, Why removed label, if the request doesn't define a
> value ? Why not used the default value ?
>
> The idea was that the web client has the possibility to remove an
> advertised text label completely if it is not used. E.g. if a composition
> defines a text item with id 'author', the web client can simply ignore it
> if it does not want to have author's name printed. Note that the labels
> without ids are not removed as they are considered to be fix, so not
> subject to client text replacement (original meaning of label id was that
> this text item is subject to text replacement by web client. Later, the id
> has been generalized as an id for every item type).
>
> Another possibility would be to remove the item only if the client gives
> an empty text and use the default text otherwise. What do you think?
>


I prefer to remove the label only if the user gives an empty text.
Can I do it ?


Regards,
René-Luc


On 27.05.2013 22:23, rldhont wrote:

> Hi Marco and other devs,
>>
>> In src/mapserver/qgsconfigparser.**cpp:530 we can read :
>>
>>   //replace label text
>>   foreach ( QgsComposerLabel *currentLabel, composerLabels )
>>   {
>> QString title = parameterMap.value( currentLabel->id().toUpper() );
>>
>> if ( title.isEmpty() )
>> {
>>   //remove exported labels not referenced in the request
>>   if ( !currentLabel->id().isEmpty() )
>>   {
>> c->removeItem( currentLabel );
>> delete currentLabel;
>>   }
>>   continue;
>> }
>>
>> currentLabel->setText( title );
>> currentLabel->**adjustSizeToText();
>>   }
>>
>> This code is used to draw composer label with value defined by the QGIS
>> WMS Server Request GetPrint.
>>
>> The bug defined in the issues #7894 
>> http://hub.qgis.org/issues/**7894is 
>> probably du to the method adjustSizeToText()
>> Someone can confim it ?
>>
>> Question for Marco, Why removed label, if the request doesn't define a
>> value ? Why not used the default value ?
>>
>> Regards,
>> René-Luc D'Hont
>> 3Liz
>> __**_
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/**mailman/listinfo/qgis-**developer
>>
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Weberstrasse 5, CH-8004 Zürich, Switzerland
> marco.hugentobler@sourcepole.**ch 
> http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>
> __**_
> 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] New Icons - difficult to "read"

[Jonathan Moules]

+1 for unified data adding button. From a use-perspective there's no good
reason that raster adding should be separate from vectors for instance.


Relating to the new iconset - I agree with liking the style and see what
it's trying to do. The design philosophy seems to be that there are common
components which are then glued together. A yellow star seems to mean
"new", a magnifying glass means some sort of zoom thing etc.

It's logical, the sort of thing that makes sense to a developer.

The problem is, I don't believe it works. Icons should be
immediately recognisable - if you have 10 (TEN!) icons which have a big
magnifying glass and then only a small portion of the icon is different
between each of them, they become harder to use.

In depth example: take the Back, Next, and Refresh view icons. The new QGIS
icons all have a magnifying glass behind them (I can barely make out the
"refresh" circle). Why? In comparison, I have four web-browsers in front of
me, all have these buttons and all of them are simple arrows/refresh
circles. None of them have a picture of a web-page behind them.
ArcGIS and MapModeller both use simple arrows/circles too. MapInfo doesn't
seem to have this functionality.
At this point these icons are standard conventions, but the QGIS 2.0
iconography makes that part only 1/6th of the actual icon, instead giving
prominence to a magnifying glass that's entirely unnecessary.

Jonathan

On 27 May 2013 23:11, Antonio Locandro  wrote:

> Just a thought, but most of the problems are due to the fact each *add
> feature* has an icon for "quick access". I would simply vote to have an
> unified add data button and then select the data you want, someone has
> proposed something about it but don´t know if it will make it for 2.0 nor
> do I remember the exact reference. IMHO QGIS has way to many icons
> cluttering the UI and using precious space specially on small screen laptops
>
> *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
>
>
>
>
> > Date: Mon, 27 May 2013 23:07:16 +0200
> > From: rob...@szczepanek.pl
> > To: li...@linfiniti.com
> > CC: qgis-developer@lists.osgeo.org
> > Subject: Re: [Qgis-developer] New Icons - difficult to "read"
>
> >
> > Hi Tim,
> >
> > On 25.05.2013 11:06, Tim Sutton wrote:
> > >
> > > @Robert - what about using a background colour scheme whereby e.g. all
> > > add layer icons get the same background colour and then you can remove
> > > e.g. the + and layer picture elements as they are visually grouped.
> > > Just a thought anyway
> >
> > This is an interesting idea, but I'm afraid hard to implement. We could
> > get very strange mixture of colours (location of icons changes...). We
> > could also make one background colour per toolbar. But there are several
> > toolbars and we (man) - in opposite to women - don't recognize so many
> > colours :)
> >
> > Maybe simply skip some icon elements in toolbars, with many similar
> > operations (like add layer)?
> > regards,
> > Robert
> > ___
> > 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
>
>

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer