Rich text editor

[lylythechosenone]

Goals

A rich text editor that can support different colors, font families, styles and sizes, all inline with each other, efficiently.

Steps

1. A rich text format
   • Look at existing implementations like lapce
   • Figure out an efficient representation
2. Rich text rendering
3. Some way to represent it in .slint files.

This is mostly an issue for me to keep track of my progress. CC @hunger.

Edit (Simon): The acceptance criteria here is to have all the APIs/enablers in place in Slint to permit developers to create (simple) rich text editing capabilities in their applications. We don't need to impose a concrete UI on the editing itself.

[FloVanGH]

Thank you for your suggestion.

Rich text is definitely something we want to provide in the future. From technical side one way we could archive it, is to make use of cosmic-text in slint https://github.com/pop-os/cosmic-text.

An other point we need to think about is how rich text should be defined in the slint language.

[lylythechosenone]

I do like cosmic, but it doesn't support rich text, does it? We'd still need to build that support ourselves.

As for the second point, that's the main thing holding us up. If we assume an editor with a large amount of text, re-creating it from an rtf file or similar every time it's changed would be slow. We need some other way to store it in slint lang.

[ales-tsurko]

Hey everyone! I tried multiple Rust libraries for GUI and stopped on Slint for my next app. As many others in Rust community looking for GUI libraries, I also need rich text editor (actually, at least syntax highlighting). And I found that you considered making your own editor, because you thought cosmic-text lacks rich text. But it actually does support it (well, not in a document form, but it has attributes on top of each the document format could be implemented), so I think integrating cosmic-text wouldn't be as much work as it were with your own implementation. You can check an example here: https://github.com/pop-os/cosmic-text/blob/main/examples/rich-text/src/main.rs
Thanks!

[FloVanGH]

Hey @ales-tsurko. Thank you for your feedback. Yes we know that cosmic-text supports also rich text. Rich text in common is something that is on the agenda. We have also done some first evaluation with cosmic-text to generate the text layout and draw the glyhs then with one of our renderers (in the first test case with skia). From my point of view a cosmic-text integration is something we can handle, but it will take a little bit of time to finish it.

[dustdfg]

I tried to read about the technologies mentioned earlier and some others. I also know about html, bbcode, mdast and they look like cosmic-text. In general they all use the same concept. They represent rich text as sequence¹ of pairs (string, formatting attributes).

What about QTextDocument, it looks like it uses the same concept and even looks like it organizes the whole text document as mdast do it. It not just gives you a bunch of text it gives you a tree of nodes where leaves is the text but other nodes are structuring containers for text (lists, tables, sequence of paragraphs that contains text). The only thing that bothers me in that is that it also has QSyntaxHighlighter and I don't know how it works. Does it parse text and create from it text blocks with different formatting? Maybe but I don't know...

My summary will be: "They are all about the same concept and it looks like it is the most efficient way to make rich text"
My opinion: "I don't know about cosmic-text but it looks good and it is on Rust so if there are no any problems (which are always present and usually hidden), it a good candidate"

Footnotes

1. formally mdast uses tree instead of array like others do. Each formatted block can have nested formatting blocks. It is just a bit another representation. I think it is just easier to store tree when your main aim is to parse document and maybe convert to something else... ↩

[dustdfg]

Hey @ales-tsurko. Thank you for your feedback. Yes we know that cosmic-text supports also rich text. Rich text in common is something that is on the agenda. We have also done some first evaluation with cosmic-text to generate the text layout and draw the glyhs then with one of our renderers (in the first test case with skia). From my point of view a cosmic-text integration is something we can handle, but it will take a little bit of time to finish it.

Hello, where can it be found? I need it even if it is raw and bad...

[ogoffart]

The wip/cosmic-text branch in this repo. https://github.com/slint-ui/slint/tree/wip/cosmic-text
But it's very raw

[jacquetc]

Hello,

A few thoughts.
Wouldn't it be better to homogenize the way unicode glyphs (rich or not) are drawn on a text editor and on a simpler label ?
Is the current glyph drawer in Slint able to do draw rich unicode glyphs ?

• If yes, the harder part is already done and rich text capabilities can be extended to other UI elements, like to labels.
• If no, I see two paths : adopt globally the way cosmic-text draws these glyphs or enhance your current system to add rich text drawing.

I both cases, you create a rich text editor the way you want. Commonality with Cosmic is well and good if all the participants share the same goals. Different specs can create frictions and forks (at best) or force you to create another crate altogether (the worst, since you already lost time and energy in the first crate).

Some (non-Rust) UI frameworks uses the OS implementation of Core Text (iOs), DirectWrite(Windows), ... Maybe not a good solution since Slint is focused on embedded devices.

What do you think ?

[tronical]

We need something like #1325 (a data model) before we can add support for rich text. In scope are the necessary APIs to allow users to implement rich text editors. A GUI in Slint for rich text editing itself (controls for formatting) is not in scope.

[lylythechosenone]

I second this. I think we may be able to close this issue, or retire it for now, in favor of the one you mentioned, as that one seems to have encompassed the goals of this one.

Leaving the choice of whether or not to close it to one of you guys.

[liaoxuewei]

follow with interest