QEP #11 - Fields and forms redesign

[m-kuhn]

The tab Fields on the vector layer properties dialog should be split into two different tabs that separate data-related from form- and widget-related user interface elements.

This is expected to improve user experience and usability.

[olivierdalang]

Fields tab

For me, there's a problem (already existing) with having a "fields" tab in this window.

The current "layer properties" window mostly allows to edit how QGIS should represent a data source (labels, style, simplification, etc.). Those settings are only project-wide and not much damage can be done there. This "representation of a datasource" is actually what a "layer" is.

But then, in this "layer properties" window, we viciously added some buttons to create/edit/delete columns, which creates/edits/deletes data in the underlying datasource. By doing so, we maintain a terrible confusion between a layer and a data source. With this confusion, it becomes hard to know what we're working on, and thus it becomes possible to break things.

For example, about the constraints : are they defined in the QGIS file ? Or in the database directly ? How can I tell ?

Another example, about the "metadata" tab (I never really used it): is the metadata about the QGIS layer, or if it's about the underlying datasource ? (or is it stored in the comments field of my Postgis table, or is it simply stored in my QGIS file ?). I never used the metadata tab, but I guess the fields are about the QGIS Layer, while the "properties" textbox displays info about the datasource.

I'd suggest to be very clear about the difference between a datasource and a layer. It's a very important one, and one that is hard to understand for every beginner.

In this particular case, I'd suggest to remove every data related button/setting from the "layer properties" window. The "layer properties" window should be about "layer properties", which has not much to do with the underlying data.
All data-related operations would have to be done in the attribute table, where it's clear what we're working on. If we're not happy with that, we should have a "data source operation" (or something) window.

What could be acceptable still is some information read-only information about the underlying data. Maybe we could find a graphical way (italic ?) to represent that this information comes from the underlying data, and must be changed at data-source level.

Forms tab

One detail about the suggested UI changes: I'd love to have the ability to set several forms widget at once. It happens to me quite often that I want to set multiple column's widget to "hidden", or set multiple columns to the same widget with the same parameters.

Thanks !

[anitagraser]

note: the screenshot of the fields dialog is titled "form"

[nyalldawson]

@m-kuhn Looks like a good idea to me - my only suggestion would be to add the field type to the list of fields. Otherwise it will be quite tedious to go through each field to determine their types. This could be done either by adding the type in brackets after the name (eg "id (int)", "name (string:50)", etc), or by making the field list widget a table with a column for field type.

[m-kuhn]

@nyalldawson
Yes, a bit more information would be good.
Alias probably as well. And the comment. They could be in the tooltip. Alias: Comment

[m-kuhn]

@olivierdalang

Thank you for your comments and sorry for the delay.

I agree that it would be good to have a stronger differentiation between layer and datasource than we currently have.

But at the same time I think it is not that easy because these concepts are mixed inherently. To take your example of the attribute table, this is not just the data source but actually a combination of data from the source with changes from the (layer) edit buffer on top. And virtual fields and joined fields which are also not from the data source. Currently you see almost nowhere in QGIS the real data source (except db manager I guess).

So the only widgets that allow to modify the data source on that page are the ones on top (that are linked to the layer editing). And not even they modify the data source directly, but write to the edit buffer.

Personally I don't think that having an extra page (with most of the information from this page duplicated) will make it easier to use that software. Nor do I think that the attribute table is a place that helps to understand that difference.

But I like your idea of giving some kind of visual hint to the user. That could be icons or colors that are used if an operation involves data source changes. And in the attribute table using a different background color for the columns that are not directly retrieved from the data source.

Concerning constraints (which are not part of this QEP and only mentioned as a possible future benefit). As we are normally working on the edit buffer we abstracted away the database constraints. That also means, that a user does not get immediate feedback when something he does to the edit buffer will not be accepted by the database backend. To overcome this, my idea would be to have constraints that are enforced on anything entering the edit buffer and allow to react immediately and not only when committing to the database. And it would allow to have some constrained interface for data sources that do themselves not support the concept of constraints. Such constraints therefore would be local and could optionally be synchronized with database constraints.

Concerning metadata, I have no idea.

Setting several form widgets at once would be a nice feature that can go with that change or as a separate additional one. I'll offer that one as an optional add-on.

[NathanW2]

QEPs done via issues now.

New ticket at #37

Sorry for the inconvenience.

Email out soon on why.