Support hidden or vertical `Label` in `Form`

[AlbinoGeek]

Is your feature request related to a problem? Please describe:

I was created the remaining 7guis^1 applications for the fyne/7guis^2 repository, however, many of the remaining examples require a concept of field validation and state that we currently group into Form (since we don't have Data Binding Validation.)

The only problem is that the demonstrations become rather untrue to the originals when using Form as it is now.

Is it possible to construct a solution with the existing API?

Not sure.

Describe the solution you'd like to see:

In writing that application, I would like the ability to Hide FormItem Labels

However, there are also other use-cases where I would like Vertically-Stacked FormItem Labels

Currently, the only option is Tabulated Horizontally Prefixed FormItem Labels

[andydotxyz]

since we don't have Data Binding Validation

Data binding can provide validation (as the converters do)

The only problem is that the demonstrations become rather untrue to the originals when using Form as it is now.

Is it using form functionality? Maybe it would be easier to put it in a VBox if not.

[fpabl0]

Related to #1701

IMHO, this kind of features could be achieved by encapsulating label and hints to the actual widget (Entry, Select, etc) or creating a new widget/container called FormField that holds and decorates the widget with Label, Hint and Error texts. Although, it could only happen after we have layouts with alignment.

[andydotxyz]

If we want to support label-on-left and label-above (and perhaps no-label) a new widget does not really fix this. Aligning widgets based on the right-hand edge of all labels is trivial if this is 1 widget, but if every row is a different widget then it is a lot harder. This does not need to wait for any new alignment code if we add the functionality to Form because label (left) and any widgets (on the right) align correctly now. If the form re-orients it knows how to adjust positions to retain this alignment.

[andydotxyz]

The only problem is that the demonstrations become rather untrue to the originals when using Form as it is now.

Looking at the 7guis I would personally like it if we /did/ have labels. anonymous date fields are no good in real life.

[AlbinoGeek]

Looking at the 7guis I would personally like it if we /did/ have labels. anonymous date fields are no good in real life.

Sounds good -- I still stand by the request to have above-labels or no-labels on forms though :)

I would use above-labels everywhere on the mobile versions of my forms.

[fpabl0]

Aligning widgets based on the right-hand edge of all labels is trivial if this is 1 widget, but if every row is a different widget then it is a lot harder.

Agreed. Label-on-left form could not be part of widget, because it depends of other widgets, although this new widget could have a way to specify the label size using a private method, then we could adjust labels to the same size inside Form.

This does not need to wait for any new alignment code if we add the functionality to Form because label (left) and any widgets (on the right) align correctly now. If the form re-orients it knows how to adjust positions to retain this alignment.

You're right. My mistake.

[andydotxyz]

Although this new widget could have a way to specify the label size using a private method, then we could adjust labels to the same size inside Form.

This does not sound like a nice API TBH.

What I want to make sure is that our widgets hold a purpose. Just like the rest of the API it should be clear in what it provides. Having a public widget that exists for the purpose of allowing different configurations of a form does not really fit that definition, if I have understood correctly.

[fpabl0]

Having a public widget that exists for the purpose of allowing different configurations of a form does not really fit that definition, if I have understood correctly.

The idea is basically a FormField that encapsulates label, hint and error, without the need to use specifically a Form (so it can be used independently). But when the FormField is used in a form with labels in the left/right, it can use the that private method to do it and it would be simpler IMHO. For example, this could occur inside FormWidget (I have done it with VBox to facilitate the ilustration, it doesn't look bad though):

func makeForm(action func(), fields ...*FormField) fyne.CanvasObject {
    // get max label width
    maxLabelWith := float32(0)
    for _, f := range fields {
        maxLabelWith = fyne.Max(maxLabelWith, f.labelMinWidth())
    }

    // set label width
    objs := make([]fyne.CanvasObject, 0, len(fields))
    for _, f := range fields {
        f.setLabelMinWidth(maxLabelWith)
        objs = append(objs, f)
    }

    // add buttons
    objs = append(objs, layout.NewSpacer(),
        container.NewHBox(
            widget.NewButton("Action", action),
        ),
    )

    // organize the form
    return container.NewVBox(objs...)
}

https://user-images.githubusercontent.com/12239342/107155799-66e86480-6948-11eb-900d-c33c80884fce.mp4

[andydotxyz]

My opinion is that the proposed widgets here are more likely to add confusion than value. Additionally if you want to not show labels then use a VBox instead of a form. Supporting vertical arrangement when space is tight is interesting, but I think is under the previous form tickets.