Autor Thema: Widget-Dokus; War: svgplot widget update - wie update "hochladen"?  (Gelesen 824 mal)

Offline curt

  • Full Member
  • ***
  • Beiträge: 353
@setstate
Eine Frage zum Vorgehen bei fehlerhaften Widgets, die ohne bekannten Autor sind, aber (wohl) über Deinen update-Mechanismus verteilt werden.

Konkret geht es um svgplot: Das funktioniert mit aktuellen FTUI-Versionen nicht. Mit zwei kleinen Änderungen kann es lauffähig gemacht werden, hier beschrieben: https://forum.fhem.de/index.php?topic=77223.0
Ich habe die Änderungen getestet - ja, dann funktioniert das svgplot-Widget wieder.

Wie geht man da weiter vor?
Kannst Du die beiden kleinen Änderungen bei diesem Widget einpflegen - auf dass das Widget fehlerfrei über update verteilt wird?

Subject nach Threaddrift angepasst.
« Letzte Änderung: 10 November 2018, 23:36:30 von curt »
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline setstate

  • Hero Member
  • *****
  • Beiträge: 3824
  • FHEM TabletUI
    • FHEM Tablet UI
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #1 am: 19 Oktober 2018, 11:18:56 »
ist jetzt im Ftui svgplot widget geändert

Offline curt

  • Full Member
  • ***
  • Beiträge: 353
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #2 am: 20 Oktober 2018, 02:10:44 »
Danke-schön.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline curt

  • Full Member
  • ***
  • Beiträge: 353
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #3 am: 09 November 2018, 04:37:07 »
@setstate

Ich habe mir erlaubt, einen kurzen Wiki-Artikel zu diesem FTUI-Modul zu schreiben. Die Situation ist doch folgende: Irgendwo im Forum-Raum kreiseln FTUI-Module rum, manche sind in Deinem update-Zyklus, andere nur im Forum veröffentlicht, manche davon (DWD-opendata) nicht mehr funktional: Irgendwann mit schneller Hand gecodet, im Forum veröffentlicht, kaputt, tot.

Allein typisch ist: Der Autor ist verschollen.

Mein Ziel ist weniger, die Modulwelt von FTUI zu retten. Es ist schon Eigennutz, Du siehst es ganz am (rechten) Rande meines neu geschriebenen Artikels: Da ist der Kasten, der erzählt wer der Autor (hier: u/i) ist. Und wo der Hauptthread im Forum ist.

Ich halte das für extrem wichtig - also das bei allen FTUI-Wiki-Artikeln der Kasten rein kommt. Denn dieser Kasten fehlt bei praktisch allen FTUI-Artikeln. Ich will mich da gern aktiv beteiligen.

Vielleicht sollte ich noch die URL zum Artikel verraten: https://wiki.fhem.de/wiki/FTUI_Widget_Svgplot

(Dort ist mir der Codeblock missraten. Aber das ist lässlich: Wiki-Prinzip: Habe Mut!)

@eki geht mit gutem Beispiel voran ... (Oder soll ich das machen, eki?)
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline setstate

  • Hero Member
  • *****
  • Beiträge: 3824
  • FHEM TabletUI
    • FHEM Tablet UI
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #4 am: 09 November 2018, 06:55:27 »
Sehr gut!
Dokumentationen ist wichtig, ich weiß. Leider bin ich nicht der Wortakrobat, wie man unschwer erkennen kann.  :)

Umso besser finde ich es, wenn das jemand spontan übernimmt.

Offline curt

  • Full Member
  • ***
  • Beiträge: 353
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #5 am: 09 November 2018, 07:13:55 »
Sehr gut!
Dokumentationen ist wichtig, ich weiß. Leider bin ich nicht der Wortakrobat, wie man unschwer erkennen kann.  :)

Umso besser finde ich es, wenn das jemand spontan übernimmt.

Naja, Dokus kann ich schon.
Das Problem ist eher, dass jeder [selbst ich] auch noch ein Leben hat, man hat ja auch noch anderes. Das bedeutet:  Der Weg zur Hölle ist mit guten Vorsätzen gepflastert ...

Im ersten Schritt habe ich vor, sämtlichen Wiki-FTUI-Artikeln den Kasten (rechts) "Der war Autor, den erreichst Du so, das ist hier der primäre Thread" zu verpassen.

Da ich nun auch nicht der Heiland bin, mir wächst ja kein Gras aus der Tasche, würde ich Dich immer informieren wollen: Vier Augen sehen ja mehr als zwei. Ich weiß noch nicht, wie ich diesen Teil (Dich informieren) löse.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline Ulm32b

  • Full Member
  • ***
  • Beiträge: 295
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #6 am: 10 November 2018, 01:29:48 »
Naja, Dokus kann ich schon.
Das Problem ist eher, dass jeder [selbst ich] auch noch ein Leben hat, man hat ja auch noch anderes. Das bedeutet:  Der Weg zur Hölle ist mit guten Vorsätzen gepflastert ...

Im ersten Schritt habe ich vor, sämtlichen Wiki-FTUI-Artikeln den Kasten (rechts) "Der war Autor, den erreichst Du so, das ist hier der primäre Thread" zu verpassen.

Da ich nun auch nicht der Heiland bin, mir wächst ja kein Gras aus der Tasche, würde ich Dich immer informieren wollen: Vier Augen sehen ja mehr als zwei. Ich weiß noch nicht, wie ich diesen Teil (Dich informieren) löse.

Für die Mitarbeit am Wiki möchte ich hier ausdrücklich werben, denn manches lässt sich noch verbessern. Anhand des Doku-Threads https://forum.fhem.de/index.php?topic=66578.15 kann man nachvollziehen, wieviel Herzblut und Nachtstunden hier schon eingeflossen sind. Es gelang ein erstaunlich hoher Standardisierungsgrad, z.B. indem bereits der erste Satz quasi genormt ist (Da weicht svgplot schon ab). Bei den css-Klassen wird nicht eine flache Tabelle gefüllt, sondern mit cleveren Verweisen gearbeitet. Auch die Gliederung ist weitgehend vereinheitlicht:
  • Attribute
  • css-Klassen
  • Hinweise
  • Beispiele
  • Web-links
Den Mehrwert eines durchgängigen Infokastens sehe ich noch nicht so recht:
  • Zweck/Funktion: Wird durch einen guten ersten Satz erschöpfend beschrieben.
  • Typ: Inoffiziell: Was sagt mir das?
  • Dokumentation: Die beste Dokumentation ist doch genau die Seite, auf der ich mich gerade befinde.
  • Modulname: Redundante Information, steht schon in der Überschrift.
  • Verweis auf commandref: Na ja, kein einziges FTUI-Widget ist in der FHEM-Commandref beschrieben, weil das dort nicht hingehört.
Zusammen mit der Suchfunktion im Forum kommt man bei bestehenden Widget-Beschreibungen doch schon ziemlich weit. Mehr bringen würde m.E.:
  • Eine systematische Untersuchung auf Vollständigkeit der Attribute und css-Klassen.
  • Erstellung von fehlenden Widget-Beschreibungen (dabei am besten den Quelltext bestehender Widgets zugrunde legen, damit die Standards zur Anwendung kommen).
  • Füllen von Lücken, z.B. Navigationsmethoden
Neulich habe ich versucht, die Errungenschaften des vergangenen Quartals im Wiki festzuhalten. Beispiel: Text im Bild. Vielleicht etwas hemdsärmlig wurde eine halbwegs passende Stelle gesucht und dann vorrangig mit copy-Paste gearbeitet. Von Zeit zu Zeit ist da ein ordnender Blick ganz nützlich. Zu tun gibt es genug...

Offline curt

  • Full Member
  • ***
  • Beiträge: 353
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #7 am: 10 November 2018, 21:24:17 »
@Ulm32b
Danke für Deinen umfangreichen Post. Selbstverständlich werde ich mich an von der Mehrheit getragende Standards halten. Zu einigen Punkten meine -subjektive- Sicht bzw. Antwort:

Es gelang ein erstaunlich hoher Standardisierungsgrad, z.B. indem bereits der erste Satz quasi genormt ist (Da weicht svgplot schon ab).

Wo genau kann ich mir die Normung ansehen? Bzw. kannst Du bitte an Hand des ersten Satzes mir zeigen/begründen, wie man es richtig macht?

Es gelang ein Den Mehrwert eines durchgängigen Infokastens sehe ich noch nicht so recht:

Ausgehend von meinem Nutzerverhalten (gibt es ein FTUI-Widget für meine Aufgabe) scheint es mir mehrere Klassen von FTUI-Widgets zu geben: Widgets, die im update-Prozess von @setstate integriert sind (Unterklassen: funktional, defekt); Widgets, die nicht integriert sind, aber funktional sind sowie Widgets, die defekt sind.

