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. #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 #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]

So number 1 in the comment above seems to be done. I was correct that the selection doesn't work right for text fields, and it does seem to be offset by the distance from the edge of the text field to the edge of the text.

[Updownquark]

Looks like the text field is where I intended it to be in that last big comment. Still a few things keep it from being what it should be though:

1. Blinking cursor
2. Cursor placement on click seems just a little bit off.
3. Text fields typically don't change size as the amount of text does, but maybe this could be an option
4. Newline characters are being put into the document, but line breaks are not being rendered. New line characters should not be allowed in text fields by default, but since they're going in they should be rendering.
5. My initial thought is that I'd like this widget to be the sole default editable text renderer in MUIS instead of having multiple widgets, e.g. text area. If this is to be so, text field needs lots more configuration to make it multi-line, scrollable (future), support cut/copy/paste of formatted text (e.g. RTF), etc. Part of this may be to develop an editor with font options, though maybe that's not for the base project. TextField might need to be renamed if it becomes more flexible than text fields typically are. Does need to support multi-line. Styles are for a different widget.
6. Empty stubs exist in the text selection behavior for using the up and down navigation buttons. Left and right work correctly.

[Updownquark]

I did not mean to close this.

[Updownquark]

The above commit should say that cut was also implemented.

[Updownquark]

The cursor blink sort of works correctly now. But there are some strange rendering issues. With the fixes I've done today the rendering issues have bled over into the document in general, so that MUIS looks much worse than it did yesterday. But I'm confident I've only exposed problems that have been here for a while and need to be fixed immediately.

[Updownquark]

The text field looks a bit better, but the highlight color flashes between the correct shade of blue and a washed-out shade. There's double-rendering of the document happening (the text selection change causes the text element to completely re-render and causes the text field to re-render the previous cursor area (this is the latest rendering fix that fixed little black pixels when selection changed), so these are not combined in the event queue because the cursor stretches out of the bounds of the text element. Not sure if I should try to make an attempt to combine these. Seems like I should later), but this should not cause display issues. This is the next thing to investigate.

[Updownquark]

I have fixed the highlight color flashing issue. Turns out it was a problem with ArrayUtils.cachingIterable in prisms. Referring to my comment a month ago, I'm not noticing strange rendering issues in the document in general now. Guess I'll have to be on the lookout for this.

[Updownquark]

2 things to investigate now. There's obviously a bug because the border should see its styles. The second is that I don't understand at the moment why I can't put the border and the cursor overlay right under the body, but when I tried to do that MUIS gave me an intelligible error saying that was illegal.

[Updownquark]

TextField looks great now. The next thing is to support a length attribute, which sets the preferred width of the field (in units of characters). I can't decide whether the default value of length should be 30ish or if it should be unset, meaning the text field prefers to grow with its contents. Along with this, I need to implement the ability to navigate large amounts of text within a small text field, using keyboard navigation (arrows, end, home, etc.). The cursor location must always be visible in the text field and text that falls off to the left and right must not be visible.

[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!!!