Re: [QGIS-Developer] Changelog entries can be reordered now

[Régis Haubourg]

Hi, Nice!
Cheers,
Régis

2018-02-05 23:31 GMT+01:00 Tim Sutton :

> Hi all
>
> If you are a changelog manager working on the visual changelog, note that
> Etienne Trimaille has added support for drag and drop ordering now of the
> ordering of the entries in the changelog. If you need manager rights please
> contact me with your user name. Thanks Etienne!
>
> Regards
>
> Tim
> —
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Project chair:* QGIS.org
>
> Visit http://kartoza.com to find out about open source:
>
> Desktop GIS programming services
> Geospatial web development
> GIS Training
> Consulting Services
>
> *Skype*: timlinux
> *IRC:* timlinux on #qgis at freenode.net
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Issues with custom forms with Python (in both QGIS 2 and QGIS 3)

[Victor Olaya]

Hi

I am writing documentation about custom forms, but I am encountering some
problems.

In the case of QGIS 2, it seems that there is no way of avoiding the dialog
to be closed when the OK button is clicked. I read this blog post
by
Nathan, in which it disconnects the default 'accepted' signal from the
'dialog.accept' slot. I tried that, but it doesnt seem to be working. It
runs the validation function that I connect to that signal, but even if I
dont accept the dialog in that function, it closes it.

I also tried using the disconnectButtonBox() method of the QgsAttributeForm
class, but it does nothing. The buttons still do their work.

Is this a bug, or I am doing something wrong?

In QGIS3, it seems that now only the ui file can be provided, but not a
python file with the form logic. How is that added now?

Thanks!
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] how to warn user when when reading project XML

[Denis Rouzaud]

Thanks a lot guys, a much clever approach!

Le lun. 5 févr. 2018 à 18:15, Martin Dobias  a écrit :

> On Mon, Feb 5, 2018 at 11:08 PM, Nyall Dawson 
> wrote:
> >
> > For those following at home, Denis and I had a quick brainstorm and
> > settled on the idea of instead extending QgsReadWriteContext to add
> > error collection/reporting there.
>
> Awesome, just wanted to suggest to use that class :-)
>
> Cheers
> Martin
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [734] Locate points along lines approval notification.

[noreply]

Plugin Locate points along lines approval by pcav.
The plugin version "[734] Locate points along lines 0.3" is now approved
Link: http://plugins.qgis.org/plugins/LocatePoints/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Native algorithms not loaded in qgis 2.99

[David Marteau]

Hi All

Using processing from python using latest master branch  (from commit 
325af48680)  have noticed that native (C++) algorithms  are not loaded anymore !

The native provider does not appears in the list of provider
Native algorithms are not usable anymore  (ex 'qgis:joinattributestable')

All others python algorithms are loaded from a Processing.initialize() call.

Is there anything to do to enable native processing algorithms from python ?

Otherwise this would be a regression from 0a17c370f7.


Thx,

David
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Changelog entries can be reordered now

[Tim Sutton]

Hi all 

If you are a changelog manager working on the visual changelog, note that 
Etienne Trimaille has added support for drag and drop ordering now of the 
ordering of the entries in the changelog. If you need manager rights please 
contact me with your user name. Thanks Etienne!

Regards

Tim
—







Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] how to warn user when when reading project XML

[Nyall Dawson]

On 6 February 2018 at 06:33, Denis Rouzaud  wrote:
> Hi all,
>
> I am wondering what's the best way to warn the user when reading XML is not
> going as expected i.e. when an error is encountered.
>
> Here is the path to the method I want to warn from:
>
> QgsProject::read
> QgsProject::readProjectFile
> QgsProject::_getMapLayers
> QgsProject::addLayer
> QgsMapLayer::readLayerXML
> QgsVectorLayer::readXML
> QgsVectorLayer::readSymbology
> QgsEditFormConfig::readXML
>
> I see only two solutions:
>
> 1. Using success return value and some errorMessage.
>  This is partly done in readSymbology but totally incomplete (always returns
> true and errorMessage are not used at all...)
> It would require a finer grain than bool as return value (info / warning /
> error, probably).
> It would probably be a a list of error messages.
>
> 2. Emitting signals.
> But that means bring the connections all the way up to the project by
> connecting and disconnecting the map layers and all other objects during the
> way down. Moreover, many config object are not QObjects.
>
> To me solution 1. sounds nicer but is an API break.
> The small feature I am working on is targeted to 3.2 si I would need to set
> this in place prior to release.
>
> Is there somehting I am missing?

