SelectableText → ScrollTextCore; EditField → EditBoxCore

[dhardy]

Since SelectableText and EditField do not have scroll support they are best not used except as a child of another widget which manages their scroll behaviour (i.e. ScrollText, EditBox). The renames help emphasize this. (Further renaming before the next release is possible; internal module edit_field is not renamed for now.)

The property editable is replaced with read_only (an inversion: slightly clearer and aligns the default behaviour with the default boolean value false).

Add fn EditBox::with_frame_style; use in examples/splitter.rs instead of EditField. Motivation: EditField should not have been used here since it does not support scrolling. This is somewhat of a hack; ideally frames and margins will be reworked to avoid drawing "box" boundaries next to a visual divider like GripPart.

[m-hugo]

Since SelectableText and EditField do not have scroll support they are best not used except as a child of another widget which manages their scroll behaviour (i.e. ScrollText, EditBox). The renames help emphasize this.

Since SelectableText does not have scroll support, let's rename it ScrollTextSomething lol

and what if someone is looking for selectable non-scrolling text or scrolling non-selectable text?

[dhardy]

let's rename it ScrollTextSomething lol

It's a component of ScrollText; mostly ScrollText should be used instead. As for not having scroll support, it is a Viewport widget so a name like TextViewportee might be more accurate. We need a better name for "a thing intended to be seen through a viewport"... the closest word in the English lexicon is probably "view", unfortunately this is rather inspecific and already used for a different purpose (kas-view).

As they say, there are two hard things in computer science: cache invalidation and naming things.

and what if someone is looking for selectable non-scrolling text or scrolling non-selectable text?

The reasons for the current design are:

• For short UI labels, neither scrolling nor selection is usually required. Furthermore, if this part of the UI is inside a scroll region, it is convenient to be able to click + drag on this UI pane to scroll it, thus it is preferable for common widgets like Label not to handle clicks.
• For displaying error messages, longer instructions or configuration examples it is more likely both that selection is desired and that scrolling may be required; ScrollText is intended for these usages.

Now, it would be possible to add configuration to ScrollText to disable click handling (and thus selection) or adjust/remove the size limit used when sizing SelectableText (i.e. affecting initial size requirements to make scrolling less likely). It's also possible to put a Label or Text in a ScrollRegion, though that's a little less efficient.