Feature form improvements [QgsQuick]

[sklencar]

Changes are related to following widgets used in the FeatureForm:

Checkbox:

• fixed old import of QgsQuick
• changed indicator of a checkbox to be able to apply styles

DateTime:

• fixed wrong behaviour of the widget if a value is undefined
• replaced label with textfield with formatting options (ported from QField)

ExternalResources:

• fixed pixalation of icons
• added new icon without alternative border to be able to put color overlay on it
• fixed broken layout of icons

ValueMap

• updated way how to read option values from field config/setup (ported from QField, related to changes of the field config since QGIS 3.x)

TextEdit:

• Unified styling of the widgets - added some padding, changed background, height

Fields style added to QgsFeatureFormStyle
Added "fields" style object to customize some properties (e.g color, height, radius) of editor widgets. Due to new style options also widgets have been updated.

Description

Include a few sentences describing the overall goals for this PR (pull request). If applicable also add screenshots.

Checklist

Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

• Commit messages are descriptive and explain the rationale for changes
• Commits which fix bugs include fixes #11111 in the commit message next to the description
• Commits which add new features are tagged with [FEATURE] in the commit message
• Commits which change the UI or existing user workflows are tagged with [needs-docs] in the commit message and contain sufficient information in the commit message to be documented
• I have read the QGIS Coding Standards and this PR complies with them
• This PR passes all existing unit tests (test results will be reported by travis-ci after opening this PR)
• New unit tests have been added for core changes
• I have run the scripts/prepare-commit.sh script before each commit

[PeterPetrik]

maybe would be nice to get opinion of @m-kuhn ?

[m-kuhn]

Good stuff in here.
But quite hard to review as it's quite a lot of different things. Have they gone to some other (modular) review before at lutra?

[PeterPetrik]

if I understand it correctly it is tested with latest (development) version of https://github.com/lutraconsulting/input ( @wonder-sk ?)

[m-kuhn]

Evenmore, the bugfix label is probably only partially applicable given the above ;)

[wonder-sk]

Have they gone to some other (modular) review before at lutra?

unfortunately not :-/ But we discussed already with @sklencar that next time the individual fixes should go to separate well defined commits...

Evenmore, the bugfix label is probably only partially applicable given the above ;)

There are no new features here really, so I would be happy to get this merged in 3.6 - but if others feel strongly against we can postpone it to 3.8...

[m-kuhn]

unfortunately not :-/ But we discussed already with @sklencar that next time the individual fixes should go to separate well defined commits...

Great 👍

There are no new features here really, so I would be happy to get this merged in 3.6 - but if others feel strongly against we can postpone it to 3.8...

Not really, I'm in favor of merging quickly.
And in general I don't think we should treat the whole quick library with the same level of stability as the rest. There are very few dependencies on it and no official downloads will ship it, it's really just a dev library. I'd actually be in favor of tagging it as experimental to make this clear, including no API stability guarantee.