[QGIS-Developer] Plugin [1102] AequilibraE approval notification.

[noreply]

Plugin AequilibraE approval by pcav.
The plugin version "[1102] AequilibraE 0.4.1" is now approved
Link: http://plugins.qgis.org/plugins/AequilibraE/
___
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

[Alexander Bruy]

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&geo=IT&q=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: 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: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Matplotlib-users] tricontour crashing in QGIS3

[Chris Crook]

Thanks Benhamin.   - I'll certainly look in to that.  The installations are all 
using apt on ubuntu.  Using standard repositories apart from the QGIS nightly 
build.  I'm not sure if QGIS uses qhull directly or indirectly - I'll 
investigate that.  

From: Benjamin Root [ben.v.r...@gmail.com]
Sent: 05 February 2018 11:55
To: Chris Crook
Cc: matplotlib-us...@python.org; qgis-developer@lists.osgeo.org
Subject: Re: [Matplotlib-users] tricontour crashing in QGIS3

Looks like a conflict for the qhull library, which matplotlib vendors and 
builds as a part of its packaging. How did qgis and matplotlib get installed? 
Perhaps they were built with conflicting flags, perhaps? Just a few ideas off 
of the top of my head.

Ben Root


On Sun, Feb 4, 2018 at 3:55 PM, Chris Crook 
mailto:ccr...@linz.govt.nz>> wrote:
I'm looking for help debugging or fixing a problem in matplotlib tricontour.  I 
am using this in a QGIS plugin (www.qgis.org).  The call 
to tricontour causes QGIS to crash.   Running python3 on ubuntu 16.04 
(matplotlib 1.5.1) and 17.10 (matplotlib 2.0.0).

Running in the debugger gives the following result

Thread 1 "qgis.bin" received signal SIGSEGV, Segmentation fault.
0x7fff4f7ca098 in qh_initstatistics ()
   from 
/usr/lib/python3/dist-packages/matplotlib/_qhull.cpython-35m-x86_64-linux-gnu.so
#0  0x7fff4f7ca098 in qh_initstatistics ()
   from 
/usr/lib/python3/dist-packages/matplotlib/_qhull.cpython-35m-x86_64-linux-gnu.so
#1  0x7fff4f7c6f82 in qh_initqhull_start ()
   from 
/usr/lib/python3/dist-packages/matplotlib/_qhull.cpython-35m-x86_64-linux-gnu.so
#2  0x7fff4f7d12bc in qh_new_qhull ()
   from 
/usr/lib/python3/dist-packages/matplotlib/_qhull.cpython-35m-x86_64-linux-gnu.so
#3  0x7fff4f7a3821 in ?? ()
   from 
/usr/lib/python3/dist-packages/matplotlib/_qhull.cpython-35m-x86_64-linux-gnu.so
#4  0x7fff5d977039 in PyCFunction_Call ()
   from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#5  0x7fff5da831b5 in PyEval_EvalFrameEx ()
   from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#6  0x7fff5db13cac in ?? ()
   from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#7  0x7fff5db13d83 in PyEval_EvalCodeEx ()
   from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#8  0x7fff5d99bad8 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0


The python code is

np.save('/home/chris/temp/data.x',x)
np.save('/home/chris/temp/data.y',y)
np.save('/home/chris/temp/data.z',z)
np.save('/home/chris/temp/data.l',levels)
print("Extend",repr(extend))
cs = plt.tricontour(x, y, z, levels, extend=extend)

I've called matplotlib from a simple python script using the saved data 
(np.save) in a simply python script and it runs without problem, so the problem 
appears to arise running within the QGIS3 python environment.

Can you suggest any reason why it might be different running from within QGIS 
and how I can work around/fix this!

Thanks
Chris Crook



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.
___
Matplotlib-users mailing list
matplotlib-us...@python.org
https://mail.python.org/mailman/listinfo/matplotlib-users

___
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 execute and import into spatialite eerrors

[matteo]

oh you guys are fast!

thanks Salvatore and Nyall!

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

[Alexander Bruy]

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



-- 
Alexander Bruy
___
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?

[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

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

[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

Re: [QGIS-Developer] Processing execute and import into spatialite eerrors

[Nyall Dawson]

On 4 February 2018 at 22:54, matteo  wrote:
> Hi dev,
>
> it seems that both "Import into SL" and "Sl execute query" are broken.

Fixed in master.

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] tricontour crashing in QGIS3

[Tom Chadwin]

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

[QGIS-Developer] tricontour crashing in QGIS3

[Chris Crook]

I'm looking for help debugging or fixing a problem in matplotlib tricontour.  I 
am using this in a QGIS plugin (www.qgis.org).  The call to tricontour causes 
QGIS to crash.   Running python3 on ubuntu 16.04 (matplotlib 1.5.1) and 17.10 
(matplotlib 2.0.0).

Running in the debugger gives the following result

Thread 1 "qgis.bin" received signal SIGSEGV, Segmentation fault.
0x7fff4f7ca098 in qh_initstatistics ()
   from 
/usr/lib/python3/dist-packages/matplotlib/_qhull.cpython-35m-x86_64-linux-gnu.so
#0  0x7fff4f7ca098 in qh_initstatistics ()
   from 
/usr/lib/python3/dist-packages/matplotlib/_qhull.cpython-35m-x86_64-linux-gnu.so
#1  0x7fff4f7c6f82 in qh_initqhull_start ()
   from 
/usr/lib/python3/dist-packages/matplotlib/_qhull.cpython-35m-x86_64-linux-gnu.so
#2  0x7fff4f7d12bc in qh_new_qhull ()
   from 
/usr/lib/python3/dist-packages/matplotlib/_qhull.cpython-35m-x86_64-linux-gnu.so
#3  0x7fff4f7a3821 in ?? ()
   from 
/usr/lib/python3/dist-packages/matplotlib/_qhull.cpython-35m-x86_64-linux-gnu.so
#4  0x7fff5d977039 in PyCFunction_Call ()
   from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#5  0x7fff5da831b5 in PyEval_EvalFrameEx ()
   from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#6  0x7fff5db13cac in ?? ()
   from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#7  0x7fff5db13d83 in PyEval_EvalCodeEx ()
   from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0
#8  0x7fff5d99bad8 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0


The python code is

np.save('/home/chris/temp/data.x',x)
np.save('/home/chris/temp/data.y',y)
np.save('/home/chris/temp/data.z',z)
np.save('/home/chris/temp/data.l',levels)
print("Extend",repr(extend))
cs = plt.tricontour(x, y, z, levels, extend=extend)

I've called matplotlib from a simple python script using the saved data 
(np.save) in a simply python script and it runs without problem, so the problem 
appears to arise running within the QGIS3 python environment.

Can you suggest any reason why it might be different running from within QGIS 
and how I can work around/fix this!

Thanks
Chris Crook



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] Editing rule based labeling with the new QGIS3 python API

[Dominique Lyszczarz]

ok I found the solution, it was because I use an expression for labeling
and I had forgotten to set QgsPalLayerSettings().isExpression to True.

Thanks again for your time.

2018-02-04 14:15 GMT+01:00 Martin Dobias :

> On Sun, Feb 4, 2018 at 1:36 PM, Dominique Lyszczarz 
> wrote:
> >
> > I have another question : after settings some labeling rules with pyqgis,
> > the labels are not displaying but if I just enter the rule settings
> through
> > the gui and directly exit it without changing anything then the labels
> are
> > displayed correctly. Is there any register action needed for each rule
> that
> > I forgot in my code ?
>
> It is hard to say without seeing a code snippet that I could run
> myself. Does it help if you force map refresh (e.g. by moving the map
> a bit or zooming in/out)? It is also worth playing with "simple"
> labeling in pyqgis first as that might help you understand whether it
> is just a problem of rule-based labeling or it applies to simple
> labeling as well.
>
> 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

Re: [QGIS-Developer] Editing rule based labeling with the new QGIS3 python API

[Martin Dobias]

On Sun, Feb 4, 2018 at 1:36 PM, Dominique Lyszczarz  wrote:
>
> I have another question : after settings some labeling rules with pyqgis,
> the labels are not displaying but if I just enter the rule settings through
> the gui and directly exit it without changing anything then the labels are
> displayed correctly. Is there any register action needed for each rule that
> I forgot in my code ?

It is hard to say without seeing a code snippet that I could run
myself. Does it help if you force map refresh (e.g. by moving the map
a bit or zooming in/out)? It is also worth playing with "simple"
labeling in pyqgis first as that might help you understand whether it
is just a problem of rule-based labeling or it applies to simple
labeling as well.

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] Processing execute and import into spatialite eerrors

[matteo]

Hi dev,

it seems that both "Import into SL" and "Sl execute query" are broken.

I get this stacktrace when opening the algorithm:


TypeError: QComboBox.findText(str, Qt.MatchFlags
flags=Qt.MatchExactly|Qt.MatchCaseSensitive): argument 1 has unexpected
type 'bool'
Traceback (most recent call last):
  File
"/home/matteo/lavori/QGIS/build-qgis3/output/python/plugins/processing/gui/ProcessingToolbox.py",
line 304, in executeAlgorithm
dlg = AlgorithmDialog(alg)
  File
"/home/matteo/lavori/QGIS/build-qgis3/output/python/plugins/processing/gui/AlgorithmDialog.py",
line 69, in __init__
self.setMainWidget(self.getParametersPanel(alg, self))
  File
"/home/matteo/lavori/QGIS/build-qgis3/output/python/plugins/processing/gui/AlgorithmDialog.py",
line 76, in getParametersPanel
return ParametersPanel(parent, alg)
  File
"/home/matteo/lavori/QGIS/build-qgis3/output/python/plugins/processing/gui/ParametersPanel.py",
line 82, in __init__
self.initWidgets()
  File
"/home/matteo/lavori/QGIS/build-qgis3/output/python/plugins/processing/gui/ParametersPanel.py",
line 119, in initWidgets
wrapper = WidgetWrapperFactory.create_wrapper(param, self.parent)
  File