For those following at home, Denis and I had a quick brainstorm and
settled on the idea of instead extending QgsReadWriteContext to add
error collection/reporting there.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS 3 Python Console Python Error

[Nyall Dawson]

On 6 February 2018 at 07:52, C Hamilton  wrote:
> Is anyone else getting this error with the latest QGIS 3 (2.99.0-287) when
> the Python Console is selected from the Plugins menu? I am running on
> Windows 7.
>
> Traceback (most recent call last):
>   File "", line 2, in
>   File "C:/OSGEO4~1/apps/qgis-dev/./python\console\console.py", line 48, in
> show_console
> _console = PythonConsole(parent)
>   File "C:/OSGEO4~1/apps/qgis-dev/./python\console\console.py", line 84, in
> __init__
> self.console = PythonConsoleWidget(self)
>   File "C:/OSGEO4~1/apps/qgis-dev/./python\console\console.py", line 110, in
> __init__
> self.shell = ShellScintilla(self)
>   File "C:/OSGEO4~1/apps/qgis-dev/./python\console\console_sci.py", line 71,
> in __init__
> self.runsource(line)
>   File "C:/OSGEO4~1/apps/qgis-dev/./python\console\console_sci.py", line
> 624, in runsource
> sys.stdout.fire_keyboard_interrupt = False
> AttributeError: 'NoneType' object has no attribute 'fire_keyboard_interrupt'
>
>
> Consequently, no python console is displayed.

Fixed already by Jürgen:

https://github.com/qgis/QGIS/commit/325af486807122db6946dcaeef22236b41f4d512

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] QGIS 3 Python Console Python Error

[C Hamilton]

Is anyone else getting this error with the latest QGIS 3 (2.99.0-287) when
the Python Console is selected from the Plugins menu? I am running on
Windows 7.

Traceback (most recent call last):
  File "", line 2, in
  File "C:/OSGEO4~1/apps/qgis-dev/./python\console\console.py", line 48, in
show_console
_console = PythonConsole(parent)
  File "C:/OSGEO4~1/apps/qgis-dev/./python\console\console.py", line 84, in
__init__
self.console = PythonConsoleWidget(self)
  File "C:/OSGEO4~1/apps/qgis-dev/./python\console\console.py", line 110,
in __init__
self.shell = ShellScintilla(self)
  File "C:/OSGEO4~1/apps/qgis-dev/./python\console\console_sci.py", line
71, in __init__
self.runsource(line)
  File "C:/OSGEO4~1/apps/qgis-dev/./python\console\console_sci.py", line
624, in runsource
sys.stdout.fire_keyboard_interrupt = False
AttributeError: 'NoneType' object has no attribute 'fire_keyboard_interrupt'

Consequently, no python console is displayed.

Thanks,

Calvin
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Helmut Kudrnovsky]

rashadkm wrote
> Hello all,
> 
> Here is a PR to allow integration of otb smoothly. tests are all passing,
> commits are squashed and ready to review.
> https://github.com/qgis/QGIS/pull/6272
> I did a small fix to control visibility of parameter from provider.
> Addition of specific parameter class for OTB is not included in this PR.
> 
> Thanks for feedback
> 
> On Mon, Feb 5, 2018 at 12:20 PM, Helmut Kudrnovsky 

> hellik@

>  wrote:
> 
>> >Otherwise if we don't care and just want to enable others to have QGIS
>> >intgration, they'll have to adopt the plugins.  That might work better
>> if
>> there
>> >is real interest.  But I think they usally prefer their tools to be used
>> in
>> >their own environment and don't care that much about whether it works in
>> QGIS
>> or not.  Is there solid interest of the SAGA or GRASS team to adopt
>> the
>  >providers?  Otherwise I guess they'll sooner or later will die.
>>
>> quickly screened the GRASS MLs, I can't find any entry that the GRASS
>> community was ever asked if there could be e.g. a shared attempt for an
>> automatization to create/maintain the plugin code.
>>
>> Looking at the new OSGeo website:
>>
>> *Desktop Applications*
>>
>> -QGIS Desktop
>> -GRASS GIS
>>
>> *Geospatial Libraries*
>>
>> -Orfeo ToolBox
>> -GDAL/OGR
>>
>> *Meta CRS Initiative*
>>
>> -PROJ4
>>
>> Most of the software mentioned in this thread are projects under the
>> common
>> umbrella of OSGeo.
>>
>> An option may be to ask that OSGeo plays a more proactive role in helping
>> to
>> coordinate and supporting (technically/financally/...) such inter-project
>> challenges.
>>
>> I will forward a short summary of this thread to the GRASS community.

and see here for a follow up in the GRASS community:

http://osgeo-org.1560.x6.nabble.com/Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352828.html
http://osgeo-org.1560.x6.nabble.com/Re-GRASS-user-Keeping-GRASS-OTB-algorithm-in-qgis-processing-td5352836.html




-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] how to warn user when when reading project XML

[Denis Rouzaud]

Hi all,

I am wondering what's the best way to warn the user when reading XML is not
going as expected i.e. when an error is encountered.

Here is the path to the method I want to warn from:

QgsProject::read
QgsProject::readProjectFile
QgsProject::_getMapLayers
QgsProject::addLayer
QgsMapLayer::readLayerXML
QgsVectorLayer::readXML
QgsVectorLayer::readSymbology
QgsEditFormConfig::readXML

I see only two solutions:

1. Using success return value and some errorMessage.
 This is partly done in readSymbology but totally incomplete (always
returns true and errorMessage are not used at all...)
It would require a finer grain than bool as return value (info / warning /
error, probably).
It would probably be a a list of error messages.

2. Emitting signals.
But that means bring the connections all the way up to the project by
connecting and disconnecting the map layers and all other objects during
the way down. Moreover, many config object are not QObjects.

To me solution 1. sounds nicer but is an API break.
The small feature I am working on is targeted to 3.2 si I would need to set
this in place prior to release.

Is there somehting I am missing?

Cheers,
Denis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1305] Calidad-CAR approval notification.

[noreply]

Plugin Calidad-CAR approval by pcav.
The plugin version "[1305] Calidad-CAR 1.0" is now approved
Link: http://plugins.qgis.org/plugins/CalidadCAR/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 05/02/2018 18:00, Rashad Kanavath ha scritto:
> Hello all,
> 
> Here is a PR to allow integration of otb smoothly. tests are all
> passing, commits are squashed and ready to review.
> https://github.com/qgis/QGIS/pull/6272
> I did a small fix to control visibility of parameter from provider.
> Addition of specific parameter class for OTB is not included in this PR.

+1 for the general idea, pending a code review.
Thanks Rashad.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

Hello all,

Here is a PR to allow integration of otb smoothly. tests are all passing,
commits are squashed and ready to review.
https://github.com/qgis/QGIS/pull/6272
I did a small fix to control visibility of parameter from provider.
Addition of specific parameter class for OTB is not included in this PR.

Thanks for feedback

On Mon, Feb 5, 2018 at 12:20 PM, Helmut Kudrnovsky  wrote:

> >Otherwise if we don't care and just want to enable others to have QGIS
> >intgration, they'll have to adopt the plugins.  That might work better if
> there
> >is real interest.  But I think they usally prefer their tools to be used
> in
> >their own environment and don't care that much about whether it works in
> QGIS
>  >providers?  Otherwise I guess they'll sooner or later will die.
>
> quickly screened the GRASS MLs, I can't find any entry that the GRASS
> community was ever asked if there could be e.g. a shared attempt for an
> automatization to create/maintain the plugin code.
>
> Looking at the new OSGeo website:
>
> *Desktop Applications*
>
> -QGIS Desktop
> -GRASS GIS
>
> *Geospatial Libraries*
>
> -Orfeo ToolBox
> -GDAL/OGR
>
> *Meta CRS Initiative*
>
> -PROJ4
>
> Most of the software mentioned in this thread are projects under the common
> umbrella of OSGeo.
>
> An option may be to ask that OSGeo plays a more proactive role in helping
> to
> coordinate and supporting (technically/financally/...) such inter-project
> challenges.
>
> I will forward a short summary of this thread to the GRASS community.
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-
> f4099106.html
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing Help system

[Paolo Cavallini]

Hi Matteo, all,
my proposals, see below:

Il 05/02/2018 14:23, matteo ha scritto:
> Last week I made a call for doc reviewer for the Processing Help System
> docs written till now (thanks to the grant proposal program).
> 
> Pretty most all of the native QGIS algorithm have been described and
> lots of improvements have been made (pictures, better descriptions,
> updated descriptions, etc.).
> 
> At the moment just a small part of the descriptions is available because
> a lot of docs are waiting for a review:
> 
> https://github.com/qgis/QGIS-Documentation/pulls?q=is%3Apr+is%3Aopen+label%3A%22Processing+help%22
> 
> I think these descriptions have to be reviewed before the release.

merge all; if some descriptions have to be improved or corrected, even
avter release; the earlier the merge, the better. having a much improved
help system and not showing it to users does not make sense.
if someone has serious objections please speak out, otherwise I'd just go.

> Also there are also some problems with some link (e.g. when the
> algorithm provider is labeled as *native* and not as *qgis*) and there
> is already a ticket opened [0].

if this is not too difficult, I suggest fixing it (Alaex, could you?).

> Finally: for some other algorithms (e.g. those of SAGA) there is no
> description. Clicking on the help button shows a **Not Found** page.
> What about having a kind of template "this algorithm is not described,
> if you want to help."

redirect all ``docs/user_manual/processing_algs/saga/*`` links to a page
with something like "Help missing - please help us improving this by
sending us your description of this alg" with either a link to a GH page
to be edited or a mailto (is there someone willing to take this review?
Matteo, would yo be available?

If necessart, we could use some additionsl funds from QGIS to finish up
and polish this important work.

All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1362] Advanced Line Editor approval notification.

[noreply]

Plugin Advanced Line Editor approval by pcav.
The plugin version "[1362] Advanced Line Editor 1.0" is now approved
Link: http://plugins.qgis.org/plugins/ale/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Processing Help system

[matteo]

Hi all,

even if not strictly related to the dev list, I'd like to point out my
thoughts here.

Last week I made a call for doc reviewer for the Processing Help System
docs written till now (thanks to the grant proposal program).

Pretty most all of the native QGIS algorithm have been described and
lots of improvements have been made (pictures, better descriptions,
updated descriptions, etc.).

At the moment just a small part of the descriptions is available because
a lot of docs are waiting for a review:

https://github.com/qgis/QGIS-Documentation/pulls?q=is%3Apr+is%3Aopen+label%3A%22Processing+help%22

I think these descriptions have to be reviewed before the release.

Also there are also some problems with some link (e.g. when the
algorithm provider is labeled as *native* and not as *qgis*) and there
is already a ticket opened [0].

Finally: for some other algorithms (e.g. those of SAGA) there is no
description. Clicking on the help button shows a **Not Found** page.
What about having a kind of template "this algorithm is not described,
if you want to help."

Thanks for any thought

Cheers

Matteo


[0] https://issues.qgis.org/issues/17231
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [830] QPackage approval notification.

[noreply]

Plugin QPackage approval by pcav.
The plugin version "[830] QPackage 1.4" is now approved
Link: http://plugins.qgis.org/plugins/QPackage/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [828] QBan(o) approval notification.

[noreply]

Plugin QBan(o) approval by pcav.
The plugin version "[828] QBan(o) 1.3" is now approved
Link: http://plugins.qgis.org/plugins/QBano/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Helmut Kudrnovsky]

>Otherwise if we don't care and just want to enable others to have QGIS
>intgration, they'll have to adopt the plugins.  That might work better if
there
>is real interest.  But I think they usally prefer their tools to be used in
>their own environment and don't care that much about whether it works in
QGIS
providers?  Otherwise I guess they'll sooner or later will die. 

quickly screened the GRASS MLs, I can't find any entry that the GRASS
community was ever asked if there could be e.g. a shared attempt for an
automatization to create/maintain the plugin code.

Looking at the new OSGeo website:

*Desktop Applications*

-QGIS Desktop
-GRASS GIS

*Geospatial Libraries*

-Orfeo ToolBox
-GDAL/OGR

*Meta CRS Initiative*

-PROJ4

Most of the software mentioned in this thread are projects under the common
umbrella of OSGeo.

An option may be to ask that OSGeo plays a more proactive role in helping to
coordinate and supporting (technically/financally/...) such inter-project
challenges.

I will forward a short summary of this thread to the GRASS community.



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Broken 'randomness' for new layer styles?

[Régis Haubourg]

Hi guys,
having default colors is really nice, great to see some work there. But
aren't we in a feature freeze period.?

I plead for the great "release often" mantra that we tend to forget these
times. 4 months between two releases is fairly short most users can live
without perfect random colors.
3.0 is not the holy grail, we'll have plenty of time for new fun features
in the future.

To be more crude, I see no fun in building a gigantic pile of untested new
features. Please also listen the complaints of the documentation team, but
also of the silent clients who try to build there IT plans on QGIS.

Sorry for that,  I like when it's fun, but this time, I really don't get
what makes it critical to do this now, and not within a months in 3.1
branch.

Regards
Régis

2018-02-05 5:48 GMT+01:00 Nyall Dawson :

> On 3 February 2018 at 19:04, Raymond Nijssen 
> wrote:
>
> > I think those colors should be:
> > - not too dark (too close to black)
> > - not too close to grey
> > - not bright yellow, since this is the selection color
>
> Totally agree
>
> > Another thought here, for polygons I find myself changing the standard
> black
> > outline to a darker and opaque version of the fill color. And often I
> prefer
> > using a transparent fill color cause it makes it much easier to viewing
> > results on the background map. Could this be the default or an option?
>
> Me too. However - I don't think this should be default behavior. The
> reason is that if we make the initial outline color a non-desaturated
> color (say dark blue if a polygon layer is assigned a blue fill
> color), then this outline color is kept whenever a
> categorized/graduated style is applied to the layer. So you'd end up
> with classes with different colors (say red/green/yellow) having a
> dark blue outline color. This is going to be ugly, yet a lot of users
> may not notice AND even if they do it's non-trivial to change this for
> new QGIS users.
>
> So I'd rather stick with the safer option and keep the
> "make-the-outline-a-darker-version-of-the-fill" as an advanced users
> tweak.
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] tricontour crashing in QGIS3

[Tom Chadwin]

Hi Chris

Please accept my apologies. Why I didn't see the output in your mail is
beyond me. Thanks.

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] tricontour crashing in QGIS3

[Chris Crook]

Hi Tom

The previous mail did have the backtrace as far as the python interpreter ... 
while I could post the rest of it that will be more layers of python and the 
standard QGIS plugin invocation.  My feeling is that won't add to understanding 
the issue .. but can post if it seems useful to you

Thanks
Chris

From: QGIS-Developer [qgis-developer-boun...@lists.osgeo.org] on behalf of Tom 
Chadwin [tom.chad...@nnpa.org.uk]
Sent: 05 February 2018 10:12
To: qgis-developer@lists.osgeo.org
Subject: Re: [QGIS-Developer] tricontour crashing in QGIS3

Cab you paste a backtrace? I know you described it in the other thread, but I
think the trace itself could help others to investigate.

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



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

Re: [QGIS-Developer] plugin causes 2.99 to crash - help?

[Tom Chadwin]

Jürgen E. Fischer wrote
> So it's far from "drop in"...

Understood. Thanks for the info.

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [481] go2streetview approval notification.

[noreply]

Plugin go2streetview approval by pcav.
The plugin version "[481] go2streetview 7.5" is now approved
Link: http://plugins.qgis.org/plugins/go2streetview/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Il 04/02/2018 12:27, Rashad Kanavath ha scritto:

> If my proposal to keep otb provider in qgis was allowed, then it will be
> two simple steps. But I don't see that happening soon.

nothing is decided yet.

> Anyways, if the provider is a plugin or not, it is important to have api
> to show/hide widgets from algorithm dialog.( see my other mail on
> parameter groups)

I believe this would be useful for other backends too - what is your
opinion?

All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Hi Juergen,

Il 03/02/2018 16:02, Jürgen E. Fischer ha scritto:

> The question is who is the driving force behind the provider plugins.  If we
> want those algorithms in QGIS, we will probably have to maintain the plugins,
> if we don't want them to die.
> 
> Otherwise if we don't care and just want to enable others to have QGIS
> intgration, they'll have to adopt the plugins.  That might work better if 
> there
> is real interest.  But I think they usally prefer their tools to be used in
> their own environment and don't care that much about whether it works in QGIS
> or not.  Is there solid interest of the SAGA or GRASS team to adopt the
> providers?  Otherwise I guess they'll sooner or later will die.

agreed fully

> At the very least the packaging in OSGeo4W will have to adapted.  The easiest
> way would just to remove the dependencies.  This should also kill the current
> problem with the 2GB NSIS limit (GRASS depends on python2, SAGA has wxWidgets,
> OTB Qt4).
> 
> The plugins would be downloaded from within QGIS and instruct the user how
> install the rest of the binaries (eg. from OSGeo4W or other sites (like OTB)).

IMHO anything that does not work out of the box will be just
unaccessible for a large part of users. Standalone packages have been a
key of success for QGIS.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis



signature.asc
Description: OpenPGP digital signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Mon, Feb 5, 2018 at 7:31 AM, Alexander Bruy 
wrote:

> BTW, there is also another possible issue to consider. Where users
> will report tickets related to OTB algorithms and who will address
> them?


Come on!. Users already reports issue to OTB if that is the problem.
Do you know any bugs fixed in OTB processing by QGIS team?
To be fair, the processing plugin is in qgis.  And no matter how you
explain some users doesn't listen.
Are you saying this as a problem or something plugin would solve?


2018-02-05 5:43 GMT+02:00 Nyall Dawson :
> > On 4 February 2018 at 22:27, Rashad Kanavath 
> wrote:
> >
> >> Well, OTB provider plugin will be able to fetch and install otb
> binaries. So
> >> users installing plugin is the extra step needed.
> >> 1. Install QGIS
> >> 2. install otb provider plugin
> >> 3. select/download && install otb package
> >
> > This sounds great - and all the more reason why (in my opinion)
> > publishing the provider as a separate plugin is appropriate. A lot of
> > users will only have to make a couple of clicks and have a fully
> > functional OTB install and processing provider ready to go.
> >
> > On the other hand, I don't think this approach is suitable at all for
> > a core provider. What would you propose to do for Linux users? OTB may
> > or may not be available in their distro's repos (e.g. it's not
> > available for Fedora), so how would the plugin install the dependency
> > in this case? Or what about for Windows users who do not have
> > administrative rights to install software?
> >
> > I personally don't think there's any way to guarantee that OTB (or
> > SAGA for that matter) is available for all QGIS installs, even if we
> > can manually trigger a download and install via a plugin. And if they
> > aren't, then we make things harder for our users, QGIS trainers and
> > support providers -- the feature set of a standard QGIS install will
> > vary greatly depending on the platform it's installed upon and user's
> > privileges on that platform.
> >
> > Nyall
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Alexander Bruy
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Paolo Cavallini]

Hi all,
sorry, I miss a point here: we have a dev who volunteers to maintain a
piece of code. He is quite credible. His proposal minimize the overhead
to QGIS code, and moves much of the complexity to an external sw.
Why do we suggest to keep him out of the door?
All the best.

Il 05/02/2018 06:31, Alexander Bruy ha scritto:
> BTW, there is also another possible issue to consider. Where users
> will report tickets related to OTB algorithms and who will address
> them?
> 
> 2018-02-05 5:43 GMT+02:00 Nyall Dawson :
>> On 4 February 2018 at 22:27, Rashad Kanavath  
>> wrote:
>>
>>> Well, OTB provider plugin will be able to fetch and install otb binaries. So
>>> users installing plugin is the extra step needed.
>>> 1. Install QGIS
>>> 2. install otb provider plugin
>>> 3. select/download && install otb package
>>
>> This sounds great - and all the more reason why (in my opinion)
>> publishing the provider as a separate plugin is appropriate. A lot of
>> users will only have to make a couple of clicks and have a fully
>> functional OTB install and processing provider ready to go.
>>
>> On the other hand, I don't think this approach is suitable at all for
>> a core provider. What would you propose to do for Linux users? OTB may
>> or may not be available in their distro's repos (e.g. it's not
>> available for Fedora), so how would the plugin install the dependency
>> in this case? Or what about for Windows users who do not have
>> administrative rights to install software?
>>
>> I personally don't think there's any way to guarantee that OTB (or
>> SAGA for that matter) is available for all QGIS installs, even if we
>> can manually trigger a download and install via a plugin. And if they
>> aren't, then we make things harder for our users, QGIS trainers and
>> support providers -- the feature set of a standard QGIS install will
>> vary greatly depending on the platform it's installed upon and user's
>> privileges on that platform.
>>
>> Nyall
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> 


-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Example script for Processing in QGIS 3

[G. Allegri]

Thanks Alexander,
guys you're working very fast! Cool.

I will do some testing asap.
Giovanni

Il 5 feb 2018 8:44 AM, "Alexander Bruy"  ha
scritto:

> Starting from b6c2de48 scrips are just usuall Processing algorithms:
> normal or feature-based.
> Testing and feedback are welcome.
>
> 2018-01-29 12:44 GMT+02:00 G. Allegri :
> > Rephrasing what I wrote before, what about dropping ScriptAlgorithm and
> make
> > ScriptAlgorithmProvider simply provide its algorithms from the special
> > scripts folder?
> >
> > giovanni
> >
> >
> >
> > 2018-01-29 10:51 GMT+01:00 G. Allegri :
> >>
> >> Hi Anita,
> >> that's exactly what I also was thinking about. What about dropping
> scripts
> >> in favour of "on the fly"  QgsProcessingAlgorithms?
> >> A single, unified, way of defining them, without the special parameters
> >> syntax of scripts...
> >>
> >> Giovanni
> >>
> >> 2018-01-29 9:55 GMT+01:00 Anita Graser :
> >>>
> >>> I've decided to go the algorithm provider plugin route for my scripts:
> >>> https://anitagraser.com/2018/01/28/porting-processing-
> scripts-to-qgis3/
> >>>
> >>> But I'm also thinking of my students whom I want to show how to write
> >>> tools for QGIS. For many of them, it's their first contact with
> Python, so
> >>> starting a provider plugin is well out of their comfort zone. On the
> other
> >>> hand, the scripts are not very pythonic. Many beginners already had
> issues
> >>> with the QGIS2 version of scripts. I think, they would have an easier
> time
> >>> if they would only have to implement a QgsProcessingAlgorithm with the
> rest
> >>> of the provider plugin complexity hidden from their sight. If that's
> >>> possible.
> >>>
> >>> Regards,
> >>> Anita
> >>>
> >>>
> >>>
> >>>
> >>> On Sat, Jan 27, 2018 at 4:48 PM, G. Allegri 
> wrote:
> 
>  I know Alexander. The point was processing scripts and their future...
> 
>  giovanni
> 
>  Il 27 gen 2018 4:29 PM, "Alexander Bruy" 
> ha
>  scritto:
> >
> > It is possible to write algorithms using same approach as in core.
> Just
> > create
> > "provider plugin" and that's it. This functionality was here almost
> > from the very
> > beginning of the Processing.
> >
> > 2018-01-27 17:08 GMT+02:00 G. Allegri :
> > > Honestly I think script syntax wasn't that bad. At least it was
> quite
> > > easy
> > > for a set of power users, as I could verift during my past courses.
> > > Anyway I agree with the rationale: having a unified, pythonic way,
> to
> > > write
> > > both algorithms and scripts... well, might be the case to
> ultimately
> > > drop
> > > scripts?
> > >
> > > Whatever the choice, we should make users aware of the current
> > > unclear
> > > situation, that things are being discussed and still evolving. This
> > > will
> > > prevent confusion and maybe encourage participation.
> > >
> > > How could this discussion be brought forward? My first question
> would
> > > be: do
> > > we still need scripts?
> > >
> > > In any case thanks to Nyall and the others for the great work! ;)
> > >
> > > Giovanni
> > >
> > >
> > > Il 27 gen 2018 12:15 PM, "Paolo Cavallini" 
> ha
> > > scritto:
> > >>
> > >> Il 27/01/2018 00:39, Nyall Dawson ha scritto:
> > >>
> > >> > It's not too late to improve this for 3.x. Why don't we get the
> > >> > daily
> > >> > Python users and experts involved here and come up with a more
> > >> > Python-like approach to processing scripts?
> > >>
> > >> IMHO this is worth a wider announcement and call for help, if
> > >> possible
> > >> with some kickoff instructions.
> > >> All the best.
> > >>
> > >> --
> > >> Paolo Cavallini - www.faunalia.eu
> > >> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> > >> https://www.google.com/trends/explore?date=all=IT=
> qgis,arcgis
> > >> ___
> > >> QGIS-Developer mailing list
> > >> QGIS-Developer@lists.osgeo.org
> > >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-
> developer
> > >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-
> developer
> > >
> > >
> > > ___
> > > QGIS-Developer mailing list
> > > QGIS-Developer@lists.osgeo.org
> > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-
> developer
> >
> >
> >
> > --
> > Alexander Bruy
> 
> 
>  ___
>  QGIS-Developer mailing list
>  QGIS-Developer@lists.osgeo.org
>  List info: 

Re: [QGIS-Developer] Keeping OTB algorithm in qgis processing

[Rashad Kanavath]

On Mon, Feb 5, 2018 at 4:43 AM, Nyall Dawson  wrote:

> On 4 February 2018 at 22:27, Rashad Kanavath 
> wrote:
>
> > Well, OTB provider plugin will be able to fetch and install otb
> binaries. So
> > users installing plugin is the extra step needed.
> > 1. Install QGIS
> > 2. install otb provider plugin
> > 3. select/download && install otb package
>
> This sounds great - and all the more reason why (in my opinion)
> publishing the provider as a separate plugin is appropriate. A lot of
> users will only have to make a couple of clicks and have a fully
> functional OTB install and processing provider ready to go.
>
> On the other hand, I don't think this approach is suitable at all for
> a core provider. What would you propose to do for Linux users? OTB may
> or may not be available in their distro's repos (e.g. it's not
> available for Fedora), so how would the plugin install the dependency
> in this case? Or what about for Windows users who do not have
> administrative rights to install software?
>

did you checked this package?
https://www.orfeo-toolbox.org//packages/OTB-6.4.0-Linux64.run
and others?
https://www.orfeo-toolbox.org//packages/

We don't need admin rights to install otb. just unzip and it works. Same
for mac and linux.
The dependency is libc and libc++ runtime. And I think any centos6 is our
reference platforms.

Issues you asked is why we introduced binary packages for OTB.


>
> I personally don't think there's any way to guarantee that OTB (or
> SAGA for that matter) is available for all QGIS installs, even if we
> can manually trigger a download and install via a plugin. And if they
> aren't, then we make things harder for our users, QGIS trainers and
> support providers -- the feature set of a standard QGIS install will
> vary greatly depending on the platform it's installed upon and user's
> privileges on that platform.
>
> Nyall
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer