You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Factor out the material form control part of Input so it can be reused in non-text-editing scenarios #6421
Currently, the DatePicker "launcher widget" is a button. This is a feature request from Customer Leafy to add the ability to make the launcher widget look like a text input (probably with a format string that displays the current date).
"It would be great to leave what the input field will launch to the client. We currently use input fields to launch all kinds of things: custom full-page pickers, date pickers and even Google Drive file picker.
All we are asking for here is an input field that retains the same semantics as the regular one (can display errors, hints, values etc) except for one key area: We should be able to install a tap handler instead of launching into a text edit mode with keyboard."
Yeah we should abstract out the part of Input that shows the hint, the error message, etc, into a component that can be re-used by Input and by this generic widget, and then also provide some specifically for time values and date values with a similar API to Input.
We recently fixed a bug in our native app where users were able to paste data into these launcher fields. We need these fields to be read only. No keyboard launch, no manual input, no copy/paste.
We turn off text suggestions / auto correct so you don't get red squiggly lines for these elements.
If you are curious, this is the layout we currently use for launcher elements:
If material mandates a different design, I am up for presenting that to our UX and pushing it through. That is, we don't have to have an Input field to display this data. You could have regular text widget with a button whose label is configurable; or no button. Check out the due date etc fields for this form:
changed the title [-]<input> with custom tap handler[/-][+]Factor out the material form control part of Input so it can be reused in non-text-editing scenarios[/+]on Nov 3, 2016
I've uploaded a PR that factors out the Input support for label text and hint text and so on into a separate class called InputContainer. InputContainer manages an arbitrary widget child. Input now uses InputContainer to manage its InputField.
I think InputContainer addresses all of the requirements listed in: #6421 (comment)
Here's an example of InputContainer. Most of the complexity has to do with the dialog that's used to actually collect user input. Hopefully the InputContainer part is clear enough.
import 'dart:async';
import 'package:flutter/material.dart';
class InputContainerDemo extends StatefulWidget {
@override
_InputContainerDemoState createState() => new _InputContainerDemoState();
}
class _InputContainerDemoState extends State<InputContainerDemo> {
bool focused = false;
InputValue value = InputValue.empty;
String text = "";
TextStyle get textStyle => Theme.of(context).textTheme.subhead;
Future<dynamic> showInputDialog() {
return showDialog(
context: context,
child: new SimpleDialog(
title: new Text("Provide Input"),
children: <Widget>[
new StatefulBuilder(
builder: (BuildContext context, StateSetter setState) {
return new Padding(
padding: const EdgeInsets.all(16.0),
child: new Input(
value: value,
style: textStyle,
labelText: 'input label',
hintText: 'input hint',
onChanged: (InputValue newValue) {
setState(() {
value = newValue;
});
},
onSubmitted: (InputValue newValue) {
setState(() {
Navigator.pop(context, value.text);
});
},
),
);
},
),
],
),
);
}
@override
Widget build(BuildContext context) {
return new Scaffold(
appBar: new AppBar(title: new Text('InputContainer Demo')),
body: new Padding(
padding: const EdgeInsets.all(16.0),
child: new SizedBox.expand(
child: new Column(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: <Widget>[
new GestureDetector(
behavior: HitTestBehavior.opaque,
onTap: () {
setState(() {
focused = true;
showInputDialog().then((dynamic dialogValue) {
setState(() {
text = dialogValue;
focused = false;
});
});
});
},
child: new InputContainer(
focused: focused,
isEmpty: text.isEmpty,
labelText: 'input label',
hintText: 'input hint',
style: textStyle,
// The child needs to occupy as much vertical space as the Text object
// needs, even if the Text object's text is an empty string.
child: new SizedBox(
height: textStyle.fontSize,
child: new Text(text, style: textStyle),
),
),
),
],
),
),
),
);
}
}
void main() {
runApp(new MaterialApp(home: new InputContainerDemo()));
}
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
tvolkert commentedon Oct 25, 2016
"It would be great to leave what the input field will launch to the client. We currently use input fields to launch all kinds of things: custom full-page pickers, date pickers and even Google Drive file picker.
All we are asking for here is an input field that retains the same semantics as the regular one (can display errors, hints, values etc) except for one key area: We should be able to install a tap handler instead of launching into a text edit mode with keyboard."
[-]<input> like element for launching a DatePicker[/-][+]<input> with custom tap handler[/+]tvolkert commentedon Oct 25, 2016
@mpcomplete @Hixie
Hixie commentedon Oct 25, 2016
Yeah we should abstract out the part of Input that shows the hint, the error message, etc, into a component that can be re-used by Input and by this generic widget, and then also provide some specifically for time values and date values with a similar API to Input.
mehmetf commentedon Oct 28, 2016
A few more thoughts on this:
If you are curious, this is the layout we currently use for launcher elements:
mehmetf commentedon Nov 3, 2016
@mpcomplete
I would be okay with alternatives for this. I understand it might be hard to untangle in such a short time. Things that are required:
Highly optional:
[-]<input> with custom tap handler[/-][+]Factor out the material form control part of Input so it can be reused in non-text-editing scenarios[/+]HansMuller commentedon Nov 16, 2016
I've uploaded a PR that factors out the Input support for label text and hint text and so on into a separate class called InputContainer. InputContainer manages an arbitrary widget child. Input now uses InputContainer to manage its InputField.
I think InputContainer addresses all of the requirements listed in: #6421 (comment)
Here's an example of InputContainer. Most of the complexity has to do with the dialog that's used to actually collect user input. Hopefully the InputContainer part is clear enough.
Roll engine and update tests (#22643)
github-actions commentedon Sep 5, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.