Gemeinschafst projekt: rtf änliches komponente !

[Christian]

LoL Openoffice hat kaum cpu-last und die kunst bei solch einer komponente ist natürlich nicht immer alles neu zeichnen zu müssen...

[pluto]

doch hat es, drücke mal nur ein Zeichen länger Zeit.
Dann wirst du es auch sehen. Du musst natürlich die CPU anzeige im Panel drin haben, sonst siehst du das nicht. muss mal drauf achten, wenn du schneller schreibst oder so.

ich denke mein Programm da genauso... und das Problem ist ja auch klar:
je mehr Objekte ich habe desto länger ist die For schleife und desto mehr aufrufe von Textout habe ich.

[Christian]

Ich denke das hat andere Gründe beim OO z.b. Rechtschreibprüfung du Nase.
Von sowas billigem kommt 0 CPU Last. Und wenn du das ordentlich machst, funktioniert das auch.

[pluto]

du Nase ich habe die Rechtschreibprüfung abgeschaltet bei OO. *G*

PS: ein neues Wort spiel mit der Nase oder wie ?

[monta]

Du 'Nase' kannst deine Komponenten eh nicht mit OpenOffice vergleichen, und wenn du damit ne CPU-Auslastung, wie OpenOffice hast, na dann guten nacht. Vergleich es mit Wordpad, KWrite oder soetwas.

Und beispielsweise Wordpad macht sich im TaskManager beim normalen schreiben mit 1% und weniger bemerkbar. Ein bisschen mehr wird es hauptsächlich beim Scrollen, weil eben dort neu gezeichnet werden muss.

[pluto]

lol, evlt. habt ihr recht. Aber ich habe einen Guten Anfang. ich denke das ich es jetzt auf jeden Fall hinbekommen werde. Es ist nur noch eine Frage der zeit.

ich habe mir das so Vorgestellt:
Zuerst möchte ich eine normale Editor Komponente schreibe vergleichbar mit einem TMemo.
Funktionen:
- Editor Funktionen wie ein Memo.
- such Funktionen:
einmal soll auto. ein Such Dialog kommen was der Programmierer von außen Konfiguieren kann.
über eine Funktion soll das Abrufbar sein. jetzt soll es eine Option im Dialog geben, die alle Fund stellen hervorhebt wie bei Gedit unter Linux.
Es soll Regulärer Ausdrücke unterstützen für das suchen und ersetzen.
Es soll ein eigenen Higleiter System geben:
Jeder Higleiter soll in einer Datei abgespeichert werden, so der der User ganz einfach einen eigenen higleiter schreiben kann.

- Sprung Marken: und zwar nicht nur 0-9 sondern auch A-Z
Soviel dazu.

Wenn das soweit ist:
Funktionen für die Formatierung:
Fett, Kusif, Ausrichtung, Unterstrichen und soweiter.

Es soll die Möglichkeit geben einmal die Funktionen Direkt anzusprechen oder es soll von der Komponente eine Toolbar eingeblendet werden auf Wunsch.

Wenn das Fertig ist, möchte ich einen Wapper erstellen für die Delphi RichEdit Komponente.
Dieser Wapper Klasse soll als Emulater Funktionieren. Dachte ich mir. Das dürfte das einfachste sein.

Später möchte ich noch verschiedne Dateien laden und speichern können:
html, pdf, rtf, Open Office,.....

Es soll auch noch eine Variante geben die gleich ein TPageControl dabei hat.
und die entsprechenden Funktionen wie Alles Speichern, schließen und soweiter.

ach ja: zum kopieren/ausschneiden/einfügen einmal soll das über das gewohnte strg+c gehen oder auch wieder über strg+c+zahl oder Buchstabe damit ich mehrer Stellen kopieren kann. Diese Funktion habe ich einmal in einem Projekt bei mir eingebaut.

zu den Grund Funktionen zählen bei mir:
Normal wie gewohn schreiben zu können.
navigieren mit den üblichen Tasten: Pfeiltasten, Bild auf und ab, Pos 1 und Ende. Löschen Entf, Einfügen.

Markieren mit Maus und Tastertur.

Wenn das so weit ist. Mache ich mit den Such und Ersetzten Funktionen weiter.

PS:
Irgendwie hat die 7za Oberfläche aufeinmal den reiz verloren evlt. liegt es daran das ist dort einen seltsamen Fehler gibt, mit großeren Archiven und den ich einfach nicht erklären kann.
Evlt. werde ich sie weiter Entwickeln sobald ich den Grund und eine Lösung weiß.

So eine Komponente zu schreiben ist schon lange ein "Traum" von mir. und Jetzt habe ich sogar die Möglichkeit dazu.

[Euklid]

Viel Erfolg!
Euklid

[pluto]

Danke !

[theo]

lol, evlt. habt ihr recht. Aber ich habe einen Guten Anfang. ich denke das ich es jetzt auf jeden Fall hinbekommen werde. Es ist nur noch eine Frage der zeit.

