[QGIS-Developer] Error with hdf5.dll on Windows build.

[Nathan Woodrow]

Hi,

Trying to build on Windows for master I'm getting the following:

C:\OSGeo4W\bin\hdf5.dll : fatal error LNK1107: invalid or corrupt file:
cannot read at 0x2B0

It looks like cmake is trying to use that in the scripts and not the lib
file but I can't see why it wants to do that.

Any thoughts?



- Nathan
___
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] Python API for 3D

[Nyall Dawson]

On Sat, 29 Sep 2018 at 00:21, Martin Dobias  wrote:

>
> I think for the time being we should still treat the 3D library as
> having unstable API - so I wanted to check how others would feel about
> having Python API for qgis_3d that would be marked as unstable, i.e.
> there may be changes between 3.x releases? I think with big warnings
> in the docs that the API may change we can get others to experiment
> with 3D functionality while not offending anyone too much if we break
> it later. The idea is that the API would get frozen at some point
> later in 3.x release cycle or for QGIS 4.

I don't see an issue with this -- there's other parts of code exposed
to PyQGIS which is also clearly marked as non-stable. Some processing
classes for instance.

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] Plugin [1429] Karika approval notification.

[noreply]

Plugin Karika approval by pcav.
The plugin version "[1429] Karika 1.5" is now approved
Link: http://plugins.qgis.org/plugins/karika/
___
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] Python API for 3D

[Martin Dobias]

Hi Matthias

On Fri, Sep 28, 2018 at 4:47 PM Matthias Kuhn  wrote:

> Hi Martin,
> I think that's a good move. Having an experimental Python 3D API is better
> than not having a Python 3D API. And if it's communicated clearly, it's
> every developers choice to build something on top of an unstable API.
> Just to ask, do you have clear plans for API changes or is it more a move
> to keep the door for API modifications open in case it turns out it is
> required?
>

I don't really have any concrete plans for API changes within the 3D
library - I just feel that it may easily happen in the future as we will be
adding more functionality or refactoring existing code :-)

Anyway I would try to keep the changes in API break docs so that devs have
some guidance in case there are some breaks.

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] Python API for 3D

[Alessandro Pasotti]

On Fri, Sep 28, 2018 at 4:21 PM Martin Dobias  wrote:

> Hi all
>
> I have been thinking it would be good to finally have Python API also
> for qgis_3d library. Until now I have kept the 3D library
> intentionally without Python bindings so that it is possible to move
> the code around without being blocked by the API stability
> requirement.
>
> I think for the time being we should still treat the 3D library as
> having unstable API - so I wanted to check how others would feel about
> having Python API for qgis_3d that would be marked as unstable, i.e.
> there may be changes between 3.x releases? I think with big warnings
> in the docs that the API may change we can get others to experiment
> with 3D functionality while not offending anyone too much if we break
> it later. The idea is that the API would get frozen at some point
> later in 3.x release cycle or for QGIS 4.
>
> Cheers
> Martin
>


Hi Martin,

I think it's a good idea!

... if the warning is big enough and not light gray over a white background
;)


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

[QGIS-Developer] Python API for 3D

[Martin Dobias]

Hi all

I have been thinking it would be good to finally have Python API also
for qgis_3d library. Until now I have kept the 3D library
intentionally without Python bindings so that it is possible to move
the code around without being blocked by the API stability
requirement.

I think for the time being we should still treat the 3D library as
having unstable API - so I wanted to check how others would feel about
having Python API for qgis_3d that would be marked as unstable, i.e.
there may be changes between 3.x releases? I think with big warnings
in the docs that the API may change we can get others to experiment
with 3D functionality while not offending anyone too much if we break
it later. The idea is that the API would get frozen at some point
later in 3.x release cycle or for QGIS 4.

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 [1380] Batch Hillshader approval notification.

[noreply]

Plugin Batch Hillshader approval by pcav.
The plugin version "[1380] Batch Hillshader 2.3.0" is now approved
Link: http://plugins.qgis.org/plugins/batch_hillshader-master/
___
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] form font barely readable

[Richard Duivenvoorde]

On 09/28/2018 10:49 AM, Matthias Kuhn wrote:

> Have a look here, that's the default behavior with setEnabled, where the
> actual modification of the widget is done:
> 
> https://github.com/qgis/QGIS/blob/master/src/gui/editorwidgets/core/qgseditorwidgetwrapper.cpp#L65

Ok, I actually did fiddle here a little:

https://github.com/qgis/QGIS/blob/master/src/gui/editorwidgets/qgstexteditwrapper.cpp#L140

There we set a 'Disabled'-Palette on the text.
If I comment that line you get the top dialog as seen in attached
'defaultPalette2.png'.
So: a 'normal' line-edit... which could make a user try to edit it...
Though (see the bottom dialog in the same image) we have more
differences now since we use the wrappers: we show a 'clear-button' in
the lineEdit if we are editable now).

I also tried to remove the frame (see topNoFrame_bottomCurrent2.png) here:
https://github.com/qgis/QGIS/blob/master/src/gui/editorwidgets/qgstexteditwrapper.cpp#L198
In the image to me it looks a little 'naked'.
For reference in the same image the bottom dialog is current situation;
in my view badly readable

To me it is actually ok to use the normal palette, I do not like the
view of a lineedit withouth frame I think.

So what do others think?

Regards,

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] form font barely readable

[Matthias Kuhn]

Hi Richard

On 9/28/18 10:17 AM, Richard Duivenvoorde wrote:
> On 09/28/2018 12:07 AM, Nyall Dawson wrote:
>> On Fri, 28 Sep 2018 at 00:08, Richard Duivenvoorde  
>> wrote:
>>> Using the I-tool and viewing via 'Auto open form', the attributes of a
>>> feature are barely readable (see attached screenshot).
>> Oh this has bugged me a LOT too! I'd very much like to see this
>> changed, but I'm not sure if there's some rationale behind it I'm
>> missing...
>>
>> Nyall
> Looking into this a little, we use make the widget 'enabled=false' I think?
>
> What about instead only do 'readOnly=true'?
> Then you 'miss' the visual cue that a form field is read only.
> There could be a message when you try to edit the field?
>
> Or in combination with 'frame=false' you would get a form in which the
> fields do not like 'input fields'.

That sounds like an idea.

Have a look here, that's the default behavior with setEnabled, where the
actual modification of the widget is done:

https://github.com/qgis/QGIS/blob/master/src/gui/editorwidgets/core/qgseditorwidgetwrapper.cpp#L65

it needs to be checked with all different widgets if they are still in a
sane and expected readonly state. If one is not, the behavior can be
finetuned in their respective wrapper, as done e.g. here
https://github.com/qgis/QGIS/blob/master/src/gui/editorwidgets/qgsrelationreferencewidgetwrapper.cpp#L136

Cheers

Matthias


>
> Mmm, was trying to look into this, to find out that we use a wrapper
> around the widgets:
>
> https://github.com/qgis/QGIS/blob/master/src/gui/qgsattributeform.cpp#L1077
>
> Removing the
> ww->setEnabled( enabled );
> morphs the input in the default input of QGIS
> ww does not have readonly or frame anymore
>
> So more difficult then I hoped :-(
>
> 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
-- 
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] form font barely readable

[Richard Duivenvoorde]

On 09/28/2018 12:07 AM, Nyall Dawson wrote:
> On Fri, 28 Sep 2018 at 00:08, Richard Duivenvoorde  
> wrote:
>> Using the I-tool and viewing via 'Auto open form', the attributes of a
>> feature are barely readable (see attached screenshot).

> Oh this has bugged me a LOT too! I'd very much like to see this
> changed, but I'm not sure if there's some rationale behind it I'm
> missing...
> 
> Nyall

Looking into this a little, we use make the widget 'enabled=false' I think?

What about instead only do 'readOnly=true'?
Then you 'miss' the visual cue that a form field is read only.
There could be a message when you try to edit the field?

Or in combination with 'frame=false' you would get a form in which the
fields do not like 'input fields'.

Mmm, was trying to look into this, to find out that we use a wrapper
around the widgets:

https://github.com/qgis/QGIS/blob/master/src/gui/qgsattributeform.cpp#L1077

Removing the
ww->setEnabled( enabled );
morphs the input in the default input of QGIS
ww does not have readonly or frame anymore

So more difficult then I hoped :-(

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