Complexity of a Text Input Widget
Both of the v1.6 patches so far have addressed regressions in Lagrange's text input widget. This is because I did a major rewrite of its internals to better support multiline long-form content. Since the widget is quite complex, several details and edge cases broke in its behavior.
This got me thinking, exactly how complex is the `InputWidget` class? It has the following functionality in addition to the normal behavior of any `Widget`:
- full Unicode support (internally UTF-8), including bidirectional text
- variable or monospace font
- hard-wrapped lines (\n)
- word-wrapping to fit widget width
- user preference for Return key modifier for line break/accept
- moving the cursor via arrow keys
- moving up/down by a word-wrapped line segment
- jumping to next/previous word
- jumping to start/end of the line
- jumping to start/end of the word-wrapped line segment
- jumping to start/end of content
- page up/down
- some keys depend on the operating system (e.g., select all)
- copy to and paste from system clipboard
- undo
- option to revert all edits when pressing Escape
- insert/overwrite cursor mode
- backspace and forward delete a character or an entire marked range
- marking text for selecting while holding Shift
- positioning cursor with the mouse pointer
- marking text for selection by dragging the pointer
- selecting whole words with the pointer (after double click)
- select all with a triple click
- scrolling with mouse wheel or trackpad
- drawing only the currently visible lines, some of which are word-wrapped
- drawing the selection mark
- drawing a blinking cursor that stops blinking when typing
- drawing a hint text if the field is empty
- periodic content backup (for the upload editor)
- expanding/shrinking widget height depending on amount of content, but only to some maximum height
- if only a single visible line is allowed: scroll horizontally or vertically? (earlier it was horizontally, then expanding, now vertically)
- URL mode that disables word wrapping
- sensitive input mode that renders all characters as •
- sensitive input mode disallows line breaks
- fixed-length mode that also disallows line breaks (e.g., UI scale factor)
- option to select all when widget is focused
- configurable paddings (e.g., room for lock icon in URL field)
- buffer all visible content for faster drawing when unfocused
- validator callback to see if content can be accepted
- traditional editor mode that ignores user's preference on line break keyboard modifier
- highlight domain name in URLs (still broken in v1.6.2)
- omit "gemini:" from URLs if short on space (since it's the default, broken in v1.6.2)
😬
With a feature list like this, one can understand why text editors are apps in their own right. (The class stands at 2000 lines of code at the moment.)
Even if I was using a ready-made text editor from some GUI framework, there's plenty of custom functionality here that would complicate things. Some of these could be quite difficult to do depending on the framework.
I'll be making more tweaks and fixes for v1.6.3. Fortunately, severity of the remaining bugs is trending down.
📅 2021-08-04
🏷 Lagrange
CC-BY-SA 4.0