TextField

[Updownquark]

Have the option of multiple lines instead of a separate TextArea widget (?)

Also create a ValidatedTextField widget. This widget should have modes for unset, incomplete, invalid, validation pending, and valid. Should have a simple mechanism for specifying styles for these different modes. Default would be a red fuzzy border for unset, incomplete, and invalid (possibly slightly different between them), an animated progress-like border for pending, and fading green fuzzy border for valid, finishing with an inconspicuous visual cue that the input is validated.

[Updownquark]

The error preventing this from working says a widget already accepts an attribute named "role". I foresaw this when working on templates (#32, here) a while back, but didn't address it at the time. The problem is that I'm using a border, another templated widget, with specified content inside the template for text field. So to specify the content of the border from outside the template, there has to be a role for the text field template, and a role for the border. Right now the attribute manager only allows one attribute of a given name.

The correct way to resolve this is to allow multiple attributes with the same name, and define well which one gets assigned if an attribute is specified by name (as opposed to by the attribute object itself). I suspect the attribute last accepted should be the one specifiable by name, but I need to make sure.

The other problem is that in order to specify styles for the internals of the text field (corner radius of the border should be zero, the background color of the label should be white), I have to resort to using groups. As I wrote in #38, I think I should be able to specify styles for the attach points inside a template.

[Updownquark]

Text field now shows up. I had it showing the border with white inside (margin spacing between the border and the white). But after I moved the white style to the border pane, the border doesn't show up anymore. The border texture code is being called, so I don't know why it's not working.

[Updownquark]

Text field now renders correctly. At least 4 more things to do:

1. Special style schemas #38 Need to add the ability to specify styles for attach points in a templated widget. Shouldn't have to declare a group for each attach point we might want to style.
2. Design the input models/mechanisms for the text field. A text field needs a cursor where text will be inserted upon keyboard input. It needs the ability to select by drag and copy to clipboard (this will need to be done on a text element as well. See the comment on Implement Label Widget #8), and paste from clipboard.
3. Determine the scope of this widget. Should this allow multiple lines? Should it allow formatting in the text, e.g. styles? How complex will its document model be? Multi-line, yes. Styles, no.
4. Hook up to MUIS models

[Updownquark]

The next thing to do is design the input mechanism. Think about allowing some of this to be specified in an attribute so that the feel of the widget can be switched out.

[Updownquark]

Not leaving it in a great state here. :-( There's still parsing errors with the style sheets even though I thought I'd fixed them. Gotta fix them before anything else has a chance to work. That said I did some good work today, even though text selection still isn't working. To do now:

1. Fix text selection in text elements.
   • Fix the style parsing bugs
   • Make sure the indexes for anchor and cursor are right
   • Create a texture that uses the document to draw the background of the text element, obeying the background style behind selected text.
2. Make sure text selection works for text fields (may not look right as-is with the offsets and borders)
3. Implement text input for text fields
4. Implement copy/paste

[Updownquark]

Good day! The design work and implementation for basic text fields is almost done, barring conceptual problems that show up later. There's an exception for one of the last features, filling a text box with more text than it can display. There's only one more feature I can think of that the basic (1-line) text box needs, and that's Home and End key support (with and without shift held).

[Updownquark]

Text field looks better and better. There are a few issues, and then some features to add:
The issues:

1. It seems that sometimes the text exit layout and the cursor overlay get out of sync, so that the cursor is displayed just a little ways off from where the cursor actually is over the text.
2. There's a broader eventing issue that is causing render artifacts when the user holds down a key (e.g. an arrow).

The features:

1. End/Home support
2. Hook up to MUIS models (for text fields and labels)
3. Multi-line support
4. Up/down/ Page Up/Page Down support
5. Better style support (perhaps write a demo where the user can press a button or enter text in a field that will change the text color of new text entered into another field (leaving old text the same color)) Styles are for another widget.
6. Cut/Copy/Paste formatted text (e.g. RTF) No styles.
7. Think about other features, e.g. formatting, validation, etc. These may or may not end up being different widgets that use text field.

[Updownquark]

Hooking up to models (text fields and labels) is next.

[Updownquark]

I need to be able to change the document in a text element so a MUIS model may specify an actual document for a text widget. This would allow the model to insert a model that does different kinds of formatting. Possibly the use case for this is not likely and can be done other ways. Replacing the document is not trivial though. Listeners may have already been added to the document which would need to be transferred to the new document, but documents coming in from models may have listeners on them that MUIS did not add. It's sticky.

[Updownquark]

I need to test the latest code before I really call it good, but TextField is pretty good now. I'm gonna work on a nice demo of the existing functionality for a while before I add more features.

[Updownquark]

Just realized I need to fix TextField to not apply user changes to the model until focus lost or enter is pressed. Perhaps this could be an option.

[Updownquark]

Been thinking more about this. I think rich editing will be done by a more complicated widget than this. Probably one with lots of buttons and other widgets to facilitate creating more complex documents. I'm not sure if formatting and validating should be done in this class or not (most likely not), but regardless that will be a separate task.

So the things that need to be done before this can be closed are:

1. Change the AbstractSelectableDocumentModel to only send out updates when the write lock is released. This will allow batching and perhaps elimination of some events.
2. Enable some kind of insulation between what the user is editing and the model value. The model value should not be written each and every time the user presses a key. Focus lost and Enter (Ctrl+Enter for multi-line fields) should trigger a model write.
3. Support multi-line well and include this in the text field test. This needs to be an option that is disabled by default. Normally pressing enter should commit the field's value but should not make another line. In a multi-line field, enter should not commit the field's value. Ctrl+Enter should.
4. Double-click should highlight the word. Triple-click should select the line.
5. Text box goes really short when all text is removed. Text element needs to keep its preferred height when all the text is gone.

[Updownquark]

Multi-line support is in and text field looks pretty good. I mentioned in the comment just above that I wanted to batch events from AbstractSelectableDocumentModel. I tried this last night and it seemed like it messed some things up. My solution seemed simple and I don't understand why it didn't work. It's very possible that this can be done and it's also possible there's some conceptual problem with it. In any case, it doesn't affect text field's functionality to not be there. I'm sure to find bugs in it in the future, but I declare that the development of text field is done!!!