Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indicator on volatile default values #280

Open
signedav opened this issue Feb 9, 2024 · 0 comments
Open

Indicator on volatile default values #280

signedav opened this issue Feb 9, 2024 · 0 comments

Comments

@signedav
Copy link

signedav commented Feb 9, 2024

QGIS Enhancement: Indicator on volatile default values

Date 2023/02/09

Author Dave Signer (@signedav)

Contact david at opengis ch

maintainer @signedav

Version QGIS 3.36

Summary

At the moment we have default values that can be applied when editing. Depending on the expression, they could depend on all attributes or they could refer to other attribute values. If this is the case, the values are updated "real time" in the form. Still, there are other expressions that do not update the widget values "real time", but can lead to new values (such as now(), rand() etc.). These are updated when the form is closed (i.e. on OK, or in the attribute table on index change). This keeps the performance stable, but it can be confusing for a user that the stored values differ from the values they saw in the form before.

image

Therefore, at least an indicator would be nice to show the user that these values are volatile.

Volatile vs. depending widgets

Here I call the widgets that are updated "real time" dependent widgets. Their expression refers to other attributes on which they depend, or functions that depend on "all_attributes".

All other widgets that contain functions in their expressions are called volatile. Not only now(), rand() (although they are mostly affected), but also other functions that could lead to a value change after the update.

"Apply default values on update"

Usually default values are applied on creating a new feature. With this setting they are applied on update.

image

More info about behavior of "Apply default values on update"

On Add Feature

  • Create and form opens:
    • normal-default-values are set
    • apply-on-update-default-values are set (all of em)
  • Changing a value in the open form:
    • normal-defalt-values are not reset
    • apply-on-update-default-values are reset when they are depending
    • apply-on-update-default-values are not reset when they are volatile
  • Pressing "Ok":
    • normal-defalt-values are not reset
    • apply-on-update-default-values are not reset when they are depending
    • apply-on-update-default-values are not reset when they are volatile (because they are set on form opens)

Identify and open Form

  • Form opens:
    • normal-default-values are not reset
    • apply-on-update-default-values are not reset (all of em)
  • Changing a value in the open form (only possible in edit mode):
    • normal-defalt-values are not reset
    • apply-on-update-default-values are reset when they are depending
    • apply-on-update-default-values are not reset when they are volatile
  • Pressing "Ok":
    • normal-defalt-values are not reset
    • apply-on-update-default-values are not reset when they are depending
    • apply-on-update-default-values are reset when they are volatile

Attribute table form view

  • Selecting feature and form is visible:
    • normal-default-values are not set
    • apply-on-update-default-values are not set
  • Changing a value in the open form (only possible in edit mode):
    • normal-defalt-values are not reset
    • apply-on-update-default-values are reset when they are depending
    • apply-on-update-default-values are not reset when they are volatile
  • "Changing feature selection":
    • normal-defalt-values are not reset
    • apply-on-update-default-values are not reset when they are depending
    • apply-on-update-default-values are not reset when they are volatile

This here is the behavior that should be - but still, there is a bug qgis/QGIS#56174 but this is not the scope here

Proposed Solution

Having an indicator marking all the widget where the values could change after closing the form.

image

Proposed icon is dark-grey ⤭ but open for alternatives

Affected Files

This is only prototype hacking. For a productive sollution, we might consider the use cases (add feature, where the values do not change on "OK" vs. edit feature).

qgsattributeformeditorwidget.h

    /**
     * Set volatile status
     */
    void setVolatileStatus();
    
    [...]
    
    QLabel *mVolatileLabel = nullptr;

qgsattributeformeditorwidget.cpp

void QgsAttributeFormEditorWidget::setVolatileStatus()
{
    mVolatileLabel->setText( QStringLiteral( "<font color=\"#4f4f4f\"><b>%1</b></font>" ).arg( QChar( 0x292D ) ) );
    mVolatileLabel->setToolTip( QStringLiteral( "This value could be reevaluated on closing the form\nbecause of the apply default value on update functionality") );
}

(mVolatileLabel is coded like mConstraintResultLabel)

qgsattributeform.cpp

void QgsAttributeForm::updateFieldDependenciesDefaultValue( QgsEditorWidgetWrapper *eww )
{
  QgsExpression exp( eww->field().defaultValueDefinition().expression() );
  
  if( exp.referencedColumns().isEmpty() && (!exp.referencedFunctions().isEmpty() || !exp.referencedVariables().isEmpty()) )
  {
      const QList<QgsAttributeFormEditorWidget *> formEditorWidgets = mFormEditorWidgets.values( eww->fieldIdx() );

      for ( QgsAttributeFormEditorWidget *formEditorWidget : formEditorWidgets )
        formEditorWidget->setVolatileStatus();

  }

Performance Implications

Not expected.

Backwards Compatibility

Affects only the layout, so no issues here.

Votes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant