Eto: Construct RTF string without bothering RichTextArea

Hey @katatunix, thanks for the request. I've actually been working on something along these lines (a TextBuffer of sorts) that has all the same api's as RichTextArea but lets you construct it separately then append (or set) it to the RichTextArea.

One thing that I'd like it to do is make it so it can be constructed in a background thread, but not all platforms would support this unfortunately. I'm still investigating this though.

If you have any code on this, I would like to take a look at it.

@LaraSQP I just uploaded my work so far in PR #1507

Since the RichTextArea control only handles a few properties (font + style, fore + back color), why not write a "simple" rtf class to compose an rtf string and then feed it to the RichTextArea.Rtf property?

Something like:

https://www.codeproject.com/Articles/30902/RichText-Builder-StringBuilder-for-RTF

Am I missing something here and coming across as a moron again?

@LaraSQP no, that totally works. GTK doesn't support RTF though.

I don't think Eto needs to provide that feature directly, as there's no reason you can't use an external RTF builder then feed it into Eto's control.

Did not know about GTK and RTF. That's a bummer.

The external RTF builder won't work as is because of the problems brought up by the original poster (different classes/types compared to Eto e.g., Font, Color ...) and, in any case, the RTF stream would need to be converted into something displayable by GTK. Thus, your TextBuffer.

Darn

@LaraSQP You _could_ theoretically build the RTF using an external tool/api, then load it into Eto. You can use Eto's Font/Color and translate those to an RTF-friendly format if really needed.

The problem with RTF however is that even though it is a "standard", it really is composed differently depending on the platform (at least Mac vs. Windows). The font names specified in the RTF in particular are very different. You can see the differences using TextEdit on Mac vs. WordPad on Windows.

Hope this helps.

Messy indeed.

It must be said you have done a great work with the Linux port. Hardly any performance penalty despite heavy use of multiple fonts and colors.

The same code on Windows is a slug though.

The same code on Windows is a slug though.

Yeah, not sure how to get around that.. FlowDocument is extremely slow.

Since the performance in Linux is excellent, would you know its performance is on a Mac?

@LaraSQP it should be pretty fast on macOS too. in my experience it's just WPF that is pretty slow at this point. I'd like to find a way to make it faster though (;

In that case, consider this issue closed for me.