Hallo Wolfgang,ich kann dir schwer immer direkt auf einzelne Punkte antworten, dann würde die Antwort wegen Wiederholungen sehr lang und auch nicht unbedingt klarer. Deine Aussage, dass andere Dokumentationen von objektorientierten Modellen damit zurechtkämen, kann ich nicht widerlegen, weil ich selbst meist selbst entwickelt habe. Aber das Wesen der UML (= Unified Modeling Language, der Metode für das Modellieren und Dokumentieren objektorientierte Modelle) ist doch gerade, dass man Attribute und Methoden bei dem Objekt beschreibt, bei dem sie definiert sind, und sie nicht bei den Erben wiederholt. Genau das tut auch die Dokumentation der API von LibreOffice, darum kannst du auch nicht sagen, dass sie unverständlich und nutzlos ist. Sie ist im Gegenteil sehr nützlich, denn auf ihr aufbauend wurde das doch sehr erfolgreiche Produkt OpenOffice/LibreOffice erstellt und weiterentwickelt.
Für einen Entwickler, der mit den Objekten etwas tun will, ist das nicht ganz so bequem, das habe ich ja schon zugestanden, weil er die gesammelten Attribute und Methoden eines Objekts nicht auf einen Schlag angeboten bekommt. Aber dem wird ja abgeholfen: Die Methoden dbg_..., die du als "mittelschwerer Schwachfug" abtust, tun ja genau das, sie listen vollständig alle Attribute bzw. Methoden eines Objekts auf. Die Aufbereitung ist allerdings nicht optimal, es ist eben nur eine Auflistung, und programmieren musst du halt die eine Zeile mit dem Aufruf dbg_..., den Code, um zu dem Objekt zu gelangen, musst du ja ohnehin haben, wozu brauchst du sonst die Informationen? Xray bereitet die Informationen schon viel besser auf, außerdem kannst du es verwenden, um für verschiedenen Objekte, vor allem für das gerade markierte, alle Attribute und Methoden zu zeigen. Und es bietet die Möglichkeit des Drilldown, nämlich entweder den Wert eines einfachen Attributs anzuzeigen oder eine Methode auszuführen, sofern sie nur einen Parameter benötigt, oder das neue Nachfahre-Objekt wiederum mit seinen Attributen und Methoden anzuzeigen usw. Und früher konnte auch noch die Doku aus der API angezeigt werden, das geht bloß jetzt nicht mehr, seit man bei LibreOffice die Technik der Ablage der Doku verändert hat. Aber auch ohne das - ich hatte es früher mal aktiviert, aber bei einem Wechsel dann nicht mehr, weil es anders für mich genaus so bequem war - bedeutet es ja nur, parallel zu LibreOffice mit Xray den Browser mit der API-Doku offen zu haben und dort das Attribut oder die Methode unter den Class Members auszuwählen. Diese Art der Doku durch Zugriff auf die Originaldoku von LibreOffice sollte eigentlich dem entsprechen, was ich aus deinen Klagen heraushöre, eine gesonderte Doku läuft ja immer Gefahr, veraltet zu sein.
Und spätestens wenn man Xray hat, kann deine Behauptung, ... Und dann müsste man vorher schon wissen, was genau man abfragen möchte, d. h. wie die Methode oder Eigenschaft o. ä. lautet, über die man etwas wissen will. Und da bei vielen Methoden auch noch unterschiedliche Parametersätze möglich sind, muss man natürlich auch noch vorher genau wissen, welchen Satz man zu verwenden gedenkt. Aber wenn ich das alles schon *weiß*, dann brauch ich keine Dokumentation mehr.nicht mehr stimmen. Denn du siehst ja eben alle Eigenschaften und Methoden und zu jeder die Parameter, und in der Original-Doku findest du die weiteren Informationen. Wie soll eine ander Doku dir abnehmen, zu entscheiden, welche Daten du sehen willst, und welche Operationen du darauf ausführen willst? Du musst immer aus der Liste der verfügbaren Attribute und Methoden das/die passende auswählen, der Unterschied besteht nur darin, wie gut dich die Doku unterstützt. Hier gebe ich zu, dass die vorhandene Doku zum API manchmal sehr knapp ist. Aber wenn ich die Vielzahl an Dokumentation (auch Gebrauchsanweisungen...) Revue passieren lasse, die einem im täglichen Leben begegnet, dann ist das immer noch im oberen Bereich! Und ist denn die Dokumentation zu Calc, wo du dich, zumindest aus deinen letzten Antworten zu schließen, unter anderem tummelst, besser? Zeigt das nicht, dass deine Forderung bezüglich UNO etwas extraordinär und vielleicht nicht ohne Ressentment ist? Der andere Weg ist, eine ziemlich sicher unvollständige, wenn auch von der Häufigkeit der Verwendung her gesehen fast alle Fälle umfassende Darstellung zu geben, die auch noch über die Doku hinausgehende Informationen liefert und Beispiele gibt. Und das tun die Bücher von Bernard Marcelly und Laurent Godard, von Thomas Krumbein und von Andrew Pitonyak, in unterschiedlichem Umfang und in unterschiedlicher Vorgehensweise. Pitonyaks ist wohl das älteste und hängt noch eher an Einzelfällen, aber auch da kann man immer noch Informationen finden, die man in den anderen Büchern nicht findet. Das systematischste und umfassendste ist für mich das Buch von Marcelly und Godard, aber es mag sein, dass du es nicht kennst, weil es nur in Französisch erhältlich ist. Bernard hat mir mitgeteilt, dass sein Verleger keinen englischsprachigen Verlag fand, der eine Übersetzung herausbringen wollte, obwohl sie einen Freiwilligen an der Hand hatten, der die Übersetzung machen wollte. Für eine deutsche Version sahen sie das noch schwieriger. Ich kann aber aus eigenen Erfahrung sagen, dass man mit den geschilderten Mitteln sehr wohl sehr schnell das finden kann, um unterschiedlichste Anwendungen mit LibreOffice Basic zu erstellen. Ich selbst komme vom Großrechner, habe später auch mit vernetzten Computern gearbeitet, aber in dieser Umgebung eher Projekte durchgeführt und modelliert und designt und nicht selbst programmiert, höchstens Programme gelesen. Ich musste also doch vieles erst neu lernen, als ich mit damals noch OpenOffice und Basic begann (Basic selbst ist dann natürlich ein Klacks, aber die Objekte waren doch relativ neu). Daher denke ich, dass ich zumindest nicht mit mehr Vorwissen begann als du hast. Das Buch von Thomas Krumbein hat mir die ersten - und zweiten - Schritte beigebracht, dann kamen die anderen dazu. Und was sich nicht dort fand, fand sich manchmal im Internet (z.B. als größten Brocken die Beschreibung, wie man Tabellen innerhalb eines Dialogs nutzen kann, die bisher nicht dokumentiert ist, zufällig auch von Thomas) und meistens durch Verwendung von Xray und genauerem Untersuchen von max. einer Handvoll von Attributen oder Methoden durch Nachschauen in der Doku (was fast immer schon die nichtgeeigneten ausschloss) und durch Ausprobieren des kleinen Rests. Dass ich mit diesem Wissen "geboren" wäre, kannst du also wahrlich nicht behaupten. Das Ganze ist also sehr wohl zugänglich, nicht unbedingt leicht für jeden Unbedarften, aber für jemanden, der "seit Jahrzehnten mit Objektmodellen rummacht", auf jeden Fall. Ist denn der Unterschied zu der von dir geschilderten "idealen" Dokumentation wirklich so groß? Beschreibt deine ideale Doku wirklich alles so klar, dass du das nur noch in Programmmcode umsetzen musst? Ich habe in meinem Berufsleben nur eine mich befriedigende Dokumentation gefunden, in der man alle Fragen nachschlagen konnte und eine Antwort fand, das war die zu PL/I, aber das war eine Programmiersprache mit doch im Vergleich zu UNO sehr begrenztem Umfang, und hatte doch schon mehrere hundert Druckseiten in DIN A4. Ich habe zuletzt meist mit SAP (weltweit erfolgreich!) gearbeitet, ein wirklich großes System, die Anzahl der Tables ließ sich übers Internet so schnell gar nicht rauskriegen, es sind mehrere zehntausend, Objekte, die ja nicht unbedingt 1:1 zu den Tables passen, sind es aber dann ungefähr so viele, wenn nicht mehr (man packt da oft allgemeine Konzepte in Tabellen mit 5, 6 Schlüsseln, da stecken dann vielleicht viele Objekte dahinter). Aber wenn ich was aus diesen Tabellen brauchte, fand ich keine Doku, nur nackte Informationen über die Tabellen u.ä. Alles andere musste ich mir selbst erarbeiten. Die geschilderte Eigenrecherche bei LibreOffice ist dagegen einfach und bei einem kostenlosen System meiner Meinung durchaus zumutbar (abgesehen davon, dass du meiner Meinung nach gar nicht mehr erwarten darfst). Du bist ja, wie man aus deinen häufigen Aktivitäten in der Mailing-List sieht, sonst auch nicht abgeneigt, dich zu engagieren, und deine Hinweise sind ja wirklich hilfreich.
Aber einen kleinen Seitenhieb zum Abschluss kann ich mir nicht verkneifen:Die von dir genannte Seite von Bernard Marcelly existiert nicht mehr, das stimmt. Die Referenz steht sicher irgendwo, sicher mehrfach, aber Internetseiten wie auch Mailadressen ändern sich häufiger. Das heißt aber nicht, wie du schreibst, dass das Werkzeug nicht mehr verfügbar ist. Erstens wird auf der aufgerufenen Seite erklärt, dass der Provider oder irgend etwas anderes Übergeordnetes nicht mehr weiter betrieben wird, was keinen Schluss auf eine einzelne Seite bzw. deren Inhalt zulässt. Und zweitens liefert eine Suche im Internet nach Bernard Marcelly (in meinem Fall mit DuckDuckGo als zweiten Treffer nach einem nur partiell zutreffenden, aber halt professionellen Amazon-Treffer) schnell die neue (oder vielleicht auch schon bisher vorhandene?) Seite http://berma.pagesperso-orange.fr/index2.html, in der du Xray runterladen kannst. Letztlich hast du also FakeNews produziert (weil das Internet "nichts vergisst"), sicher in begrenztem Umfang, aber ein bisschen mehr Sorgfalt wäre besser gewesen (als Frage formulieren?), vor allem, weil das so einfach gewesen wäre.
Das sollte dir auch bezüglich deiner Ablehnung von UNO zu denken geben. Gruß Gerhard Am 28.07.2018 um 19:33 schrieb Wolfgang Jäth:
Am 28.07.2018 um 00:41 schrieb Gerhard Weydt:deine Beschreibung trifft auf die API-Dokumentation zu, denn die ist offensichtlich für die Implementierung erstellt worden bzw. wird dafür erweitert/angepasst. Da ist eine andere Sicht notwendig als für die Anwendungsprogrammierung.Im Prinzip nein: Eine Dokumentation sollte verständlich sein, und nicht voraussetzen, dass man eh schon kennt, was man darin nach schlagen möchte. Dann ist sie nämlich nutzlos.Die hierarchische Gliederung der Objekte für das Design einer Anwendung hat sich bewährt, objektorientierte Modellierung hat sich durchgesetzt. Die Problematik, dass dann ein Objekt Eigenschaften und Methoden von übergeordneten Objekten erbt, die man nicht direkt bei dem Objekt findet, hat man immer bei solchen Modellen, das ist keine spezielle Schwäche von UNO.Richtig; aber alle mir sonst bekannten Dokumentationen von objektorientierten Modellen kommen damit zu recht. /Darauf/ kannst du es also nicht schieben.Sie wird aber offensichtlich aufgewogen bzw. übertroffen durch viele Vorteile, die dieses Konstrukt bei der Implementierung und folglich auch der Ausführung bietet. Die Arbeit mit einem solchen Modell dürfte unter anderem wegen der Implementierung von LibreOffice in verschiedenen Betriebssystemen notwendig sein.Ich kritisiere nicht die objektorietierte Modellstruktur; mit objektorientierter Programmierung mach ich seit den 90er Jahren rum. Ich kritisiere die dazu nicht vorhandene *Dokumentation*.Diese für eine Anwendungsentwicklung erst einmal vorhandene Lücke, die du ja offensichtlich thematisierst, behebt aber schon UNO grundsätzlich, wenn auch nicht besonders benutzerfreundlich (aber das ist auch nicht im Aufgabenbereich von UNO, das die Kernfunktionalität bereitstellt) durch die Bereitstellung der Funktionen dbg_properties, dbg_methods und dbg_supportedInterfaces, die bei fast jedem Objekt zur Verfügung stehen und eben diese Verstreuung über mehrere Hierarchieebenen auflösen, indem sie alle verfügbaren Eigenschaften, Methoden und (weniger direkt wichtig) Interfaces eines Objekts auflisten.Ja, über die bin ich auch schon gestolpert. Aber diese Funktionen sind mittelschwerer Schwachfug; sorry. Um darüber an Informationen zu gelangen, müsste man erst ein Programm oder Makro o. ä. schreiben. Und dann müsste man vorher schon wissen, was genau man abfragen möchte, d. h. wie die Methode oder Eigenschaft o. ä. lautet, über die man etwas wissen will. Und da bei vielen Methoden auch noch unterschiedliche Parametersätze möglich sind, muss man natürlich auch noch vorher genau wissen, welchen Satz man zu verwenden gedenkt. Aber wenn ich das alles schon *weiß*, dann brauch ich keine Dokumentation mehr. Abgesehen davon, dass man diese Funktionen /selbst/ überhaupt erst mal kennen muss, und natürlich die dafür benötigten Parameter. Ihre Namen und möglichen Parameter könnte man theoretisch natürlich einer vernünftigen Dokumentation entnehmen - so es eine gäbe. Tut es aber nicht. Womit sich die Katze in den eigenen Schwanz beißt ...Wesentlich besser wird das noch durch das darauf aufbauende wunderbare Werkzeug Xray, das diese Informationen noch viel verständlicher aufbereitet (Ich fand das so hilfreich, dass ich eine deutsche Übersetzung erstellt habe). Man muss sich nur die eventuell interessanten Eigenschaften und Methoden raussuchenGenau das *ist* doch das Problem: Um die überhaupt raus suchen zu *können*, musst du erst mal *wissen*, was es denn überhaupt für (möglicherweise interessante) Methoden und Eigenschaften in dem Objekt *gibt*. In einer vernünftigen Dokumentation kann man all das und noch viel mehr *nachlesen*; bei UNO musst du mit diesem Wissen *geboren* sein.Eine gewisse Eigenrecherche und anschließendes Ausprobieren ist bei einer solch komplexen Materie gar nicht zu vermeiden, und da sammelt sich Wissen auch nur sukzessive an. Systematische Darstellungen haben Andrew Pitonyak, Thomas Krumbein und - am umfassendsten - Bernard Marcelly & Laurent Godard gegeben, aber auch in einem Buch von kanpp 1000 Seiten (Marcelly/Godard, nicht die neueste Version) kann man nur die einigermaßen wichtigeren Situationen behandeln. In diesem Licht verstehe ich deinen "Hass" eigentlich nicht, weil es gar nicht nötig ist, dich mit der Hierarchie herumzuschlagen, du findest ja mit Xray (was kostenlos ist und in Sekunden installiert) alles direkt beim Objekt.Eben: Welches Objekt? Normalerweise starte ich mit einem *Problem*, nicht mit einem *Objekt*. Zu dem für die Lösung dieses Problems notwendigen Objekt muss ich mich erst mal *durcharbeiten*. Da hilft auch nicht dein (wenn ich nicht wüsste, dass du es nicht so gemeint hast, schon fast zynisch klingender) Verweis auf Eigenrecherche. Ich würde diese Eigenrecherche ja durchaus gerne *durchführen*, wenn es eine Dokumentation o. ä. *gäbe*, in der ich recherchieren *könnte*. Gibt es aber nicht; auch dein hochgelobtes xray bietet das nicht, sondern ur die Dokumentation zu Methoden und Parametern, die ich *vorher* schon *kennen* muss, um sie abfragen zu können. Es kann *nicht* dabei *helfen*, diese Eigenschaften und Methoden überhaupt erst mal zu *finden* (abgesehen davon,dass das Tool anscheinend seit 2 Jahren nicht mehr angeboten wird; http://bernard.marcelly.perso.sfr.fr ist jedenfalls schon so lange down).Und systematische Darstellungen in mehreren Büchern. Aber ohne Aufwand lernt man den Umgang mit mit einem komplexen System eben nicht.Ich *würde* den Aufwand ja gerne *betreiben*, wenn es irgend eine vernünftige Dokumentation *gäbe*. Aber auch die von dir angesprochenen Bücher (zumindest die ich kenne) sind nicht besser strukturiert (abgesehen davon, dass man heutzutage eigentlich eine Online-Dokumentation erwarten kann). Wolfgang, dem aber leider offensichtlich nur die Möglichkeit bleibt, Buddhist zu werden, und dann darauf zu hoffen, dass er in seinem nächsten Leben vielleicht mit diesem Wissen geboren werden wird :-(
-- Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy