[FHEM Tablet-UI] Dokumentation (Diskussionsthread)

[Standarduser]

Hat jemand Lust, die Linienformen des Chart-Widgets zu dokumentieren?
Ich finde keine Beispieldaten, mit denen man den Unterschied wirklich gut darstellen kann.

//edit: blöde Autokorrektur 

[drhirn]

Warum etwas weglassen? Die eine Zeile brauchen wir doch nicht sparen. Lieber eine vollständige Doku, das macht es einfacher.

Ok, dann schreiben wir alles hin. Werde "meine" Widgets dementsprechend ergänzen falls nötig.

[Ulm32b]

Ok, dann schreiben wir alles hin. Werde "meine" Widgets dementsprechend ergänzen falls nötig.

Halte ich auch für die bessere Lösung.

Frage mich aber immer noch, wie ich für meine Widgets ohne nervtötendes und zeitaufwendiges Ausprobieren herausfinde, welche CSS-Klassen funktionieren. Was immer man dazu irgendwo findet, ist mit Vorsicht zu genießen. Bei clock habe ich im js übrigens Bezeichner gefunden, die Nesges gar nicht dokumentiert hatte.

Vielleicht meldet sich auch noch jemand, der sich hierauf spezialisiert. Ich wäre froh.

[Ulm32b]

Mit playstream hatte ich mir eine schöne Suppe eingebrockt. Sah eingangs alles easy aus, dann stieß ich auf die URL-Geschichte, produzierte Aufwand bei Setstate und mühte mich dann auch mit dem Beispiel ab (am Ende sieht alles immer ganz einfach aus). Wie auch immer; ich denke, es hat sich gelohnt.

Weil hier mehrere Widgets zusammenwirken, habe das als eigenständiges Beispiel veröffentlicht: https://wiki.fhem.de/wiki/FTUI_Beispiel_Webradio
Andere dürfen da direkt weitermachen, z.B. die Playlists online abgreifen und einbinden ...

Es haben sich ja schon einige mit komplexen Audiolösungen beschäftigt. Damit fange ich lieber gar nicht erst an.

[All-Ex]

@All-Ex du stiller Korrigierer, danke dafür!

Gerne Tolle Arbeit, die ihr macht!

1. In der Widget-Doku von Homestatus ist gut zu erkennen, dass das mittlere Symbol nicht richtig zentriert ist. Weiß jemand, woran das liegt? Bei mir ist das nämlich auch so.

Dazu hatte ich hier mal einen Patch vorgeschlagen, der jedoch bisher nicht eingebaut wurde:
https://forum.fhem.de/index.php/topic,60781.msg522282.html

Range- und Dimmer-Widget sind auch fertig.

Beim Dimmer-Widget könnte man noch Beispiele unterbringen. Ich habe nur HUE-Lampen zur Verfügung und kann andere (MiLight, FS20-Dimmer) daher nicht verifizieren.

Habe eben ein Beispiel für Homematic-Dimmer ergänzt.

[drhirn]

Noch eine Frage zu "alles dokumentieren": Wenn ein Widget die selben Attribute verwendet, wie ein anderes Widget, sollen wir's dann trotzdem nochmal dokumentieren? Wäre bei einer Änderung ja doppelte Arbeit.

[Standarduser]

Hast Du ein Beispiel?

Grundsätzlich wäre ich eigentlich schon dafür, weil ich die Meinung von setstate teile:

Ich hatte in der Github Readme zwar auch angefangen, Dopplungen wegzulassen, aber mittlerweile denke ich: besser ist eine vollständige Auflistung pro Element (Widget). Wenn jemand gezielt nach einem Widget sucht und alle Optionen / Parameter wissen will, wird er niemals vorher die kpl. Doku lesen, um alle Standards zusammen zu puzzeln. Man will alles auf einem Punkt haben. Mit Copy&Paste ist das eigentlich kein Problem.

Aber sicher muss man da auch immer den Einzelfall betrachten.

[drhirn]

Da gibt's mehrere. Für Pagebutton gelten z.B. alle Attribute von Switch. Für Thermostat alle von Knob.

Behauptet zumindest die GitHub-Doku

[Standarduser]

ja, aber wer sieht dann noch durch, wenn man von einem widget aufs nächste verweist?

baue im am pagebutton, muss ich dann zu switch springen, um die standard-attribute zu lesen, die dort in einem anderen kontext verwendet werden, und dann wieder zurück zu pagebutton, um pagebutton-spezifische sachen zu finden, und dann wieder zurück zum switch, um allgemeine sachen zu finden, und dann wieder zurück zu pagebutton, um pagebutton-spezifische sachen zu finden, und dann wieder zurück zum switch, um allgemeine sachen zu finden, und dann wieder zurück zu pagebutton, um pagebutton-spezifische sachen zu finden, und dann wieder zurück zum switch, um allgemeine sachen zu finden, ...

Das könnte ich noch ewig fortführen, denn so in etwa sieht es bei mir aus, wenn ich an meiner UI arbeite 

[drhirn]

Deswegen wurden ja die Browser-Tabs erfunden

Verstehe schon, was du meinst. Befürchte aber halt, dass die Doku irgendwann auseinanderläuft. Wenn z.B. der Knob ein neues Attribut erhält, das aber bei den anderen nicht nachgezogen wird.

[Standarduser]

Da hast Du nicht ganz unrecht. Auf alle Fälle wäre ein Hinweis, dass Pagetab eine Ableitung von Switch ist, nicht verkehrt. Derjenige, der die Doku aktualisiert, muss da schon ganz schön aufpassen. Durch diesen Hinweis wird das aber irgendwann mal jemandem auffallen, sodass es nachgezogen werden kann.

Insgesamt stellt sich nacher sowieso die Frage, wie man die Doku aktuell halten kann. Richtig zuverlässig würde das wohl nur funktionieren, wenn setstate an einer bestimmten Stelle einen kurzen Hinweis hinterlässt, was sich geändert hat.
Das aus irgendwelchen Threads, in denen Änderungen ja oftmals entstehen, herauszufischen, wird wohl kaum gelingen und wäre eher mit Zufall verbunden.

Vielleicht hat setstate eine Idee dazu, wie er uns auf dem Laufenden halten kann?

[drhirn]

Ich hab das bisher immer dazugeschrieben. Beim Thermostat z.B. steht: "Für das Thermostat-Widget gelten dieselben Attribute, wie für das Knob-Widget. Und zusätzlich noch die folgenden: "
"Knob-Widget" natürlich in Form eines Links.

[Ulm32b]

Und dann kommt da ein in Ehren ergrauter Datenbankadministrator (ich bin keiner, zumindest was den Datenbankadministrator betrifft) daher und sagt: "Leute, so etwas haben wir doch schon damals sauber über Abfragen abgebildet." Gibt's dafür in Wikis keine Werkzeuge? Ich sehe allerdings auch ein, dass tolle Lösungen in einem etwas anarchischen Umfeld auch schnell wieder einschlafen können.

[drhirn]

Die gibt's: Semantic MediaWiki oder die Cargo Extension.
Ist allerdings ein Overkill, den ich den Admins hier nicht antun will.

Aber die Sache mit der Wartung ändert sich im Großen und Ganzen trotzdem nicht.

[drhirn]

Pagebutton ist fertig. Ihr dürft da aber gerne ergänzen/korrigieren/etc. Ich bin da nicht ganz sattelfest.