Eto: Construir string RTF sem incomodar RichTextArea

Olá @katatunix , obrigado pelo pedido. Na verdade, tenho trabalhado em algo nesse sentido (uma espécie de TextBuffer) que tem todas as mesmas APIs de RichTextArea, mas permite que você construa separadamente e depois acrescente (ou defina) a RichTextArea.

Uma coisa que eu gostaria que ele fizesse é que ele pudesse ser construído em um thread de segundo plano, mas nem todas as plataformas suportariam isso, infelizmente. Ainda estou investigando isso.

Se você tiver algum código sobre isso, gostaria de dar uma olhada nele.

@LaraSQP Acabei de

Uma vez que o controle RichTextArea lida apenas com algumas propriedades (fonte + estilo, cor anterior + posterior), por que não escrever uma classe rtf "simples" para compor uma string rtf e, em seguida, alimentá-la para RichTextArea.Rtf propriedade?

Algo como:

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

Estou perdendo algo aqui e parecendo um idiota de novo?

@LaraSQP não, funciona totalmente. GTK não suporta RTF embora.

Não acho que o Eto precise fornecer esse recurso diretamente, pois não há motivo para você não usar um construtor RTF externo e alimentá-lo no controle do Eto.

Não sabia sobre GTK e RTF. Isso é uma chatice.

O RTF builder externo não funcionará como está devido aos problemas levantados pelo autor original (diferentes classes / tipos em comparação com Eto, por exemplo, Fonte, Cor ...) e, em qualquer caso, o fluxo RTF precisaria ser convertido em algo exibível pelo GTK. Portanto, seu TextBuffer .

Maldito

@LaraSQP Você

O problema com o RTF, entretanto, é que mesmo sendo um "padrão", ele realmente é composto de forma diferente dependendo da plataforma (pelo menos Mac vs. Windows). Os nomes das fontes especificados no RTF em particular são muito diferentes. Você pode ver as diferenças entre o TextEdit no Mac e o WordPad no Windows.

Espero que isto ajude.

Realmente bagunçado.

Deve ser dito que você fez um ótimo trabalho com o porte Linux. Quase nenhuma penalidade de desempenho, apesar do uso intenso de várias fontes e cores.

O mesmo código no Windows é uma lentidão.

O mesmo código no Windows é uma lentidão.

Sim, não tenho certeza de como contornar isso .. FlowDocument é extremamente lento.

Já que o desempenho no Linux é excelente, você saberia que seu desempenho é em um Mac?

@LaraSQP deve ser bem rápido no macOS também. na minha experiência, é apenas o WPF que é muito lento neste ponto. Eu gostaria de encontrar uma maneira de torná-lo mais rápido (;

Nesse caso, considere este problema encerrado para mim.