Re: [QGIS-Developer] Inconsistency in QgsServerRequest parameter handling ?

[Alessandro Pasotti]

On Wed, Apr 10, 2019 at 11:37 PM David Marteau  wrote:

>
> > Le 10 avr. 2019 à 23:21, pblottiere  a
> écrit :
> >
> > Hi David,
> >
> >
> >> If you try:
> >>
> >> request.setParameter('FOOBAR','foobar')
> >>
> >> then
> >>
> >> request.parameter('FOOBAR')
> >>
> >> then you get an empty string,
> >>> Even if I add  an 'allowed' parameter by hand:
> >>>
>  request.setParameter('FI_POINT_TOLERANCE','25')
> >
> > Actually, QgsServerRequest and QgsServerParameters are high level
> > classes which are not aware of valid parameters defined in services. For
> > example, FI_POINT_TOLERANCE is a valid parameter in WMS service, and
> > defined within the WMS module. But it's totally encapsulated within the
> > module (a shared library so), and considered as unknown from
> > QgsServerParameters. The only valid parameters from the
> > QgsServerParameters point of view are those which are common for all
> > services (WMS, WFS, and so on) like SERVICE, VERSION, REQUEST, ...
> >
> > If you want to retrieve the full query from the request without any
> > filter on valid parameters, you may use request.url(). However, I think
> > we could probably add a fallback on the `parameter()` method to return
> > invalid parameters too. I'll do a PR tomorrow and I'll ping you to check
> > if the behaviour suits you.
> >
> >
>
> Yes, this is what I was thinking about Looking at the code: maybe adding a
> lookup to the 'unmanaged' parameters if the code is not found should
> restore the symmetry setParameter/parameter.
>
> I'm standing from the python plugin's point of view - services and
> filters: plugins are expecting some behavior when setting/getting
> parameters. If a plugin override a parameter it can only doing it using the
> requestHandler which is aware
> only of the  base QgsServerParameters owned by the  QgsServerRequest
> instance, so they should be able to set/get parameters in a transparent way.
>
> Regards
>
> David.
>
>
Hi David,

that makes sense, I agree completely, it's odd I didn't catch this issue
before during one of my tests with plugins, I often use parameters to pass
information around within plugins.

May I suggest that we add a test case to protect the changes when done?

Thanks!



> > Regards,
> >
> > Paul
> >
> >
> > On 4/10/19 10:37 PM, David Marteau wrote:
> >> To add some precision:
> >>
> >> Even if I add  an 'allowed' parameter by hand:
> >>
> >>> request.setParameter('FI_POINT_TOLERANCE','25')
> >> then
> >>
> >>> request.parameter('FI_POINT_TOLERANCE')
> >> return an empty string
> >>
> >>> Le 10 avr. 2019 à 19:46, David Marteau  a écrit :
> >>>
> >>>
> >>> Hi devs,
> >>>
> >>> I found a strange and seemingly inconsistent behavior when accessing
> QgsServerRequest parameters:
> >>>
> >>> If you try:
> >>>
> >>> request.setParameter('FOOBAR','foobar')
> >>>
> >>> then
> >>>
> >>> request.parameter('FOOBAR')
> >>>
> >>> then you get an empty string,
> >>>
> >>> If you call
> >>>
> >>> request.parameters()
> >>>
> >>> Then your get a dictionary with all the values previously set.
> >>>
> >>> At first glance it seems that request.setParameter enforce use of a
> limited set of keys (SERVICE…..
> >>>
> >>> This does not seem very consistent with the fact parameter() should
> return any value previously set with setParameter and also the fact that
> >>> request.parameters()  return all previously defined  parameters
> key/values .
> >>>
> >>> Furthemore this may be  problematic with plugins that define services
> in python and thus may define any other set of allowed parameters.
> >>>
> >>> Should I open an issue ?
> >>>
> >>> 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



-- 
Alessandro Pasotti
w3:   www.itopen.it
___
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] Advice? Sneaky trick for call out labels

[Tim Sutton]

To clarify a little, I am trying to avoid the label text crossing the call-out 
line.

Regards

Tim

> On 10 Apr 2019, at 23:02, Tim Sutton  wrote:
> 
> Hi Friends
> 
> So I am using logic like this* to make call out labels using a geometry 
> generator:
> 
> make_line(
>   closest_point($geometry,
>   make_point( "auxiliary_storage_labeling_positionx" , 
> "auxiliary_storage_labeling_positiony" )),
>   make_point( "auxiliary_storage_labeling_positionx" , 
> "auxiliary_storage_labeling_positiony" )
> )
> 
> The line runs from the closest point along the edge of the polygon to the 
> bottom left corner of the label box. With this configuration it works well 
> when my ‘lollipop’ callout label is north-east of the polygon being labelled:
> 
> 
> 
> But doesn’t work when the label is e.g. south west of the polygon:
> 
> 
> 
> Now I am wondering if we have any options for getting the geometry of the 
> label box so I can do the reverse and get the closest point along the edge of 
> the label box to the polygon being labelled. So my question:
> 
> Is there any sneaky trick for getting the geometry of the label box for a 
> feature in an expression? And no, using an opaque background for my label to 
> mask away the call out line doesn’t really hack it. I know the label box 
> isn’t being calculated at the time the polygon is being rendered so the 
> answer is probably ’no’ but maybe someone else has a clever idea to make may 
> lollipops work when labels are south (or east or west for that matter) of the 
> feature being labelled?
> 
> Thanks!
> 
> Regards
> 
> Tim
> 
> 
> 
> —
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Tim Sutton
> 
> Co-founder: Kartoza
> Ex 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 
> 
> I'd love to connect. Here's my calendar link  
> to make finding time easy.
> 

—









Tim Sutton

Co-founder: Kartoza
Ex 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

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
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] Advice? Sneaky trick for call out labels

[Tim Sutton]

Hi Friends

So I am using logic like this* to make call out labels using a geometry 
generator:

make_line(
  closest_point($geometry,
  make_point( "auxiliary_storage_labeling_positionx" , 
"auxiliary_storage_labeling_positiony" )),
  make_point( "auxiliary_storage_labeling_positionx" , 
"auxiliary_storage_labeling_positiony" )
)

The line runs from the closest point along the edge of the polygon to the 
bottom left corner of the label box. With this configuration it works well when 
my ‘lollipop’ callout label is north-east of the polygon being labelled:



But doesn’t work when the label is e.g. south west of the polygon:



Now I am wondering if we have any options for getting the geometry of the label 
box so I can do the reverse and get the closest point along the edge of the 
label box to the polygon being labelled. So my question:

Is there any sneaky trick for getting the geometry of the label box for a 
feature in an expression? And no, using an opaque background for my label to 
mask away the call out line doesn’t really hack it. I know the label box isn’t 
being calculated at the time the polygon is being rendered so the answer is 
probably ’no’ but maybe someone else has a clever idea to make may lollipops 
work when labels are south (or east or west for that matter) of the feature 
being labelled?

Thanks!

Regards

Tim



—









Tim Sutton

Co-founder: Kartoza
Ex 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

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
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] Inconsistency in QgsServerRequest parameter handling ?

[David Marteau]

> Le 10 avr. 2019 à 23:21, pblottiere  a écrit :
> 
> Hi David,
> 
> 
>> If you try:
>> 
>> request.setParameter('FOOBAR','foobar')
>> 
>> then
>> 
>> request.parameter('FOOBAR')
>> 
>> then you get an empty string,
>>> Even if I add  an 'allowed' parameter by hand:
>>> 
 request.setParameter('FI_POINT_TOLERANCE','25')
> 
> Actually, QgsServerRequest and QgsServerParameters are high level
> classes which are not aware of valid parameters defined in services. For
> example, FI_POINT_TOLERANCE is a valid parameter in WMS service, and
> defined within the WMS module. But it's totally encapsulated within the
> module (a shared library so), and considered as unknown from
> QgsServerParameters. The only valid parameters from the
> QgsServerParameters point of view are those which are common for all
> services (WMS, WFS, and so on) like SERVICE, VERSION, REQUEST, ...
> 
> If you want to retrieve the full query from the request without any
> filter on valid parameters, you may use request.url(). However, I think
> we could probably add a fallback on the `parameter()` method to return
> invalid parameters too. I'll do a PR tomorrow and I'll ping you to check
> if the behaviour suits you.
> 
> 

Yes, this is what I was thinking about Looking at the code: maybe adding a 
lookup to the 'unmanaged' parameters if the code is not found should restore 
the symmetry setParameter/parameter.

I'm standing from the python plugin's point of view - services and filters: 
plugins are expecting some behavior when setting/getting parameters. If a 
plugin override a parameter it can only doing it using the requestHandler which 
is aware
only of the  base QgsServerParameters owned by the  QgsServerRequest instance, 
so they should be able to set/get parameters in a transparent way.

Regards

David.

> Regards,
> 
> Paul
> 
> 
> On 4/10/19 10:37 PM, David Marteau wrote:
>> To add some precision:
>> 
>> Even if I add  an 'allowed' parameter by hand:
>> 
>>> request.setParameter('FI_POINT_TOLERANCE','25')
>> then
>> 
>>> request.parameter('FI_POINT_TOLERANCE')
>> return an empty string
>> 
>>> Le 10 avr. 2019 à 19:46, David Marteau  a écrit :
>>> 
>>> 
>>> Hi devs,
>>> 
>>> I found a strange and seemingly inconsistent behavior when accessing 
>>> QgsServerRequest parameters:
>>> 
>>> If you try:
>>> 
>>> request.setParameter('FOOBAR','foobar')
>>> 
>>> then
>>> 
>>> request.parameter('FOOBAR')
>>> 
>>> then you get an empty string,
>>> 
>>> If you call
>>> 
>>> request.parameters() 
>>> 
>>> Then your get a dictionary with all the values previously set.
>>> 
>>> At first glance it seems that request.setParameter enforce use of a limited 
>>> set of keys (SERVICE…..
>>> 
>>> This does not seem very consistent with the fact parameter() should return 
>>> any value previously set with setParameter and also the fact that
>>> request.parameters()  return all previously defined  parameters key/values .
>>> 
>>> Furthemore this may be  problematic with plugins that define services in 
>>> python and thus may define any other set of allowed parameters.
>>> 
>>> Should I open an issue ?
>>> 
>>> 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

Re: [QGIS-Developer] Inconsistency in QgsServerRequest parameter handling ?

[pblottiere]

Hi David,


> If you try:
>
> request.setParameter('FOOBAR','foobar')
>
> then
>
> request.parameter('FOOBAR')
>
> then you get an empty string,
>> Even if I add  an 'allowed' parameter by hand:
>>
>>> request.setParameter('FI_POINT_TOLERANCE','25')

Actually, QgsServerRequest and QgsServerParameters are high level
classes which are not aware of valid parameters defined in services. For
example, FI_POINT_TOLERANCE is a valid parameter in WMS service, and
defined within the WMS module. But it's totally encapsulated within the
module (a shared library so), and considered as unknown from
QgsServerParameters. The only valid parameters from the
QgsServerParameters point of view are those which are common for all
services (WMS, WFS, and so on) like SERVICE, VERSION, REQUEST, ...

If you want to retrieve the full query from the request without any
filter on valid parameters, you may use request.url(). However, I think
we could probably add a fallback on the `parameter()` method to return
invalid parameters too. I'll do a PR tomorrow and I'll ping you to check
if the behaviour suits you.


Regards,

Paul


On 4/10/19 10:37 PM, David Marteau wrote:
> To add some precision:
>
> Even if I add  an 'allowed' parameter by hand:
>
>> request.setParameter('FI_POINT_TOLERANCE','25')
> then
>
>> request.parameter('FI_POINT_TOLERANCE')
> return an empty string
>
>> Le 10 avr. 2019 à 19:46, David Marteau  a écrit :
>>
>>
>> Hi devs,
>>
>> I found a strange and seemingly inconsistent behavior when accessing 
>> QgsServerRequest parameters:
>>
>> If you try:
>>
>> request.setParameter('FOOBAR','foobar')
>>
>> then
>>
>> request.parameter('FOOBAR')
>>
>> then you get an empty string,
>>
>> If you call
>>
>> request.parameters() 
>>
>> Then your get a dictionary with all the values previously set.
>>
>> At first glance it seems that request.setParameter enforce use of a limited 
>> set of keys (SERVICE…..
>>
>> This does not seem very consistent with the fact parameter() should return 
>> any value previously set with setParameter and also the fact that
>> request.parameters()  return all previously defined  parameters key/values .
>>
>> Furthemore this may be  problematic with plugins that define services in 
>> python and thus may define any other set of allowed parameters.
>>
>> Should I open an issue ?
>>
>> 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

Re: [QGIS-Developer] Bug #21460?

[Patrick Dunford]

Thanks for that information. I was unaware there really is such a small 
community of developers.


I guess that Gis software is specialised enough that there is not 
general interest to attract the wider community support that some of the 
major open source projects produce, whether this is a larger development 
community or financial support from a sponsor.


I only use a small fraction of the capabilities of the software. 
Unfortunately it is not practicable at this time for me to contribute 
more than bug reports to the software. The fact that we even have this 
software in the open source community is greatly appreciated by me.


On 8/04/19 8:30 PM, Paolo Cavallini wrote:

Hi Cory,

On 08/04/19 00:57, Cory Albrecht wrote:

I was wondering when Bug #21460
 was going to get some attention?
It's about  QGIS not forming proper PostGIS SQL updates correctly,
specifically for null values.

may I suggest you an interesting read?
https://nyalldawson.net/2016/08/how-to-effectively-get-things-changed-in-qgis/
Cheers.

___
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] Crashes on closing QGIS

[Matthias Kuhn]

On 4/10/19 11:05 PM, Nyall Dawson wrote:
> On Wed, 10 Apr 2019 at 23:50, Thomas Baumann  
> wrote:
>> Hi there,
>>
>> same situation here: QGIS 3.6 crashed several times when trying to close it.
>>
>> QgsCoordinateTransform::transformPolygon :
>> QgsCoordinateTransform::transformPolygon :
>> QgsCoordinateTransform::QgsCoordinateTransform :
>> QHashData::free_helper :
>> QgsCoordinateTransform::addToCache :
>> QgsCoordinateTransform::invalidateCache :
>> QgsApplication::exitQgis :
>> QgisApp::~QgisApp :
> I think I fixed this one recently with NathanW's help. I'm not 100%
> sure, because I could never reproduce it myself.
>
> I also thought the auth manager one was fixed by Matthias recently?

Yes, an auth manager related one has been fixed (and backported to 3.4
and 3.6) a month ago

https://github.com/qgis/QGIS/pull/9334

https://github.com/qgis/QGIS/pull/9336


My point was by no means that crashes on exit should be or are
neglected, sorry that I expressed myself badly.

Matthias

>
> 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
>
-- 
Matthias Kuhn
matth...@opengis.ch 
+41 (0)76 435 67 63 
OPENGIS.ch Logo 
___
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] Crashes on closing QGIS

[Nyall Dawson]

On Wed, 10 Apr 2019 at 23:50, Thomas Baumann  wrote:
>
> Hi there,
>
> same situation here: QGIS 3.6 crashed several times when trying to close it.
>

> QgsCoordinateTransform::transformPolygon :
> QgsCoordinateTransform::transformPolygon :
> QgsCoordinateTransform::QgsCoordinateTransform :
> QHashData::free_helper :
> QgsCoordinateTransform::addToCache :
> QgsCoordinateTransform::invalidateCache :
> QgsApplication::exitQgis :
> QgisApp::~QgisApp :

I think I fixed this one recently with NathanW's help. I'm not 100%
sure, because I could never reproduce it myself.

I also thought the auth manager one was fixed by Matthias recently?

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] Crashes on closing QGIS

[Thomas Baumann]

Hi there,

@Alessandro Pasotti; thanks for pointing out that there are several persons
affected by bugs which cause QGIS3 to crash on exit.
I know that my stacktrace is different from Andreas' one. when I said "same
here" I was refering to Andreas'  statement  "We always have crashes on
closing QGIS (on Windows)".

@Jürgen Fischer: ok. here is the long story about the stacktrace ;-) :
Yesterday I created some layers (mostly memory layers )with the processing
toolbar (reproject, union and so on). Then I did not touch the opened
project until today when I wanted to close QGIS and it warned me that there
are unsaved memory layers. So I canceled the closing and saved the layer.
After that I tried to close QGIS and it crashed.

@Matthias Kuhn: I can understand that the priority is not as high as if
would be if data would be corrupted but if I have a look at
https://issues.qgis.org/issues/20283 I see nearly 70 tickets linked to this
one where it was reported that QGIS crashes while closing so I think it's
obvious that is is a nasty bug that affects a lot of people.
Doing a quick google search for the term " proj_lpz_dist"  shows a lot of
cases where the coordinate transformation of a polygonlayer seems to cause
problems:

proj_lpz_dist :
QgsCoordinateTransform::transformPolygon :


Does someone know what "proj_lpz_dist" stands for?

If I would have been able to reproduce the error I would have contacted our
QGIS support provider to let them fix the bug but until now it was not
possible to reproduce the crash.

Is there something else that can be done to help fixing this bug?
This bug is one of the reasons why QGIS3 cannot be rolled out for
productiuon use at my workplace. Even if QGIS3 has very nice new features
QGIS2.18 is still way more stable at the moment, so we postpone the QGIS3
rollout from week to week.

regards,
Thomas




Am Mi., 10. Apr. 2019 um 17:30 Uhr schrieb Jürgen E. Fischer :
>
> Hi,
>
> On Wed, 10. Apr 2019 at 16:14:50 +0200, Alessandro Pasotti wrote:
> > @thomas : there are already dozen of issue reports with your stacktrace,
> > which is very different from Andrea's.
>
> namely https://issues.qgis.org/issues/20283, but a clue how to reproduce
the
> issue.   People tend to just post the crash report, but most of the time
no
> information how to reproduce the issue - this is not one of the issue
where the
> pure stacktrace is conclusive.
>
>
> 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
https://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on
FreeNode
> ___
> 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] No LTR on openSUSE repos

[Patrick Dunford]

It looks to me that there is a community of openSUSE users out there 
building packages. You should try and engage with the people that have 
built community packages to see if they can develop this package.


On 2/04/19 4:01 AM, Yann POUFFARIX wrote:
Yes, but still waiting the answer... We still have 3.6 on repos but 
that's all. No communication at all and permanent "failed" status on 
build.opensuse.org 




___
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] Inconsistency in QgsServerRequest parameter handling ?

[David Marteau]

To add some precision:

Even if I add  an 'allowed' parameter by hand:

> request.setParameter('FI_POINT_TOLERANCE','25')

then

> request.parameter('FI_POINT_TOLERANCE')

return an empty string

> Le 10 avr. 2019 à 19:46, David Marteau  a écrit :
> 
> 
> Hi devs,
> 
> I found a strange and seemingly inconsistent behavior when accessing 
> QgsServerRequest parameters:
> 
> If you try:
> 
> request.setParameter('FOOBAR','foobar')
> 
> then
> 
> request.parameter('FOOBAR')
> 
> then you get an empty string,
> 
> If you call
> 
> request.parameters() 
> 
> Then your get a dictionary with all the values previously set.
> 
> At first glance it seems that request.setParameter enforce use of a limited 
> set of keys (SERVICE…..
> 
> This does not seem very consistent with the fact parameter() should return 
> any value previously set with setParameter and also the fact that
> request.parameters()  return all previously defined  parameters key/values .
> 
> Furthemore this may be  problematic with plugins that define services in 
> python and thus may define any other set of allowed parameters.
> 
> Should I open an issue ?
> 
> 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] Canonical way to customize QGis toolbar icons within themes?

[Sebastian M. Ernst]

Hi all,

I am looking for a/the canonical way to customize QGis toolbar icons
(or, in general, the icons of certain actions throughout QGis), like for
instance the icons for "New project" or "Open project" as part of a theme.

Themes can contain icons and reference them, see for instance here:
https://github.com/qgis/QGIS/tree/93e761dd2396af21db9bb93e26d7cba680c906ca/resources/themes/Blend%20of%20Gray

Is there possibly a way to use *.qss style sheets to point to specific
actions in QGis, e.g. the "new project" action, and modify their icons?

Or can I modify icons of certain actions through a plugin at runtime?

What I have messed with so far: I can overwrite icons in ...
https://github.com/qgis/QGIS/tree/93e761dd2396af21db9bb93e26d7cba680c906ca/images/themes/default
... and rebuild QGis from source. It appears that the icons become part
of the binary or one of its libraries as compiled resources.

Best regards,
Sebastian




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] Crashes on closing QGIS

[Matthias Kuhn]

Hi

I can help with the why part of the message:

- it has been caused by a wide variety of different reasons over time

- these reasons are often very specific to a local setup/project/system
environment

- because it doesn't cause data loss, the priority is reduced from
super-urgent to high

That said, this message unfortunately doesn't help to solve the problem,
but hopefully helps to understand

Matthias