Ja, klar. Aber lieber Pluto sei mir nicht böse. Ich behaupte nach wie vor dass du noch nicht mal die Probleme erkannt hast, die so ein RichEdit Teil mit sich bringt.
Das hat erstmal mit Suchfunktionen und Sprungmarken gar nichts zu tun.
Da muss du erst ganz kleine Brötchen backen und die sind für dich meiner Einschätzung nach noch zu gross.
Es ist kein Zufall, dass es in der Pascal-Welt sowas nicht OpenSource gibt.
Selbst die Trolltechs konnten in der QT Version 2 (Kylix) noch keinen brauchbaren Rich-Editor vorweisen. Und die Jungs sind bestimmt nicht auf den Kopf gefallen.
Ich würde sagen, dass ein Textverabeitungsprogramm zu schreiben mit zu den schwierigsten Programmieraufgaben zählt.
Also: Unterschätze die Aufgabe nicht und überschätze dich selber nicht!
Das ist wirklich nicht böse gemeint aber ich glaube, dass du besser mal deine 7za Oberfläche fertig machen würdest. Das ist um viele Dimensionen einfacher.
Und immer wenn du sagst: "Jetzt hab ich's dann gleich" weiss ich, dass du höchstens mal vernebelt die Spitze des Eisbergs erkennen kannst.
Ich hatte dir hier http://www.lazarusforum.de/download.php?id=97" onclick="window.open(this.href);return false; mal ein Bild gemacht, was als Diskussionsgrundlage hätte dienen sollen.
Und das war noch sehr einfach.
Deine Antwort darauf, was in diesem Bild zu erkennen ist, war etwa gleich qualifiiziert wie die Antwort eines 8 jährigen Kindes:

Naja ich sehe ein Bild mit unterschiedlich großen Text in unterschiedlichen Farben Da gestellt Ach ja der untere text scheint ein Absatzt zu sein.

Hier solltest du anfangen: zu erkennen worum's überhaupt geht. Welches sind Seiteneigenschaften, welches Absatzeigenschaften, welches Buchstabeneigenschaften.
Was will ich mit "Ofo" sagen? Das sind überlappende Glyphen, welche gewisse Zeichenmethoden im vornherein ausschliessen.
Dir sollten auch Begriffe wie Flattersatz oder Blocksatz geläufig sein, bevor du nur daran denkst sowas zu programmieren.

[schnullerbacke]

Wo @theo Wahr hat, da hat er Wahr.

Ich würde mal an deiner Stelle nicht davon ausgehen, das eine Textverarbeitung den gesamten Text auf dem Canvas vorhält, das ist schon aus Platzgründen höchst unwahrscheinlich. Im Studium durften wir im Praktikum einen kleinen Texteditor basteln, der sollte nicht mehr als 3 Seiten in einer Matrix halten und in diesen Grenzen auch editierbar sein. Ich war etwas vorlaut und hab das mit Pointern gelöst, wogegen der Prof. auch nichts einzuwenden hatte. Allerdings kam der Hinweis, nicht mehr zu machen als verlangt wird.

Das sollte dich nun auf die Idee bringen, das solche Texte immer nur partiell im Speicher gehalten werden. Es wird "vorausschauend" sowohl nach vorne wie nach hinten gelesen, damit beim Scrollen immer die nächste Seite zur Verfügung steht. Bei manchen Editoren kann man das auch sehen, das es so gemacht wird, weil die beim Scrollen immer nur seitenorientiert arbeiten. Genau das macht aber den Umgang mit den verschiedenen Formaten so schwierig. Schließlich darf die jeweils neue Seite ein anderes Format als die vorherige haben. Trotzdem darf Schriftfarbe und Schriftart auf der neuen Seite der vorhergehenden entsprechen. Das mußt du steuern. Um das fließend scrollen zu können mußt du mit 2-3 Seiten Vorhalt rechnen. Bei jedem Seitenwechsel muß wieder vorausschauend eingelesen werden. Man fährt also in Praxi ein kleines Fenster über das Textfile und verschiebt das in die gewünschte Richtung.

Nun kannst du mal leise nachdenken, was das heißt wenn du nun auf der gerade sichtbaren Seite eine Textstelle oder einen Absatz einfügen willst. Das bedeutet doch wohl, das alles was folgt nach hinten verschoben werden muß. Das geht auf der Datei nur sehr bedingt, beim Stream müßtest du da schon den Rest vom Stream in einen Puffer schreiben, das neue Stück anhängen und dann soviele Zeichen aus dem Puffer hinten dran hängen bis die Seite wieder aufgefüllt ist. Der verbleibende Rest des Puffers muß dann vorne in die nächste Seite geschrieben werden und der Überhang von dieser wieder in die nächste und so fort...

Das schreit also schonmal nach mindestens 2 Threads, einen für den bearbeiteten Text im Speicher, einem 2ten der das Verschieben übernimmt. Dabei müssen alle Formate richtig mit fortgeschrieben werden. Das ist für einen einzelnen kaum zu leisten, es sei denn es kommt nicht drauf an wann das fertig wird. 4-5 Jahre Arbeit dürften das aber sein, bis da was halbwegs brauchbares herauskommt.

