Eto: Konstruieren Sie RTF-String, ohne RichTextArea zu stören

Hey @katatunix , danke für die Anfrage. Ich habe tatsächlich an etwas in dieser Richtung gearbeitet (einer Art TextBuffer), das die gleichen APIs wie RichTextArea hat, aber Sie können es separat erstellen und dann an das RichTextArea anhängen (oder festlegen).

Eine Sache, die ich gerne hätte, ist es so zu machen, dass es in einem Hintergrundthread erstellt werden kann, aber leider würden nicht alle Plattformen dies unterstützen. Ich recherchiere das aber noch.

Wenn Sie einen Code dazu haben, würde ich ihn mir gerne ansehen.

@LaraSQP Ich habe gerade meine

Da das RichTextArea Steuerelement nur wenige Eigenschaften behandelt (Schriftart + Stil, Vorder- + Rückseitenfarbe), warum nicht eine "einfache" RTF-Klasse schreiben, um einen RTF-String zu erstellen, und ihn dann an das RichTextArea.Rtf füttern.

Etwas wie:

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

Übersehe ich hier etwas und komme ich wieder wie ein Idiot rüber?

@LaraSQP nein, das funktioniert total. GTK unterstützt jedoch kein RTF.

Ich glaube nicht, dass Eto diese Funktion direkt bereitstellen muss, da es keinen Grund gibt, einen externen RTF-Builder zu verwenden und ihn dann der Kontrolle von Eto zuzuführen.

Wusste nichts über GTK und RTF. Das ist schade.

Der externe RTF-Builder funktioniert aufgrund der Probleme, die das Originalposter aufgeworfen hat (andere Klassen/Typen im Vergleich zu Eto, z. B. Schriftart, Farbe ...) von GTK in etwas anzeigbares umgewandelt. Somit ist Ihr TextBuffer .

Verflixt

@LaraSQP Sie _könnten_ das RTF theoretisch mit einem externen Tool / einer externen API erstellen und dann in Eto laden. Sie können die Schriftart/Farbe von Eto verwenden und diese bei Bedarf in ein RTF-freundliches Format übersetzen.

Das Problem mit RTF ist jedoch, dass es, obwohl es ein "Standard" ist, je nach Plattform (zumindest Mac vs. Windows) unterschiedlich zusammengesetzt ist. Insbesondere die im RTF angegebenen Schriftnamen sind sehr unterschiedlich. Sie können die Unterschiede sehen, wenn Sie TextEdit auf Mac vs. WordPad unter Windows verwenden.

Hoffe das hilft.

In der Tat chaotisch.

Es muss gesagt werden, dass Sie mit der Linux-Portierung großartige Arbeit geleistet haben. Kaum Leistungseinbußen trotz intensiver Verwendung mehrerer Schriftarten und Farben.

Der gleiche Code unter Windows ist jedoch ein Slug.

Der gleiche Code unter Windows ist jedoch ein Slug.

Ja, ich weiß nicht, wie man das umgehen soll. FlowDocument ist extrem langsam.

Da die Leistung unter Linux ausgezeichnet ist, wissen Sie, dass die Leistung auf einem Mac ist?

@LaraSQP es sollte auch auf macOS ziemlich schnell sein. meiner Erfahrung nach ist es nur WPF, das zu diesem Zeitpunkt ziemlich langsam ist. Ich würde gerne einen Weg finden, es schneller zu machen (;

Betrachten Sie in diesem Fall dieses Thema für mich als abgeschlossen.