In vielen solchen Fällen wäre der Autor von Interesse - dessen Name/Nick fehlt flächendeckend.

Die Angabe des Hauptthreads für dieses Widget im Forum wäre für Fragen hilfreich.

Es gelang ein
  • Dokumentation: Die beste Dokumentation ist doch genau die Seite, auf der ich mich gerade befinde.

Ich habe den einzigen vorhandenen Kasten (und das ist der von FTUI selbst) kopiert und minimal abgewandelt. Das der nicht richtig passt - ist mir klar. Ich bin (siehe oben) aber schon davon überzeugt, dass ein Kasten mit grundlegenden Informationen (vierte vielleicht: wird weiter entwickelt / eingestellt) erforderlich ist.

Es gelang ein
  • Verweis auf commandref: Na ja, kein einziges FTUI-Widget ist in der FHEM-Commandref beschrieben, weil das dort nicht hingehört.

Ich hatte das drin gelassen, weil ich nicht überschauen kann, ob es bei manchen Widgets Referenzbezüge gibt.

Es gelang ein Zusammen mit der Suchfunktion im Forum kommt man bei bestehenden Widget-Beschreibungen doch schon ziemlich weit.

Das sehe ich aus eigenem Erleben ganz und gar nicht so. Ich erlebe das ständig völlig anders: Entwickler verschollen (falls überhaupt erkennbar ist, wer das war). Unklar, ob Widget noch funktioniert und ich zu dumm bin - oder eben nicht mehr funktioniert. Vermutlich hat das oft mit Versionswechseln von FTUI zu tun.

Es gelang ein
  • Eine systematische Untersuchung auf Vollständigkeit der Attribute und css-Klassen.

Eine Vielzahl von Widgets sind nicht einmal schlecht im Wiki dokumentiert - sie sind überhaupt nicht dokumentiert. Ein Blick auf die FTUI-Wikiseite (unten sind Links auf zwei Widget-Klassen) reicht. Selbst wenn sie dokumentiert sind, dann sind mögliche Optionen/Schalter/Attribute nicht dokumentiert; vgl. beispielhaft Calview-Widget.

Anderes Beispiel:
Derzeit scheitere ich im Forum selbst mit aktiven Nachfragen an einem Widget für DWD-opendata, das sind die Daten mit Vorhersage des Deutschen Wetterdienstes. Der ist aus zwei Gründen interessant: Der ist der einzige hier vorhandene mit einem 1km-1km-Raster. Der kommt mit einer Vielzahl an validen Daten. -
Das Widget weather scheint das integriert zu haben, es ist unklar ob in der aktuellen Version. Weiterhin ist die konkrete Nutzung (mir) völlig unklar. Darüber hinaus existieren ein (vermutlich sogar zwei) weitere DWD-opendata-Widgets. Da von mir gefundene ist mir Quelltext im Forum, scheint aber nicht funktional zu sein.

Es gelang ein
  • Erstellung von fehlenden Widget-Beschreibungen (dabei am besten den Quelltext bestehender Widgets zugrunde legen, damit die Standards zur Anwendung kommen).

Mir wäre lieb, wenn wir uns über den Kasten verständigen könnten. Ich halte den aus eigenem Erleben für notwendig. Wir können das gern auch in einem passenderen Thread diskutieren.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline curt

  • Full Member
  • ***
  • Beiträge: 353
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #8 am: 10 November 2018, 23:51:49 »
Anderes Beispiel:
Derzeit scheitere ich im Forum selbst mit aktiven Nachfragen an einem Widget für DWD-opendata, das sind die

Dazugehörige Diskussion hier: https://forum.fhem.de/index.php/topic,86847.0.html
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline curt

  • Full Member
  • ***
  • Beiträge: 353
Antw:svgplot widget update - wie update "hochladen"?
« Antwort #9 am: 11 November 2018, 05:16:20 »
Auch die Gliederung ist weitgehend vereinheitlicht:
  • Attribute
  • css-Klassen
  • Hinweise
  • Beispiele
  • Web-links

Weiterer Nachtrag, hierzu:
Das ist alles schön und fein - und idealerweise super korrekt. Und ich komme mir ganz klein vor:

Ich fand das Widget svgplot, es funktionierte nicht. Dann fand ich einen Beitrag, der war ein Jahr her: Da schrieb jemand, wie man dieses Widget wieder zum Leben erwecken könne - Antwort erhielt er nie.

