Eto: Construya una cadena RTF sin molestar a RichTextArea

Hola @katatunix , gracias por la solicitud. De hecho, he estado trabajando en algo en este sentido (una especie de TextBuffer) que tiene todas las mismas api que RichTextArea, pero le permite construirlo por separado y luego agregarlo (o configurarlo) al RichTextArea.

Una cosa que me gustaría que hiciera es que se pueda construir en un hilo de fondo, pero desafortunadamente no todas las plataformas lo admitirían. Sin embargo, todavía estoy investigando esto.

Si tiene algún código sobre esto, me gustaría echarle un vistazo.

@LaraSQP Acabo de subir mi trabajo hasta ahora en PR # 1507

Dado que el control RichTextArea solo maneja algunas propiedades (fuente + estilo, color frontal + posterior), ¿por qué no escribir una clase rtf "simple" para componer una cadena rtf y luego alimentarla al RichTextArea.Rtf propiedad?

Algo como:

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

¿Me estoy perdiendo algo aquí y parezco un idiota de nuevo?

@LaraSQP no, eso funciona totalmente. Sin embargo, GTK no es compatible con RTF.

No creo que Eto necesite proporcionar esa función directamente, ya que no hay ninguna razón por la que no pueda usar un constructor RTF externo y luego alimentarlo al control de Eto.

No sabía nada de GTK y RTF. Eso es un fastidio.

El constructor RTF externo no funcionará como está debido a los problemas planteados por el póster original (diferentes clases / tipos en comparación con Eto, por ejemplo, fuente, color ...) y, en cualquier caso, el flujo RTF debería ser convertido en algo visualizable por GTK. Por lo tanto, su TextBuffer .

Maldito

@LaraSQP En teoría,

Sin embargo, el problema con RTF es que, aunque es un "estándar", en realidad está compuesto de manera diferente según la plataforma (al menos Mac frente a Windows). Los nombres de fuente especificados en el RTF en particular son muy diferentes. Puede ver las diferencias entre TextEdit en Mac y WordPad en Windows.

Espero que esto ayude.

De hecho, desordenado.

Debe decirse que ha hecho un gran trabajo con el puerto de Linux. Casi ninguna penalización en el rendimiento a pesar del uso intensivo de múltiples fuentes y colores.

Sin embargo, el mismo código en Windows es una babosa.

Sin embargo, el mismo código en Windows es una babosa.

Sí, no estoy seguro de cómo solucionarlo ... FlowDocument es extremadamente lento.

Dado que el rendimiento en Linux es excelente, ¿sabría que su rendimiento es en una Mac?

@LaraSQP también debería ser bastante rápido en macOS. en mi experiencia, es solo WPF el que es bastante lento en este punto. Sin embargo, me gustaría encontrar una manera de hacerlo más rápido (;

En ese caso, considere este problema cerrado para mí.