Lazarus Dokumentation

[mschnell]

Genau deswegen lehne ich das ab

Wenn tatsächlich einmal Wiki als Basis für das Help Authoring System genutzt werden sollte, muss natürlich nicht nur eine Möglichkeit geschaffen werden, die aus Wiki stammenden Texte in Lazarus mit F1 anzuzeigen (also entweder - wie momentan ja schon existent - ein Konverter Wiki -> CHM, oder ein Lazarus Hilfe-Plugin, das auf "F1" die passende Seite des Wiki (online oder aus einer offline-Kopie) im Browser anzeigt), sondern auch ein Import anderswo vorhandener Informationen in das Wiki.

-Michael

[Socke]

Was ich nicht richtig zusammengebracht habe, ist die Seiten in der Wiki umzubenennen. Es geht, die alten Seiten bleibt aber als Weiterleitung über. Da weis ich noch nicht, wie man das richtig hinbekommt.

Den normalen Benutzern fehlen die Berechtigungen, Seiten zu verschieben ohne eine Weiterleitung einzurichten. Bevor die Weiterleitung gelöscht wird, sollten auch alle Links auf die ursprüngliche Seite (http://wiki.freepascal.org/Special:What ... itentitel>) korrigiert werden.

[marcov]

(also entweder - wie momentan ja schon existent - ein Konverter Wiki -> CHM, oder ein Lazarus Hilfe-Plugin, das auf "F1" die passende Seite des Wiki (online oder aus einer offline-Kopie) im Browser anzeigt)

Welche Konverter meinst du? Ich kennen keiner der wiki-CHM macht. Es gibt kein praktischer offline Hilfe basiert wiki außer af0815's noch sehr frühen Experimenten

Genau deswegen lehne ich das ab

Wenn tatsächlich einmal Wiki als Basis für das Help Authoring System genutzt werden sollte, muss natürlich nicht nur eine Möglichkeit geschaffen werden, die aus Wiki stammenden Texte in Lazarus mit F1 anzuzeigen, sondern auch ein Import anderswo vorhandener Informationen in das Wiki.

Eben wenn man annehmt das dieser Diskussion immer etwas praktisches wird (und das ist schon nicht sehr glaubhaft), wird das grundsätzlich nie passieren. Unit Dokumentation bleibt fpdoc. Es benötigt dauerhafte Synchronisation mit die Quellen kann man kaum anders, und FPC ändert sich sowieso nicht.

[Christian]

Es gibt schon lange 2 wiki HTML Converter den älteren von mir ca 7 Jahre alt. Und vor 4 Jahren hat Mathias G. auch einen geschrieben.

[mschnell]

Welche Konverter meinst du? Ich kennen keiner der wiki-CHM macht. Es gibt kein praktischer offline Hilfe basiert wiki außer af0815's noch sehr frühen Experimenten

Andreas (af0815) arbeitet gerade damit, siehe lazarus@lists.lazarus.freepascal.org -> "Howto work with wikiget and wikiconvert tools"

Es benötigt dauerhafte Synchronisation mit die Quellen kann man kaum anders, und FPC ändert sich sowieso nicht.

Ganz schlechter Ansatz. Es braucht eine einzige Quelle, aus der andere Formate automatisiert erstellt werden können. Der Import in das (danach einzige) Quell-Format wird nur einmal angewendet (und braucht deshalb zum Glück auch nicht dokumentiert werden.)

-Michael (der auch nicht daran glaubt, dass das jemals passiert )

[marcov]

Es gibt schon lange 2 wiki HTML Converter den älteren von mir ca 7 Jahre alt. Und vor 4 Jahren hat Mathias G. auch einen geschrieben.

wiki html exporter <> chm Konverter (wies M. Schnell sagte). zb Links müssen funktionieren und transformiert werden nach ms-its:// usw.

[marcov]

Welche Konverter meinst du? Ich kennen keiner der wiki-CHM macht. Es gibt kein praktischer offline Hilfe basiert wiki außer af0815's noch sehr frühen Experimenten

Andreas (af0815) arbeitet gerade damit, siehe lazarus@lists.lazarus.freepascal.org -> "Howto work with wikiget and wikiconvert tools"

Redundant, war schon genannt (eben in dein Quote).

Es benötigt dauerhafte Synchronisation mit die Quellen kann man kaum anders, und FPC ändert sich sowieso nicht.

Ganz schlechter Ansatz. Es braucht eine einzige Quelle,

Ich meinte die Pascal Quellen. Ein Extrahierter dafür ist makeskel (Partner zu fpdoc), der die leeren XMLs generiert. Die Dokumentation ist auch schon da in die ergänzte XMLs.

Mann sollte also an einem Zeitpunkt geupdatete XMLs synchronisieren müssen mit Wiki (und die Übersetzungen da), lokale Modifikationen behalten usw.

Ein Problem ist wenn ein Symbol sich in der Namespace ändert (zb ein Prozedur wechselt von Unit und bekommtt rtl.sysutils.procedurex stat rtl.system.procedurex).

In fpdoc gibt es dann einige Warnungen während den Makeskel lauf, und den XML Nodes werden von Hand um gehangen. Aber Wiki muss das am nächster Import auch folgen, und das Artikel auch noch in Wiki UND im neuen fpdoc Import modifiziert sein!

aus der andere Formate automatisiert erstellt werden können.

RTF,PDF,CHM,HTML,TXT gibts schon.

Der Import in das (danach einzige) Quell-Format wird nur einmal angewendet (und braucht deshalb zum Glück auch nicht dokumentiert werden.)

Ich habe keine Ahnung was fuer ein einziges Quell Format hier gemeint ist, ich meinte Pascal Quellen, und synchronization davon mit fpdoc.

-Michael (der auch nicht daran glaubt, dass das jemals passiert )

Lazarus braucht nur der Wiki für Dokumentation der IDE daran zu geben (für etwa, was, 50 Lemma gegen mehrere tausende fpdoc Lemma), und das in Fpdoc format zu machen.

Das ist wenn man auf ein einzigen Format steht. Ich würde schon Glücklich sein wenn der IDE Wiki sich gut exportieren lässt (sammt Bilder usw) und eine CHM offline möglich macht. Weniger einheitlich für Developer, aber einheitlich für Anwender (alles chm, alles offline)

Ich habe kein Problem damit die IDE Hilfe im Wiki zu lassen (bis zb dafür Tools entwickelt sein es innerhalb der IDE zu tun). Nur sollte den Kontent einfach zu exportieren und transformieren sein.

Das einige Nachteil das ich mir denken kann ist Verlinkung zwischen IDE Hilfe einerseits und fpdoc doku (lcl,lazutils,fcl,rtl) und latex (ref,user,prog) anderseits. Man kann sich aber fragen wie nötig das ist.

[af0815]

zb Links müssen funktionieren und transformiert werden nach ms-its:// usw.

Kann mir wer verraten wo ich wegen Informationen zu dem Thema ansetzten kann ?
Wiki nach chm geht ja (relativ) Problemlos mit den vorhandenen Programmen. In Wikiget kann ich mich relativ schnell einarbeiten. wikiconvert geht teilweise, nur wie das mit den Index, erstellen derselben etc. funktioniert ist mir noch unklar.

[af0815]

Zum Problem, das wikiget --allmissing probleme macht, hab ich mal einen Patch (0027344) eingereicht (mein Erster :- )

mit dem Patch wird der Fehler nur gemeldet, das Programm läuft dann durch und (fast) die ganze Wiki ist lokal am Rechner.

[marcov]

zb Links müssen funktionieren und transformiert werden nach ms-its:// usw.

Kann mir wer verraten wo ich wegen Informationen zu dem Thema ansetzten kann ?

Ich meinte cross-CHM Links. Wie von IDE zu LCL oder so.

Ich habe mich heute components/wiki kurz angeschaut, und es sieht recht gut aus.

Links muss man unterteilen in 3 Kategorien, ziel

1. innerhalb das exportierten Teil des Wikis
2. In Dokumentation die sich in andere CHM befindet
3. außerhalb das exportierten Teil des Wikis und restlichen Internet

Typ 1. soll man meistens nach relative Pfaede zum Dokuments Root umwandeln. Weil Wiki eine plattes Struktur darstellt soll das einfach (und schon getan) sein.

Typ 2. was ich meinte. Wenn ich Wikconvert Korrekt sehe hängt dies ab von zielformat. fpdoc -> wandeln nach fpdoc referenzen wie <link id="#rtl.UnixType.cchar"> usw. chm -> wandeln nach inter-chm links <a href="ms:its://rtl.chm/pfad/zu/html"> oder so.

Typ 3 bleibt immer extern html links, weil existieren nicht lokal.

Wiki nach chm geht ja (relativ) Problemlos mit den vorhandenen Programmen. In Wikiget kann ich mich relativ schnell einarbeiten. wikiconvert geht teilweise, nur wie das mit den Index, erstellen derselben etc. funktioniert ist mir noch unklar.

Es gibt auch wiki->fpdoc->chm ? Kann sein das das inter-chm links einfacher macht, weil man nur das fpdoc Namespace Pfad braucht zu spezifizieren (geht mit mit Änderungen in fpdoc)

[af0815]

Habe eine kleine Übersicht über die Dokumentation im Wiki gemacht (Deutsch/Englisch). Dabei ist mir aufgefallen, das die Version der MediaWiki keine vernünftigen Tools zur Verwaltung von Mehrsprachigkeit enthält. Wie zum Beispiel Translate Erweiterung.
Es ist nicht leicht das zu machen. Und dabei habe ich beide Seiten selbst erstellt Vor allen das beide Seiten gleich sind UND BLEIBEN.

Es ist wie ein roter Faden, Dokumentationswerkzeuge sind zwar da, aber nicht wirklich im Fokus.

Edit: Link zur Wiki eingefügt

[marcov]

Habe heute Mittag versucht neue CHMs zu generieren. (immer schlimm das ersten mal mit einer neuen Branche, bis heute nur mit 2.6.x getan)

Es ist noch nicht ideal (rtl.chm als auch lcl.chm sind kleiner als letzter Mal, aber das ist nur wenig, und rtl.chm enthält nicht langer unit oldlinux), aber ich hoffe nur kleine Probleme.

Die LCL XMLs sind noch nicht regeneriert weil Formatierungs-probleme für sehr große Diffs sorgten, also neuere Methods sind vielleicht nicht sichtbar.

Das Archiv ist http://www.stack.nl/~marcov/doc-chm_wit ... _trunk.zip

[af0815]

Ich habe heute versucht aus dem Wiki die Dokumentation für die IDE Hilfe (IDE Window:) zu extrahieren, das geht problemlos. Auch die Umwandlung in das FPDoc Format geht problemlos.
Nur jetzt habe ich ein Verzeichnis voll mit FPCDoc xml Dateien (auch in allen möglichen Sprachen), nur wie bekomme ich das ganze in eine Struktur die dem Lazarus angepasst ist ?

Ich muss ja jetzt auch einen Index aufbauen und LazDE ist auch keine Hilfe, der stürzt bei den eigentlich richtig geschriebenen xml Files ab. Kann mit der Struktur nicht umgehen.
Hat wer eine Idee dazu ?

[Socke]

Nur jetzt habe ich ein Verzeichnis voll mit FPCDoc xml Dateien (auch in allen möglichen Sprachen), nur wie bekomme ich das ganze in eine Struktur die dem Lazarus angepasst ist?

FPDoc liefert bei mir nur ein leeres Ergebnis? Wie sieht dein Befehl aus um die XML-Dateien zu übersetzen? Ich versuche es mit:

Code: Alles auswählen

fpdoc --descr-dir=. --format=html --output=./out --package=Lazarus

Ich muss ja jetzt auch einen Index aufbauen und LazDE ist auch keine Hilfe, der stürzt bei den eigentlich richtig geschriebenen xml Files ab. Kann mit der Struktur nicht umgehen.
Hat wer eine Idee dazu?

Bei mir (Lazarus trunk) lädt LazDE die Dateien, zeigt aber teilweise keine Texte an und man kann diese auch nicht bearbeiten.
Edit:

Auch die Umwandlung in das FPDoc Format geht problemlos.

Die Topics benötigen ebenfalls ein name-Attribut. Die Topics dürfen nur innerhalb von module-Elementen nicht geschachtelt werden. Innerhalb von package sind maximal zwei topic-Ebenen erlaubt (siehe http://www.freepascal.org/docs-html/fpd ... 90005.3.31).

[af0815]

Bei mir (Lazarus trunk) lädt LazDE die Dateien, zeigt aber teilweise keine Texte an und man kann diese auch nicht bearbeiten.

Auch Trunk, wenn ich versuche mich in den Knoten zu bewegen, stürzt LazDE ab. Ich habe es aber noch nicht mit den Debugger probiert.
Bei der Hilfe sind so viele Baustellen auf einmal und noch dazu fast keine Information vorhanden (wie HowTo's).

Laut den Dokus von FPDoc sollten die xml Dateienen gültig sein (Das von dir erwähnte muss ich mir erst genauer ansehen). Allerdings anders aufgebaut als die Dateien der restlichen Doku. Dort muss ich mich auch erst einarbeiten.