Ich habe dessen Änderungen getestet - funktioniert.
Sodann habe ich @setstate (das Modul ist in seinem Updatezyklus) gebeten, mal heftig ins Getriebe zu greifen und ohne Kenntnis seines verschollenen Autoren die Änderungen einzuarbeiten. Hat er getan. (Und gelegentlich können wir alle mal darüber nachdenken, warum ein Jahr vergehen musste.)

Ich habe anschließend diese Wiki-Kurzdoku geschrieben. Und soeben -falls ich Deinen Hinweis recht verstanden habe- den ersten Satz geändert.

Gleichzeitig bitte ich um Verständnis:

Erstens bin ich hier nicht der, der sybillische Andeutungen analysiert: Entweder sagst Du klar, was ich falsch machte. - Oder es gibt für mich das Wiki-Prinzip "sei mutig". Ich habe meine Lebenszeit nicht in der Lotterie gewonnen.

Zweitens werde ich das Widget nicht analysieren. Weder auf CSS-Klassen noch auf sonstwas. - Ich habe es gefunden. Es funktioniert. Im Wiki beschreibe ich, wie man das nutzt.

Du darfst auch gutwillige neue Autoren (fremder Widgets) gern mitnehmen: Ich werde keine 22 Seiten des von Dir vorgeschlagenen Threads daraufhin prüfen, ob da irgendwo eine Guideline steht. Die steht da mit einiger Sicherheit nicht, da steht vermutlich die Entstehungsgeschichte der Guideline. Die ist nicht relevant.

Relevant wäre
* wo im Wiki steht die Guideline für FTUI-Module
* wo im Wiki finde ich die kopierfähige Blaupause?

Ich bleibe weiterhin dabei
* es braucht einen Kasten mit den relevanten Infos zum FTUI-Modul (näheres gern später)

Nicht aufregen, bitte: Ich bin im Team der Guten.
Lieber nochmal lesen.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline Ulm32b

  • Full Member
  • ***
  • Beiträge: 295
Antw:Widget-Dokus; War: svgplot widget update - wie update "hochladen"?
« Antwort #10 am: 12 November 2018, 00:42:41 »
Gleich vorab: Dies ist mein letzter Beitrag zu diesem Thema. Vielleicht gerade rechtzeitig, bevor sich die Debatte verselbständigt wie z.B. im Calview-"Bugreport" (https://forum.fhem.de/index.php/topic,91903.msg845561.html#msg845561).
Zitat
Wo genau kann ich mir die Normung ansehen? Bzw. kannst Du bitte an Hand des ersten Satzes mir zeigen/begründen, wie man es richtig macht?
Eine Doku der Doku gibt es nicht. Mein Hinweis auf den Doku-Thread war auch nicht als Aufforderung gedacht, ihn zu studieren. Wenn man möchte, kann man dort nachvollziehen, wie fast aus dem Nichts etwas sehr Vorzeigbares entstand. Bildet man die Schnittmenge von
  • "Das Widget Checkbox ist ein Widget für FHEM Tablet UI, welches als Umschalter zwischen zwei Zuständen eingesetzt wird."
  • "Das Circlemenu Widget ist ein Widget für FHEM Tablet UI, das mehrere Widgets nach einem Klick auf ein einziges anzeigen kann."
  • "Das Widget Clock ist ein Widget für FHEM Tablet UI, welches die aktuelle Zeit des jeweiligen Endgerätes in digitaler Form wiedergibt."
  •   ... (das sind einfach mal die ersten drei in der Reihe)
sollten gewisse Ähnlichkeiten erkennbar sein. (Bei dieser Gelegenheit fällt mir auf, dass die genaue Position des Wortes Widget nicht einheitlich ist.  8))
Zitat
In vielen solchen Fällen wäre der Autor von Interesse - dessen Name/Nick fehlt flächendeckend.
Die Frage habe ich mir eigentlich nie gestellt. Wenn es ein Problem gab, habe ich stets versucht, selbiges möglichst verständlich zu schildern. Dann haben "alle" mitgelesen. Und wenn einer helfen konnte, hat er geholfen. Was will man mehr? Oft ist es gar nicht der Autor, sondern ein anderer User, der sein Anwenderwissen teilt.
Zitat
Die Angabe des Hauptthreads für dieses Widget im Forum wäre für Fragen hilfreich.
Es gibt im Allgemeinen keinen Hauptthread. Und wenn, dann ist er unübersichtlich und damit unpraktisch, siehe:
Zitat
(Zitat Thorsten Pferdekämper vom 15.8.2018 [FUIP]: "
Btw.: Ich hatte schon einmal darum gebeten, für neue Probleme neue Threads aufzumachen. Anscheinend interessiert das keinen, daher mache ich diesen hier jetzt zu,
Gruß,
   Thorsten"
Grundsätzlich ist gegen die Angabe des Autors nichts einzuwenden (wenn er einverstanden ist). Immerhin wäre diese Angabe auf Dauer valide. In den überschaubaren Fällen, wo jemand ein Widget in Pflege genommen hat, könnte man das zusätzlich vermerken. Nützlich erscheint mir auch: "Bekannte Fehler" (stichwortartig kurz und prägnant mit Link auf den zugehörigen Thread; in erster Linie sollten Bugs im Forum abschließend behandelt werden und es deshalb gar nicht bis zum Wiki schaffen). Das wären schon einmal mögliche Inhalte eines Infokastens. Ein Hinweis "Zuletzt getestet <Datum>" wäre dann und nur dann sinnvoll, wenn sich jemand findet, der das regelmäßig für alle Widgets (in allen denkbaren Konstellationen  :o) nachhält. Wenn nicht, wird daraus schnell Datenmüll.

Ich finde, dass Du in Deinen Beiträgen mit leuchtenden Farben schwarz malst:
Zitat
"nicht funktional, kaputt, defekt, eingestellt, verschollen, tot."
- Na ja, da sieht man sich ja auf einem Trümmerfeld.
Zitat
"Eine Vielzahl von Widgets sind nicht einmal schlecht im Wiki dokumentiert - sie sind überhaupt nicht dokumentiert. Ein Blick auf die FTUI-Wikiseite (unten sind Links auf zwei Widget-Klassen) reicht. Selbst wenn sie dokumentiert sind, dann sind mögliche Optionen/Schalter/Attribute nicht dokumentiert; vgl. beispielhaft Calview-Widget."
Wenn man die Nesges-Widgets mitzählt, gibt es für ca. 90% der gelisteten integrierten Widgets eine (höchstwahrscheinlich unvollkommene) Doku. Aber man kann natürlich wieder schwarz malen und größere Lücken bei den 3rd-Party-Widgets bemängeln. Wenn man die einfach einmal gedanklich ausblendet ("Die gibt es gar nicht."), dann vermisst man sie nicht und fühlt sich doch gleich wohler.
Erfreulicherweise hast Du bei Calview Dein erarbeitetes Wissen geteilt. Das haben in anderen Widgets schon viele andere gemacht, gewiss auch zu Deinem Nutzen.

Die wahrscheinlich von Dir hier zugeordnete Kategorie "Modul (inoffiziell)" sollte in FTUI nicht verwendet werden; das sind FHEM-Module.
Zitat
Derzeit scheitere ich im Forum selbst mit aktiven Nachfragen an einem Widget für DWD-opendata.
Die meisten Anwender (so auch ich) scheinen mit den verfügbaren Wetterdaten (z.B. Proplanta) zufrieden zu sein und engagieren sich entsprechend weniger für DWD, zumal dort wohl öfter ein Pflegeaufwand droht. Das ist Deine Chance. Stattdessen wird gejammert, dass der Support nicht funktioniert. Wenn sich jemand solche Kritik zu Herzen nehmen sollte, wird er doch abgeschreckt, Neues auszuprobieren und Gleichgesinnte zu suchen.
Zitat
Ich fand das Widget svgplot, es funktionierte nicht. Dann fand ich einen Beitrag, der war ein Jahr her: Da schrieb jemand, wie man dieses Widget wieder zum Leben erwecken könne - Antwort erhielt er nie.
Ich habe dessen Änderungen getestet - funktioniert.
Sodann habe ich @setstate (das Modul ist in seinem Updatezyklus) gebeten, mal heftig ins Getriebe zu greifen und ohne Kenntnis seines verschollenen Autoren die Änderungen einzuarbeiten. Hat er getan. (Und gelegentlich können wir alle mal darüber nachdenken, warum ein Jahr vergehen musste.)
Könnte man auch als Seitenhieb auf setstate deuten, na prima.
Zitat
Zweitens werde ich das Widget nicht analysieren. Weder auf CSS-Klassen noch auf sonstwas. - Ich habe es gefunden. Es funktioniert. Im Wiki beschreibe ich, wie man das nutzt.
Schade; die Kompetenz dafür dürftest Du haben.

Dein Ansatz scheint zu sein: Für jedes Widget wird ein Verantwortlicher benannt; gerne schreibst Du selbst das Protokoll. Und dann erwartest Du, dass Anfragen aller Art zeitnah beantwortet werden. So läuft das nicht. Auch besonders aktive User nehmen sich teils mehrmonatige Auszeiten; das ist vollkommen in Ordnung. Dann muss man sich mit Anfragen/Wünschen eben in Geduld üben. Oder sich selbst helfen. Und wenn ein Know-how-Träger ganz aussteigt, ist das nichts anderes als der normale Gang der Dinge (auch wenn man teilweise nicht daran denken mag).

Es gibt gewiss Dinge, die man bei FTUI (gerade weil es inzwischen beachtliche Reife erreicht hat) anders machen könnte. Zu Grundsatzfragen äußere mich aber nur, wenn ich selbst einen Lösungsbeitrag leisten kann.
Zitat
Nicht aufregen, bitte: Ich bin im Team der Guten.
Lieber nochmal lesen.
Habe ich mehrmals gemacht und nehme in Kauf, hier nicht das letzte Wort zu haben.
« Letzte Änderung: 12 November 2018, 16:35:59 von Ulm32b »

Offline curt

  • Full Member
  • ***
  • Beiträge: 353
Antw:Widget-Dokus; War: svgplot widget update - wie update "hochladen"?
« Antwort #11 am: 12 November 2018, 20:09:33 »
Der Thread nimmt eine unschöne Wendung, das missbehagt mir.

Ich nehme zur Kenntnis, dass ich bereits den Einleitungssatz falsch machte, da gibt es Richtlinien. Gleichzeitig gibt es sie nicht (zum nachlesen). Gut - da habe ich keine Chance. Mir leuchtet ein, dass es besser ist unter sich zu bleiben.

Ich nehme zur Kenntnis, dass der Autor bedeutungslos sei. Ich nehme zur Kenntnis, dass ein Hinweis auf einen vorhandenen Anker-Thread nicht erwünscht ist. Ich nehme zur Kenntnis, dass der Autor bedeutungslos sei. Ein Hinweis, wann das Widget funktionierte ist auch nicht gewünscht. Hingegen erfahre ich meine Motivation, meinen Ansatz. Interessant.

Damit hat sich jede Diskussion über die Nennung des Widget-Autoren erledigt.

Klarstellung zu svgplot: Das Widget ist offensichtlich verwaist (und einer der Gründe, warum ich vorhatte, bei der Doku mitzuhelfen). Vor gut einem Jahr hatte jemand samt Lösung im Forum darauf verwiesen, gleichwohl an unerwarteter Stelle. - Ich habe vor einigen Tagen @setstate auf den Bugfix verwiesen. Er hat das sehr schnell in (ein fremdes) Widget eingebaut. Wo da ein Seitenhieb auf setstate ist, wird Dein Geheimnis bleiben.

Tatsächlich ist richtig, dass ich mir (und anderen) die Arbeit vereinfachen will. Nur so entwickelte sich die Menschheit. Und selbstverständlich ist es schöner, schnell Antworten zu bekommen - als gar keine.

Danke für die freundliche Begrüßung.
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 845
Antw:Widget-Dokus; War: svgplot widget update - wie update "hochladen"?
« Antwort #12 am: 13 November 2018, 09:47:18 »
Ich nehme zur Kenntnis, dass ich bereits den Einleitungssatz falsch machte, da gibt es Richtlinien. Gleichzeitig gibt es sie nicht (zum nachlesen). Gut - da habe ich keine Chance. Mir leuchtet ein, dass es besser ist unter sich zu bleiben.

Öhm, mir war nicht bewusst, dass es da Richtlinien gibt. Und ich bin einer von denen, die damals viel mitgearbeitet haben. ;)

Während der Arbeit an der Doku hat sich einfach ein grundlegender Aufbau einer Widget-Seite ergeben. Und wir waren uns einig, dass es Sinn macht, wenn die Seiten ungefähr gleich aussehen.
Nicht nur im FHEM-Wiki sollte jede Seite eine Einleitung haben. Und die sollte eine kurze Zusammenfassung des beschriebenen Inhalts sein. Damit hat sich der Einleitungssatz einfach so ergeben. Und da der eine vom anderen abgeschrieben hat und zumindest ich immer bei einer neuen Seite eine bereits existierende kopiert habe, hat dann halt einfach der Einleitungssatz immer gleich ausgesehen. Ich persönlich finde das gut, aber dass das eine Richtlinie sein soll, sehe ich eigentlich nicht so.

Ein Widget dem "einen Autor" zuzuordnen ist mitunter gar nicht so einfach. Wir reden hier immerhin von OpenSource. Da kann jeder ändern wie er will. Kann gut sein, dass der Original-Autor irgendwann sein ursprünglich entwickeltes Widget gar nicht mehr wieder erkennt. Ihn trotzdem als "Ansprechpartner" festzulegen, ist gar nicht so praktisch.

Bezüglich der Dokumentation von unbekannten Widgets: Ich habe damals viele dokumentiert, die ich überhaupt nicht kannte. Und nie verwendet habe. Bis heute nicht. Hab sie halt auf eine Testseite eingebaut, geschaut, was alles möglich ist, wenn nötig den Quellcode analysiert und die Erkenntnisse niedergeschrieben. Habe nie gesagt, dass alles so richtig war. Und in einem Jahr noch genau so funktioniert. Hab auch nie versprochen, dass ich mich weiterhin um die von mir erstellte Wiki-Seite kümmere. Das geht einfach nicht, dazu müsste man das Widget nützen und ständig das Forum im Auge behalten, ob's irgendwelche neuen Erkenntnisse dazu gibt. Das ist aber halt auch das Wesen eines öffentlichen Wikis: Kann jeder andere auch machen. Und schön wäre, wenn das auch geschehen würde.

Ein Hinweis, wann das Widget funktionierte ist auch nicht gewünscht.

Fände ich persönlich jetzt nicht uninteressant. Wäre gut im Abschnitt "Hinweise" aufgehoben. Muss dann aber halt auch verlässlich gepflegt werden.

Offline curt

  • Full Member
  • ***
  • Beiträge: 353
Antw:Widget-Dokus; War: svgplot widget update - wie update "hochladen"?
« Antwort #13 am: 15 November 2018, 03:23:41 »
@drhirn
Öhm, mir war nicht bewusst, dass es da Richtlinien gibt. Und ich bin einer von denen, die damals viel mitgearbeitet haben. ;)

Ich bin beruhigt. @Ulm32b hatte mich schon sehr verschreckt.

Während der Arbeit an der Doku hat sich einfach ein grundlegender Aufbau einer Widget-Seite ergeben. Und wir waren uns einig, dass es Sinn macht, wenn die Seiten ungefähr gleich aussehen.

Logisch.

Nicht nur im FHEM-Wiki sollte jede Seite eine Einleitung haben. Und die sollte eine kurze Zusammenfassung

Den Teil können wir uns sparen: Mein neuer Artikel hat genau diese Einleitung. Was @Ulm32b da hat, habe ich nicht verstanden.

Ein Widget dem "einen Autor" zuzuordnen ist mitunter gar nicht so einfach.

Ich bin ja nun auch nicht erst seit gestern auf dieser Welt: Dein weiterer Text könnte von mir sein. - Ja, so ist das halt. Dann steht im Feld Autor "u/i". Aber das ist allemal besser als ein funktionierendes Widget gar nicht zu dokumentieren.

Wir reden hier immerhin von OpenSource.

Missverständnis bzw. Dissens. Ich rede von Widgets, die offensichtlich funktionieren, aber der Autor abhanden gekommen ist. Wenn sie nun schon funktionieren, kann man die dokumentieren. Ok, ich kann da keine CSS-Klassen aufführen, mir fehlt auch die Kraft, den Code zu analysieren. Aber zu sagen "gugg, das geht, schaue mal den Beispielcode" scheint mir schon wichtig.

Siehe Widget svgplot: Das würde es nicht geben, wenn @ststate nicht auf meinen Hinweis hin die Korrektur einer völlig anderen Person eingepflegt hätte. Und nun gibt es den Wiki-Artikel, der beschreibt wie man das nutzt. Und das es 2018-10 funktionierte. Und das der Autor unbekannt ist.

Die Alternative ist: Kein Artikel.

Bezüglich der Dokumentation von unbekannten Widgets: Ich habe damals viele dokumentiert, die ich überhaupt nicht kannte. Und nie verwendet habe. Bis heute nicht. Hab sie halt auf eine Testseite eingebaut, ...

Also die Kraft habe ich nicht.
Magst Du mal wieder? Mein erster Vorschlag wäre fullcalview - von dem nicht mal klar ist, ob das noch funktional ist. Rein theoretisch ist das ein optisch genialer Monatskalender.

Zitat
Ein Hinweis, wann das Widget funktionierte ist auch nicht gewünscht.
Fände ich persönlich jetzt nicht uninteressant. Wäre gut im Abschnitt "Hinweise" aufgehoben. Muss dann aber halt auch verlässlich gepflegt werden.

