Pull together various text elements to a basic proposal

[andydotxyz]

We have discussed this plenty before but could benefit from wider examination.

[charlesdaniels]

One issue I think needs to be addressed is how will text selection work? Even if we don't want to address rich text editing yet, the user will still want to be able to copy/paste.

On desktop, mouse events could be passed into the individual rich text cells, since we know where the mouse and the cell are, and the selection logic handled internally. Then each cell could be responsible for rendering selected text internally. This could be combined with an endpoint for "give me the clipboard contents for whatever you have selected internally".

This might be trickier to handle on mobile/touch.

[andydotxyz]

One issue I think needs to be addressed is how will text selection work? Even if we don't want to address rich text editing yet, the user will still want to be able to copy/paste.

Aha yes a very good catch. I think an optional pair of methods Select(pos1, pos2) and SelectedText could do it right?
Then each object returned could add a highlight and the RichText would be responsible for any gaps between the elements...

[charlesdaniels]

I think this could work for basic text selection.

However, we may want to think of what the story looks like for rich text segments that have more complex interactivity. For example, consider an equation editor which allows subscripts and superscripts to be edited by clicking on them. Maybe we don't need to address that in the first pass, but I think we want to make sure it could be added in the future without major breakage. Perhaps an optional InteractableRichTextSegment interface, in the same spirit as the different types of repository interfaces in storage.

Something else worth considering would be - can we support changing the cursor type (on desktop) for different portions of a text segment? This may come into play with complex interactive rich text segment. Again, I think the initial version of this could be done without this feature, but we should consider how the API could be extended in the future.

TL;DR: we should think about having storage repository style extensibility for rich text segments.

[andydotxyz]

However, we may want to think of what the story looks like for rich text segments that have more complex interactivity.

The CanvasObject returned could be anything. If you want to put a full interactive element in there you can.
I don't think that the proposal needs to differentiate between regular visuals and interactive elements.
As long as the code response to the methods we provide it should work as you imagine.

[andydotxyz]

can we support changing the cursor type (on desktop) for different portions of a text segment?

Yes, any of the CanvasObjects could choose to control the cursor display by implementing the appropriate Cursorable methods.

[andydotxyz]

OK, this is now ready for review I think, previous comments all in - thanks :).

(sorry about the force push, my Git got very, very messed up)