"/home/matteo/lavori/QGIS/build-qgis3/output/python/plugins/processing/gui/wrappers.py",
line 1556, in create_wrapper
return WidgetWrapperFactory.create_wrapper_from_class(param, dialog,
row, col)
  File
"/home/matteo/lavori/QGIS/build-qgis3/output/python/plugins/processing/gui/wrappers.py",
line 1618, in create_wrapper_from_class
return wrapper(param, dialog, row, col)
  File
"/home/matteo/lavori/QGIS/build-qgis3/output/python/plugins/processing/gui/wrappers.py",
line 151, in __init__
self.setValue(param.defaultValue())
  File
"/home/matteo/lavori/QGIS/build-qgis3/output/python/plugins/processing/gui/wrappers.py",
line 1323, in setValue
if self.combo.findText(value) >= 0:
TypeError: QComboBox.findText(str, Qt.MatchFlags
flags=Qt.MatchExactly|Qt.MatchCaseSensitive): argument 1 has unexpected
type 'bool'


I can use SL data from browser, db manager, etc..

Should I open a ticket?

Thanks!

Matteo
___
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] Editing rule based labeling with the new QGIS3 python API

[Dominique Lyszczarz]

Thank you very much Martin for this quick fix, tested this morning and it
works as expected now.

I have another question : after settings some labeling rules with pyqgis,
the labels are not displaying but if I just enter the rule settings through
the gui and directly exit it without changing anything then the labels are
displayed correctly. Is there any register action needed for each rule that
I forgot in my code ?

2018-02-03 22:34 GMT+01:00 Martin Dobias :

> Hi Dominique
>
> On Sat, Feb 3, 2018 at 11:24 AM, Dominique Lyszczarz 
> wrote:
> >
> > Unfortunately I can't find how to iterate over existing rules, the
> > labeling() method available for vector layers return an object of
> > QgsAbstractVectorLayerLabeling class
>
> That should be fixed on master now:
> https://github.com/qgis/QGIS/commit/4b365a8f47d96b35f7609859e58038
> 8927ae0606
>
> 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

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

[Rashad Kanavath]

On Sat, Feb 3, 2018 at 5:02 PM, Jürgen E. Fischer  wrote:

> Hi Paolo,
>
> On Thu, 01. Feb 2018 at 11:57:28 +, Paolo Cavallini wrote:
> > Il 01/02/2018 11:51, Alexander Bruy ha scritto:
> > > IMHO, if it is really important for them, they should find a way to
> contact
> > > devs and support development.
>
> > > R provider was removed from core in May 2017 and as far as I can see
> nobody
> > > asked about it in mailing lists. So I suppose it is not important.
>
> > unfortunately users are often silent. but I agree, this is a way of
> > stimulating they reactions.
>
> I guess they'll start complaining once the find that GRASS and SAGA have
> been
> removed from the windows standalone.  Before hardly anyone will notice -
> just
> like nobody noticed that there were more hidden providers, because their
> dependencies were not installed and in turn nobody missed them, when they
> were
> removed again.
>
> 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.
>
> 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).
>

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

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.

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)


>
> 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)).
>
> There could also be processing provider plugin packages in OSGeo4W that
> have
> the providers and depend on available binaries there.  Although those
> packages
> would need to be available for all or a selection of qgis packages (qgis,
> qgis-rel-dev, qgis-ltr, qgis-ltr-dev and qgis-dev).
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel.
> +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax.
> +49-4931-918175-50
> Software Engineer   D-26506 Norden
> http://www.norbit.de
>
> ___
> 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] Saving New Map View(s)

[Richard Duivenvoorde]

On 03-02-18 23:24, Nyall Dawson wrote:
> On 3 February 2018 at 19:23, Richard Duivenvoorde  wrote:
>> On 03-02-18 09:38, Paolo Cavallini wrote:
>>> Il 03/02/2018 00:44, Nyall Dawson ha scritto:
>>>
 No, you're correct. Closing the view deletes it and removes it from
 the project. What would you suggest happens here?
>>>
>>> IMHO this ends up in erasign user data without warning, which is a
>>> serious bug. A warning before closing could suffice.
>>
>> Yes, I agree: only warn the user 'if you close this view, it will not be
>> saved in your project' or something like that.
> 
> Sounds reasonable. Can you file a regression covering this and assign to me?

Done,

https://issues.qgis.org/issues/18039

Thanks,

Richard
___
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?

[Richard Duivenvoorde]

On 03-02-18 23:19, Nyall Dawson wrote:
>> Plan sounds great, but I think we should not try to do this for 3.0.
>> The old 'random' colors are ok for now, there are really too much issues
>> in current master to fix, which will affect average users.
> The difference is - fixing the default color assignment is a FUN
> project, and something I'm motivated to tackle before release.
> 
> On the contrast... if I have to look at any more Python binding
> issues/memory leaks/object conversion code, I'm likely to end up in a
> catatonic state and be no use to anyone!

Ok, then  go go.. let there be love and colors all over QGIS :-)
___
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