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.

skyjake

📅 2021-08-04

🏷 Lagrange

CC-BY-SA 4.0

skyjake's Gemlog