Einfacher dürfte es da wohl sein, einfach ein existierendes Textverarbeitungsprogramm aufzurufen und dem die Bearbeitung zu überlassen. Alleine für die Variablen für Serienbriefe und ähnlichem hat man da noch genug zu tun. Aber selbst das kann man heute getrost den Textverarbeitungen überlassen. OpenOffice bietet dir ja schließlich auch eine Schnittstelle zu verschiedenen Datenbanken an. Und OO kann nun wirklich ne ganze Menge Formate, also verschwende nicht deine Zeit und mach lieber das 7z fertig, das ist lehrreicher und auch noch schwierig genug, wie du selbst schon gesehen hast.

-Erhard

[theo]

Das sollte dich nun auf die Idee bringen, das solche Texte immer nur partiell im Speicher gehalten werden. Es wird "vorausschauend" sowohl nach vorne wie nach hinten gelesen, damit beim Scrollen immer die nächste Seite zur Verfügung steht.

Der Grundgedanke ist schon richtig. aber das ist erst Aufgabe Nr. 549 beim schreiben eines solchen Dings.
Da kommt noch gaaaanz viel vorher. Daran würde ich am Anfang der Entwicklung auch noch nicht denken, sonst kriegst du nie was hin.
Es stimmt auch nicht ganz. Sobald du HTML editieren willst, kannst du die A4 Seite vergessen. Da kann eine Seite theoretisch unbegrenzt lang sein.
Du musst aber aber schon ausrechnen wie gross die totalen rendering-Dimensionen sind wegen den Scheiss Scrollbars
Aber du musst es nicht bei jeder Buchstabeneingabe machen. Ich würde also auch hier eher den Absatz statt die Seite als Einheit nehmen um zu bestimmen wann im Grossen total neu gerendert werden muss. Da sind natürlich viele feine Methoden denkbar, wie man das beschleunigen kann. Die definitve Bremse ist aber das Zeichnen, v.a. z.B. unter GTK2 mit Anti-Aliased Fonts. Das ist echt langsam und da darf man wirklich nur jeweils das Minimum neu zeichnen.
Ausserdem würde ich am Anfang nicht mit Threads arbeiten. Das wird viel zu kompliziert und es gibt erst mal schlauere Methoden zur Beschleunigung.

[schnullerbacke]

@theo

Aber man muß es halt vom Start weg bereits berücksichtigen, sonst muß man die Textgröße beschränken. Das macht ja nun gar keinen Sinn. Und das später abändern ist nun auch nicht das Gelbe vom Ei.

Und bisher hatte ich für mich immer den größten Erfolg wenn ich vom Kleinsten ausgegangen bin. Das wäre dann in diesem Fall das "sichtbare Fenster" über dem Text. Bekommt man da das Verschieben sauber hin finden sich die anderen Sachen nachher schon. Bei HTML hast du zwar Recht, aber eben auch nur eingeschränkt. Realiter wird niemand so ein riesen Ding verschicken, schon der Zeiten wegen die da anfallen.

Mein Ansatz wäre da, von vorne herein 3 Streams zu öffnen. Front, virtual und Tail. Das vereinfacht die Schieberei. Ab da muß man sich dann aber stramm Gedanken um die Formatierung machen und wie man die aufrecht erhält. Gleichviel, einfach ist das jedenfalls nicht. Zumindest sind da trickreiche Operationen auf den Streams nötig, wie z.B. einen Teil aus dem Stream löschen, ein Teil einfügen, anhängen oder davor hängen. Alles Sachen die die Streams nicht standardmäßig anbieten.

[schnullerbacke]

Als Anregung fällt mir da noch ein:

Warum eigentlich die Formatangaben im Text halten. Die könnte man abhängig vom Format auch in einem Stream halten und dann im Textfile an den entsprechenden Stellen nur noch den Verweis auf das Format in Form der Stream-Position eintragen. Also (FormDelimiter+StreamPos, Bsp.: '#' + integer). Dann kann man problemlos den gesamten Text als ASCII-Text behandeln indem man diese Angaben einfach überliest. Gleichfalls kann man mit einer Austauschtabelle den Formattyp schnell ändern und braucht bei Änderungen immer nur bis zum nächsten Vorkommen einer Formatangabe weiterlesen.

@theo

Das könnte auch das Problem mit den Scrollbars lösen. Die Formate gibt es in fester Anzahl, hinten dran könnte man in der Formatdatei auch die speziellen Angaben für das Gesamtformat halten, also auch die aktuelle Seitenzahl.

[theo]

@Schnulli: Du gehst halt von einem ganz anderen Prinzip aus als ich, drum kann ich dazu nicht viel sagen.
Wenn ich dich richtig verstehe, willst du direkt mit dem Source-Stream, also direkt auf dem Ziel Format (z.B. HTML, RTF) arbeiten?
Das halte ich für nicht praktikabel.
Aber lass gut sein. Das lösen wir im Moment hier wahrscheinlich eh nicht.

[Christian]

@theo 100% zustimm im Bezug auf euch beide.