-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
widget.Entry and widget.Form redesign #1701
Comments
Related to #1269. |
I'd personally see a move to the consistent formats available in Material Design Spec when it comes to Entry and Form: Even from the Flutter Specification, (the current version) the fields are much larger than shown in your video. TypesAnatomy and key properties for filled text
https://material.io/components/text-fields/flutter#outlined-text |
@AlbinoGeek You are right. The app in the video I had to develop it quickly, so I just wanted to do something functional. |
@fpabl0 Now I understand 👍🏻 Consider: https://github.com/fyne-io/fyne-x We could play with this over there. |
As this is modifications to existing widgets, and in-keeping with out goals for 2.0 I would recommend keeping the development here in the main repo. |
@andydotxyz So what should be next step? Will widget.Entry be redesigned to satisfy material design specs? |
If we could adapt the existing widgets with your changes to be more inline with material design I think it will be a bit improvement. mine question that comes to mind is should we adapt the form layout for mobile vs desktop? For example a left/right label/entry on bigger screens and the above/below layout for narrower? |
@andydotxyz hmm and that means editing widget.Entry or creating another one called TextField and deprecating widget.Entry? Then TextFormField will use a TextField internally to render an input with the label. Hmm I think the big problem with left/right label approach is harder to use because of the alignment with the others FormInput labels (we have to treat labels and inputs as independent objects instead of just one). Above/below approach is more versatile and more compact, so I would say that both desktop and mobile must have above/below approach, and the ones who wants the other approach, they can easily create it using a TextField and a Label within a Grid, but it is just my point of view. |
Yeah, that's the thing -- this requires quite a large re-design to the The dimensions of this component are entirely different than the I've found implementing material design's "spacious by default" components required changing Fyne's padding model... Which was also a breaking change. Filled TextFieldOutlined TextField: |
@AlbinoGeek I think |
That's a good point on it being a new major version, and I agree with you on As far as I know, As per the rounded corners, the specification also lists the amount of rounding as theme-specific -- it would be fair for
The page I have linked shows examples of material forms on mobile, with and without inline labels. |
Our widgets are occasionally limited by the canvas capabilities, then we get the features in to canvas and move on :). Theme2 is in place, we can add a new color type to articulate this if required. We also still need to split focus from selected color as well. There is a lot to do before 2.0 but we have 2 solid weeks of coding before we need to feature freeze ;). |
We should, if we can, continue with the current Entry field - I don't see any reason why that should not be possible. |
I see, but if widget.Entry shows Helper Text and Error Text, then its MinSize is going to be larger, doesn't it matter? |
There is a balance to be made here :) we want to avoid re-layout if possible, so reserving space fits better with how we have designed to now. Material Design seems to imply that you have either helper or error text, so maybe we have the error overlay the helper? |
Sorry, I don't understand very much what do you mean by "reserving space" 😅. Does it mean to keep the space as it is now?
Yes, that's right, just one of them is shown at a time. widget.Entry may have a belowText (or something like that) that will be the helper text if there is no error. However |
The current The filled Material Design TextField MinSize is |
@AlbinoGeek maybe widget.Entry could have a min height of 37 + 16 (when using helper text or error text), to avoid changing dramatically the size of this widget? |
@fpabl0 Fair points. It might not feel... like there's enough room to "breath" -- but again, this is based on the It's also worth noting that Material Design uses And to be fair, the |
@AlbinoGeek maybe we can just be flexible and try to convert the entry widget in a similar widget to the one in material design? I have edited the Entry widget to have a new boolean field called OutlineBorder, so users can choose if they want the underline form or the outline border form:
This screenshot shows the two forms: I have seen that the underline color will be red only if the field is unfocused (and has an error), is it the desired behavior? Personally, I prefer to show the red color as soon as the person makes the mistake (just like in the video in the start of this issue), isn't it better? |
We typically don't expose "design choices" as widget API as the widgets focus on behavior. The theme / widget should pick a design and just use it if following the Fyne API intent.
Icon background should be transparent to show through what is below, perhaps something else is going on here?
Yes, this is intended - confirmation will be shown immediately, but error markings will not show during edits. See "Assistive elements" in https://material.io/components/text-fields. |
I was considering that the space required would be left blank so it can be used - i.e. if a widget might use some space then make sure you have available space to use it. |
I see, that is one of thing I am not totally agreed with Fyne, that kind of behavior is too rigid and limit the reusability of the widgets to create others. The theme should set the default options for all the widgets but not force them to look as state in the theme. That's the way Flutter works, you can themify your app from Theme settings and all the widgets will look according to the theme, nevertheless, you can customize their styles if you want, the theme does not force you to use one single style.
Yes, that will be better and it matches all the needs, transparent background by default on icons should be great.
I see, that's fine. So, with the new changes (adding Leading and Trailing icons) the confirm icon must disappear, right? And user trailing icon must appear as long as there is no error?
Hmm, talking about label required space, then I think yes. But for helper or error text, I think that would change the size of the widget dynamically, otherwise it will look a weird blank space unused? |
Yes, indeed, but we have a different design style in that regard. The theme does not enforce the look however - it's the widget package that enforces use of theme. Custom widgets, or extended versions of the builtin ones, can choose not to.
I don't follow on this point sorry - I don't know how the addition of more icons was part of your proposal. The Entry already includes the right-hand area for items, that is how the validation and password icon are included.
We want to avoid doing this as it causes the whole UI to rearrange based on one widget state. Unless by design (such as accordion) this should not happen. Let us explore options - I suspect there is a way, I wonder if the label could be re-used as error instead of an additional help text area. Or perhaps it is optional, and reserved if that option is enabled? Just thinking out loud here. |
Back form a large internet outage: So, as per my understand of Material Design Specification (e.g.: imho / iirc): The leading icon is used to indicate different field types (such as Currency symbols, Data Entry, etc.) The trailing icon (as already used) is for validation and password visibility toggle. The bottom text area is always padded out -- and is either:
You can enable both helper text and the character counter. You can enable both helper text and validation.
SpecificationThe The
|
Ok, I see, that's fine.
I see, however as we cannot fully customize them (I am referring to the extended versions) without changing the theme, we have to either create a new widget from scratch or do some tricky code to fully customize it (as the TextFormField widget in the video, I have to take the objects of Entry widget from Objects() function and change their style from that slice). But, it is only my opinion, there are many advantages to have all the styles in the Theme, like consistency. Hmm maybe, there should EntryStyle type to edit all the entry style from the Theme? And basically for all widgets that can have various styles.
It does not part of my proposal, however as you said before you want "to be more inline with material design", I think you want to incorporate them as it states in the material design specs. But I am agreed with you, those new icons are not really important, it is just to "indicate different field types" (as @AlbinoGeek said)
Oh I see, sorry I didn't know it.
Reserved space must be a great option to avoid UI to rearrange dynamically and as @AlbinoGeek said, it seems that material design spec states that "The bottom text area is always padded out" . Maybe there should be a default Helper Text, to avoid have an empty space? Maybe something like "* Optional" or "* Required" if they attach a required validator (only if there is an implementation for common validators). Also, text lines must be limited to one line to avoid resizing the UI (specially for validation errors messages). |
@fpabl0 One unfortunate correction on my part, I have found examples in Material Design spec where a field does not have either helper text, validation or character count (such as the fields shown within the "Contacts" apps.) However... I have also found examples where they had no helper text, but did have validation-- where the layout did have to reflow because of validation. I really don't like that last situation. |
@fpabl0 Can you please join the #fyne gophers slack channel so I can send you more information? |
It seems great, but I think Entry must be working separately as it is different from the others (label animation for example only occurs in Entry, label in the center without placeholder only happens in Entry too). Or that means Entry would not have those features and it will just have a stacked label?
Yes, I can. I have just joined. |
Related PRs pushing this issue along: PRs
Issues |
After 2.0 we need to return to this for the label / form layout discussion I think. |
Removed blocking label as the stuff that requires the breaking changes are in. |
@fpabl0 Can I please get the code for the Border outline? |
Hello @BhanuMeghraj 👋
I would suggest you to not do so (editing directly the Entry widget), because you could lose the latest versions of Fyne that could include fixes and improvements. Instead, you can extend the Entry widget or create a custom one. Extending should be the easiest way for this, basically you would need to draw
Unfortunately I don't have that code anymore 😞, because I migrated to the latest fyne version and hard reset the changes I have done in that application, sorry. |
You could also overlay a rectangle on top, setting a stroke colour and width instead of drawing 4 lines. |
Yes that would be easier :) |
Hey there, sorry for not replying I have tried the suggestion given by @andydotxyz and it worked for me .Thankyou @fpabl0 and @andydotxyz |
could you show me your code? I have encountered some probelm. |
Is your feature request related to a problem? Please describe:
Yes, the current widget.Entry does not show the error messages, just notify to the user that there is an error. Current widget.Form only allows us to create 1 column form.
Is it possible to construct a solution with the existing API?
Yes, it is possible but there will be break changes (at least for the widget.Form, the other ones can be implemented as new widgets)
Describe the solution you'd like to see:
I have designed some apps with Flutter framework and I could say that its API is great. So maybe Fyne could adopt somethings from it. Based on it and to make things easier, the Entry widget could be redesign to this appearance:
fyne-textfield.mp4
And then create something like a widget.TextFormField that will add the label on the top of rectangle input as you can see in the video.
widget.Form could be completely redesign to accept variable columns.
This is how the above video was done:
Every TextFormField has an InputType that will prevent the user to enter letters when a number is expected (for example). It has a SetValidator function where we can add validators (FormValidator is a helper to add common validations). widget.Form will have three fields Inputs, Divisor and ButtonContainer, as you can see. Then we can user form.Build(cols) to create the form as fyne.CanvasObject by specifying the number of columns we want. form.IsValid() will trigger Validate() method on all the inputs and will return true or false to indicate if the form has errors or not. form.Save() will trigger the OnSaved callback that will have the inputs. form.Reset() will reset all inputs to its zero values (or the user initial ones??).
xcontainer.NewPadded is a new container too, that allows user to create custom paddings. By using just xcontainer.NewPaddingOpts() we are created a padding container just like the container.NewPadded, but you can add more options for example:
The text was updated successfully, but these errors were encountered: