[FHEM Tablet-UI] Dokumentation (Diskussionsthread)

[drhirn]

Und  zu Beginn ein Minimal Code Beispiel
Bei dem AV Receiver Beispiel fragt man sich als Newbie bestimmt, "inline"?, "wider"? "w2"? Muss dass immer dabei sein? Gehört das zum Widget?

Guter Hinweis!
Baue ich gleich um und sollten wir bei den anderen Widgets auch beherzigen. Schnurzpiepegal, wie das Beispiel dann in der Praxis aussieht, hauptsache das Wesentliche funktioniert.

[drhirn]

Und was mir auch gerade auffällt:
Wir sprechen zwar immer von FTUI, aber korrekt ist eigentlich FHEM Tablet-UI. Die Überschrift sollte also FHEM Tablet-UI Widget: Select lauten.
Den Seitentitel würde ich wie zuvor geschrieben benennen.

Finde ich nicht so tragisch. FTUI ist halt viel kürzer. Und wir werden einfach auf der Hauptseite oft genug erwähnen, dass FTUI die Abkürzung ist, dann wird das schon klar.

[Standarduser]

Der Seitenname ist schon gut so. Ein "/" ist in MediaWiki ein Zeichen für Unterseiten. Die sind aber im FHEM-Wiki (und in Standard-Installationen von MediaWiki) nicht aktiviert. Ich habe das gestern mit den FHEM-Wiki-Leuten besprochen, wir belassen es auch dabei.
In deinem Fall wäre der Seitenname dann FHEM_Tablet_UI/Widget_Select, das ist ziemlich lang und eigentlich kaum merkbar. Deshalb finde ich meine Version eigentlich hübscher und praktischer.

Das von mir vorgeschlagene Namens-Schema wird doch genau so schon verwendet -> für die FAQ.
Es soll sich auch niemand die Adressen merken müssen. Ich würde alle Seiten auf der Hauptseite genau so verlinken, wie im ersten Post dargestellt. Somit ist die Hauptanlaufstelle immer die gleiche.

Ich hatte mir auch überlegt, die Verlinkung mit Bildern in Tabellenform zumachen. Dadurch gibt es auch gleichzeitig eine (optische) Übersicht darüber, welche Widgets überhaupt existieren.

Die Seite nur Widget_Select zu nennen fände ich deswegen kritisch, weil es ja sein könnte, dass mit einem anderen Modul irgendwann auch Widgets erstellt werden können. Das könnte zu Konflikten führen. ...

Haste recht, sehe ich auch so.

Attribute, mit denen man das Aussehen steuern kann? Da gibt's ja eh nur die CSS-Klassen. Und die stehen ja in der Tabelle. Die müssen wir nicht jedes Mal extra beschreiben. Reicht, wenn wir das auf der Hauptseite machen.
Oder habe ich dich falsch verstanden?

Ich glaube, Du hast mich richtig verstanden. Eine Sache, die mich am Github-Wiki total nervt ist, dass man ständig hin und her springen muss. Wenn ich ein Widget einbaue, dann will ich das auch formatieren. Dazu muss man ständig scrollen oder, wie hier, Seiten wechseln.
Es sind auch nicht alle Formatierungsattribute für alle Widgets verfügbar. So wäre doch dann eigentlich klar, was geht und was nicht.
Dass die Tabellen dann immer ähnlich, und oft vielleicht auch gleich, sind, würde ich hier einfach in Kauf nehmen. Dann macht es ja eigentlich auch keine Mühe, die einzufügen. Oder?

[drhirn]

Die FAQ wird auch dann von mir gekübelt, der Seitenname ist blöd . Ich bin mir aber noch nicht sicher, ob es schlauer ist, die FAQ in der Hauptseite einzubauen, oder doch auf einer eigenen zu lassen.

Die Idee mit der Verlinkung in Tabellenform mit Bild ist super. Sollten wir so machen. Könnten höchstens die unterschiedlichen Widget-Größen zum gestalterischen Problem werden.

Bezüglich Formatierungsoptionen hast du recht, das macht mich im GitHub-Readme auch immer fertig. Ich überlege mir was. Eventuell können wir da eine Wiki-Vorlage bauen, in der zwar alle Optionen aufgelistet sind, aber nur die angezeigt werden, die für dieses Widget möglich sind.

[Standarduser]

Ja, oder einfach die Vorlage hernehmen, den Inhalt auf die aktuelle Seite kopieren und rauslöschen, was nicht zum aktuellen Widget passt
Wenn es da etwas dynamisches gäbe, wäre das jedoch auch mega.

Sollten wir vielleicht auch eine Infobox je Widget mit aufnehmen, in der die wichtigsten Fakten stehen? Zum Beispiel, wer das entwickelt hat (sofern nachvollziehbar), ob das überhaupt noch gewartet wird, und wenn ja, wer das macht. Vielleicht auch ein Link zu dem Thread, wo das initial angekündigt wurde.

Ich bin beim durchgehen des JS-Verzeichnisses auf Widgets gestoßen, die ich bisher überhaupt noch nicht auf dem Zettel hatte. Zum Beispiel "joinedlabel". Einige funktionieren scheinbar auch nicht mehr (mit 2.5). Vielleicht sollte das auch mit hinein.

[drhirn]

Kopieren und löschen ist unpraktisch wenn's Änderungen an der jeweiligen Klasse gibt. Das muss dann bei jedem Widget händisch nachgetragen werden.
Und die dynamische Geschichte habe ich mir grad durchgedacht, das geht so leider nicht wie ich mir das vorgestellt hätte.

Infobox ist gut, ich würde aber sagen, wir konzentrieren uns jetzt mal drauf, dass die Inhalte ins Wiki kommen. Alles andere können wir danach noch machen.

[Kermit20]

<zustimm>

Hatte ich auch auf meiner "Müsste man mal machen"-Liste

Das ist auch auf meiner Liste noch vorhanden. Ich habe dann im letzten Update die folgende Datei im Verzeichnis gefunden:

index_layout.html

Diese veranschaulicht sehr schön die "neuen" Strukturen. Denke das könnte man schon nutzen (Zustimmung vorausgesetzt)

Code Auswählen Erweitern

            <!-- vbox hbox -->
            <li data-row="1" data-col="1" data-sizey="2" data-sizex="2">
                <header>vbox > hbox</header>
                <div class="vbox">
                    <div class="hbox">
                        <div class="red" data-type="switch" data-device="dummy1"></div>
                        <div class="green" data-type="switch" data-device="dummy2"></div>
                    </div>
                    <div class="hbox">
                        <div class="blue" data-type="switch" data-device="dummy3"></div>
                        <div class="orange" data-type="switch" data-device="dummy4"></div>
                    </div>
                </div>
            </li>
           
            <!-- Sheet > Row > Cell -->
            <li data-row="1" data-col="3" data-sizey="2" data-sizex="2">
                <header>Sheet > Row > Cell</header>
                <div class="sheet">
                    <div class="row">
                        <div class="cell" data-type="symbol" data-device="dummy1"></div>
                        <div class="cell" data-type="symbol" data-device="dummy2"></div>
                    </div>
                    <div class="row">
                        <div class="cell" data-type="symbol" data-device="dummy3"></div>
                        <div class="cell" data-type="symbol" data-device="dummy4"></div>
                    </div>
                </div>
            </li>
           


Ich würde mich auch geren einbrigen, da ich immer wieder an Grenzen Stoße und dann froh bin, wenn ich was zum Nachlesen finde.

[Standarduser]

Dann greif doch gleich zu und nimm den Layout-Teil (oder zumindest ein Stück davon).

Hat eigentlich jemand mal alle Widgets gleichzeitig auf einer Seite platziert und würde mir das zur Verfügung stellen (für die Übersicht), oder muss ich das alleine zurecht basteln?

[drhirn]

Da nehmen wir dann einfach die, die in den Widget-Seiten verwendet werden. Erspart 1x Aufwand und Speicherplatz.

[Standarduser]

Kopieren und löschen ist unpraktisch wenn's Änderungen an der jeweiligen Klasse gibt. Das muss dann bei jedem Widget händisch nachgetragen werden.
Und die dynamische Geschichte habe ich mir grad durchgedacht, das geht so leider nicht wie ich mir das vorgestellt hätte.

Wie verbleiben wir jetzt mit den Formatierungsattributen?
Ohne fehlt für mich ein wesentlicher Aspekt, der Änderungsaufwand ist aber natürlich deutlich höher. Finden wir da vielleicht noch einen gängigen Mittelweg? Oder bauen wir es erstmal ein und suchen trotzdem parallel nach einer besseren Umsetzung dafür?

[drhirn]

Letzteres. Ich hab schon einen Ansatz, der ist nur noch etwas unübersichtlich. Ich muss nochmal drüber schlafen und melde mich wahrscheinlich morgen im Laufe des Tages mit einem Ergebnis.

[Ulm32b]

Ich warte jetzt vorläufig, bis erste Vorbilder für die formale Einbindung da sind; dann werde ich auch einen inhaltlichen Beitrag leisten.

Nur zu. 

[Standarduser]

Wie wollen wir jetzt eigentlich vorgehen, wenn bei der Umsetzung der Dokumentation inhaltliche Fragen entstehen?
Ich arbeite gerade an der Doku für Push und stolpere hier über data-hide (hab ich bisher noch nicht verwendet). Womit wird dieser Wert denn verglichen, ein data-get gibt es ja (laut bisheriger doku ) nicht? Oder bezieht sich das auf data-warn?

Abgesehen von dieser ernstgeleinten Frage, sollen wir solche Dinge direkt hier klären oder lieber einen eigenen Thread dafür eröffnen?

[DocCyber]

Ein sehr begrüßenswerter Thread!

Ich erkläre mich ebenfalls bereit, Texte und Beispiele einzubringen, sobald über die gewünschten Strukturen Einigkeit erzielt wurde.

Mein Thema könnte Flexbox werden, denn da tobe ich mich gerade aus... 

[DocCyber]

Abgesehen von dieser ernstgemeinten Frage, sollen wir solche Dinge direkt hier klären oder lieber einen eigenen Thread dafür eröffnen?

Ich fände es besser, wenn solche Fragen separat geklärt werden. Andernfalls würde dieser Thread hier zu umfangreich, weil sich viele Verzweigungen ergäben.
Man sollte aber einen Link auf einen solchen Verzweigungs-Thread hier einstellen.