QEP 66: Better editor widgets with support for arrays and maps about qgis-enhancement-proposals HOT 15 OPEN

Hi Patrick

For backward compatibility reasons, it would not be a good idea to switch to an QList or QMap internal representation.

I would think it is preferable to use QList and QMap (or QHash) for arrays/maps because they can be stored in QVariant easily. Additionally, in QGIS 3.0 we are free to break compatibility. I believe the native storage instead of JSON would make it easier to use the new types in the code...

from qgis-enhancement-proposals.

@wonder-sk, if you guys are OK breaking backward compatibility that much, I would be happy to use QList and QMap for those types. I agree with you.

from qgis-enhancement-proposals.

I would think it is preferable to use QList and QMap (or QHash) for arrays/maps because they can be stored in QVariant easily.

+1 . I'd much rather see use of proper lists/maps in place of json strings.

from qgis-enhancement-proposals.

The structure of the strings returned for PostGIS native arrays would be changed from the specific PostgreSQL default representation (for example: {Georges,Germaine,"Cloé, Tulip","Henri Charles"}) to a JSON representation (for example: ["Georges","Germaine","Cloé, Tulip","Henri Charles"]). This could be a problem for custom plugins relying on that format.

I don't quite follow this. Do you mean so that the tables are usable in older QGIS versions?

from qgis-enhancement-proposals.

@nyalldawson, Yes, the current version of QGIS can work with tables containing array types. It just shows them as strings looking like in my example. If you edit them with the correct syntax, it works.

If I have no negative feedback by tomorrow morning about using QMap and QList internally, I'll change the QEP in that direction.

from qgis-enhancement-proposals.

The array/map proposal looks like it's on the right track for me! @m-kuhn or @3nids would be best to advise on the proposed editor widget changes.

Can you add a section outlining what tests you'll be adding too? I think for adding a new field type we should have tests covering:

• handling of the type in QgsField/QgsFields/QgsFeature
• individual provider test cases for each provider that supports the data type (read + write)

from qgis-enhancement-proposals.

@pvalsecc Nice proposal.
I am not sure to understand why an editor widget would "barely" support a given type ? What kind of use cases do you have in mind ?

The QgsEditorWidgetRegistry::findBestMatch looks if this table exists in the database of the given layer

How do you see that ? A connection to the database from the layer url ? Or new methods to vector data provider ?

I wonder if the mapping between a field and its editor widget (extra type information) could be made through typeName() and comment(), i.e. without the need of an auxiliary metadata table ?

from qgis-enhancement-proposals.

Nice ideas! Probaly related to: #37 ?

from qgis-enhancement-proposals.

@mhugo, this rating would be reserved for TextEdit. Let's take an example for an enumerated type in PostgreSQL. TextEdit can "barely" support it, but a specialized "EnumEdit" could, in the future "perfectly" support it.

The way to get the connection to the DB has not been investigated for the moment. There must be a way, since the style of a layer can come from a table. If I am going to that level of details, I'm doing a PR instead of a QEP ;-)
I guess I can get the QgsVectorDataProvider from the QgsVectorLayer and ask it. At least add a method to do it, that returns null for providers that don't know about that.

Your proposal to go through typeName() is not working. Imagine a color column in a table. In PostgreSQL, it will be stored as an int4 and that would be the content of typeName. So you want to be able to ship your DB with some info saying that this column of this table is actually to be used with the "ColorEdit" widget (to be implemented). The comment() one is dangerous. This stuff could be used in existing applications for other purpose and recycling it would mess it up. But, I could add another attribute to it and transmit this value in there.

from qgis-enhancement-proposals.

this rating would be reserved for TextEdit. Let's take an example for an enumerated type in PostgreSQL. TextEdit can "barely" support it, but a specialized "EnumEdit" could, in the future "perfectly" support it.

Is it equivalent to say each editor widget maps to some types and if no widget is found for a type, it is considered as text ?

About the metadata table, thanks for the clarification. Indeed comments() is not very clean. Maybe it is too early to state on this, but adding a new property to QgsField or QgsEditFormConfig to get the widget type from the provider may be considered.

Anyway, +1 from me for this proposal :)

from qgis-enhancement-proposals.

OK, updated:

• Switched the internal representation to QMap/QList when possible
• Added info about tests
• A few details here and there

What's the next steps? I'm new to this process and I'm not sure how the voting is done and where it is recorded. Anyway, it's vacation period... I guess I have to leave it up longer than a week, isn't it?

from qgis-enhancement-proposals.

Nice initiative!

Add a virtual method to QgsEditorWidgetFactory allowing a factory to tell how good it is to edit/represent a given field.

There is already bool QgsEditorWidgetFactory::supportsField() which is there fore the same purpose. If you introduce a new method that is more precise than this simple boolean, better remove this one (it's 3.0 time 😄 ).
I'd probably return an integer and start with values like 50 and 100 (i.e. not 1, 2, 3) this way there's enough space between the values to reorder them easily down the road also for 3rd party contributed widgets.

Concerning maps, it would be nice to be able to "promote" certain map values to look like real fields to QGIS. If you know there will be in all features a map key (e.g. "image_path") you can just promote that to a real field, QGIS will offer it as such throughout the API and load/write it to/from the map transparently. It's just an idea I had once and can easily be added later on.

Widget types from a table
The place in the code where the data for that will be collected is not yet determined.

We have a similar project upcoming in the next months. We will be doing this as a plugin/python code. The decision to implement this as a python extension was taken based on the fact that there are a lot of schemas (In Switzerland there is Interlis which also contains useful information which cannot always be mapped to postgres databases but can help to identify suitable widgets. Interlis is then preprocessed by yet another tool which adds yet more interesting information. In the EU it's interlis and I'm sure other countries have different schemas.). Do you think it would also work for you to keep this code separate?

from qgis-enhancement-proposals.

@m-kuhn,

There is already bool QgsEditorWidgetFactory::supportsField() which is there fore the same purpose. If you introduce a new method that is more precise than this simple boolean, better remove this one (it's 3.0 time 😄 ).

The idea was that supportsField would call the new method by default. But I have nothing against removing it.

I'd probably return an integer and start with values like 50 and 100 (i.e. not 1, 2, 3) this way there's enough space between the values to reorder them easily down the road also for 3rd party contributed widgets.

OK

Concerning maps, it would be nice to be able to "promote" certain map values to look like real fields to QGIS. If you know there will be in all features a map key (e.g. "image_path") you can just promote that to a real field, QGIS will offer it as such throughout the API and load/write it to/from the map transparently. It's just an idea I had once and can easily be added later on.

IMHO, this is already solved by the field calculator. Just add new fields with expressions taking the values from the map.

Do you think it would also work for you to keep this code separate?

I'd rather put a decent behaviour in the core, adding possible hooks for plugins to add more. For example, you don't use the widget type table, but you have a plugin registering itself so that findBestMatch offers it the possibility to choose the type.

from qgis-enhancement-proposals.

IMHO, this is already solved by the field calculator. Just add new fields with expressions taking the values from the map.

That will only allow reading, no? Adding write support for virtual fields would of course be a nice enhancement too, but I'm not sure it's trivial.

I'd rather put a decent behaviour in the core, adding possible hooks for plugins to add more. For example, you don't use the widget type table, but you have a plugin registering itself so that findBestMatch offers it the possibility to choose the type.

That sounds good.
And whatever is provider specific (postgres metatables) can be safely put there.

from qgis-enhancement-proposals.

Has there been any progress on this? I would definitely chip in towards sponsoring this enhancement!

from qgis-enhancement-proposals.