On 4/10/19 8:28 PM, C Hamilton wrote:
> I will confirm that my QGIS 3.6 crashes as well especially when
> clicking on the X in the upper right hand corner. I don't know why
> this has been such a problem over time because it has plagued many
> versions of qgis.
>
> Calvin
>
> On Wed, Apr 10, 2019 at 9:50 AM Thomas Baumann
> mailto:rdbath.regiod...@gmail.com>> wrote:
>
> Hi there,
>
> same situation here: QGIS 3.6 crashed several times when trying to
> close it.
>
> regards,
> Thomas
>
> PS: attached is one crash report:
> 
>
> h2. User Feedback
>
> QGIS Crashed when I tried to close QGIS
>
> h2. Report Details
>
> *Crash ID*: 62f1fcd2045780cb9f127836e6b579b8665f3e63
>
>
> *Stack Trace*
> 
> proj_lpz_dist :
> proj_lpz_dist :
> QgsCoordinateTransform::transformPolygon :
> QgsCoordinateTransform::transformPolygon :
> QgsCoordinateTransform::QgsCoordinateTransform :
> QHashData::free_helper :
> QgsCoordinateTransform::addToCache :
> QgsCoordinateTransform::invalidateCache :
> QgsApplication::exitQgis :
> QgisApp::~QgisApp :
> CPLStringList::operator[] :
> main :
> BaseThreadInitThunk :
> RtlUserThreadStart :
> 
>
>
> *QGIS Info*
> QGIS Version: 3.6.0-Noosa
> QGIS code revision: commit:58734527ab
> Compiled against Qt: 5.11.2
> Running against Qt: 5.11.2
> Compiled against GDAL: 2.4.0
> Running against GDAL: 2.4.0
>
>
>
> *System Info*
> CPU Type: x86_64
> Kernel Type: winnt
> Kernel Version: 10.0.14393
>
>
> Am Mo., 8. Apr. 2019 um 11:22 Uhr schrieb Andreas Neumann
> mailto:a.neum...@carto.net>>:
>
> Hi,
>
> We always have crashes on closing QGIS (on Windows) -
> regardless of version - it happens on 3.4, 3.6 and master.
>
> Seems to be related to the authentication manager. Is this a
> known issue? Are there ideas how to fix the issue?
>
> Here is the crashlog:
>
> Crash ID: 0f25782d491a42462ec5c96af91c45b3e9859bd3
>
> Stack Trace
>
> QMutex::lock : QMutexLocker::QMutexLocker : ::operator()
> qgsauthmanager.cpp:145
> QtPrivate::FunctorCall,QtPrivate::List,void, >::call
> qobjectdefs_impl.h:128 QtPrivate::Functor,0>::call,void>
> qobjectdefs_impl.h:239
> QtPrivate::QFunctorSlotObject,0,QtPrivate::List,void>::impl
> qobjectdefs_impl.h:427 QMetaObject::activate :
> QThread::finished : QThread::currentThreadId : QThread::start
> : BaseThreadInitThunk : RtlUserThreadStart :
>
>
>
>
> QGIS Info
> QGIS Version: 3.7.0-Master
> QGIS code revision: 5a85e206f6
> Compiled against Qt: 5.11.2
> Running against Qt: 5.11.2
> Compiled against GDAL: 2.4.1
> Running against GDAL: 2.4.1
>
>
>
> System Info
> CPU Type: x86_64
> Kernel Type: winnt
> Kernel Version: 6.1.7601
>
> ___
> 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 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
-- 
Matthias Kuhn
matth...@opengis.ch 
+41 (0)76 435 67 63 
OPENGIS.ch Logo 
___
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] Crashes on closing QGIS

[C Hamilton]

I will confirm that my QGIS 3.6 crashes as well especially when clicking on
the X in the upper right hand corner. I don't know why this has been such a
problem over time because it has plagued many versions of qgis.

Calvin

On Wed, Apr 10, 2019 at 9:50 AM Thomas Baumann 
wrote:

> Hi there,
>
> same situation here: QGIS 3.6 crashed several times when trying to close
> it.
>
> regards,
> Thomas
>
> PS: attached is one crash report:
> 
>
> h2. User Feedback
>
> QGIS Crashed when I tried to close QGIS
>
> h2. Report Details
>
> *Crash ID*: 62f1fcd2045780cb9f127836e6b579b8665f3e63
>
>
> *Stack Trace*
> 
> proj_lpz_dist :
> proj_lpz_dist :
> QgsCoordinateTransform::transformPolygon :
> QgsCoordinateTransform::transformPolygon :
> QgsCoordinateTransform::QgsCoordinateTransform :
> QHashData::free_helper :
> QgsCoordinateTransform::addToCache :
> QgsCoordinateTransform::invalidateCache :
> QgsApplication::exitQgis :
> QgisApp::~QgisApp :
> CPLStringList::operator[] :
> main :
> BaseThreadInitThunk :
> RtlUserThreadStart :
> 
>
>
> *QGIS Info*
> QGIS Version: 3.6.0-Noosa
> QGIS code revision: commit:58734527ab
> Compiled against Qt: 5.11.2
> Running against Qt: 5.11.2
> Compiled against GDAL: 2.4.0
> Running against GDAL: 2.4.0
>
>
>
> *System Info*
> CPU Type: x86_64
> Kernel Type: winnt
> Kernel Version: 10.0.14393
>
>
> Am Mo., 8. Apr. 2019 um 11:22 Uhr schrieb Andreas Neumann <
> a.neum...@carto.net>:
>
>> Hi,
>>
>> We always have crashes on closing QGIS (on Windows) - regardless of
>> version - it happens on 3.4, 3.6 and master.
>>
>> Seems to be related to the authentication manager. Is this a known issue?
>> Are there ideas how to fix the issue?
>>
>> Here is the crashlog:
>>
>> Crash ID: 0f25782d491a42462ec5c96af91c45b3e9859bd3
>>
>> Stack Trace
>>
>>
>> QMutex::lock :
>> QMutexLocker::QMutexLocker :
>> ::operator() qgsauthmanager.cpp:145
>> QtPrivate::FunctorCall,QtPrivate::List,void, >::call qobjectdefs_impl.h:128
>> QtPrivate::Functor,0>::call,void> qobjectdefs_impl.h:239
>> QtPrivate::QFunctorSlotObject,0,QtPrivate::List,void>::impl 
>> qobjectdefs_impl.h:427
>> QMetaObject::activate :
>> QThread::finished :
>> QThread::currentThreadId :
>> QThread::start :
>> BaseThreadInitThunk :
>> RtlUserThreadStart :
>>
>>
>>
>>
>> QGIS Info
>> QGIS Version: 3.7.0-Master
>> QGIS code revision: 5a85e206f6
>> Compiled against Qt: 5.11.2
>> Running against Qt: 5.11.2
>> Compiled against GDAL: 2.4.1
>> Running against GDAL: 2.4.1
>>
>>
>>
>> System Info
>> CPU Type: x86_64
>> Kernel Type: winnt
>> Kernel Version: 6.1.7601
>> ___
>> 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 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] Inconsistency in QgsServerRequest parameter handling ?

[David Marteau]

Hi devs,

I found a strange and seemingly inconsistent behavior when accessing 
QgsServerRequest parameters:

If you try:

request.setParameter('FOOBAR','foobar')

then

request.parameter('FOOBAR')

then you get an empty string,

If you call

request.parameters() 

Then your get a dictionary with all the values previously set.

At first glance it seems that request.setParameter enforce use of a limited set 
of keys (SERVICE…..

This does not seem very consistent with the fact parameter() should return any 
value previously set with setParameter and also the fact that
request.parameters()  return all previously defined  parameters key/values .

Furthemore this may be  problematic with plugins that define services in python 
and thus may define any other set of allowed parameters.

Should I open an issue ?

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

Re: [QGIS-Developer] Why was selection tool behaviour changed in 3.x?

[Marco Bernasocchi]

Hi

On 09.04.19 02:53, Cory Albrecht wrote:
>
>
>   Cory Albrecht mailto:m...@hanfastolfe.com>>
>
>   
> 8:14 PM (37 minutes ago)
>   
>   
> to Régis
>
> Hello Régis,
>
> Sorry for not being clear - I mean when using the selection tool in
> freehand mode. I am definitely not talking about the identification
> tool, assuming you're referring to the same thing that I am thinking
> of? Ctrl+Shift+I, or the icon that is the cursor with a the letter "i"
> in a sold blue circle. I'm not sure I would call that new as it's been
> part of QGIS since I started using it in about 2015. Perhaps you're an
> old salt from the 1.x days? ;-)
>
> As a principle of UX design, ideally, the user should do the same
> action - click and drag - for any type of selection, both to maintain
> internal consistency in the application and with common ways of doing
> things in the broader computer universe. This lets people learn new
> software quickly by having a set of transferable actions that can get
> them up and running and doing rudimentary things quickly. It also
> helps reduce unintended errors caused by using common actions that get
> unexpectedly interpreted different than the user is used to. Things
> like this contribute to how easy or frustrating an application is to
> use, both for new and long time users.
>
> 1. For the "Select Feature(s)", click and drag to indicate the
> diagonally opposite corners of a selection rectangle.
> 2. For the "Select Features by Freehand", click and drag to create an
> irregular blob of selection area.
> 3. For the "Select Features by Radius", click and drag to indicate the
> centre of a selection circle and it's radius.
>
> In 2.x the answer to all of those was yes, but in 3.x it's yes, no, no.
I just tested and the answer are, as Régis mentioned, the same as in
2.18 ( tested using 3.4.4). the behavior you describe is only true when
you activate "select by polygon".
>
> In vector and raster drawing applications, drawing rectangles, circles
> and blobs is done by click and drag, as is selecting rectangular,
> circular or irregular blobby areas. If you release and click elsewhere
> then drag, you start drawing a new object, or you discard the first
> selection and start outlining a new one. Word processing and text
> section, video editors and frame selection, sound editors and lengths
> of time in a track, they all have the user do these conceptually
> similar tasks in the same way - click and drag to create a selection ,
> new click discards old selection.
>
> Another principle of UX design is that you don't change how a user
> does something unless there is clear benefit that outweighs the
> trouble of relearning, especially for action concepts that are common
> in the broader sphere. When you make changes without benefits you
> cause friction in your user flows (some call those "point points"),
> and that means people find that task (and potentially the application
> as a whole) difficult and frustrating to use.
>
> For those three methods of selection there's nothing to be gained by
> making QGIS 3.x the odd one out in how this is done. There's no
> benefit added by extra functionality in these selection methods. All
> it does is create pain points, both by being different from everybody
> else and by being inconsistent internally.
That is exactly why QGIS does it the same why as other tools.
>
> The exception to this is the poly gone selection tool. I've never
> encountered it outside of QGIS and ArcGIS. Drawing applications have
> polygon drawing tools in which you sequentially click the polygon's
> points, just like how you create features on polygon or line layers in
> QGIS, but there's no polygon selection analogue. As such it makes
> sense to take the feature creation method of sequential clicks over
> for use in a polygon selection tool rather than coming up with a whole
> new user flow like click and drag and tapping the space bar for the
> points.
>
> And so I wonder - what was the rationale behind making this change?

