Access to higher-fidelity events for TextField

[jonhoo]

At the moment, TextField only supports the OnChanged event callback, which triggers every time the user makes an edit to the field (often just a single character change). It is hard to build useful features on top of this, because you do not know if the user pressed a key, pasted, released a key, erased a character, etc. Furthermore, you cannot detect actions such as the user pressing the enter key in the field, because this does not change the contents of the text field. Having a finer-grained set of events for TextField (keyUp and keyDown come to mind) would be extremely useful, and would enable much richer interactions with input fields.

[andlabs]

With regards to things like disambiguating pastes and insertions and deletions, the question is what the underlying OS provides me with. I can map out a table of what I can/cannot do later.

As for the Enter key, the issue is what constitutes "editing finished" varies between OSs. Again, I don't have time right now, but I can go over the details later.

[jonhoo]

Much of this could be fixed by having a lower-level event binding available (onKeyUp, onKeyDown); having "semantic" text field events might be useful for ease-of-use, but it is also fairly limiting. Isn't having the low-level events available first better, as it allows any use-case to be implemented? When something like OnEditFinished is ready, authors could switch to that to simplify their code, but at the moment it isn't even possible to fake such a feature. Furthermore, there are many operations that could be interesting to implement (arrow up for command history for example), and you wouldn't want to have to implement them all as separate event types.

Also, given that OnChange is already a thing, presumably you have access to the raw keyboard events, so propagating them up should not be particularly hard? If you want, I could implement it myself and submit a PR. A few pointers about how/where you would want it implemented would be useful though.

[andlabs]

From what I gather, when the user hits the Enter key on an edit control in a Windows dialog, the entire dialog is asked to close because the "default button" is triggered by default on the Enter key. I don't know if this is how most programs nowadays actually behave, but this was the original intended design. (It's implemented sloppily. We can override this behavior with a subclass.)

GTK+ has similar functionality, but it's disabled by default and the entry sends editing-done (a GtkCellEditable signal) in that case.

I have no idea what OS X does.

[andlabs]

So wait, what set of events are you interested in?