Eto: Construire une chaîne RTF sans déranger RichTextArea

Salut @katatunix , merci pour la demande. J'ai en fait travaillé sur quelque chose dans ce sens (une sorte de TextBuffer) qui a tous les mêmes API que RichTextArea mais vous permet de le construire séparément puis de l'ajouter (ou de le définir) à RichTextArea.

Une chose que j'aimerais qu'il fasse, c'est qu'il puisse être construit dans un fil d'arrière-plan, mais malheureusement, toutes les plates-formes ne le prendraient pas en charge. Je suis toujours en train d'enquêter là-dessus.

Si vous avez un code à ce sujet, j'aimerais y jeter un œil.

@LaraSQP Je viens de télécharger mon travail jusqu'à présent dans PR #1507

Puisque le contrôle RichTextArea ne gère que quelques propriétés (police + style, couleur avant + arrière), pourquoi ne pas écrire une classe rtf "simple" pour composer une chaîne rtf puis la transmettre au RichTextArea.Rtf propriété ?

Quelque chose comme:

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

Est-ce que je rate quelque chose ici et que je redeviens un crétin ?

@LaraSQP non, cela fonctionne totalement. GTK ne prend pas en charge RTF cependant.

Je ne pense pas qu'Eto ait besoin de fournir cette fonctionnalité directement, car il n'y a aucune raison pour que vous ne puissiez pas utiliser un générateur RTF externe puis l'alimenter sous le contrôle d'Eto.

Je ne connaissais pas GTK et RTF. C'est une déception.

Le constructeur RTF externe ne fonctionnera pas tel quel en raison des problèmes soulevés par l'affiche d'origine (différentes classes/types par rapport à Eto par exemple, Font, Color ...) et, dans tous les cas, le flux RTF devrait être converti en quelque chose affichable par GTK. Ainsi, votre TextBuffer .

Zut

@LaraSQP Vous _pouvez_ théoriquement construire le RTF à l'aide d'un outil/api externe, puis le charger dans Eto. Vous pouvez utiliser la police/couleur d'Eto et les traduire dans un format compatible RTF si nécessaire.

Le problème avec RTF est cependant que même s'il s'agit d'un "standard", il est vraiment composé différemment selon la plate-forme (au moins Mac vs Windows). Les noms de polices spécifiés dans le RTF en particulier sont très différents. Vous pouvez voir les différences en utilisant TextEdit sur Mac par rapport à WordPad sur Windows.

J'espère que cela t'aides.

Désordonné en effet.

Il faut dire que vous avez fait un excellent travail avec le portage Linux. Pratiquement aucune pénalité de performance malgré une utilisation intensive de plusieurs polices et couleurs.

Le même code sur Windows est une limace cependant.

Le même code sur Windows est une limace cependant.

Oui, je ne sais pas comment contourner cela. FlowDocument est extrêmement lent.

Puisque les performances sous Linux sont excellentes, sauriez-vous que ses performances sont sur un Mac ?

@LaraSQP, cela devrait également être assez rapide sur macOS. d'après mon expérience, c'est juste WPF qui est assez lent à ce stade. J'aimerais trouver un moyen de le rendre plus rapide cependant (;

Dans ce cas, considérez que ce problème est clos pour moi.