a very quick google search returned the whole rationale to changing the
behavior of the Node tool [0] but none for the behavior you describe,
which I could not reproduce. Could you show us a screencast?

[0] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/69

oh, and cheers

Marco

>
> On Mon, Apr 8, 2019 at 6:00 AM Régis Haubourg
> mailto:regis.haubo...@gmail.com>> wrote:
>
> Hi Cory,
> I must say I didn't notice any difference on the selection tool
> behavior on my side.
> I don't think there was any explicit attempt to homogenize the
> selection behavior with the node tool new ergonomy.
>
> Just a check, in the maptool dropdown list for selection tool, are
> your using the freehand selection tool or the classical clic and
> drag selection tool?
>
> I've seen similar surprising issues with the new "identify" tool
> that now can interrogate features in a polygon. Users got confused
> when 

Re: [QGIS-Developer] Crashes on closing QGIS

[Jürgen E . Fischer]

Hi,

On Wed, 10. Apr 2019 at 17:29:01 +0200, Jürgen E. Fischer wrote:
> namely https://issues.qgis.org/issues/20283, but a clue how to reproduce the
> issue.

oops, "a clue" as in "no clue at all". ;)


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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/
___
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] Crashes on closing QGIS

[Jürgen E . Fischer]

Hi,

On Wed, 10. Apr 2019 at 16:14:50 +0200, Alessandro Pasotti wrote:
> @thomas : there are already dozen of issue reports with your stacktrace,
> which is very different from Andrea's.

namely https://issues.qgis.org/issues/20283, but a clue how to reproduce the
issue.   People tend to just post the crash report, but most of the time no
information how to reproduce the issue - this is not one of the issue where the
pure stacktrace is conclusive.


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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/
___
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] loading attribute table with a lot of fields

[Martin Landa]

Hi,

I got a strange experience with QGIS (3.4) when opening attribute
table with larger number of fields (here 512 fields). Attribute table
opens very quickly, but then QGIS freeze for dozens of seconds (not
able to scroll attribute table).

Do you have similar experience? Known issue? Thanks! Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
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] Crashes on closing QGIS

[Alessandro Pasotti]

 


@thomas : there are already dozen of issue reports with your stacktrace,
which is very different from Andrea's.


On Wed, Apr 10, 2019 at 3:50 PM Thomas Baumann 
wrote:

> Hi there,
>
> same situation here: QGIS 3.6 crashed several times when trying to close
> it.
>
> regards,
> Thomas
>
> PS: attached is one crash report:
> 
>
> h2. User Feedback
>
> QGIS Crashed when I tried to close QGIS
>
> h2. Report Details
>
> *Crash ID*: 62f1fcd2045780cb9f127836e6b579b8665f3e63
>
>
> *Stack Trace*
> 
> proj_lpz_dist :
> proj_lpz_dist :
> QgsCoordinateTransform::transformPolygon :
> QgsCoordinateTransform::transformPolygon :
> QgsCoordinateTransform::QgsCoordinateTransform :
> QHashData::free_helper :
> QgsCoordinateTransform::addToCache :
> QgsCoordinateTransform::invalidateCache :
> QgsApplication::exitQgis :
> QgisApp::~QgisApp :
> CPLStringList::operator[] :
> main :
> BaseThreadInitThunk :
> RtlUserThreadStart :
> 
>
>
> *QGIS Info*
> QGIS Version: 3.6.0-Noosa
> QGIS code revision: commit:58734527ab
> Compiled against Qt: 5.11.2
> Running against Qt: 5.11.2
> Compiled against GDAL: 2.4.0
> Running against GDAL: 2.4.0
>
>
>
> *System Info*
> CPU Type: x86_64
> Kernel Type: winnt
> Kernel Version: 10.0.14393
>
>
> Am Mo., 8. Apr. 2019 um 11:22 Uhr schrieb Andreas Neumann <
> a.neum...@carto.net>:
>
>> Hi,
>>
>> We always have crashes on closing QGIS (on Windows) - regardless of
>> version - it happens on 3.4, 3.6 and master.
>>
>> Seems to be related to the authentication manager. Is this a known issue?
>> Are there ideas how to fix the issue?
>>
>> Here is the crashlog:
>>
>> Crash ID: 0f25782d491a42462ec5c96af91c45b3e9859bd3
>>
>> Stack Trace
>>
>>
>> QMutex::lock :
>> QMutexLocker::QMutexLocker :
>> ::operator() qgsauthmanager.cpp:145
>> QtPrivate::FunctorCall,QtPrivate::List,void, >::call qobjectdefs_impl.h:128
>> QtPrivate::Functor,0>::call,void> qobjectdefs_impl.h:239
>> QtPrivate::QFunctorSlotObject,0,QtPrivate::List,void>::impl 
>> qobjectdefs_impl.h:427
>> QMetaObject::activate :
>> QThread::finished :
>> QThread::currentThreadId :
>> QThread::start :
>> BaseThreadInitThunk :
>> RtlUserThreadStart :
>>
>>
>>
>>
>> QGIS Info
>> QGIS Version: 3.7.0-Master
>> QGIS code revision: 5a85e206f6
>> Compiled against Qt: 5.11.2
>> Running against Qt: 5.11.2
>> Compiled against GDAL: 2.4.1
>> Running against GDAL: 2.4.1
>>
>>
>>
>> System Info
>> CPU Type: x86_64
>> Kernel Type: winnt
>> Kernel Version: 6.1.7601
>> ___
>> 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



-- 
Alessandro Pasotti
w3:   www.itopen.it
___
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] Crashes on closing QGIS

[Thomas Baumann]

Hi there,

same situation here: QGIS 3.6 crashed several times when trying to close it.

regards,
Thomas

PS: attached is one crash report:


h2. User Feedback

QGIS Crashed when I tried to close QGIS

h2. Report Details

*Crash ID*: 62f1fcd2045780cb9f127836e6b579b8665f3e63


*Stack Trace*

proj_lpz_dist :
proj_lpz_dist :
QgsCoordinateTransform::transformPolygon :
QgsCoordinateTransform::transformPolygon :
QgsCoordinateTransform::QgsCoordinateTransform :
QHashData::free_helper :
QgsCoordinateTransform::addToCache :
QgsCoordinateTransform::invalidateCache :
QgsApplication::exitQgis :
QgisApp::~QgisApp :
CPLStringList::operator[] :
main :
BaseThreadInitThunk :
RtlUserThreadStart :



*QGIS Info*
QGIS Version: 3.6.0-Noosa
QGIS code revision: commit:58734527ab
Compiled against Qt: 5.11.2
Running against Qt: 5.11.2
Compiled against GDAL: 2.4.0
Running against GDAL: 2.4.0



*System Info*
CPU Type: x86_64
Kernel Type: winnt
Kernel Version: 10.0.14393


Am Mo., 8. Apr. 2019 um 11:22 Uhr schrieb Andreas Neumann <
a.neum...@carto.net>:

> Hi,
>
> We always have crashes on closing QGIS (on Windows) - regardless of
> version - it happens on 3.4, 3.6 and master.
>
> Seems to be related to the authentication manager. Is this a known issue?
> Are there ideas how to fix the issue?
>
> Here is the crashlog:
>
> Crash ID: 0f25782d491a42462ec5c96af91c45b3e9859bd3
>
> Stack Trace
>
>
> QMutex::lock :
> QMutexLocker::QMutexLocker :
> ::operator() qgsauthmanager.cpp:145
> QtPrivate::FunctorCall,QtPrivate::List,void, >::call qobjectdefs_impl.h:128
> QtPrivate::Functor,0>::call,void> qobjectdefs_impl.h:239
> QtPrivate::QFunctorSlotObject,0,QtPrivate::List,void>::impl 
> qobjectdefs_impl.h:427
> QMetaObject::activate :
> QThread::finished :
> QThread::currentThreadId :
> QThread::start :
> BaseThreadInitThunk :
> RtlUserThreadStart :
>
>
>
>
> QGIS Info
> QGIS Version: 3.7.0-Master
> QGIS code revision: 5a85e206f6
> Compiled against Qt: 5.11.2
> Running against Qt: 5.11.2
> Compiled against GDAL: 2.4.1
> Running against GDAL: 2.4.1
>
>
>
> System Info
> CPU Type: x86_64
> Kernel Type: winnt
> Kernel Version: 6.1.7601
> ___
> 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] Plugin [1633] ArcGIS ImageServer Connector approval notification.

[noreply]

Plugin ArcGIS ImageServer Connector approval by pcav.
The plugin version "[1633] ArcGIS ImageServer Connector 2.0.1" is now approved
Link: http://plugins.qgis.org/plugins/ImageServerConnector/
___
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 [629] Networks approval notification.

[noreply]

Plugin Networks approval by pcav.
The plugin version "[629] Networks 2.3.3" is now approved
Link: http://plugins.qgis.org/plugins/networks/
___
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] Why was selection tool behaviour changed in 3.x?

[Tom Chadwin]

Hi Cory

From memory, there was a lot of discussion about making this change in the
vertex editor. It's not true to say that QGIS is an outlier: the rationale
behind the change - along with the reasons Jo mentions and increasing the
ability to be more accurate if you don't have to hold down the button - was
to align with the behaviour of CAD, which does use "click-click", rather
than click-and-drag.

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] PyQGIS WMS tiles don't load on Windows

[Tom Chadwin]

This confusion will not have been helped by the fact that PyQGIS (I seem to
recall) makes XYZ layers inherit from WM(T)S layers. That makes sense from a
functional point of view (they're all served rasters), but from a
standards/terminology point of view, it's pretty confusing.

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] No LTR on SUSE repos

[Daniele Viganò]

We have packaging for Fedora which is RPM based [0]: it may be used as a
starting point for OpenSUSE. Indeed you'll need mostly to change the
section about dependencies: names may be different and something may be
missing.

About numbers: COPR [1] gives a rough estimated number of repo downloads
which is around 1.5k. I was also surprised by the quantity of feedback
received about these packages: I was not expecting so many (proactive)
users.

Daniele

[0] https://github.com/qgis/QGIS/tree/master/rpm
[1] https://copr.fedorainfracloud.org/coprs/dani/qgis/


-- 
*Daniele Viganò*
http://daniele.vigano.me
___
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 [1633] ArcGIS ImageServer Connector approval notification.

[noreply]

Plugin ArcGIS ImageServer Connector approval by pcav.
The plugin version "[1633] ArcGIS ImageServer Connector 2.0.0" is now approved
Link: http://plugins.qgis.org/plugins/ImageServerConnector/
___
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