Ich bin der mit den ganz kleinen Brötchen: FHEM habe ich seit gut einem Jahr. FTUI seit vielleicht einem halben Jahr. Ich halte es bis zum Erbrechen schlecht, dass ich Beiträge mit Wigdets finde, die vielleicht irgendwann mal mit einer alten FTUi-Version funktionierten.

Aus meiner Sicht muss in dem rechten Kasten stehen:
Aktueller Autor ist -> Nickname
Widget hat funktioniert -> Jahr-Monat

Ich weiß, dass das alles nicht optimal sein kann, Du sagtest schon "Pflege". Aber andererseits ist ein "hat 2013-01 funktioniert" ein deutlich besserer Hinweis als "wir haben gar keine Ahnung, übrigens haben wir den Wiki-Artikel auch gar nicht geschrieben, der Artikel existiert nicht. Vergiss alles, wir helfen Dir nicht."

So, jetzt will ich noch stinkig sein über den Beitrag von @Ulm32b .
« Letzte Änderung: 15 November 2018, 03:29:35 von curt »
RPI 3 Busware-CC1101 Jeelink HomeMatic Z-Wave (USB) + viele RPI Zero W

Offline drhirn

  • Sr. Member
  • ****
  • Beiträge: 845
Antw:Widget-Dokus; War: svgplot widget update - wie update "hochladen"?
« Antwort #14 am: 15 November 2018, 09:01:46 »
Wenn sie nun schon funktionieren, kann man die dokumentieren. Ok, ich kann da keine CSS-Klassen aufführen, mir fehlt auch die Kraft, den Code zu analysieren. Aber zu sagen "gugg, das geht, schaue mal den Beispielcode" scheint mir schon wichtig.

Naja, dann mach doch. Hindert dich niemand daran.
Uns ging's damals darum, FTUI überhaupt mal im Wiki zu dokumentieren. Inklusive der Widgets, die von setstate geschrieben wurden.
Bei den 3rd Party Widgets wurde vermerkt, dass nicht sichergestellt werden kann, dass die funktionieren. Aus meiner Sicht reicht der Hinweis vollkommen aus. Wenn einer das anders sieht, steht ihm frei, das zu ändern.

Siehe Widget svgplot: Das würde es nicht geben, wenn @ststate nicht auf meinen Hinweis hin die Korrektur einer völlig anderen Person eingepflegt hätte. Und nun gibt es den Wiki-Artikel, der beschreibt wie man das nutzt. Und das es 2018-10 funktionierte. Und das der Autor unbekannt ist.

Ist ja auch gut. Freut mich immer, wenn auch andere im Wiki mitarbeiten. Soll ja auch der Sinn eines Wikis sein.


Ich bin der mit den ganz kleinen Brötchen: FHEM habe ich seit gut einem Jahr. FTUI seit vielleicht einem halben Jahr. Ich halte es bis zum Erbrechen schlecht, dass ich Beiträge mit Wigdets finde, die vielleicht irgendwann mal mit einer alten FTUi-Version funktionierten.

Und wieder: Es steht dir frei, an dem Zustand etwas zu ändern. Du darfst nur nicht erwarten, dass es andere tun.


Aus meiner Sicht muss in dem rechten Kasten stehen:
Aktueller Autor ist -> Nickname
Widget hat funktioniert -> Jahr-Monat

Mit dem Kasten hast du dich in ein Minenfeld begeben! Die Info-Box ist nur für FHEM-Module. Und ein FTUI-Widget ist kein FHEM-Modul. Über die Idee mit so einer Hinweisbox selbst mag ich nicht urteilen. Ich hab da keine Meinung dazu. Könnte auch alles einfach im Einleitungssatz vorkommen. Aber diese Vorlage für die Info-Box deklariert die ganze Wiki-Seite als FHEM-Modul (Kategorie: Modul (inoffiziell)). Das ist ganz, ganz schlecht. Also wenn man so eine Info-Box wollte, müsste man selber eine Vorlage basteln.

Einen Autor zu erwähnen, der unbekannt ist, halte ich übrigens nur für bedingt sinnvoll.


So, jetzt will ich noch stinkig sein über den Beitrag von @Ulm32b .

Dafür gibt's keinen Grund. Er hat seine Meinung konstruktiv geäußert. Da war sogar ein Lob dir gegenüber dabei ;).

 

decade-submarginal