Eto: Создайте строку RTF, не беспокоя RichTextArea

Привет @katatunix , спасибо за запрос. Я действительно работал над чем-то в этом направлении (своего рода TextBuffer), который имеет все те же API, что и RichTextArea, но позволяет вам создавать его отдельно, а затем добавлять (или устанавливать) его в RichTextArea.

Одна вещь, которую я хотел бы сделать, - это сделать так, чтобы он мог быть построен в фоновом потоке, но, к сожалению, не все платформы поддерживают это. Я все еще расследую это.

Если у вас есть код по этому поводу, я хотел бы взглянуть на него.

@LaraSQP Я только что загрузил свою работу в PR # 1507

Поскольку элемент управления RichTextArea обрабатывает только несколько свойств (шрифт + стиль, передний + задний цвет), почему бы не написать "простой" класс rtf для составления строки rtf, а затем передать его в RichTextArea.Rtf свойство?

Что-то вроде:

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

Я что-то здесь упускаю и снова веду себя дебилом?

@LaraSQP нет, это полностью работает. Однако GTK не поддерживает RTF.

Я не думаю, что Eto нужно предоставлять эту функцию напрямую, поскольку нет причин, по которым вы не можете использовать внешний построитель RTF, а затем передать его в элемент управления Eto.

Не знал про GTK и RTF. Это облом.

Внешний построитель RTF не будет работать как есть из-за проблем, поднятых исходным плакатом (разные классы / типы по сравнению с Eto, например, Font, Color ...) и, в любом случае, поток RTF должен быть преобразован во что-то отображаемое с помощью GTK. Таким образом, ваш TextBuffer .

Штопать

@LaraSQP Вы _ можете_ теоретически построить RTF, используя внешний инструмент / api, а затем загрузить его в Eto. Вы можете использовать Eto's Font / Color и перевести их в RTF-формат, если это действительно необходимо.

Проблема с RTF, однако, заключается в том, что хотя он и является «стандартом», на самом деле он составлен по-разному в зависимости от платформы (по крайней мере, Mac или Windows). В частности, имена шрифтов, указанные в RTF, сильно различаются. Вы можете увидеть различия, используя TextEdit на Mac и WordPad в Windows.

Надеюсь это поможет.

Действительно грязно.

Надо сказать, что вы проделали большую работу с портом Linux. Вряд ли какое-либо снижение производительности, несмотря на частое использование нескольких шрифтов и цветов.

Однако тот же код в Windows - это слизняк.

Однако тот же код в Windows - это слизняк.

Да, не знаю, как это обойти ... FlowDocument работает очень медленно.

Поскольку производительность в Linux отличная, знаете ли вы, что она работает на Mac?

@LaraSQP, это должно быть довольно быстро и на macOS. по моему опыту, это просто WPF, который на данный момент работает довольно медленно. Я бы хотел найти способ сделать это быстрее (;

В таком случае считайте этот вопрос для меня закрытым.