Renovate FlxInputText

[MSGhero]

trafficstars

Assuming openfl's input text is good, what should stay and what should go inside this class?

• Does the FlxSprite caret stay? It would interfere with the existing caret unless their blinking lined up.
• Anything boundary-related can be removed, right? The functions would point to the inner textfield's functions if they need to exist, but I feel like they existed solely for the caret placement.
• backgroundColor/backgroundSprite, hasFocus, passwordMode, filterMode, fieldBorder, etc are already implemented by openfl.text.TextField. And is there a reason these aren't in FlxText?
• The mouse press and key press code can be removed?

I guess the underlying question is "Are FlxText and FlxInputText just flixel wrappers for TextField, or do these properties and methods need to be custom-implemented?"

[larsiusprime]

1. The inner textfield's caret is not rendered in real time, it takes a snapshot of the textfield and rasterizes it when the text changes, so the caret probably does need to stay, or else we have to constantly re-rasterize the input text.
2. The boundary-related stuff can indeed fall through to the native textfield stuff, provided that's properly implemented now. The boundary calculations were a bit of a hack to deal with the fact that in the old openfl, you didn't have these functions for textfields.
3. These features weren't implemented in the old text field I believe, so if they exist in the new one we can just fall through to them.
4. Not 100% sure about this. Remember, the actual underlying text field is not actually on the stage, it's just being used in the background so it's in a weird limbo place rather than on a regular openfl display list context. That said, we don't want to duplicate unnecessary code (particularly with exotic stuff like IME input, etc), so we want to piggyback on the new, good, input text logic. That might take some creativity to properly delegate events.

Hopefully my answers to the above 4 give you a picture of how things work. It IS a wrapper around TextField, but it's not entirely straightforward because you don't have the regular openfl display list to give you the same event structure and interaction behavior "for free."

[larsiusprime]

Just had an idea -- I believe on HTML5 target a very similar approach is used -- a native DOM TextField is created off-stage and used to drive the inputs, which is basically what we're doing here in Flixel. So we can look to that as an example.

[MSGhero]

Textfields are a lot weirder than I thought they were haha.

[MSGhero]

So what's going on under the hood is there's a real tf somewhere, and we're copy pasting what it looks like into flixel? Which is why we need a custom caret. But then the real tf is not receiving keyboard input (unless we do the DOM tf stuff). And the boundary characters and getCharAtPoint just fall through.

Does not being on the stage have other consequences, like dispatching events or contains()? I guess flixel/ui deals with both of those.

[larsiusprime]

Yeah so flixel just completely subverts the entire flash/openfl API event model. Basically the only thing in flixel that touches that is FlxGame itself, which is a flash.display.Sprite, and the various input stuffs (keyboard, gamepad, etc) ultimately rely on flash-style events, but flixel's schtick from thereon out is to provide the end user with its own kind of display list (flixel's add() instead of flash's addChild()), etc.

And yeah, we use our own event system in flixel-ui.

By "contains" I assume you mean this? http://docs.openfl.org/openfl/display/DisplayObjectContainer.html#contains

That depends on the standard display list hierarchy, yeah.