Hallo zusammen!
Es mehren sich die Wünsche nach einer etwas aktuelleren Dokumentation für die Tablet-UI, zu lesen an verschiedenen Stellen und in verschiedenen Kommentaren. Verständlich, sind doch bei weitem nicht alle Funktionen und Attribute dokumentiert. Vieles bekommt man eben nur im "Vorbeigehen" mit.
Dies soll nun der Versuch sein, das Thema etwas voran zu bringen.In diesem Thread soll es weniger um die technischen Inhalte gehen, als viel mehr darum, das ganze strukturell und organisatorisch zu diskutieren.Da die Dokumentation schon ziemlich weit ist, dürfen nun auch gern die Inhalte der Dokumentation diskutiert werden.Ich beginne mit dem Vorschlag von setstate...
Zitat von: setstate am 06 Februar 2017, 16:23:39
Ich wäre für das FHEM Wiki als Hauptdoku. Jeder der ein Problem lösen konnte und sich fragt, warum steht das nirgends, sollte das gleich im Wiki eintragen. Am besten Unterseiten nach Widget getrennt und ein großer Punkt "get started" mit Hinweisen zu Layout, Positionierung, Farben usw. Viel mit Verlinkungen über Schlagworte und Inhaltsverzeichnisse. Und viele Codesnipsel - nur mit den minimal notwendigen Attributen und Klassen. ...
...und schlage folgenden Aufbau vor:
+--Hauptseite (Vorstellung des Projektes)
+--Getting Startet (Schnelleinstieg ins Thema, Installation)
+--Layoutvarianten(Grundladen/Möglichkeiten)
| +-Gridster (mit Parametererklärung und grafischen Zusammenhängen)
| +-Flexbox (mit Parametererklärung und grafischen Zusammenhängen) {Ersteller:Kermit20}
| +-Cell/Row (mit Parametererklärung und grafischen Zusammenhängen) {Ersteller:Kermit20}
+--Formatierung (Grundsätzliches zu Symbolen, Farben, groß/klein/dick/dünn/wasauchimmer)
+--Widgets (Ausführliche Beschreibung der Widgets, mit Beispielbildern, Formatierungsmöglichkeiten, usw.)
| +-agenda
| +-button
| +-calview
| +-chart done
| +-checkbox done
| +-circlemenu done
| +-classchanger
| +-clicksound
| +-clock done
| +-colorwheel done
| +-datetimepicker done
| +-departure done
| +-dimmer done
| +-eventmonitor
| +-fullcalview
| +-gds
| +-highchart
| +-highchart3d
| +-homestatus done
| +-html
| +-iframe
| +-image done
| +-input done
| +-itunes_artwork
| +-javascript
| +-joinedlabel
| +-klimatrend done
| +-knob done
| +-kodinowplaying
| +-label done
| +-level done
| +-link done
| +-loading
| +-medialist
| +-meteogram
| +-mpdnowplaying
| +-multistatebutton
| +-notify
| +-pagebutton done
| +-pagetab done
| +-playstream done
| +-popup done
| +-progress done
| +-push done
| +-range done
| +-readingsgroup done
| +-reload
| +-rotor done
| +-screensaver
| +-select done
| +-settimer
| +-simplechart done
| +-slideout
| +-slider done
| +-spinner done
| +-svgplot
| +-swiper
| +-switch done
| +-symbol
| +-thermostat done
| +-tts
| +-uwz
| +-volume done
| +-wakeup
| +-wdtimer
| +-weather done
| +-weekdaytimer
| +-weekprofile
| +-wind_direction done
+--Beispiele
| +-Zeitschaltung done
| +-Datetimepicker done
| +-Webradio done
+--Templates
+--FAQ
+--CSS-Tricks
+--Eigene Widgets erstellen
+--...
Um jetzt aber nicht das totale Chaos ausbrechen zulassen und doppelte Arbeit zu vermeiden, wäre es vielleicht sinnvoll, wenn sich die Leute melden, die einen bestimmten Bereich/Widget dokumentieren wollen. Ich würde das dann in der Übersicht ergänzen. Außerdem wäre es sicher gut, wenn man sich auf einen einheitlichen Aufbau der Widget-Doku einigen könnte, damit sich die Leser auch schnell darin zurecht finden.
Ein Benutzerkonto für das Wiki kann hier beantragt werden: https://wiki.fhem.de/wiki/FHEMWiki:Administratoren (habe ich auch gerade getan).
Inhalt der Widget-Doku:- Bilder der verschiedenen Formatierungsmöglichkeiten (Vergleich: http://knowthelist.github.io/fhem/tablet/demo_spinner.html)
- Verfügbare Formatierungsattribute
- Verfügbare Steuerungsattribute
- FHEM-Definition zugehöriger Devices (falls zutreffend)
Folgende Festlegungen wurden getroffen:- Namensgebung der Wiki-Seiten für Widgets nach folgendem Schema:
FTUI Widget <Widgetname>- Namensgebung der Wiki-Seiten für Beispiele nach folgendem Schema:
FTUI Beispiel <Thema des Beispiels>- Hauptsprache der Dokumentation:
Deutsch- Der Grundsätzliche Aufbau sollte an FTUI Widget Select (https://wiki.fhem.de/wiki/FTUI_Widget_Select) und FTUI Widget Push (https://wiki.fhem.de/wiki/FTUI_Widget_Push) orientieren
- CSS-Klassen sollen in der Vorlage (https://wiki.fhem.de/wiki/Vorlage:FTUI_Klasse) gepflegt und daraus verwendet werden
- Einleitung der Seite sollte so aussehen:
Das [[{{PAGENAME}}|<Widget-Name>]] ist ein Widget für [[FHEM Tablet UI]]...Noch ein paar generelle Anmerkungen zur Vorgehensweise:Die Tablet-UI Hauptseite im Wiki besteht momentan (vereinfacht gesagt) aus:
- Einleitung
- Auflistung aller Widgets
- Konfiguration aller Widgets
- Beispiele zu allen Widgets
Wenn jemand eine Seite erstellt hat, dann bitte das entsprechende Widget (Konfiguration und Beispiele) aus der Hauptseite löschen und den Link in der Widget-Liste auf die neue Seite umlenken. So gibt es keine doppelte Doku. Bei der Zusammenfassung der Änderung schreibt Ihr dann bitte hinein, dass die Doku für dieses Widget auf eine neue Seite ausgelagert wurde.
Tipp: Manchmal sind die Beispiele von der Hauptseite besser, als die auf Github.
Danke für's Thread-Erstellen!
Die generellen Attribute fehlen noch. Und ein Absatz zur Installation.
Die Positionierung würde ich auf der Hauptseite abhandeln, Beispiele dann auf einer Unterseite (eine gemeinsame Unterseite für alle drei Möglichkeiten).
Wir müssen uns über die Namensgebung der Widget-Seiten einigen. Schlage vor FTUI Select Widget.
Und wir sollten uns einigen, ob wir's auf englisch oder deutsch machen.
Eine Untergruppe fällt mir noch ein: "eigene Widgets erstellen"
Zitat von: setstate am 06 Februar 2017, 18:18:15
Eine Untergruppe fällt mir noch ein: "eigene Widgets erstellen"
Das ist ja fast die wichtigste ;)
Zitat von: drhirn am 06 Februar 2017, 18:17:18
1. Die generellen Attribute fehlen noch. Und ein Absatz zur Installation.
2. Die Positionierung würde ich auf der Hauptseite abhandeln, Beispiele dann auf einer Unterseite (eine gemeinsame Unterseite für alle drei Möglichkeiten).
3. Wir müssen uns über die Namensgebung der Widget-Seiten einigen. Schlage vor FTUI Select Widget.
4. Und wir sollten uns einigen, ob wir's auf englisch oder deutsch machen.
1. Sehe ich im Getting startet
2. Ja, kann man eigentlich gut zusammenfassen
3. Mir egal, Hauptsache immer nach dem gleichen Schema
4. Ich stimme für deutsch. Übersetzen kann man das ja zusätzlich noch.
Ich nehm auf jeden Fall das Select-Widget. Da hab ich nämlich grad mal ein Beispiel gemacht, damit ich weiß, wie's aussehen könnte ;)
Die Theorie/Basis sieht schon mal sehr gut aus. Lasst es uns umsetzen. Freu mich.
gesendet von meinem Note via Tapatalk
Das sieht gut aus. Ich würde auch gerne mithelfen, denke aber das ich noch nicht genug Erfahrung habe um mitzuschreiben. Ich könnte aber Korrektur lesen und austesten. Gut fände ich auch Links zu guten HTML\CSS Seiten(selfhtml....). Ich sehe oft Fragen die eigentlich reines HTML\CSS sind.
Mitschreiben geht immer. Zu Anfang geht's ja nur darum, Bestehendes zu übernehmen und eventuell zu ergänzen. Solltest du wider Erwartens was falsch machen, können das ja andere korrigieren.
Links zu HTML/CSS-Seiten halte ich nicht für notwendig. Eine Suchmaschine kann eigentlich jeder verwenden (sollte man zumindest meinen). Und außer SelfHTML (http://selfhtml.org) und dem Mozilla Developer Network (https://developer.mozilla.org/en-US/docs/Web/CSS) braucht man eigentlich nicht viel ;)
Die Frage wäre noch, ob die def's der fhem-Devices auch in den Beispielen abgelegt werden sollen/müssen.
Oft kopiert man sich den ftui-Code und bekommt es dann nicht hin, weil das Device im fhem selber nicht so
aussieht, wie es müsste.
Man könnte den Devicecode natürlich auch auf der wiki-Seite des jeweiligen Moduls oder unter den Code Snippets
ablegen und verlinken.
Es sollte nur einheitlich gehandhabt werden.
Ich denke, es wäre eine gute Idee, auch die passende FHEM-Config mit ans Beispiel anzuhängen
Zitat von: redlav am 06 Februar 2017, 19:43:03
Die Frage wäre noch, ob die def's der fhem-Devices auch in den Beispielen abgelegt werden sollen/müssen.
Hab ich mir auch überlegt. Halte ich grundsätzlich für eine gute Idee. Befürchte aber, dass die Leute dann einfach die DEFs kopieren und dann dazu Fragen stellen, weil sie nicht verstehen, was sie da tun.
Zitat von: drhirn am 06 Februar 2017, 19:52:42
Befürchte aber, dass die Leute dann einfach die DEFs kopieren und dann dazu Fragen stellen, weil sie nicht verstehen, was sie da tun.
Die Frage kommt sowieso. Wenn nur der ftui-Code da steht, funktioniert es ja auch nicht automatisch in fhem.
Manches ist ja auch nicht unbedingt trivial ;) Mir hilft es immer, wenn ich die def's dazu habe, weil ich dann die Chance habe die commandref
anhand dieses Beispiels zu verstehen. Sonst breche ich mir da gerne schonmal einen ab.
Zitat von: drhirn am 06 Februar 2017, 19:20:41
Mitschreiben geht immer. Zu Anfang geht's ja nur darum, Bestehendes zu übernehmen und eventuell zu ergänzen. Solltest du wider Erwartens was falsch machen, können das ja andere korrigieren.
Das kann ich machen. Abschreiben kann ich gut ;D
Mir fallen noch ein paar Untergruppen ein:
- Versionshistorie
- Beispielseiten (index-example.html), inkl. der aktuellen Header
- User Demos: Einige stellen in den Thread ihre Seiten vor. Nachträglich die zu finden ist nicht gerade einfach
https://forum.fhem.de/index.php?topic=37378.0
Deinen 2. und 3. Anstrich sehe ich eigentlich bei "komplexe Beispiele". Da passt denke ich so ziemlich alles rein. Ob das nun wirklich so heißen muss, oder ob es da nicht eine treffendere Bezeichnung gibt, darf natürlich gern diskutiert werden.
Ab einem bestimmten Punkt macht es sicher auch Sinn, das noch etwas weiter zu untergliedern, aber das werden wir ja dann sehen.
Nur was soll man sich unter Versionshistorie vorstellen und wer soll das pflegen?
Benutzerkonto beantragt.
Ich würde mit
| +-label
anfangen. Später gern weitere.
Zitat von: Standarduser am 06 Februar 2017, 22:06:10
Nur was soll man sich unter Versionshistorie vorstellen und wer soll das pflegen?
z.B. die Neuheiten von 2.4 / 2.5 / ...
Arbeitet jemand z.B. noch mit 1.x gibt es einen besseren Überblick mit den Veränderungen. Lässt sich natürlich streiten wie ausführlich das gemacht wird. Vielleicht reicht auch der erste Post aus 2.5
https://forum.fhem.de/index.php/topic,65604.msg568058.html#msg568058
Zitat von: TWART016 am 06 Februar 2017, 23:05:33
z.B. die Neuheiten von 2.4 / 2.5 / ...
Arbeitet jemand z.B. noch mit 1.x gibt es einen besseren Überblick mit den Veränderungen. Lässt sich natürlich streiten wie ausführlich das gemacht wird. Vielleicht reicht auch der erste Post aus 2.5
https://forum.fhem.de/index.php/topic,65604.msg568058.html#msg568058
Und auch Tipps und Tricks was man beim Umstieg auf eine neue Version beachten muss.
Generell wären Tipps und gute Besipiele sehr hilfreich. Es gibt häufig die gleichen Fallen in die man reintappt. Gerade bei Formatierung gibt es da immer wieder Spass...
Hier mal ein Beispiel, wie es aussehen könnte: Als Teil (!) der Beschreibung von Switch.
(Die entscheidende Information zur Nutzung von on-for-timer in dummies erhielt ich gerade eben von einem Hero im FHEM-Forum.)
Zeitschaltung für einen Switch
Ein Switch soll auf ,,on" und nach einer definierten Zeit automatisch wieder auf ,,off" geschaltet werden. Auch ein manuelles Ausschalten soll jederzeit möglich sein. Realisiert wird dies durch den FHEM-Befehl ,,on-for-timer xx". Bei dummy-Devices setzt dies voraus, dass das Attribut ,,useSetExtensions 1" gesetzt ist. Bei anderen Devices bitte selbst prüfen.
FHEM:
define Zeitschalter dummy
attr Zeitschalter setList on off
attr Zeitschalter useSetExtensions 1
FTUI (In diesem Beispiel beträgt die Zeitdauer 20 s):
<div data-type="switch" class="cell" data-device="Zeitschalter" data-fhem-cmd='IF ([Zeitschalter:state] eq "off") (set Zeitschalter on-for-timer 20) ELSE (set Zeitschalter off)'></div>
Zitat von: Ulm32b am 07 Februar 2017, 00:47:02
Hier mal ein Beispiel, wie es aussehen könnte: Als Teil (!) der Beschreibung von Switch.
(Die entscheidende Information zur Nutzung von on-for-timer in dummies erhielt ich gerade eben von einem Hero im FHEM-Forum.)
Zeitschaltung für einen Switch
Ein Switch soll auf ,,on" und nach einer definierten Zeit automatisch wieder auf ,,off" geschaltet werden. Auch ein manuelles Ausschalten soll jederzeit möglich sein. Realisiert wird dies durch den FHEM-Befehl ,,on-for-timer xx". Bei dummy-Devices setzt dies voraus, dass das Attribut ,,useSetExtensions 1" gesetzt ist. Bei anderen Devices bitte selbst prüfen.
FHEM:
define Zeitschalter dummy
attr Zeitschalter setList on off
attr Zeitschalter useSetExtensions 1
FTUI (In diesem Beispiel beträgt die Zeitdauer 20 s):
<div data-type="switch" class="cell" data-device="Zeitschalter" data-fhem-cmd='IF ([Zeitschalter:state] eq "off") (set Zeitschalter on-for-timer 20) ELSE (set Zeitschalter off)'></div>
So etwas wäre für mich aber unter "Speziallösungen" zu suchen (mit Link vom/zum Switch). Die Standard-Section zum Switch sollte nur die Standards enthalten. "Keep it simple!" ist mir wichtig
Für die Einleitung/Basics ein Vorschlag:
Um den Aufbau einer FTUI-Seite schneller/einfacher zu verstehen, wäre eine grafische Darstellung des Zusammenhangs von cols, rows und den Pixel-Werten der 'Kacheln' hilfreich.
Zitat von: hobu am 07 Februar 2017, 08:57:53
Für die Einleitung/Basics ein Vorschlag:
Um den Aufbau einer FTUI-Seite schneller/einfacher zu verstehen, wäre eine grafische Darstellung des Zusammenhangs von cols, rows und den Pixel-Werten der 'Kacheln' hilfreich.
<zustimm>
Hatte ich auch auf meiner "Müsste man mal machen"-Liste
Falls es der eine oder andere noch nicht mitbekommen hat:
Ich schreibe im ersten Beitrag die Gedanken, die hier geäußert werden, mit, damit sich alle einen Überblick verschaffen können, wie der aktuelle Stand aussieht.
Außerdem hab ich mir schonmal Gedanken gemacht, wie der Seitenaufbau der Widget-Doku aussehen könnte.
Vielleicht etwas in dieser Richtung:
WIDGET NAME
Beschreibung, wofür es verwendet werden kann, usw.
--------------------------------------------------------
+------+ +------+ +------+ +------+
| | | | | | | |
| Bild | | Bild | | Bild | | Bild |
| | | | | | | |
+------+ +------+ +------+ +------+
Kurze Beschreibung je Bild, mit welchen Attributen diese
Darstellung erreicht werden kann.
WIDGET-SPEZIFIESCHE ATTRIBUTE
zum Beispiel data-get, data-set, data-icons, ...
Attribut | Beschreibung
---------+---------------------------------
Attr.1 | Beschreibung 1
Attr.2 | Beschreibung 2
Attr.3 | Beschreibung 3
... | ...
ALLGEMEINE ATTRIBUTE
Formatierungsmöglichkeiten, usw.
Attribut | Beschreibung
---------+---------------------------------
Attr.1 | Beschreibung 1
Attr.2 | Beschreibung 2
Attr.3 | Beschreibung 3
... | ...
BEISPIELE
inkl. eventuell benötigter Definition in FHEM
Seitenname auf jeden Fall: FTUI Widget Select, FTUI Widget Label, usw. Das garantiert eine alphabetische Auflistung.
Kategorie: FHEM Tablet UI
Die Dokumentation von FTUI ist für viele die Hürde, die genommen werden muß. Nicht jeder, der sein Haus/Wohnung automatisieren möchte, ist in der Lage, Wünsche in fhem abzubilden und in FTUI darzustellen, ohne sich bei jedem neuen Problem neu einzulesen.
Selbst die recht einfache Struktur von FHEM und FTUI verwirrt häufig Neueinsteiger bzw. Nicht-Programmierer wie auch ich einer bin.
Aus diesem Grund würde ich mich dazu bereit erklären, die erstellten Beiträge auf Verständlichkeit zu überprüfen. Ich glaube einfach, das durch eine gute, aber vor allem einfach zu verstehende Doku ein großes Potential liegt, fhem zu pushen.
Teilweise wird auf eine gestellte Frage im Forum mit, aus meinem Verständnis, kryptischen Formulierungen geantwortet und das sicherlich nicht absichtlich, sondern aus dem Wissen des Könnens heraus. Viele Aspekte, die für die Profis selbstverständlich sind, werden von Anfängern nur mit Fragezeichen versehen.
Das Wiki ist jetzt schon eine gute Anlaufstation und auch im Github findet man Starthilfe, aber eine komplette Doku an einem zentralen Ort wäre der Hammer.
Nur als Anregung: Im getting startet sollten vielleicht doch die Standardklassen aus der "Standard"-CSS Datei benannt werden, also welche es gibt und wie diese benannt wurden. Am wichtigsten sind allerdings die Möglichkeiten der Positionierung von Widgets auf den unterschiedlichen Plattformen (PC, Tablet, Smartphone, etc.).
Mist, abgeschweift. eigentlich wollte ich mich ja nur als Lektor anbiedern :o
Ich hab da mal ein Beispiel erstellt: FTUI Widget Select (https://wiki.fhem.de/wiki/FTUI_Widget_Select).
Bezüglich FHEM-Code bin ich noch ziemlich unschlüssig. Im Falle der aktuellen Beispiele beim Select-Widget wäre das eine Zeile für den Receiver (schafft jeder) und eine ewig lange Abhandlung bezüglich der Lichtszenen (bringt nichts). Bin mir also nicht sicher, ob eine FHEM-Definition zu den Beispielen wirklich Sinn macht.
Ob es Sinn macht oder nicht, ist sicher individuell vom Widget selbst abhängig.
Bei komplexen Steuerungen von Dummys und Timern wird man das sicher benötigen, beim Select eher nicht.
Sonst finde ich es ganz gut, nur der Seitenname ist echt ungünstig gewählt. Besser wäre https://wiki.fhem.de/wiki/FHEM_Tablet_UI/Widget_Select, ähnlich wie https://wiki.fhem.de/wiki/FHEM_Tablet_UI/FAQ.
Was fehlt, sind die Attribute, mit denen man das Aussehen steuern kann (zweite Tabelle).
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.
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?
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.
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. Deswegen habe ich noch das FTUI_ davor gestellt.
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?
Zitat von: setstate am 07 Februar 2017, 14:33:54
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.
Zitat von: Standarduser am 07 Februar 2017, 14:30:24
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.
Zitat von: drhirn am 07 Februar 2017, 14:34:24
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.
Zitat von: drhirn am 07 Februar 2017, 14:34:24
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.
Zitat von: drhirn am 07 Februar 2017, 14:34:24
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?
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.
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.
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.
Zitat von: setstate am 07 Februar 2017, 09:10:00
<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)
<!-- 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.
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?
Da nehmen wir dann einfach die, die in den Widget-Seiten verwendet werden. Erspart 1x Aufwand und Speicherplatz.
Zitat von: drhirn am 07 Februar 2017, 15:07:36
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?
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.
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. :)
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?
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... ;)
Zitat von: Standarduser am 07 Februar 2017, 19:36:34
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.
Bin der selben Meinung wie DocCyber. Ein extra Thread wird von anderen, die eventuell die selbe Frage haben, leichter gefunden.
Nichts desto trotz hätte ich data-hide so verstanden, dass du damit ein Reading angeben kannst, dessen Wert bestimmt, ob das Widget angezeigt wird oder nicht.
data-hide="STATE"
data-hide-on="!on"
data-hide-off="on"
... hätte ich so interpretiert, dass das Widget angezeigt wird, wenn der Status des Devices auf "on" steht. Sonst wird ausgeblendet.
Man korrigiere mich, wenn ich falsch liege. Hab's auch noch nie verwendet.
Zitat von: Standarduser am 07 Februar 2017, 19:36:34
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?
Gute Frage, habe es gerade mal aus dem Code versucht zu klären:
Es sieht wohl so aus, als ob fest auf "on" / "off" verglichen wird.
Es gibt zwar auch vorbereitete Werte "hide-on" / "hide-off" die eigentlich für den Vergleich angedacht sind, aber auf den ersten Blick scheinen die nicht verwendet zu werden...
Hier müsste wohl setstate zur Intention von "hide-on" / "hide-off" was sagen
Ihr seht das schon so richtig:
data-hide das Reading, dessen Wert gecheckt wird
data-hide-on "Wann ist das Hide an(on), aktiv. Bei welchem Wert?"
data-hide-off "Wann wird das Verstecken wieder aus (off) geschaltet?"
data-hide-on steht per default auf 'on|1|true' also gängige Werte, wenn was AN ist
data-hide-off Default ist hier '!on' -> alles nur nicht der Wert von data-hide-on. Aber hier nur als Stringvergleich, kein RegEx. Somit passen die Defaults garnicht zusammen.
Sinnvoller wäre
data-hide-on="on|1|true"
data-hide-off="off|0|false"
Oder
data-hide-on="on"
data-hide-off="!on"
Über Nacht kamen mir noch einige Gedanken.
Ich halte es für eine gute Idee, mal alle Attribute aus der Github-Doku zu nehmen, und diese dann im Bulk zu übersetzen.
Nacher kann man sich dann genau die Attribute, die man für die aktuelle Doku benötigt, einfach kopieren und einfügen. Nur Standard-Wert und im Einzelfall vielleicht auch etwas Inhalt müssten noch angepasst werden.
Hab mir die auch alle schonmal ins Excel gezogen - scheint einigermaßen übersichtlich zu sein.
Widget "Link" ist fertig: FTUI Widget Link (https://wiki.fhem.de/wiki/FTUI_Widget_Link)
Sehr schön!
Die Beispiele kommen mir bekannt vor ;)
Und wenn ich jetzt sagen würde, Link kann man auch als Austauscher für Seiteninhalte, genauso wie mit Pagebutton benutzen. Muss ich dann noch Infos liefern, oder findet man das irgendwie, um es im Artikel nachzutragen?
Ja, hehe, ich war so frei und hab geklaut ;)
Hmm, ich bin ja grundsätzlich dafür, dass andere statt mir denken. Kann mir zwar gut vorstellen, dass das funktioniert, wäre aber trotzdem ganz froh, wenn du zusätzliche Infos liefern könntest.
Zitat von: drhirn am 08 Februar 2017, 09:02:31
Widget "Link" ist fertig: FTUI Widget Link (https://wiki.fhem.de/wiki/FTUI_Widget_Link)
Man, Du legst ja hier vor! Da muss ich wohl auch mal ein wenig Gas geben.
Warum sind die Attribute eigentlich nicht mehr fett geschrieben? Versehen oder neuer Stil?
Zitat von: Standarduser am 08 Februar 2017, 09:45:47Warum sind die Attribute eigentlich nicht mehr fett geschrieben? Versehen oder neuer Stil?
Vergessen ;)
Ich korrigiere das bei der nächsten Änderung
Das macht sich ja echt schon.
Toll wie die Community das schnell in die Hand genommen hat und setstate ist sicher auch froh in dem Bereich entlastet zu sein. :)
Habe auchmal einen Wiki Account beantragt.
Zitat von: setstate am 08 Februar 2017, 09:30:58
Und wenn ich jetzt sagen würde, Link kann man auch als Austauscher für Seiteninhalte, genauso wie mit Pagebutton benutzen. Muss ich dann noch Infos liefern, oder findet man das irgendwie, um es im Artikel nachzutragen?
Musst du nicht, ich kann da liefern. ;)
@drhirn Es gibt noch data-load, welches ein div mit dem Content einer HTML Datei füllen kann.
Entweder du trägst das noch nach, oder ich versuche mich mal in die Wiki Bedienung reinzuarbeiten wenn mein Account da ist.
Damit kann man z.B. über Buttons den Inhalt eines Divs auf der Seite austauschen,
oder ganze Seiten tauschen um eben eine Tabbar ähnlich Pagetab zu realisieren.
So könnte das in der index.html aussehen:
<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="css/fhem-tablet-ui.css" />
<link rel="stylesheet" href="lib/font-awesome.min.css" />
<link rel="stylesheet" href="lib/jquery.toast.min.css" />
<script src="lib/jquery.min.js" defer></script>
<script src="lib/jquery.toast.min.js" defer></script>
<script src="js/fhem-tablet-ui.min.js" defer></script>
</head>
<body>
<div id="panel">
<div class="page" id="content-1"></div>
<div class="page" id="content-2"></div>
</div>
<div id="menu">
<div class="tab-bar" >
<div class="tab-link" >
<div data-type="link"
data-load="#content-1"
data-url="#content_1.html"
data-icon=""
data-color="#dbdbdb"
data-active-color="#419aff"
data-active-pattern=".*#content_1.html">
Link 1
</div>
</div>
<div class="tab-link" >
<div data-type="link"
data-load="div#content-2"
data-url="#content_2.html"
data-icon=""
data-color="#dbdbdb"
data-active-color="#419aff"
data-active-pattern=".*#content_2.html">
Link 2
</div>
</div>
</div>
</div>
</body>
</html>
Und so content_1.html und content_2.html:
content1.html:
<html>
<body>
<div class="page" id="content-1">
<div id="panel">
<!-- Start of content -->
Content 1
<!-- End of content -->
</div>
</div>
</body>
</html>
content2.html:
<html>
<body>
<div class="page" id="content-2">
<div id="panel">
<!-- Start of content -->
Content 2
<!-- End of content -->
</div>
</div>
</body>
</html>
So sieht das dann z.B. bei mir als Tabbar aus:
Eine Textsuche auf der GitHub-Seite nach "data-load" gibt 0 Treffer. Ein gutes Beispiel dafür, warum wir gerade die Community dokumentieren lassen :D
Ich werde versuchen, das nachzutragen. Darf ich deinen Anhang im Wiki verwenden? Sehr hübsch übrigens!
Vielen Dank!
Cooles mobile Schema. Hast du das übersichtlich in einer mobile-CSS für mich? Würde ich glatt als Standard so übernehmen.
Oder hast du die Farben pro Widget einzeln gesetzt?
Ich habe eine Zeit lang das Link-Widget als Page-tab-Ersatz verwendet. Das ganze ist aber ziemlich komplex und gehört meiner Meinung nach eher in den Bereich "komplexe Beispiele". Vielleicht sollten wir den parallel starten und einen Absatz "Weitere Anwendungsgebiete" einführen?
BTW: https://wiki.fhem.de/wiki/FTUI_Widget_Push
Ich finde das echt der Hammer was hier passiert!! :)
Hab das Link-Widget um die Navigation ergänzt: Navigationsbeispiel (https://wiki.fhem.de/wiki/FTUI_Widget_Link#Navigationsmen.C3.BC_mit_Link-Buttons)
Ist wirklich ein komplexes Beispiel. Aber ich denke, das kann man schon auf der Hauptseite abhandeln. Eine extra Seite für komplexe Beispiele könnte wieder unübersichtlich werden.
https://wiki.fhem.de/wiki/FTUI_Widget_Level
Können wir bitte im Einleitungstext sowohl auf die Widget-Seite selbst, als auch auf FHEM Tablet UI verweisen? Damit gleich klar ist, wo der Inhalt dazu gehört falls einer zufällig auf die Seite kommt.
Analog zum Link-Widget z.B.:
Das [[{{PAGENAME}}|Link Widget]] ist ein Widget für [[FHEM Tablet UI]] mit dem ein Text-Link oder Button erstellt werden kann um Befehle an FHEM zu senden.
Zitat von: drhirn am 08 Februar 2017, 11:09:08
Hab das Link-Widget um die Navigation ergänzt: Navigationsbeispiel (https://wiki.fhem.de/wiki/FTUI_Widget_Link#Navigationsmen.C3.BC_mit_Link-Buttons)
Ist wirklich ein komplexes Beispiel. Aber ich denke, das kann man schon auf der Hauptseite abhandeln. Eine extra Seite für komplexe Beispiele könnte wieder unübersichtlich werden.
Würde es vielleicht Sinn machen, verschiedene Navigations-Varianten mal an einer Stelle zusammenzufassen, Beispiele hinzu, sowie Vor- und Nachteile aufzulisten?
Es sind ja doch so einige Varianten im Umlauf: Slideout, Tabbar, Pagetab, Pagebutton, Link, ...
Zitat von: drhirn am 08 Februar 2017, 11:35:50
Können wir bitte im Einleitungstext sowohl auf die Widget-Seite selbst, als auch auf FHEM Tablet UI verweisen? Damit gleich klar ist, wo der Inhalt dazu gehört falls einer zufällig auf die Seite kommt.
Analog zum Link-Widget z.B.:
Das [[{{PAGENAME}}|Link Widget]] ist ein Widget für [[FHEM Tablet UI]] mit dem ein Text-Link oder Button erstellt werden kann um Befehle an FHEM zu senden.
Klar, gute Idee. Baue ich gleich bei meinen Seiten ein.
Zitat von: Standarduser am 08 Februar 2017, 11:38:17
Würde es vielleicht Sinn machen, verschiedene Navigations-Varianten mal an einer Stelle zusammenzufassen, Beispiele hinzu, sowie Vor- und Nachteile aufzulisten?
Ja, könnte man bei Gelegenheit machen.
Da fehlen übrigens 2 Kommas im Text.
Das Link Widget ist ein Widget für FHEM Tablet UI, mit dem ein Text-Link oder Button erstellt werden kann, um Befehle an FHEM zu senden.
Hallo Leute,
ich habe mit Interesse eure Beiträge verfolgt und mit Freude festgestellt das schon einiges getan wird. Aus Erfahrung möchte ich einen Ergänzenden Vorschlag machen:
Wie aus der IT so üblich, hat jeder seine "best practices"... leider führt das manchmal zu uneinheitlichen Erscheinungsbildern, Detailtiefe und möglichen Darstellungen. Da wir nun für das Thema bei "null" anfangen, sollten wir die Chance nutzen einen Standard für die Beiträge zu schaffen.
z.B.
die Darstellung von Atributen in einer Tabelle oder das Einfügen von Quelltext in einer Klappbox, Code Markierungen in Farbe und Form.
So sollten wir Wildwuchs eindämmen können.
Wir fangen zwar nicht bei null an, aber ich versteh schon, was Du meinst.
Zitat von: Kermit20 am 08 Februar 2017, 11:55:22
die Darstellung von Atributen in einer Tabelle
Machen wir doch
Zitat von: Kermit20 am 08 Februar 2017, 11:55:22
das Einfügen von Quelltext in einer Klappbox
Kommt sicher immer auf den Umfang des jeweiligen Beispiels an
Zitat von: Kermit20 am 08 Februar 2017, 11:55:22
Code Markierungen in Farbe und Form
Macht das Wiki automatisch, solange man den Parameter für die Sprache nicht vergisst
Der Gedanke kam mir auch schon. Und dann ist mir die inzwischen jahrelange Diskussion mit meinem Vorgesetzten eingefallen. Der möchte nämlich in unserem Wiki auch zuerst alle Grundregeln festgelegt haben. Ich hingegen bin der Meinung, dass es schlauer ist, den Usern zuerst mal ihre Freiheiten zu lassen und dann nachzubessern, sobald Inhalt da ist. Das Ergebnis nach 4 Jahren Diskussion: Keine Inhalte im Wiki, weil noch immer kein Regelwerk erstellt wurde :D
Ich bleibe daher bei meiner Meinung. Die Tablet UI Dokumentation ist überschaubar. Da kann leicht im Nachhinein noch geändert werden. Was sowieso notwendig sein wird, weil's immer User geben wird, die die Regeln übersehen ;).
Und wenn man sich an die bisherigen vier Beispiele hält, kann kaum was schief gehen.
Auch ich bin höchst beeindruckt. Als noch vergleichsweise unerfahrener Anwender kann ich mir noch die Brille des Newbees aufsetzen und möchte freundlich folgende Anregungen geben:
Zitatdata-url-xhr URL, mit der der Verweis im Hintergrund aufgerufen werden kann
Was bedeutet das? Wird der Link im Hintergrund geöffnet und ständig aktualisiert, um beim Aufruf die Ladezeiten zu verkürzen?
Zitatdata-active-pattern RegEx mit der der ermittelt wird, ob der Link aktiv ist. Der Check wird gegen die aktuelle "document location" durchgeführt
Bei RegEx bitte einen Verweis auf eine Erläuterung, was das ist und wofür das gut ist. Ich weiß nicht mehr genau, wo ich das seinerzeit gefunden habe, es existiert jedenfalls.
Zitatdata-active-color Farbe des Textes oder Icons wenn das "active-pattern" zutrifft same as data-color
Stammt der englische Text aus einem Copy-paste?
ZitatÜberschrift: Button zum Aufrufen einer URL
Sollte besser heißen:
Button-ähnlicher Link zum Aufrufen einer URL. Sonst wähnt man sich hier in der Beschreibung von "Button". Für Button wird es aber doch wohl eine eigene Beschreibung geben. Das gilt auch für die nachfolgenden Überschriften.
Werde ich alles korrigieren.
Bei data-url-xhr war ich mir leider nicht sicher, wie ich das am besten formulieren soll. Vorschläge erbeten.
Das mit der Farbe ist in der Tat ein Copy&Paste-Fehler.
Bzgl. RegEx: Hmm, es gibt hunderte Erklärungen im Web. Ich schau mal, ob ich eine gut verständliche Webseite finde und werde die verlinken.
RegEx ist ja bei vielen Widgets möglich. Vielleicht sollten wir das direkt in die Hauptseite zur Tablet UI als separaten Abschnitt einfügen? Oder gleich als eigenständige Seite. Immerhin kann man da ganze Abhandlungen darüber schreiben, insbesondere zu Beispielen.
RegEx ist in FHEM wichtig. Bin noch nicht ganz davon überzeugt, dass wir das überhaupt erklären sollen.
Warum verlinkt ihr nicht wiki-intern auf https://wiki.fhem.de/wiki/Regul%C3%A4rer_Ausdruck ?
Gruß, Christian
ich denke den meisten werden Beispiele mehr bringen.
Regex lesen werden die meisten können, die Schwierigkeit ist eher das erstellen ;)
Evtl eine eigene Seite mit Regex-Beispielen. Dann kann in einzelnen Widgets darauf verlinkt werden
Zitat von: krikan am 08 Februar 2017, 13:04:37
Warum verlinkt ihr nicht wiki-intern auf https://wiki.fhem.de/wiki/Regul%C3%A4rer_Ausdruck ?
Weil ich die Seite nicht kannte ;)
Ich danke!
So, ich hab jetzt eckige Augen und einen rauchenden Kopf vor lauter FTUI CSS Klassen ;)
Aber, es gibt jetzt die Vorlage FTUI Klasse (https://wiki.fhem.de/wiki/Vorlage:FTUI_Klasse). Mit der kann der Name und die Beschreibung einer bestimmten Klasse in Tabellenform angezeigt werden. Beispiel hier (http://"https://wiki.fhem.de/wiki/FTUI_Widget_Link#CSS_Klassen").
Erklärung dazu auf der Seite der Vorlage. Wichtig ist, dass zuerst eine Tabelle geöffnet wird, die einzelnen Klassen in EINER Zeile niedergeschrieben werden und die Tabelle danach wieder geschlossen wird.
Vorhanden sind alle Klassen, die ich auf die Schnelle auf der GitHub-Seite gefunden habe. Fehlen tun die, die eventuell bei Widgets dabei stehen und die, die nicht dokumentiert sind.
Ich habe die ganze Liste auch gleich auf der Hauptseite von Tablet UI (https://wiki.fhem.de/wiki/FHEM_Tablet_UI#CSS_Klassen) eingetragen.
Schön wäre noch, wenn man irgendwie trennen könnte, zwischen Klassen, die für alle Widgets gelten und solchen, die nur für bestimmte verwendet werden können. Das übersteigt aber leider mein Wissen.
Ganz glücklich bin ich nicht mit der Sache, ist ziemlich aufwändig und unübersichtlich. Aber eine bessere Lösung mit vorhandenen Mitteln fällt mir momentan nicht ein. Vorschläge daher sehr willkommen.
Die Liste der Klassen ist sicher unvollständig. Mir fällt spontan ein: "transparent" und "half-transparent", eine meiner jüngeren Entdeckungen (https://forum.fhem.de/index.php/topic,62586.msg540387.html#msg540387 (https://forum.fhem.de/index.php/topic,62586.msg540387.html#msg540387)).
Das beste Überblickswissen hierzu hat gewiss setstate. Eigentlich braucht er nur die Namen zu liefern. Was dahinter steckt, findet man meist über die Suchfunktion heraus. Die Doku steckt derzeit quasi im Forum. Insofern wäre der Aufwand für setstate überschaubar, und das ist ja gerade das Geniale an diesem Projekt.
Es ist auch gut, dass bei dieser Gelegenheit systematisch gecheckt wird, ob die Klassen für alle Widgets gelten (abgesehen von Fällen, wo dies nicht möglich bzw. sinnvoll ist). Vor meinem geistigen Auge steht eine Tabelle css_Klassen vs. Widgets. Vielleicht kann man die Tabelle mit Filtern versehen und damit überschaubar halten. Dazu kenne ich mich in HTML aber leider zu wenig aus.
Es steht natürlich jedem frei, die Vorlage selbst zu ändern ;)
Eine Tabelle "css-Klasse vs. Widget" wäre natürlich super, muss aber leider händisch gewartet werden. Und je mehr zu warten ist, desto weniger wird's gemacht befürchte ich.
Könntest Du mal bitte checken, warum die CSS-Klasse "mini" so komisch angezeigt wird?
Ich kann irgendwie das Problem nicht finden.
->https://wiki.fhem.de/wiki/FTUI_Widget_Level
Weil's die Klasse "horizontal" nicht gibt. Sollte ich eine Fehlerbehandlung einführen ;)
Verwende bitte {{FTUI Klasse|...}} nicht {{FTUI Klassen|...}}. Also ohne "N". Ist in der Dokumentation zur Vorlage noch falsch.
Ah ok. Ist mir garnicht aufgefallen.
Vielen Dank.
Ist es auch möglich, dass der Klassenname, der da -falsch- angegeben wurde, trotzdem da steht?
Im Moment steht das mit bei der Klasse mini drin.
Ich hätt's probiert, sieht aber leider nicht so aus. Muss dem morgen mal nachgehen, da habe ich mein Test-Wiki zur Verfügung.
Ok, ich füg dann aber schonmal die Klasse hinzu.
Zitat von: Thyraz am 08 Februar 2017, 10:20:55
Das macht sich ja echt schon.
Toll wie die Community das schnell in die Hand genommen hat und setstate ist sicher auch froh in dem Bereich entlastet zu sein. :)
Habe auchmal einen Wiki Account beantragt.
Musst du nicht, ich kann da liefern. ;)
@drhirn Es gibt noch data-load, welches ein div mit dem Content einer HTML Datei füllen kann.
Entweder du trägst das noch nach, oder ich versuche mich mal in die Wiki Bedienung reinzuarbeiten wenn mein Account da ist.
Damit kann man z.B. über Buttons den Inhalt eines Divs auf der Seite austauschen,
oder ganze Seiten tauschen um eben eine Tabbar ähnlich Pagetab zu realisieren.
So könnte das in der index.html aussehen:
<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="css/fhem-tablet-ui.css" />
<link rel="stylesheet" href="lib/font-awesome.min.css" />
<link rel="stylesheet" href="lib/jquery.toast.min.css" />
<script src="lib/jquery.min.js" defer></script>
<script src="lib/jquery.toast.min.js" defer></script>
<script src="js/fhem-tablet-ui.min.js" defer></script>
</head>
<body>
<div id="panel">
<div class="page" id="content-1"></div>
<div class="page" id="content-2"></div>
</div>
<div id="menu">
<div class="tab-bar" >
<div class="tab-link" >
<div data-type="link"
data-load="#content-1"
data-url="#content_1.html"
data-icon=""
data-color="#dbdbdb"
data-active-color="#419aff"
data-active-pattern=".*#content_1.html">
Link 1
</div>
</div>
<div class="tab-link" >
<div data-type="link"
data-load="div#content-2"
data-url="#content_2.html"
data-icon=""
data-color="#dbdbdb"
data-active-color="#419aff"
data-active-pattern=".*#content_2.html">
Link 2
</div>
</div>
</div>
</div>
</body>
</html>
Und so content_1.html und content_2.html:
content1.html:
<html>
<body>
<div class="page" id="content-1">
<div id="panel">
<!-- Start of content -->
Content 1
<!-- End of content -->
</div>
</div>
</body>
</html>
content2.html:
<html>
<body>
<div class="page" id="content-2">
<div id="panel">
<!-- Start of content -->
Content 2
<!-- End of content -->
</div>
</div>
</body>
</html>
So sieht das dann z.B. bei mir als Tabbar aus:
Echt schönes Design. Magst du es im Demo Thema einmal vorstellen und uns teilhaben? ;)
Hatte ich die Tage sowieso vor. ;)
Muss nur noch ein paar Sachen fertig basteln.
Faszinierend wie schnell das in der Community passiert - Die Kooperation, Begeisterung under der Schwung ist klasse!
Würde es Sinn machen bei jedem Widget auf der Seite noch zu vermerken welcher Versionsstand dokumentiert wurde, wenn sich mit neuen Versionen etwas ändert?
Sinn auf alle Fälle, aber das müsste dann jemand auch aktualisieren, wenn sich sonst nichts geändert hat, also alle Widget Seiten überarbeiten, wenn es ein Update gab.
Ich würde vielleicht eher den Weg gehen, die Widgets, die nicht mehr kompatibel sind, so wie WeekProfile, entsprechend zu markieren.
Weil ich grad gesehen habe, dass Standarduser am Slider-Widget dran ist, ich habe gestern noch mit dem Input-Widget angefangen.
Ich war auch etwas erschrocken. Wir müssen uns besser abstimmen - jetzt, wo die leichten Widgets fast alle weg sind ;D
https://wiki.fhem.de/wiki/FTUI_Widget_Slider fertig.
Und wie ich gesehen habe ist drhirn auch schon soweit:
https://wiki.fhem.de/wiki/FTUI_Widget_Input
Ich würde mir dann gleich mal noch die Checkbox reservieren.
Ja, hehe :D
Ich werde mir dann "Label" zur Brust nehmen. Könnte aber etwas länger dauern, befürchte, ich bin die nächsten Tage computerlos :'(
Bin ja übrigens gespannt, wann das erste Widget von den anderen kommt, die so begeistert von der Idee waren ;)
Zitat von: Standarduser am 08 Februar 2017, 19:13:13
Ist es auch möglich, dass der Klassenname, der da -falsch- angegeben wurde, trotzdem da steht?
Im Moment steht das mit bei der Klasse mini drin.
Ist erledigt.
In der linken Zelle steht jetzt der fehlerhafte Klassenname, in der rechten "Fehler: Klasse ist nicht vorhanden".
Bunt schreiben geht leider nicht.
Zitat von: drhirn am 09 Februar 2017, 09:42:33
Ist erledigt.
In der linken Zelle steht jetzt der fehlerhafte Klassenname, in der rechten "Fehler: Klasse ist nicht vorhanden".
Bunt schreiben geht leider nicht.
Trotzdem super, danke!
Zitat von: drhirn am 09 Februar 2017, 09:33:56
Bin ja übrigens gespannt, wann das erste Widget von den anderen kommt, die so begeistert von der Idee waren ;)
Vielleicht sollten wir uns den Badge "FTUI Doku-Team" verpassen, damit die anderen vor Ehrfurcht erstarren und vor Angst einfach loslegen ;D
Zitat von: Standarduser am 09 Februar 2017, 09:55:38
Vielleicht sollten wir uns den Badge "FTUI Doku-Team" verpassen, damit die anderen vor Ehrfurcht erstarren und vor Angst einfach loslegen ;D
Ich hab's nicht so mit Titeln und Auszeichnungen ;)
So ich habe einen Wiki-Zugang beantragt und für den generellen Aufbau / CSS ROW CEL VBOX etc. / etwas vorbereitet. Ich werde einen Teil erstellen und auch das Vorhandene nutzen. Sollte es Zustimmung finden, werde ich den Rest erweitern.
Zitat von: drhirn am 09 Februar 2017, 09:32:40
Ja, hehe :D
Ich werde mir dann "Label" zur Brust nehmen. Könnte aber etwas länger dauern, befürchte, ich bin die nächsten Tage computerlos :'(
Ich hatte die Woche leider noch keine Zeit dafür.
Da ihr zwei ja wohl eine Battle und mehr Zeit habt, warte ich jetzt erst einmal ab.
Kein Battle, keine Sorge. Bin mir sicher, Standarduser würde sich genau so freuen, wie ich, wenn andere auch einsteigen.
Ich habe keine Sorge.
Es war eher die Reaktion auf eure Seitenhiebe und die Übernahme der Doku von dem Widget Label.
Ach was, das darfst Du nicht falsch verstehen.
Hier wird niemand wegen irgendwas von der Seite angemacht.
Wir sehen das eher sportlich, also nix für ungut ;)
@bm7777: Nicht verunsichern lassen, es ist auch Teil des Wikikonzeptes, das es manchmal etwas chaotisch ist. Ich war vor einiger Zeit auch erstmal erschreckt als ich sah, dass der EIntrag zu meinem TelegramBot-Modul deutlich verändert und erweitert worden war. Inzwischen bin ich aber froh um jeden der etwas auch im Wiki einträgt und somit der community hilft.
Zitat von: drhirn am 09 Februar 2017, 09:33:56
Bin ja übrigens gespannt, wann das erste Widget von den anderen kommt, die so begeistert von der Idee waren ;)
Ich habe jetzt meine Account erhalten und muss mich orientieren, wie man einen Wiki schreibt. Als Newbee wird man ja ausdrücklich aufgefordert, erst zu lesen und dann zu klicken ;)
Wahrscheinlich ist man mit den existierenden Vorlagen schnell am Ziel.
Außerdem weiß ich noch nicht, welcher Editor für meine Zwecke geeignet ist (hat jemand einen Tip?).
Auf jeden Fall kommt von mir etwas. Inhaltlich ist ein Beitrag für die Rubrik "Sonderlösungen" ("Zeitschaltung eines Buttons") ja schon fertig, das war übrigens einer der ersten. ;)
Gibt es eine Einstiegsseite mit einer Übersicht zu den schon erstellten neuen Widget-Dokus? Dort könnte man ja seinen Claim abstecken, damit nicht zwei Leute an der selben Sache arbeiten.
Ich hätte auch nichts dagegen, wenn man in der Doku ganz konkret offene Punkte vermerkt ("Tbd"). Das wird sich dann bestimmt schnell klären.
Haben wir schon eine generelle Übereinkunft, dass jeder ohne Rückfrage Änderungen in der Doku vornehmen kann (insbes. auch kleine Schreib- und Formatierungsfehler)? Und sollte man das dann in der Änderungshistorie oder sonstwo beschreiben?
Tja, der Einstieg ins MediaWiki-Editieren ist etwas ungewohnt. Aber man hat das schnell intus, wenn man sich ein paar grundlegende Formatierungsweisen merkt.
Ich schau immer da nach, wenn mir wieder mal was entfallen ist: https://www.mediawiki.org/wiki/Help:Contents (https://www.mediawiki.org/wiki/Help:Contents)
Wenn's Fragen gibt, die dort nicht beantwortet werden, helfe ich gerne sofern ich kann.
Editor verwende ich den Wiki-internen. Das geht gut.
Grundsätzlich ist aber ein Wiki dazu da, dass jeder schreibt, korrigiert, ergänzt. Wenn man sich trotzdem nicht drüber traut, gibt es für jede Seite eine "Diskussionsseite" (zu finden links oben). Dort kann eine geplante Änderung angemerkt werden.
Ist aber alles nicht so schlimm, jede Seite kann mit einem Klick auf eine vorherige Version wieder hergestellt werden.
Vor dem Absenden einer Änderung, wäre es natürlich wünschenswert, wenn das Input-Feld "Zusammenfassung" ausgefüllt wird.
Im ersten Beitrag dieses Threads war eigentlich geplant, festzuhalten, wer an was arbeitet und was zu tun ist. Könnten wir wieder aufgreifen.
Habe mal das Label Widget (https://wiki.fhem.de/wiki/FTUI_Widget_Label) online gestellt. Bin aber leider nicht ganz fertig geworden und komme wahrscheinlich erst nächste Woche wieder dazu. Wer möchte, darf also gerne ;)
So, zurück aus der Internetdiaspora.
Hui, da hat sich ja Einiges getan im Wiki. Respekt, Jungs.
Kurze Frage:
Gibt es irgendwo eine "Assign-List", auf der man erkennen kann, wer an welchem Wiki-Eintrag arbeitet? Ich muss gestehen, dass ich die letzten 8 Seiten nur überflogen habe, aber so direkt rauslesen, welche noch nicht veröffentlichten Seiten bereits vergeben sind konnte ich nicht...
Fall nichts entegenspricht, würde ich mich über "Spinner" hermachen. Scheint noch nicht vergeben, oder?
Zitat von: tomster am 09 Februar 2017, 15:20:50
Gibt es irgendwo eine "Assign-List", auf der man erkennen kann, wer an welchem Wiki-Eintrag arbeitet? Ich muss gestehen, dass ich die letzten 8 Seiten nur überflogen habe, aber so direkt rauslesen, welche noch nicht veröffentlichten Seiten bereits vergeben sind konnte ich nicht...
Am einfachsten ist's, wenn du dir direkt auf der Tablet UI Seite (https://wiki.fhem.de/wiki/FHEM_Tablet_UI#Integrierte_Widgets) die Links zu den Widgets ansiehst. Ein rote Link sagt, die Seite gibt's noch nicht. Ein blauer, dass die Info noch von einer externen Seite übernommen werden muss. Die grünen musst du dir genauer ansehen. Verlinken sie auf eine eigene Seite ist's gut. Verlinken sie noch auf die alte Beschreibung direkt auf der Tablet UI-Seite, müssen die auch noch gemacht werden.
ZitatFall nichts entegenspricht, würde ich mich über "Spinner" hermachen. Scheint noch nicht vergeben, oder?
Spricht nichts dagegen. Danke!
Zitat von: drhirn am 09 Februar 2017, 15:54:02
Am einfachsten ist's, wenn du dir direkt auf der Tablet UI Seite (https://wiki.fhem.de/wiki/FHEM_Tablet_UI#Integrierte_Widgets) die Links zu den Widgets ansiehst. Ein rote Link sagt, die Seite gibt's noch nicht. Ein blauer, dass die Info noch von einer externen Seite übernommen werden muss. Die grünen musst du dir genauer ansehen. Verlinken sie auf eine eigene Seite ist's gut. Verlinken sie noch auf die alte Beschreibung direkt auf der Tablet UI-Seite, müssen die auch noch gemacht werden.
Da hab ich mich mißverständlich ausgedrückt. Das oben Beschriebene ist mir auch schon aufgefallen. Es könnte jedoch sein, dass Jemandem ein Widget zugeordnet ist, und der noch gar nicht angefangen hat... Wollte nur vermeiden, dass man sich Arbeit 2 Mal macht ;-)
Spinner_V0.1 setht online
Zitat von: tomster am 09 Februar 2017, 16:19:33
Spinner_V0.1 setht online
Eine Verlinkung zur Demo Seite wäre nicht schlecht.
http://knowthelist.github.io/fhem/tablet/demo_spinner.html
Zitat von: tomster am 09 Februar 2017, 16:19:33
Da hab ich mich mißverständlich ausgedrückt. Das oben Beschriebene ist mir auch schon aufgefallen. Es könnte jedoch sein, dass Jemandem ein Widget zugeordnet ist, und der noch gar nicht angefangen hat... Wollte nur vermeiden, dass man sich Arbeit 2 Mal macht ;-)
Das haben wir bisher im ersten Post dieses Threads gemacht.
Zitat
Spinner_V0.1 setht online
Super!
Zitat von: TWART016 am 09 Februar 2017, 16:22:08
Eine Verlinkung zur Demo Seite wäre nicht schlecht.
http://knowthelist.github.io/fhem/tablet/demo_spinner.html
Done!
Wobei's eigentlich fast sinnvoller wäre, ein paar Beispiele direkt auf der Wiki-Seite darzulegen. Inkl. Bilder. setstate erlaubt uns sicher, seine Beispiele auszuleihen ;)
Zitat von: drhirn am 09 Februar 2017, 16:40:19
Wobei's eigentlich fast sinnvoller wäre, ein paar Beispiele direkt auf der Wiki-Seite darzulegen. Inkl. Bilder. setstate erlaubt uns sicher, seine Beispiele auszuleihen ;)
Touché.. War ich gerade zu faul, reich ich aber die Tage nach.
So, jetzt habe ich mich als Wiki-Neuling einigermaßen orientiert und auch schon etwas korrekturgelesen.
Lt. Seite 1 ist "weather" noch nicht vergeben. Da kenne ich mich etwas aus und könnte das übernehmen.
Zitat von: Ulm32b am 09 Februar 2017, 14:10:31
Gibt es eine Einstiegsseite mit einer Übersicht zu den schon erstellten neuen Widget-Dokus? Dort könnte man ja seinen Claim abstecken, damit nicht zwei Leute an der selben Sache arbeiten.
Ich hätte auch nichts dagegen, wenn man in der Doku ganz konkret offene Punkte vermerkt ("Tbd"). Das wird sich dann bestimmt schnell klären.
Zitat von: drhirn am 09 Februar 2017, 14:22:26
Im ersten Beitrag dieses Threads war eigentlich geplant, festzuhalten, wer an was arbeitet und was zu tun ist. Könnten wir wieder aufgreifen.
Zitat von: tomster am 09 Februar 2017, 15:20:50
Kurze Frage:
Gibt es irgendwo eine "Assign-List", auf der man erkennen kann, wer an welchem Wiki-Eintrag arbeitet? Ich muss gestehen, dass ich die letzten 8 Seiten nur überflogen habe, aber so direkt rauslesen, welche noch nicht veröffentlichten Seiten bereits vergeben sind konnte ich nicht...
Ich versuche, alles Relevante immer im ersten Post dieses Threads mitzuschreiben. Wenn sich jemand meldet, der sich um eine Seite kümmern möchte, schreibe ich das dahinter. Ist eine Seite fertig, so steht das eigentlich auch da. Also am besten, Ihr schaut vor jeder Aktion nochmal in den ersten Post, damit sich keiner die Mühe umsonst macht.
Machmal bin ich aber auch offline (selten, aber passiert ;) ) Dann vielleicht nochmal die letzten Posts anschauen, ob sich irgendwer schon für ein Widget interessiert.
Zitat von: drhirn am 09 Februar 2017, 16:40:19
Wobei's eigentlich fast sinnvoller wäre, ein paar Beispiele direkt auf der Wiki-Seite darzulegen. Inkl. Bilder. setstate erlaubt uns sicher, seine Beispiele auszuleihen ;)
Das Ziel sollte sein, eine komplett unabhängige Doku zu erstellen. Bisher haben wir alle Beispiele direkt in die Wiki-Seiten integriert und ich fände es super, wenn da alle mitziehen würden.
Zitat von: Ulm32b am 09 Februar 2017, 14:10:31
Haben wir schon eine generelle Übereinkunft, dass jeder ohne Rückfrage Änderungen in der Doku vornehmen kann (insbes. auch kleine Schreib- und Formatierungsfehler)? Und sollte man das dann in der Änderungshistorie oder sonstwo beschreiben?
Bitte erstmal nicht dazwischen funken, aber gern auf Fehler hinweisen. Ich glaube, wir lernen ja hier alle noch dazu, somit ist der Lerneffekt für die betroffenen auch besser. Wir wollen aber natürlich schnellstmöglich in den normalen Wiki-Betrieb übergehen, wo dann jeder auch an jeder Seite mitarbeiten darf.
Zitat von: Ulm32b am 09 Februar 2017, 17:17:07
Lt. Seite 1 ist "weather" noch nicht vergeben. Da kenne ich mich etwas aus und könnte das übernehmen.
Zitat von: tomster am 09 Februar 2017, 15:20:50
Fall nichts entegenspricht, würde ich mich über "Spinner" hermachen. Scheint noch nicht vergeben, oder?
Ist notiert -> 1. Post im Thread
Noch ein paar generelle Anmerkungen zur Vorgehensweise:
Die Tablet-UI Hauptseite im Wiki besteht momentan (vereinfacht gesagt) aus:
- Einleitung
- Auflistung aller Widgets
- Konfiguration aller Widgets
- Beispiele zu allen Widgets
Wenn jemand eine Seite erstellt hat, dann bitte das entsprechende Widget (Konfiguration und Beispiele) aus der Hauptseite löschen und den Link in der Widget-Liste auf die neue Seite umlenken. So gibt es keine doppelte Doku. Bei der Zusammenfassung der Änderung schreibt Ihr dann bitte hinein, dass die Doku für dieses Widget auf eine neue Seite ausgelagert wurde.
Tipp: Manchmal sind die Beispiele von der Hauptseite besser, als die auf Github.
Achja, alles was im ersten Post noch nicht als "done" markiert ist, muss noch erledigt werden ;D
Zitat von: drhirn am 09 Februar 2017, 09:42:33
Ist erledigt.
In der linken Zelle steht jetzt der fehlerhafte Klassenname, in der rechten "Fehler: Klasse ist nicht vorhanden".
Bunt schreiben geht leider nicht.
Funktioniert echt gut ;)
Zitat
Bin ja übrigens gespannt, wann das erste Widget von den anderen kommt, die so begeistert von der Idee waren ;)
Zitat
Vielleicht sollten wir uns den Badge "FTUI Doku-Team" verpassen, damit die anderen vor Ehrfurcht erstarren und vor Angst einfach loslegen
Bin weder ehrfürchtig noch ängstlich, vielleicht etwas sorgfältig. :D
Bitte schön, mein erster Wiki: https://wiki.fhem.de/wiki/FTUI_Widget_Weather (https://wiki.fhem.de/wiki/FTUI_Widget_Weather)
Etwas Hilfe brauche ich noch: Wie klappt man den etwas umfangreichen Code ein?
Übringens: Geht es euch auch so? Doku schreiben finde ich gerade spannender als als meine FTUI-Seite zu optimieren. ;D
Zitat von: Ulm32b am 10 Februar 2017, 04:53:13
Bitte schön, mein erster Wiki: https://wiki.fhem.de/wiki/FTUI_Widget_Weather (https://wiki.fhem.de/wiki/FTUI_Widget_Weather)
Sieht gut aus! Zum Thema "Bitte prüfen" hätte ich folgendes beizutragen:
Die Einleitung zur Seite sollte so aussehen: Das [[{{PAGENAME}}|Widget Weather]] ist ein Widget für [[FHEM Tablet UI]]... Das hat aber All-Ex schon hinzugefügt.
Bitte nicht in der Attribute-Tabelle in der Spalte "Standard-Wert" verlinken, das könnte zu Missverständnissen führen. Die links stehen doch schon in der Beschreibung und weiter oben.
Könntest Du vielleicht 1 bis 2 Sätze zu den Beispielen hinzufügen, was da zusehen ist und wie das funktioniert, und den Beispielen richtige Namen verpassen? Ich würde die vielleicht "Einfaches Symbol mit min- und max-Temperatur", sowie "Detaillierte Wetteranzeige mit Vorhersage" nennen (oder so ähnlich). Ich fände es auch schön, wenn der Code richtig eingerückt und das Bild darüber, statt darunter wäre.
Kopiervorlage:
<li data-row="1" data-col="1" data-sizex="4" data-sizey="4">
<div class="sheet">
<div class="row">
<div class="col-1-3">
<div data-type="label" class="cell top-space narrow">morgens</div>
<div data-type="weather" data-device="Proplanta" data-get="fc0_weatherMorningIcon" data-imageset="kleinklima" class="cell"></div>
<div data-type="label" data-device="Proplanta" data-get="fc0_weatherMorning" class="cell top-narrow"></div>
<div data-type="label" data-device="Proplanta" data-get="fc0_temp06" data-unit="%B0C%0A" class="cell bigger" data-limits='[-50,0]' data-colors='["#5858FA","white"]'></div>
</div>
<div class="col-1-3">
<div data-type="label" class="cell top-space narrow">mittags</div>
<div data-type="weather" data-device="Proplanta" data-get="fc0_weatherDayIcon" data-imageset="kleinklima" class="cell"></div>
<div data-type="label" data-device="Proplanta" data-get="fc0_weatherDay" class="cell top-narrow"></div>
<div data-type="label" data-device="Proplanta" data-get="fc0_temp12" data-unit="%B0C%0A" class="cell bigger" data-limits='[-50,0]' data-colors='["#5858FA","white"]'></div>
</div>
<div class="col-1-3">
<div data-type="label" class="cell top-space narrow">abends</div>
<div data-type="weather" data-device="Proplanta" data-get="fc0_weatherEveningIcon" data-imageset="kleinklima" class="cell"></div>
<div data-type="label" data-device="Proplanta" data-get="fc0_weatherEvening" class="cell top-narrow"></div>
<div data-type="label" data-device="Proplanta" data-get="fc0_temp18" data-unit="%B0C%0A" class="cell bigger" data-limits='[-50,0]' data-colors='["#5858FA","white"]'></div>
</div>
</div>
</div>
<div class="container top-space-3x">
<div data-type="label" class="cell bigger darker">Morgen</div>
</div>
<div class="sheet">
<div class="row">
<div class="col-1-3">
<div data-type="label" class="cell top-space darker">morgens</div>
<div data-type="weather" data-device="Proplanta" data-get="fc1_weatherMorningIcon" data-imageset="kleinklima" class="cell half-transparent"></div>
<div data-type="label" data-device="Proplanta" data-get="fc1_weatherMorning" class="cell top-narrow darker"></div>
<div data-type="label" data-device="Proplanta" data-get="fc1_temp06" data-unit="%B0C%0A" class="cell bigger" data-limits='[-50,0]' data-colors='["#a3a3fc","grey"]'></div>
</div>
<div class="col-1-3">
<div data-type="label" class="cell top-space darker">mittags</div>
<div data-type="weather" data-device="Proplanta" data-get="fc1_weatherDayIcon" data-imageset="kleinklima" class="cell half-transparent"></div>
<div data-type="label" data-device="Proplanta" data-get="fc1_weatherDay" class="cell top-narrow darker"></div>
<div data-type="label" data-device="Proplanta" data-get="fc1_temp12" data-unit="%B0C%0A" class="cell bigger" data-limits='[-50,0]' data-colors='["#a3a3fc","grey"]'></div>
</div>
<div class="col-1-3">
<div data-type="label" class="cell top-space darker">abends</div>
<div data-type="weather" data-device="Proplanta" data-get="fc1_weatherEveningIcon" data-imageset="kleinklima" class="cell half-transparent"></div>
<div data-type="label" data-device="Proplanta" data-get="fc1_weatherEvening" class="cell top-narrow darker"></div>
<div data-type="label" data-device="Proplanta" data-get="fc1_temp18" data-unit="%B0C%0A" class="cell bigger" data-limits='[-50,0]' data-colors='["#a3a3fc","grey"]'></div>
</div>
</div>
</div>
</li>Bitte auch nicht vergessen, Weather aus der Hauptseite zu entfernen und den Link in der Liste umzulenken. Dazu hatte ich hier (https://forum.fhem.de/index.php/topic,66578.msg580933.html#msg580933) schonmal etwas geschrieben.
Zitat von: Ulm32b am 10 Februar 2017, 04:53:13
Etwas Hilfe brauche ich noch: Wie klappt man den etwas umfangreichen Code ein?
Bin ich garnicht so der Fan, aber drhirn hat das hier schonmal verwendet: https://wiki.fhem.de/wiki/FTUI_Widget_Link
Zitat von: Ulm32b am 10 Februar 2017, 04:53:13
Übringens: Geht es euch auch so: Doku schreiben finde ich gerade spannender als als meine FTUI-Seite zu optimieren. ;D
Absolut! Ich hab in den letzten Tagen garnichts mehr an meiner FTUI gemacht, außer den Versuch zu starten, alle Widgets mal auf eine Seite zu packen - da arbeite ich aber noch dran ;)
BTW: was sind das eigentlich für Uhrzeiten, zu denen Du aktiv bist? ;D
Ansonsten möchte ich mal allen, die sich hier beteiligen, meinen Dank aussprechen. Ich hatte eingangs schon die befürchtung, dass das 'ne Nullnummer wird. Aber das hat ja ganz schön Fahrt aufgenommen und das Ergebnis kann sich echt schon sehen lassen.
Das mit dem Ein-/Ausklappen sehe auch auch etwas skeptisch. Es ist aber da praktisch, wo lange Code-Beispiele sind, die eigentlich nicht auf den ersten Blick ersichtlich sein müssen. Und v.a. dann, wenn durch viele Beispiele die Seite zu lang wird.
Ich hab's da eigentlich nur als Demo verwendet, um zu zeigen, dass es gehen würde.
Wie's geht ist hier erklärt: https://www.mediawiki.org/wiki/Manual:Collapsible_elements (https://www.mediawiki.org/wiki/Manual:Collapsible_elements)
Zitat von: Ulm32b am 10 Februar 2017, 04:53:13
Bitte schön, mein erster Wiki: https://wiki.fhem.de/wiki/FTUI_Widget_Weather (https://wiki.fhem.de/wiki/FTUI_Widget_Weather)
Ich hab mir mal erlaubt, den fehlerhaften Link zu korrigieren. Ich denke, Du kannst das TODO nun entfernen, wenn Du magst, das ist nämlich schon recht ordentlich geworden.
Und sei nicht so zögerlich, was die Hauptseite betrifft. ;)
Wirf das Beispiel, bzw. die noch verbliebene Überschrift mit dem Link auf die neue Seite komplett raus und dreh' den Link in der Auflistung der Widgets direkt auf die neue Seite. Wenn wir durch sind, soll da nichts Widget-Spezifisches mehr stehen, sondern nur noch eine (überarbeitete) Auflistung, die auf die jeweiligen Widget-Seiten verlinkt.
Zitat von: Standarduser am 10 Februar 2017, 08:29:42
Sieht gut aus! Zum Thema "Bitte prüfen" hätte ich folgendes beizutragen:
Die Einleitung zur Seite sollte so aussehen: Das [[{{PAGENAME}}|Widget Weather]] ist ein Widget für [[FHEM Tablet UI]]... Das hat aber All-Ex schon hinzugefügt.
Wurde ja schon erledigt. Danke.
ZitatBitte nicht in der Attribute-Tabelle in der Spalte "Standard-Wert" verlinken, das könnte zu Missverständnissen führen. Die links stehen doch schon in der Beschreibung und weiter oben.
Done.
ZitatKönntest Du vielleicht 1 bis 2 Sätze zu den Beispielen hinzufügen, was da zusehen ist und wie das funktioniert, und den Beispielen richtige Namen verpassen? Ich würde die vielleicht "Einfaches Symbol mit min- und max-Temperatur", sowie "Detaillierte Wetteranzeige mit Vorhersage" nennen (oder so ähnlich). Ich fände es auch schön, wenn der Code richtig eingerückt und das Bild darüber, statt darunter wäre.
Done.
Bei der Gelegenheit:
Frage: Gibt es einen empfehlenswerten HTML-Editor für kein oder wenig Geld, der solche Einrückungen selbständig vornimmt und z.B. mitzählt, ob alle <div>s wieder geschlossen wurden? Würde mir und wohl manch anderem helfen. Derzeit nutze ich notepad++; wurde mir von unserem Oberinformatiker empfohlen; ist mir etwas zu unübersichtlich.
ZitatBitte auch nicht vergessen, Weather aus der Hauptseite zu entfernen und den Link in der Liste umzulenken. Dazu hatte ich hier (https://forum.fhem.de/index.php/topic,66578.msg580933.html#msg580933) schonmal etwas geschrieben.
und
ZitatWirf das Beispiel, bzw. die noch verbliebene Überschrift mit dem Link auf die neue Seite komplett raus und dreh' den Link in der Auflistung der Widgets direkt auf die neue Seite. Wenn wir durch sind, soll da nichts Widget-Spezifisches mehr stehen, sondern nur noch eine (überarbeitete) Auflistung, die auf die jeweiligen Widget-Seiten verlinkt.
o.k.
Mach ich noch.
Ein altes Bild ist nun nicht mehr im Wiki verlinkt. Wird das dann irgendwann automatisch gelöscht? Ich habe zwar manches über Löschanträge gefunden, aber nichts zu diesem einfachen Vorgang.
Zitat[Einklappen:] Bin ich garnicht so der Fan, aber drhirn hat das hier schonmal verwendet: https://wiki.fhem.de/wiki/FTUI_Widget_Link
Ja, stimmt. Ich hatte das vorher auch wahrgenommen, dann aber (um die Zeit :D) nicht mehr wiedergefunden.
In diesem konkreten Fall ist m.E. das Ausblenden des Codes im Interesse der Übersichtlichkeit sinnvoll.
ZitatBTW: was sind das eigentlich für Uhrzeiten, zu denen Du aktiv bist? ;D
Das ist wie in ganz alten Zeiten:
https://de.wikipedia.org/w/index.php?title=Datei:Commodore_PET2001_Startscreen_animated.gif&filetimestamp=20090317105613& (https://de.wikipedia.org/w/index.php?title=Datei:Commodore_PET2001_Startscreen_animated.gif&filetimestamp=20090317105613&)
Man sollte es ja nicht übertreiben, aber so manchmal ... ;D
ZitatIch hatte eingangs schon die befürchtung, dass das 'ne Nullnummer wird. Aber das hat ja ganz schön Fahrt aufgenommen und das Ergebnis kann sich echt schon sehen lassen.
Nichts ist mächtiger als eine Idee, deren Zeit gekommen ist.
Zitat von: Ulm32b am 10 Februar 2017, 16:01:29
Bei der Gelegenheit: Frage: Gibt es einen empfehlenswerten HTML-Editor für kein oder wenig Geld, der solche Einrückungen selbständig vornimmt und z.B. mitzählt, ob alle <div>s wieder geschlossen wurden? Würde mir und wohl manch anderem helfen. Derzeit nutze ich notepad++; wurde mir von unserem Oberinformatiker empfohlen; ist mir etwas zu unübersichtlich.
Ich glaube, den perfekten Editor gibt es nicht.
Ich arbeite vornehmlich an einem Mac und verwende eigentlich TextWrangler. Allerdings musste ich irgendwann feststellen, das Coda deutlich besser funktioniert und hab mir das dann gegönnt. Etwas vergleichbares habe ich für Windows noch nicht gefunden und benutze somit auf Arbeit ebenfalls notepad++. Der ist ganz schön hässlich und ich hab relativ viel Zeit in das Styling gesteckt, dafür funktioniert er tadellos. Für mich steht und fällt ein guter Editor mit Blockbearbeitung - das können beide, TextWrangler leider nicht.
Was meinst du mit "Blockbearbeitung"?
Kennst du zufällig eine Funktion in notepad++ wo ich z.B. <div> schreibe und automatisch sofort </div> geschlossen wird?
EDIT: Ahhhh mit MAKRO Funktion :-)
Notepad++ kann das schon. Kann man in den Einstellungen unter Auto Completion einstellen.
Wenn man die richtige "Dokumentsprache" (HTML, Javascript, ...) eingestellt ist und man klickt z.B. auf ein <div> zeigt dir Notepad++ auch an, wo das schließende ist. Aber nicht, ob eines fehlt.
Könnte mir aber gut vorstellen, dass es ein PlugIn dafür gibt.
Ich mag übrigens Notepad++, weil's eben nicht unübersichtlich ist ;)
Blockbearbeitung:
Nimm mal eine Datei mit beliebigem, mehrzeiligen Inhalt. Drück die ALT-Taste (gedrückt halten) und markiere Text über mehrere Zeilen, oder ziehe den Mauszeiger einfach gerade über mehrere Zeilen nach unten. Es erscheint nun ein Cursor über mehrere Zeilen. Und jetzt einfach mal losschreiben.
Tags schließen kann auf alle Fälle Dreamweaver, aber das ist vielleicht etwas oversized für unseren Zweck.
In notepad++ probier mal TextFX -> TextFX Settings -> auto close XHTML tags
Weiß jemand, was beim Label-Widget die Klassen "timestamp", "fixedlabel" und "fixcontent" machen?
Zitat von: drhirn am 10 Februar 2017, 17:59:34
Weiß jemand, was beim Label-Widget die Klassen "timestamp", "fixedlabel" und "fixcontent" machen?
Ja ich ;D
Übrigens,
großartige Arbeit, dir ihr gerade leistet!timestamp: zeige den Zeitstempel des Readings anstatt des Inhaltes
fixedlabel: ändere nicht den HTML-Inhalt. Der ist fest per HTMl Code. Wenn man zum Beispiel über data-limits nur die Farbe ändern möchte
fixcontent: das gleiche wie fixedlabel (ich dachte, dass das vielleicht sprechender ist und will den eher etablieren)
Wär irgendwie schockierend, wenn nicht ;)
Ok, ich lasse fixedlabel weg. Versteh's aber trotzdem noch nicht ganz. Was könnte für ein HTML-Inhalt verändert werden?
Ich schnappe mir mal das Switch-Widget, weil die Checkbox darauf aufbaut.
//Edit: https://wiki.fhem.de/wiki/FTUI_Widget_Switch -> done
Da ich ja mit der Trigger für die ganze Doku war, dachte ich zumindest auch mal ein Widget beizutragen Dabei habe ich mir gleich das einfachste Widget geschnappt, weil ich die Ursprungsversion ja auch selber beigesteuert hatte.
Dabei ist mir aufgefallen, dass es einige Widgets gibt, die so nicht auf der Hauptseite enthalten sind, aber inzwischen im Repository von setstate enthalten sind. Dies ist eins davon:
https://wiki.fhem.de/wiki/FTUI_Widget_Readingsgroup (https://wiki.fhem.de/wiki/FTUI_Widget_Readingsgroup)
Wie immer Kommentare und Änderungen sind erlaubt.
Sieht gut aus. Ein paar Typos sind drin, aber passt schon.
Du hast recht, das Repository enthält wirklich mehr, als bisher dokumentiert ist. Das muss alles noch mit rein.
Ich reservier mal das Progress-Widget
UWZ hätte ich versucht, ich habe da aber keine Erfahrung damit. Und Beispiele zu basteln ist schwierig. Wien ist wettertechnisch eher fad ;)
Neue Doku Wind_direction ist eingecheckt: https://wiki.fhem.de/wiki/FTUI_Widget_Wind_direction
Ging schnell, hatte ich hier gar nicht erst angemeldet. Allerdings ist die Frage data-calm noch offen, das ist auch als Baustelle vermerkt.
Vgl. https://forum.fhem.de/index.php/topic,36122.msg581739.html#msg581739 (https://forum.fhem.de/index.php/topic,36122.msg581739.html#msg581739)
{{Baustelle}} wird eigentlich dafür genutzt, um anderen zu zeigen, dass gerade noch daran gearbeitet wird und nicht zwei Leute gleichzeitig Änderungen vornehmen.
Wenn das Thema für Dich erstmal durch ist, reicht auch das TODO
Zitat von: Standarduser am 11 Februar 2017, 09:16:38
Sieht gut aus. Ein paar Typos sind drin, aber passt schon.
Du hast recht, das Repository enthält wirklich mehr, als bisher dokumentiert ist. Das muss alles noch mit rein.
Wenn es nur ein paar Typos sind, ist das normal bei mir :D - Ich war früher um halb drei nachts auch mal wacher...
Die Typos sind korrigiert und ich habe die FHEM-Teile noch hinzugefügt
Progress ist erledigt. Als nächstes nehme ich mir das Image-Label vor.
==edit==
Ich bräuchte bitte wiedermal eine Erklärung zu einer Klasse. Diesmal percent. Danke!
Zitat von: drhirn am 11 Februar 2017, 17:31:11
Progress ist erledigt. Als nächstes nehme ich mir das Image-Label vor.
==edit==
Ich bräuchte bitte wiedermal eine Erklärung zu einer Klasse. Diesmal percent. Danke!
Nach meinem Verständnis aus dem Code sorgt percent beim widget progress dafür, dass statt dem eigentlichen Zahlen-Wert des Progress bars zwoschen min und max ein Wert in % angezeigt wird (also wenn der absolute wert dem min.wert entspricht wird 0 angezeigt bei Erreichen des Max-Wertes die 100)
Zitat von: viegener am 11 Februar 2017, 18:10:16
Nach meinem Verständnis aus dem Code sorgt percent beim widget progress dafür, dass statt dem eigentlichen Zahlen-Wert des Progress bars zwoschen min und max ein Wert in % angezeigt wird (also wenn der absolute wert dem min.wert entspricht wird 0 angezeigt bei Erreichen des Max-Wertes die 100)
Ok, kapiert. Danke!
Mal überlegen, wie ich das jetzt kurz und knapp formuliere...
Zitat von: drhirn am 11 Februar 2017, 17:31:11
Progress ist erledigt. Als nächstes nehme ich mir das Image-Label vor.
Image-Label? Kannte ich noch garnicht.
Ich brauch mal ein bißchen Abwechslung von den Widgets ;D
Ich hatte mich schon gewundert, dass setstate vergleichsweise still war. Jetzt ist alles klar: 2.6
Nun, so ganz untätig war ich auch nicht. Die Beschreibung der Zeitschaltung ist online: https://wiki.fhem.de/wiki/FTUI_Zeitschaltung (https://wiki.fhem.de/wiki/FTUI_Zeitschaltung)
Dafür habe ich noch einiges herausgefunden und die Anwendung in Bezug auf Push und Switch systematisiert. Links auf Push und Switch sind enthalten. Umgekehrt wäre das wohl auch sinnvoll.
In https://wiki.fhem.de/wiki/FTUI_Widget_Push (https://wiki.fhem.de/wiki/FTUI_Widget_Push) ist seinerseits ein Beispiel für einen Timer enthalten. Ich empfehle, dort den Hinweis der Notwendigkeit von useSetExtensions 1 bei dummy-devices aufzunehmen, um Enttäuschungen und unnötige Anfragen im Forum zu vermeiden.
Danke für den Hinweis. Das füge ich gleich mal mit ein.
Doch noch zwei Hinweise:
1. Du kannst im Wiki ich ohne Unterstriche verlinken. Es muss also nicht [[FTUI_Widget_Push]] sein, sondern es geht auch [[FTUI Widget Push]]
2. Müssten wir nochmal diskutieren: wie benennen wir Seiten, die solche Anwendungen/Beispiele enthalten, wie Du es beschrieben hast? Ich finde da muss noch etwas in den Namen hinein, damit es einheitlich ist. Oder wie seht Ihr das?
//edit: Weiß jemand, warum die Seite der Kategorie "Seiten mit Syntaxhervorhebungsfehlern" hinzugefügt wird? Ich konnte garkeinen Fehler finden.
//edit2: habs gefunden: <source></source> ohne Angabe der Sprache ist der Grund. Hier müsste sonst <pre></pre> verwendet werden.
Genau, den Formatierungsfehler habe ich selbständig :D auch gefunden (und bereits korrigiert), hatte aber auch den Startvorteil, das selbst verbrochen zu haben. Ich hatte mir gedacht, dass HTML bei der FHEM-Def. nicht zutrifft, das rausgenommen, und das sah auch unverdächtig aus. Eine Formatvorlage "FHEM" scheint es nicht zu geben.
Auch die anderen vorgeschlagenen Verbesserungen sind jetzt drin.
Du bist hier übrigens nicht der einzige, der daraus lernt, also Danke, dass Du es mir ersparst, über die selben Steine zu stolpern ;)
Ich schnappe mir mal Simple-Chart und das richtige Chart.
Dafür würde ich die Checkbox wieder freigeben.
Einer geht noch. :P
Ich nehme mir mal playstream vor. Der steht gar nicht in der Liste. Den gibts aber.
Ich habe alle Widgets, die ich im GitHub, bei Nesges und im js-Verzeichnis gefunden habe, auf hier (https://wiki.fhem.de/wiki/FHEM_Tablet_UI#Integrierte_Widgets) aufgelistet. Sind ein paar mehr, als hier auf der ersten Seite stehen.
Image Widget ist erledigt. Mache heute eine Zwangspause.
Zitat von: Standarduser am 11 Februar 2017, 19:30:23
//edit: Weiß jemand, warum die Seite der Kategorie "Seiten mit Syntaxhervorhebungsfehlern" hinzugefügt wird? Ich konnte garkeinen Fehler finden.
//edit2: habs gefunden: <source></source> ohne Angabe der Sprache ist der Grund. Hier müsste sonst <pre></pre> verwendet werden.
Bzw.
<source lang="text">Da gibt's eine Liste der unterstützten Sprachen (https://www.mediawiki.org/wiki/Extension:SyntaxHighlight#Supported_languages)
Ich habe mal die ersten zwei "Klassen-Arten" (https://wiki.fhem.de/wiki/FHEM_Tablet_UI#CSS-Klassen) umgebaut, was das Ein-/Ausklappen betrifft. Und ihr dürft entscheiden, welche Version euch lieber ist.
Zitat von: drhirn am 12 Februar 2017, 11:28:45
Ich habe mal die ersten zwei "Klassen-Arten" (https://wiki.fhem.de/wiki/FHEM_Tablet_UI#CSS-Klassen) umgebaut, was das Ein-/Ausklappen betrifft. Und ihr dürft entscheiden, welche Version euch lieber ist.
Sieht gut aus. Mir gefällt Deine neue Variante besser.
Ich hatte das Einklappen nur eingebaut, weil ich das sonst zu unübersichtlich finde. Und mir kam zeitweise auch der Gedanke, ob das überhaupt notwendig ist, dort alle Klassen aufzulisten. Aber wenn man mal etwas sucht, ist das sicher nicht verkehrt.
Ok, ich ändere bei Gelegenheit den Rest.
Ja, war auch etwas überrascht, dass es so viele sind. Deswegen finde ich die Idee mit dem Ein-/Ausklappen eigentlich ganz gut.
Hab die Liste im ersten Post mal ergänzt.
Simplechart ist erledigt.
Darf gern noch um Bilder und Beispiele ergänzt werden, ich hab das nämlich selber noch nicht verwendet.
Das mache ich gerne. Ist wiederum das einzige, was ich benutze.
Super.
Vielleicht könntest Du bei dieser Gelegenheit auch die bisher noch nicht gestellte Frage beantworten, ob und wie sich das mit logdb verwenden lässt ;)
wenn ich von logdb Ahnung hätte gern. Aber ich benutze bestimmt nur 3% der FHEM Möglichkeiten. Also kann ich das überhaupt nicht beantworten. Sorry.
Playstream ist vorläufig fertig. Die Frage nach get-url (vgl. https://forum.fhem.de/index.php/topic,66956.msg583304.html#msg583304 (https://forum.fhem.de/index.php/topic,66956.msg583304.html#msg583304)) steht noch im Raume.
Ich nehme noch clock und steigere meine Quote. :P
Chart ist drin -> Wochenende ;)
Clock V1.0 ist drin. https://wiki.fhem.de/wiki/FTUI_Widget_Clock (https://wiki.fhem.de/wiki/FTUI_Widget_Clock) (CSS-Klassen ungeprüft eingefügt)
Ich möchte rationalisieren. Wie kann ich möglichst effizient herausfinden, welche CSS-Klassen für ein konkretes Widget funktionieren?
Für das Image-Widget habe ich noch einen Vorschlag: Im Forum kommt immer mal wieder die Frage auf, wie man es anstellt, dass sich das Bild selbständig aktualisiert. Ich habe das so verstanden, dass nocache nicht immer reicht. Der Workaround lautet, der URL einen veränderlichen String mit auf den Weg zu geben, der dann später vom Image-Widget ignoriert wird.
Das könnte man unter Hinweise erklären und vermerken.
Bei mir funktioniert das bspw. folgendermaßen (habe ich abgeguckt):
data-url="http://www.dwd.de/DWD/wetter/radar/radfilm_nrw_akt.gif?_=3455543"
"?_=3455543" ist aber doch unveränderlich, oder? Wie geht denn das?
P.S. @ Standarduser: Der Beitrag zur Zeitschaltung ist unter leicht verändertem Namen schon fertig; in der Liste ist das noch nicht vermerkt.
Zitat von: Ulm32b am 13 Februar 2017, 00:28:31
Für das Image-Widget habe ich noch einen Vorschlag: Im Forum kommt immer mal wieder die Frage auf, wie man es anstellt, dass sich das Bild selbständig aktualisiert. Ich habe das so verstanden, dass nocache nicht immer reicht. Der Workaround lautet, der URL einen veränderlichen String mit auf den Weg zu geben, der dann später vom Image-Widget ignoriert wird.
Das könnte man unter Hinweise erklären und vermerken.
Bei mir funktioniert das bspw. folgendermaßen (habe ich abgeguckt):
data-url="http://www.dwd.de/DWD/wetter/radar/radfilm_nrw_akt.gif?_=3455543"
"?_=3455543" ist aber doch unveränderlich, oder? Wie geht denn das?
P.S. @ Standarduser: Der Beitrag zur Zeitschaltung ist unter leicht verändertem Namen schon fertig; in der Liste ist das noch nicht vermerkt.
mit "nocache" wird die aktuelle Zeit in Sekunden an die URL hinten angefügt. Dadurch entstehen genau dieses ?_=1234567
Und das überlistet dann den Browser-Cache
Zitat von: Ulm32b am 13 Februar 2017, 00:10:35
Ich möchte rationalisieren. Wie kann ich möglichst effizient herausfinden, welche CSS-Klassen für ein konkretes Widget funktionieren?
Gute Frage, die uns wohl nur einer beantworten kann ;)
Ich möchte Eure Aufmerksamkeit gern nochmal auf das Thema lenken, das im Arbeitseifer etwas untergegangen ist:
Zitat von: Standarduser am 11 Februar 2017, 19:30:23
2. Müssten wir nochmal diskutieren: wie benennen wir Seiten, die solche Anwendungen/Beispiele enthalten, wie Du es beschrieben hast? Ich finde da muss noch etwas in den Namen hinein, damit es einheitlich ist. Oder wie seht Ihr das?
Konkret geht es hier um das Beispiel mit der Zeitsteuerung (https://wiki.fhem.de/wiki/FTUI_Zeitschaltung) und Date-Time-Picker (https://wiki.fhem.de/wiki/FTUI_Datetimepicker_fuer_Timer), sowie alle, die noch folgen werden.
Ich wäre dafür, dass wir die zum Beispiel "FTUI_Anwendung_Zeitschaltung" benennen. Wobei das Wort Anwendung auch gerne ersetzt werden darf. Letztlich geht es hier eigentlich nur um die Einheitlichkeit.
Was wäre "Anwendung" z.B.?
Zitat von: drhirn am 13 Februar 2017, 09:26:23
Was wäre "Anwendung" z.B.?
Bisher beschreiben wir ja einfach Widgets, wie sie aussehen und Funktionieren, mit einfachen Beispielen.
"Anwendung" wäre die Kombination mehrerer/verschiedener Widgets zu komplexen Anwendungsszenarien, wie beispielsweise die Verwendung von Push und Switch als Timer (https://wiki.fhem.de/wiki/FTUI_Zeitschaltung).
Was ich auch vorhabe: meine Umsetzung/Visualisierung meines Multiroom-Audio-Systems zu dokumentieren, also die Kombination aus Push-Elementen für die Steuerung, Spinner für die Lautstärke, Image für Cover, Switch für die Verlinkung, Select für Playlist-Auswahl, Medialist für Playlist-Content.
Das passt ja nicht in die Dokumentation von irgendwelchen Widgets sondern ist ja schon ein Stück weit mehr. Bisher hatte ich dafür den Begriff "komplexe Beispiele" genutzt, um das zu umschreiben. Und jetzt müssen wir eine richtige Bezeichnung dafür finden, damit wir auch sowas sinnvoll ins Wiki integrieren können.
Hmm, eigentlich egal, wie wir die Seiten nennen. Solange die richtige Kategorie dabei steht.
Ich habe allerdings deinen Post falsch verstanden. Dachte, das Wort "Anwendung" war als Variable gedacht.
Wenn du aber auf der Suche nach Alternativen zum Wort "Anwendung" bist, werfe ich mal "Beispiel" in den Raum.
Ich könnte mit beidem gut leben, egal ob Anwendung oder Beispiel.
Wäre nur schön, wenn wir das einheitlich gestalten und uns auf eins einigen könnten.
Die Wiki-Seite mit der Zeitschaltung würde dann demzufolge FTUI Beispiel Zeitschaltung heißen, statt wie bisher FTUI Zeitschaltung
Entscheide einfach du, wie sie heißen sollen.
Ok, ich warte mal noch, ob Ulm32b oder setstate eine Meinung dazu haben, sonst würde ich das einfach anpassen.
Rotor Widget (https://wiki.fhem.de/wiki/FTUI_Widget_Rotor) ist erledigt. Hab allerdings noch ein kleines Problem mit den Bildchen.
Ich riskier mal das Thermostat-Widget.
Traut sich eigentlich jemand über das Kapitel "Installation" drüber? Ich denke, das sollte genauer beschreiben werden.
Installation ist echt ein schwieriges Thema.
Es fehlt in der Einleitung auch noch einiges zur grundsätzlichen Funktionsweise, wie FTUI überhaupt funktioniert und wie sich so eine Oberfläche zusammensetzt. Daran wollte ich mich eigentlich mal machen, aber vorher will ich das CHart noch etwas verfeinern: DBLog vs. FileLog, weitere Beispiele
Ok.
Beim Chart kann ich dich leider nicht unterstützen. Habe das nicht in Verwendung.
Dafür ist das Thermostat-Widget (https://wiki.fhem.de/wiki/FTUI_Widget_Thermostat) fertig.
Ich schnapp mir als nächstes Homestatus und Datetimepicker.
Zitat von: Standarduser am 13 Februar 2017, 10:05:03
Ok, ich warte mal noch, ob Ulm32b oder setstate eine Meinung dazu haben, sonst würde ich das einfach anpassen.
So, bin von der Strategietagung zurück. :D
Das Schlüsselwort "Beispiel" finde ich treffender und eindeutiger als "Anwendung". Bei "Anwendung" wäre evtl. die Erwartungshaltung, dass hier erklärt wird, wo und wie man die Zeitschaltung anwenden kann.
Es gibt zwar in den Widgetbeschreibungen auch das Kapitel "Beispiele", aber das beißt sich nicht. Meine Empfehlung lautet also
FTUI Beispiel Zeitschaltung. Falls jemand weiß, wie man die Umbenennung vornimmt, kann er das gerne machen. Werden dann die Links auf diesen Beitrag automatisch nachgezogen?
Vielen Dank, Standarduser für Deinen Überblick. Dies war exakt der optimale Zeitpunkt, um die Sache zu klären.
Zitat von: setstate am 13 Februar 2017, 02:23:58
mit "nocache" wird die aktuelle Zeit in Sekunden an die URL hinten angefügt. Dadurch entstehen genau dieses ?_=1234567
Und das überlistet dann den Browser-Cache
Hm, meine Versuchsergebnisse lauten:
<div class="nocache">
<div data-type="image" data-url="http://www.dwd.de/DWD/wetter/radar/radfilm_nrw_akt.gif" data-refresh="900"></div>
</div>Der Radarfilm wird
nicht automatisch aktualisiert.
Hingegen ceteris paribus:
<div class="nocache">
<div data-type="image" data-url="http://www.dwd.de/DWD/wetter/radar/radfilm_nrw_akt.gif?_=3455543" data-refresh="900"></div>
</div>Der Radarfilm wird automatisch aktualisiert.
In die Doku sollte eine funktionierende Lösung hinein. Welche Anforderungen an diese Lösung genau zu stellen sind, ist derzeit nicht klar. Eine schnelle Webrecherche blieb ohne greifbares Ergebnis. Weitere Versuche zur Eingrenzung des Verhaltens habe ich nicht durchgeführt, würde mich mittelfristig aber dafür interessieren.
class="nocache" bei image mit rein und die url ohne das?_=1234567
Zitat von: Ulm32b am 13 Februar 2017, 18:59:17Falls jemand weiß, wie man die Umbenennung vornimmt, kann er das gerne machen. Werden dann die Links auf diesen Beitrag automatisch nachgezogen?
Umbenennen heißt bei MediaWiki "verschieben". Rechts oben kannst du unter "Mehr" die Seite verschieben. Im darauf angezeigten Input-Feld gibst du einfach den neuen Namen an. Es wird dann automatisch eine Weiterleitung von der Ursprungsseite auf die neue Seite gemacht. Die Links werden nicht nachgezogen, sind aber trotzdem noch gültig, weil sie auf die Seite verweisen, die dann weiterleitet.
Ich hab das bereits erledigt
@All-Ex du stiller Korrigierer, danke dafür!
Ich nehme mir als nächstes checkbox vor.
Datetimepicker (https://wiki.fhem.de/wiki/FTUI_Widget_Datetimepicker) und Homestatus (https://wiki.fhem.de/wiki/FTUI_Widget_Homestatus) erledigt.
Dimmer und Range reserviert
So schnell wie Ihr die widgets dokumentiert, komme ich mit dem Testen der einzelnen Teile nicht nach.
Hut ab für eure geile Arbeit.
Aber da ich noch mit dem positionieren von widgets die größsten Schwierigkeiten habe, kann ich das nur sehr wenig genießen.
Eine grundlegende Beschreibung zur Positionierung würde mir (und vielleicht auch dem ein oder anderen) sehr helfen. Für mich verschieben sich die einzelnen Bereiche lustig umher.
Die Größenangaben der widgets sind auch relativ zu ... ja zu was eigentlich?
Naja, schon wieder abgeschweift. Eigentlich wollte ich nur eure Arbeit würdigen ;) :D
Die Beschreibung zur Positionierung ist anscheinend schon in Arbeit.
Da ich im Moment keine Zeit habe mich ins Wiki einzuarbeiten , teste ich im Moment die Doku beim Anlegen eines neuen FTUI. Bisher keine Fehler gefunden und die Doku ist auch gut nachvollziehbar.
Gute Arbeit.
Ich hätte da mal zwei Fragen zu ganz unterschiedlichen Themen:
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.
2. Für die Doku zum Chart-Widget würde ich gern eine Reihe von Bildern einfügen, die die Formatierungsmöglichkeiten des grafischen Verlaufs aufzeigen sollen. Für die Farben sind das dann 7 Bilder. Wie bekomme ich die am besten und übersichtlichsten ins Wiki? Tabelle mit 7 Zellen nebeneinander oder gibt es noch einen besseren Weg? Oder sollte ich lieber ein einzelnes Bild daraus machen?
Zu 1 kann ich nichts sagen. Ist mir auch erst heute aufgefallen.
Zu 2: Mach's so, wie in der Einleitung. Mit dem <gallery>-Tag: https://www.mediawiki.org/wiki/Help:Images#Rendering_a_gallery_of_images (https://www.mediawiki.org/wiki/Help:Images#Rendering_a_gallery_of_images)
Range (https://wiki.fhem.de/wiki/FTUI_Widget_Range)- und Dimmer (https://wiki.fhem.de/wiki/FTUI_Widget_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.
So, ich glaub, mir reicht's für heute ;)
Hi,
tolle Arbeit die ihr da macht :)
Mir ist gerade aufgefallen, dass beim Range Widget das data-get fehlt. Jetzt könnte man ja meinen, es steht ja im Hauptartikel welche Attribute für alle Widgets gelten, data-device ist ja bei vielen (allen?) Widget auch nicht aufgeführt, aber dann sollte man aus Konsistenzgründen data-get überall entfernen.
Meine Meinung: data-device nicht überall aufnehmen, aber data-get beim range hinzufügen
Ich habe das jetzt nicht gleich geändert weil ich das Thema zuerst hier diskutieren möchte
Gruß Nobby
Edit: ??? ich weiß nicht, was ich da gerade für einen Aussetzer hatte ... data-get ist bei range sinnlos :-[
Mensch, ich und die Copy&Paste-Fehler. Danke für's Korrigieren Nobby!
Die data-get-Sache darfst du gerne ergänzen, wenn du möchtest. Schlage vor, wir erwähnen das wirklich bei jedem Device.
data-device hingegen ist eigentlich überflüssig. Müssen mir nicht erwähnen.
==edit==
Die Änderung von nobby an seinem Beitrag hat mich jetzt kalt erwischt ;)
Warum etwas weglassen? Die eine Zeile brauchen wir doch nicht sparen. Lieber eine vollständige Doku, das macht es einfacher.
Beim Chart gibt es übrigens kein Data-device ;)
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.
longpoll_type bei den META-Tags ergänzt
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 :-[
Zitat von: Standarduser am 14 Februar 2017, 19:08:42
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.
Zitat von: drhirn am 14 Februar 2017, 20:05:08
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.
Mit playstream hatte ich mir eine schöne Suppe eingebrockt. :P 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 (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.
Zitat von: drhirn am 14 Februar 2017, 09:51:38
@All-Ex du stiller Korrigierer, danke dafür!
Gerne :-) Tolle Arbeit, die ihr macht!
Zitat von: Standarduser am 14 Februar 2017, 14:51:50
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
Zitat von: drhirn am 14 Februar 2017, 16:22:33
Range (https://wiki.fhem.de/wiki/FTUI_Widget_Range)- und Dimmer (https://wiki.fhem.de/wiki/FTUI_Widget_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.
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.
Hast Du ein Beispiel?
Grundsätzlich wäre ich eigentlich schon dafür, weil ich die Meinung von setstate teile:
Zitat von: setstate am 14 Februar 2017, 19:14:16
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.
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 ;)
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 ;D
Deswegen wurden ja die Browser-Tabs erfunden :D
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.
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?
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.
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.
Die gibt's: Semantic MediaWiki (https://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki) oder die Cargo Extension (https://www.mediawiki.org/wiki/Extension:Cargo).
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.
Pagebutton (https://wiki.fhem.de/wiki/FTUI_Widget_Pagebutton) ist fertig. Ihr dürft da aber gerne ergänzen/korrigieren/etc. Ich bin da nicht ganz sattelfest.
Hallo,
ich möchte die Sache mit den CSS-Klasse noch einmal hochkochen. Bislang gibt es keinen Vorschlag, wie wir das effizient auf die Reihe bekommen. Wie wäre es mit folgendem Ansatz:
Jemand (;D ;D) erstellt eine FTUI-Seite und unterteilt diese schachbrettartig. In die einzelnen Felder kommt:
<div data-type="xxx" class=""></div>
<div data-type="label" class="inline">xxx</div><div data-type="label" class="">Referenz</div>
<div data-type="xxx" class="mini"></div>
<div data-type="label" class="inline">xxx</div><div data-type="label" class="inline">mini</div>
<div data-type="xxx" class="big"></div>
<div data-type="label" class="inline">xxx</div><div data-type="label" class="inline">big</div>
usw. (Vereinigungsmenge aller bekannten Klassen)
In einem Text-Editor ersetzt man nun xxx durch das zu untersuchende Widget (suchen -- ersetzen). Anschließend schaut man sich die in FTUI erzeugte Oberfläche an. Überall dort, wo sich das Bild nicht von der Referenz unterscheidet, hat die CSS-Klasse (augenscheinlich) keine Wirkung.
Das Verfahren muss wahrscheinlich noch verfeinert werden, damit man z.B. die Positionierung gegenüber benachbarten Widgets beurteilen kann.
Auf diese Weise könnte jemand (;D) die von mir erträumte große Tabelle Widgets vs. CSS erstellen. Die wäre für sich schon ein großer Wurf. Ich würde mich nicht wundern, wenn da Überraschendes zu Tage träte. Im letzten Schritt würden die Ergebnisse in die einzelnen Widgetbeschreibungen übertragen werden.
Was haltet ihr davon?
Kann jemand gerne machen ;).
Voraussetzung ist, dass wir alle Klassen zusammengesammelt haben. Sonst muss jemand dass für alle Widgets jedes Mal wiederholen, wenn eine neue Klasse auftaucht.
Und bei Sachen wie "hide-on" muss dann natürlich immer ein Reading dafür erstellt werden. Und bei Switches müsste jemand auch auf jeden draufdrücken. Usw usf
CSS kann man aber nicht nur zur optische Veränderung benutzen. Im JavaScript kann man auf Vorhandensein bestimmter Klassen prüfen und dann erst zur Laufzeit Aktionen ableiten.
Zum Beispiel "timestamp" bei Label hat keine Style Auswirkung, es wird aber dadurch etwas anderes angezeigt.
Offizielle Empfehlungen sagen zwar, solche Script beeinflussenden Klassen sollen auch besonders gekennzeichnet werden, mir Vorsilben zum Beispiel. js-timestamp müsse das stattdessen dann heißen. Aber ich kann mich damit noch nicht recht anfreunden, obwohl wir genau diese Unterscheidung jetzt bräuchten.
CSS kann man aber nicht nur zur optische Veränderung benutzen. Im JavaScript kann man auf Vorhandensein bestimmter Klassen prüfen und dann erst zur Laufzeit Aktionen ableiten.
o.k.
Die optisch unveränderten CSS wären dann "Kandidaten", bei denen man noch genauer hinschauen müsste. Kann jemand schätzen, wie groß der Anteil solcher Fälle wäre? Gefühlsmäßig eher überschaubar. Wir wollen ja nicht zum Mond fliegen und brauchen nur eine 80%-Lösung.
Zitat von: Ulm32b am 15 Februar 2017, 14:43:57
Wir wollen ja nicht zum Mond fliegen und brauchen nur eine 80%-Lösung.
Hmm, dann können wir's aber gleich so lassen, wie's ist ;)
Mit 80%-Lösung meinte ich, dass wir "automatisiert" 80% erledigen und vielleicht damit 80% (auch 50% wäre schon super) des Aufwandes einsparen, am Ende aber eine zu 99% korrekte Doku haben.
Wenn ich mir die bisher erstellten Dokus so anschaue, sind die angegebenen CSS-Klassen wohl nicht überprüft und insbesondere auch keine fehlenden ergänzt worden. Bei meinen ersten Widgets habe ich die Überprüfung der Funktion noch durchgeführt, es dann aber auch bleiben lassen. Müssten wir nicht derzeit bei den CSS-Klassen "SIND UNGEPRÜFT" vermerken?
Das ganze Thema könnte auch zu einem späteren Zeitpunkt noch einmal angegangen werden. Vielleicht hat bis dahin jemand noch eine bessere Idee. Nur her damit.
Aso, so meinst du das.
Also ich teste die Klassen immer durch. Will ja wissen, was ich da dokumentiere. Und schau in den Quellcode des jeweiligen Widgets, ob ich noch was finde. Lernt man viel dabei ;).
Ich hätte aber auch gesagt, kümmern wir uns später drum. Nützen wir jetzt lieber noch den nachlassenden Anfangsschwung und schauen, dass wir die Inhalte mal vollständig ins Wiki bringen.
Zitat von: drhirn am 15 Februar 2017, 15:12:00
Ich hätte aber auch gesagt, kümmern wir uns später drum. Nützen wir jetzt lieber noch den nachlassenden Anfangsschwung und schauen, dass wir die Inhalte mal vollständig ins Wiki bringen.
Dieser Meinung würde ich mich anschließen. Wenn ich mir überlege, wieviel Zeit ich schon in das Chart investiert habe und was das Ergebnis davon ist, hab ich da im Moment einfach überhaupt keine Lust drauf. Meist sitze ich an meinen Blog-Beiträgen nicht so lange, und da steckt teils deutlich mehr dahinter und auch das Ergebnis ist viel anschaulicher.
Aber ich will Dich keinesfalls bremsen und würde Dich auch dabei unterstützen, aber alles durchzutesten ist mir im Moment zu viel Arbeit. Ihr müsstet mal meine UI sehen, da würde ich das große Lachen kommen. Oder das Heulen ;)
Schmeiß eine "Todo"-Vorlage ins Chart-Widget und mach zwischendurch was einfaches. Zwecks Motivationsgewinnung. Simplechart z.B. :D
Und bevor ich's vergesse, ich bin grad am Knob-Widget dran.
Nee, ich hab ja auch ein kleines Ziel vor Augen:
Im Moment funktioniert das Meteogram nicht - zeigt nix mehr an. Und so richtig gut gefallen hat mir das auch nie.
Ich möchte sowas ähnliches mal mit dem Chartwidget bauen. Da kann man neben fa-icons auch verlinkte Icons anzeigen. Hab nur noch keinen Plan, wie das richtig funktioniert.
Zitat von: setstate am 13 Februar 2017, 19:25:39
class="nocache" bei image mit rein und die url ohne das?_=1234567
o.k.
Ich kann nach ausgiebigem Test bestätigen, dass die Umgehung des Browser-Cache ("nocache")
funktioniert mit:
<div data-type="image" data-url="<url1>" class="nocache"></div>
<div data-type="image" data-url="<url2>" class="nocache"></div>
nicht funktioniert mit:
<div class="nocache">
<div data-type="image" data-url="<url1>" class=""></div>
<div data-type="image" data-url="<url2>" class=""></div>
</div>
Etwas allgemeiner formuliert:
Das "nocache" muss in dem div stehen, in dem es wirken soll. Kann man das so allgemein sagen? Wenn ja, könnte das in die Beschreibungsvorlage zu nocache. Ich selbst habe das erst nach Wochen und mit Hilfe von Setstate erkannt und verstanden. Anderen möchte ich das ersparen.
P.S. Damit bleibt im Dunkeln, warum das ?_=3455543 in der URL Wunderkräfte entwickelte, aber egal.
<div class="nocache">
<div data-type="image" data-url="http://www.dwd.de/DWD/wetter/radar/radfilm_nrw_akt.gif?_=3455543" data-refresh="900"></div>
</div>
Oder so (https://wiki.fhem.de/wiki/FTUI_Widget_Image#Bild_aus_dem_Internet_anzeigen) z.B.?
Zitat von: drhirn am 15 Februar 2017, 16:03:53
Oder so (https://wiki.fhem.de/wiki/FTUI_Widget_Image#Bild_aus_dem_Internet_anzeigen) z.B.?
Schon recht. Mein Denkfehler war, dass nocache nicht in das umklammernde div durfte, wozu man verleitet wird, wenn mehrere Bilder (die ggf. auch aus- und eingeblendet werden, um somit einfaches Umschalten zu ermöglichen) aufeinanderfolgen. Für mich ist das Thema durch. Wie ich schon sagte, ich möchte es anderen erparen.
Zitat von: Ulm32b am 15 Februar 2017, 14:12:23
Hallo,
ich möchte die Sache mit den CSS-Klasse noch einmal hochkochen. Bislang gibt es keinen Vorschlag, wie wir das effizient auf die Reihe bekommen. Wie wäre es mit folgendem Ansatz:
Jemand (;D ;D) erstellt eine FTUI-Seite und unterteilt diese schachbrettartig. In die einzelnen Felder kommt:
Wenn sonst niemand ganz laut "ich will" schreit, dann mache ich mir mal Gedanken, wie man das Ganze (teil-)automatisiert erstellen kann ... im Sinne der nach dem Vorschlag folgenden Diskussion: gebt mir ein paar Tage Zeit, es ist ja nicht ganz so eilig
Knob ist fertig: https://wiki.fhem.de/wiki/FTUI_Widget_Knob
Geht ich richtig in der Annahme, dass data-hdcolor und data-width keinerlei Effekt haben?
Und könnte sich bitte jemand einen sinnvollen Einleitungstext überlegen? Ich hab keine Ahnung, wie ich beschreiben soll, was das Widget macht.
Zitat von: drhirn am 15 Februar 2017, 17:34:10
Knob ist fertig: https://wiki.fhem.de/wiki/FTUI_Widget_Knob
Geht ich richtig in der Annahme, dass data-hdcolor und data-width keinerlei Effekt haben?
Und könnte sich bitte jemand einen sinnvollen Einleitungstext überlegen? Ich hab keine Ahnung, wie ich beschreiben soll, was das Widget macht.
Wie wäre es mit:
Das Knob Widget ist ein Widget für FHEM Tablet UI, das einen verschiebbaren Statusbalken auf einer Kreisbahn erstellt. Optisch wird ein ,,Drehknopf" symbolisiert, mit dem man eine Einstellung vornimmt.
data-width muss eine Zahl sein ohne Einheit und kann durch Class Angaben (big, mini ...) überstimmt werden.
Handle Color wirkt nur bei Widgets, die die draw Funktion mit ihrer eigenen Version überschreiben. (Volume, Thermostat)
Naja, irgendwie tut sich bei mir nichts, wenn ich data-width definiere. data-height hingegen funktioniert. Kann das sein, dass data-width durch Berechnungen wieder überschrieben wird? data-height hat ja einen Standardwert. Und ich nehme an - ohne nachgesehen zu haben - dass mit Hilfe von Höhe und Breite eine Kreisform berechnet wird, oder?
Bezüglich data-hdcolor: Nehm ich aus dem Knob raus und stell's in die Widgets, bei denen es wirkt ;)
Colorwheel (https://wiki.fhem.de/wiki/FTUI_Widget_Colorwheel) erledigt. Langsam füllt sich die Liste der fertige Widgets :)
Ich habe übrigens heute bei Nesges angefragt. Wir dürfen die Dokumentation auf seiner GitHub-Seite ins Wiki übernehmen. Aber vorher wäre auszuprobieren, ob die Widgets überhaupt noch funktionieren.
Echt krass, was alles im Wiki gelandet ist. Hab auch mal die Liste im ersten Post aktualisiert.
Ich hätte mal eine Frage zum Thermostat:
Gibt es eine Möglichkeit, den Einstellkreis (oder wie das Ding heißt) generell von der Nullstellung bis zum aktuellen Wert einzufärben?
Optisch würde mir das viel besser gefallen, denn weil bei mir die Regelung sehr gut funktioniert, ist das Teil immer grau.
Zitat von: drhirn am 15 Februar 2017, 18:25:26
Colorwheel (https://wiki.fhem.de/wiki/FTUI_Widget_Colorwheel) erledigt. Langsam füllt sich die Liste der fertige Widgets :)
Könntest du das bitte noch verlinken?
http://knowthelist.github.io/fhem/tablet/demo_colorwheel.html
Zitat von: TWART016 am 15 Februar 2017, 19:37:45
Könntest du das bitte noch verlinken?
http://knowthelist.github.io/fhem/tablet/demo_colorwheel.html
Logisch. Ist erledigt. Danke für den Hinweis!
Zitat von: drhirn am 15 Februar 2017, 19:46:06
Logisch. Ist erledigt. Danke für den Hinweis!
Dank dir für den Einsatz ;)
Macht es nicht Sinn für jedes Widget so eine Demoseite zu erstellen?
Naja, dazu wären ja eigentlich die Beispiele da. Auch wenn's schon sehr hübsch aussieht.
Ein Live-Demo ist immer eine feine Sache
So hier die Version 0.1 ... da muss ich noch einiges optimieren ;)
Zitat von: Standarduser am 15 Februar 2017, 20:00:50
Ein Live-Demo ist immer eine feine Sache
Ja, aber im Wiki leider nicht abbildbar. Und wenn man's extern hosted, muss das wieder jemand betreuen.
setstate hat doch sowas schon laufen und bestimmt nix dagegen, wenn wir ihm fertige Blöcke reichen, die er nur einfügen muss. Oder ein demo zum Download
Bei eingen Klassen bin ich echt überrascht, dass diese schon bei Label eine Auswirkung haben ;)
@setstate: kannst du mal nach bg-lightblue schauen ... das ist eher schwarz ;)
Edit: Wer schon mal selbst schauen will ... html anbei
Zitat von: Nobby1805 am 15 Februar 2017, 20:55:13
@setstate: kannst du mal nach bg-lightblue schauen ... das ist eher schwarz ;)
Tippfehler in fhem-tablet-ui.css. Dort steht versehentlich
.bg-ligthblue statt
.bg-lightblue.
Zitat von: Nobby1805 am 15 Februar 2017, 20:55:13
Edit: Wer schon mal selbst schauen will ... html anbei
Ein
> zu viel nach dem abschließenden </ul>
Zitat von: drhirn am 15 Februar 2017, 21:03:36
Ein > zu viel nach dem abschließenden </ul>
Da denkt mein Editor mit ... aber ich merke das nicht und setzte das Abschlusszeichen von Hand ... passiert immer wieder ;)
Mit anderen Widgets als Label ist es nicht ganz so einfach ... da sieht man manche Effekte nicht sofort, z.B. bei push die Farbänderung beim Drücken ... auch hier wieder ein Problem bei lightblue ... wird beim drücken orange
Edit: lightgray, black und yellow wirken auch nicht ... kein Fehler sondern gewolltes Weglassen ?
ZitatMit anderen Widgets als Label ist es nicht ganz so einfach ... da sieht man manche Effekte nicht sofort, z.B. bei push die Farbänderung beim Drücken ... auch hier wieder ein Problem bei lightblue ... wird beim drücken orange
Edit: lightgray, black und yellow wirken auch nicht ... kein Fehler sondern gewolltes Weglassen ?
Irgendwie hatte ich es geahnt: Die Überprüfung des CSS-Klassen lohnt sich. ;)
Bitte dranbleiben: Der CSS-Tester (so nenne ich ihn jetzt mal) ist weniger als einen Tag alt. Er wird noch reifen.
Und dann habe ich noch etwas zu vermelden: Checkbox ist drin: https://wiki.fhem.de/wiki/FTUI_Widget_Checkbox (https://wiki.fhem.de/wiki/FTUI_Widget_Checkbox)
Ich nehme dann noch SYMBOL.
Symbol ist drin, puh.
https://wiki.fhem.de/wiki/FTUI_Widget_symbol (https://wiki.fhem.de/wiki/FTUI_Widget_symbol)
Bei der Gelegenheit möchte ich ankündigen, dass ich ab Samstag für drei Wochen keinen Zugriff auf FHEM / FTUI habe (kein Urlaub) und deshalb in meinen Aktivitäten sehr eingeschränkt bin. 3 Wochen sind für FTUI ja schon archäologische Dimensionen.
und hier der CSS-tester für Symbol ... ich bin mir allerdings nicht sicher, ob es nicht Klassen gibt deren Auswirkung man erst sieht wenn man das jeweilge widget nicht "so einfach wie möglich" aufruft :-\
Das ist genau das Problem, das ich schon angesprochen habe. Man müsste jeden einzelnen Zustand jedes Widgets abbilden können. Das wäre eine ziemliche Herausforderung.
@drhirn: Jetzt hast du bei der Beschreibung der Installation Pfade angegeben wie sie vermutlich bei dir heißen ... bei mir nicht ;)
Vorher war das neutraler formuliert
Ach, Mist, jetzt weiß ich, was ich noch vergessen habe :D
Danke für's Erinnern!
Hmm, so neutral war das vorher auch nicht. Und ich brauche eine Lösung, die ich im "Code-Teil" (für Copy&Paste), auf allen Betriebssystemen und auch für unerfahrene Benutzer verwenden kann.
Vorschläge?
Zitat... ich bin mir allerdings nicht sicher, ob es nicht Klassen gibt deren Auswirkung man erst sieht wenn man das jeweilge widget nicht "so einfach wie möglich" aufruft.
ZitatDas ist genau das Problem, das ich schon angesprochen habe. Man müsste jeden einzelnen Zustand jedes Widgets abbilden können. Das wäre eine ziemliche Herausforderung.
Wohl wahr. Ich sehe 2 Optionen:
- Die betroffenen Widgets müssen dann noch händisch überprüft werden. (Wie hoch ist der Anteil?)
- Man baut für die einzelnen CSS-Klassen eine Testumgebung auf, z.B. ein Device und Reading für data-get in FHEM und ggf. einen Schalter, mit dem man die Eingangsgrößen beeinflussen kann. Das ist definitiv aufwendig. Es könnte aber auch der Fall eintreten, dass jemand genau das spannend findet und den CSS-Tester weiter aufbaut. Die Eintrittsschwelle ist niedrig; man kann es ja einmal für eine Klasse ausprobieren und sieht dann weiter.
@drhirn:
Label-Widget: Bist Du Dir sicher, dass die Erläuterung der RegEx für data-substitution richtig ist?
Im Wiki steht
ZitatRegEx, die auf dem Wert angewandt werden soll. Standard RegEx-Schreibweise wird erwartet (s/regex/subst/modifier): data-substitution="s/no soundplayer active//g"
Mein Reading enthält folgenden Inhalt:
> UPD 2017-02-10_07:45:02 184441 ./CHANGED > UPD 2017-02-06_07:45:06 129579 ./fhem.pl > UPD 2017-01-16_07:45:02 108257 FHEM/00_THZ.pm > UPD 2017-02-11_07:45:02 155457 FHEM/01_FHEMWEB.pm > UPD 2017-01-31_07:45:03 211511 FHEM/10_ZWave.pm > UPD 2017-01-10_07:45:02 96270 FHEM/23_LUXTRONIK2.pm > UPD 2016-09-14_07:45:12 10674 FHEM/36_EleroDrive.pm > UPD 2016-12-08_07:45:12 15185 FHEM/36_EleroStick.pm > UPD 2017-01-23_07:45:02 52360 FHEM/50_HP1000.pm > UPD 2017-01-23_07:45:02 121458 FHEM/70_ENIGMA2.pm > UPD 2017-01-25_07:45:03 129968 FHEM/70_PHTV.pm > UPD 2017-01-12_07:45:02 71739 FHEM/70_Pushover.pm > UPD 2017-01-23_07:45:02 64401 FHEM/74_THINKINGCLEANER.pm > UPD 2017-02-10_07:45:02 18295 FHEM/74_XiaomiFlowerSens.pm > UPD 2017-01-21_07:45:02 55235 FHEM/92_FileLog.pm > UPD 2017-01-28_07:45:02 155778 FHEM/98_DOIF.pm > UPD 2017-02-10_07:45:02 80547 FHEM/98_DOIFtools.pm > UPD 2017-02-05_07:45:02 88609 FHEM/98_SVG.pm > UPD 2017-02-10_07:45:02 43986 FHEM/98_logProxy.pm > UPD 2017-01-06_07:45:02 442384 FHEM/firmware/JeeLink_LaCrosseGateway.bin > UPD 2017-02-11_07:45:04 2675708 docs/commandref.html > UPD 2017-02-11_07:45:05 1556240 docs/commandref_DE.html > UPD 2017-02-11_07:45:02 42743 www/pgm2/fhemweb.jsDas Zeichen > soll nun mit einem Zeilenumbruch ersetzt werden. Baue ich mein RegEx auf wie im Wiki, müsste das so aussehen: data-substitution="s/\>/<br>//g"
Im Ergebnis wird das erste auftretende Zeichen ersetzt, der rest bleibt.
Wenn ich im RegEx einen / weglasse (data-substitution="s/\>/<br>/g") funktioniert das wie gewünscht.
Ich wollte das jetzt nicht einfach anpassen, weil ich den Hintergrund nicht kenne...
Ich habe mal durchgezählt: Wir haben jetzt 32 von 72 Widgets (die Beispiele mitgezählt, das Ganze aber ohne Gewähr) und stehen damit kurz vor dem Bergfest. Die ganze Aktion wird heute 10 Tage alt. Seine individuelle Quote kann sich jeder selbst ausrechnen.
Eigentlich dachte ich mir: Machst Du die 10 voll, stelle aber fest: Die noch offenen Widgets habe ich noch nie benutzt, oder sie enthalten Attribute oder sonstige Besonderheiten, bei denen ich nicht kompetent bin, z.B. hash, Regex usw.
Das geht anderen wohl ähnlich. Dies mag ein Grund sein, dass es gerade etwas ruhiger geworden ist. Außerdem hat man ja auch noch einen Beruf und/oder eine Familie.
Vielleicht kann man sich darauf einigen, dass es für die weiteren Widgets o.k. ist, wenn (im ToDo vermerkt) ganze Bereiche offenbleiben, in der Hoffnung, dass sich Kundige finden. Bis jetzt ist schon sehr viel erreicht, und es ist ganz normal, wenn es jetzt zäher wird. Wie ich bereits andeutete, werde ich für 3 Wochen etwas passiver werden, weil ich keinen Zugriff auf mein FTUI und damit das Testsystem habe.
tragt mich mal für klimatrend ein, das ist das einzige offene Widget das ich noch verwende ...
Zitat von: Standarduser am 16 Februar 2017, 19:40:09
@drhirn:
Label-Widget: Bist Du Dir sicher, dass die Erläuterung der RegEx für data-substitution richtig ist?
Nein. Ich muss ehrlich gestehen, ich hab das ungetestet aus der GitHub-Doku kopiert, weil ich irgendwie mit RegExen auf Kriegsfuß stehe.
Zitat von: Ulm32b
Die noch offenen Widgets habe ich noch nie benutzt, oder sie enthalten Attribute oder sonstige Besonderheiten, bei denen ich nicht kompetent bin, z.B. hash, Regex usw.
Das geht anderen wohl ähnlich.
Ich glaub, ich hab bisher nur Widgets dokumentiert, die ich nicht verwende. ;)
Problem ist - glaube ich - eher, dass die übrigen Widgets kaum bzw. gar nicht dokumentiert sind. Das macht's schwieriger.
Zitat von: Ulm32b
Vielleicht kann man sich darauf einigen, dass es für die weiteren Widgets o.k. ist, wenn (im ToDo vermerkt) ganze Bereiche offenbleiben, in der Hoffnung, dass sich Kundige finden.
Ok für mich. Attribute und Spezial-Klassen sollten allerdings schon vorhanden sein, wenn irgendwie möglich.
Mir wär's ein Anliegen, dass wir noch die auf der FTUI-Wiki-Hauptseite verbliebenen Widgets loswerden. Das sind konkret:
- Circlemenu
- Departure
- Pagetab
- Popup
- Volume
Schaffen wir das?
Ich nehm mal Volume.
Klimatrend ist fertich ... ;)
Volume auch
Pagetab reserviert
Zitat von: drhirn am 17 Februar 2017, 09:48:11
Mir wär's ein Anliegen, dass wir noch die auf der FTUI-Wiki-Hauptseite verbliebenen Widgets loswerden. Das sind konkret:
- Circlemenu
- Departure
- Pagetab
- Popup
- Volume
Dann nehme ich im Rahmen meiner Möglichkeiten noch Departure.
Departure ist fertig. Das war noch einmal ein Kraftakt.
3 Anmerkungen an den Entwickler setstate:
- Derzeit gibt es zwei gleich wirkende Attribute: data-interval und data-refresh. Vielleicht sollte man eines aus der Doku herausnehmen.
- Oft genannt wurde im Forum der Wunsch nach einem Filter für die Richtungen. Ich sehe das ähnlich.
- Ebenfalls sinnvoll hielte ich ein Attribut data-title für die Kopfzeile (default: data-get), weil viele Haltestellen Leerzeichen enthalten.
Super, danke!
Würde es dir was ausmachen, wenn du "Datenquelle" und "Html" hinter "Hinweise" verschieben würdest? Damit's gleich ist, wie bei den anderen Widgets.
Klar, mach' ich sofort. Ich habe den Wald schon gar nicht mehr gesehen.
Das Highlight bei diesem Widget ist für mich weniger die optische Gestalt, sondern der zuverlässige Zugriff auf die Daten, und darauf habe ich zuerst geschaut.
Zitat von: Standarduser am 16 Februar 2017, 19:40:09
@drhirn:
Label-Widget: Bist Du Dir sicher, dass die Erläuterung der RegEx für data-substitution richtig ist?
Das ist schon so richtig, bei
data-substitution="s/no soundplayer active//g"wird no soundplayer active durch das ersetzt was zwischen den // steht, in dem Fall wird es damit einfach gelöscht. Ist vielleicht als Beispiel nicht ganz optimal, wer sich aber Titel aus einem Mediaplayer über Amad anzeigen lässt wird genau das sicher mal brauchen.
Stimmt. Daran, dass da ein String gelöscht werden soll, habe ich garnicht gedacht.
Danke für die Info.
Endlich ist im Chart-Widget auch LogProxy enthalten (wenn auch rudimentär) und ein Beispiel für die Wettervorhersage mit Proplanta: https://wiki.fhem.de/wiki/FTUI_Widget_Chart#7-Tage-Wettervorhersage_mit_Proplanta
Ist echt nicht einfach, wenn man alle 3 (Chart, LogProxy & Proplanta) bisher kaum, oder noch nie benutzt hat.
Am meisten Zeit hat mich das hier gekostet:
"ConstX:(split/\\s/,FmtDateTime(time+86400*2))[0].\\x22_00:00:00\\x22,0,100",
^^ein Eintrag in der columnspec, der <morgen> um 0:00 Uhr eine senkrechte Linie hinzufügt, um die Tage besser voneinander abzugrenzen.
Zitat von: Ulm32b am 18 Februar 2017, 16:57:27
Departure ist fertig. Das war noch einmal ein Kraftakt.
3 Anmerkungen an den Entwickler setstate:
- Derzeit gibt es zwei gleich wirkende Attribute: data-interval und data-refresh. Vielleicht sollte man eines aus der Doku herausnehmen.
- Oft genannt wurde im Forum der Wunsch nach einem Filter für die Richtungen. Ich ich sehe das ähnlich.
- Ebenfalls sinnvoll hielte ich ein Attribut data-title für die Kopfzeile (default: data-get), weil viele Haltestellen Leerzeichen enthalten.
Hierfür wurde das Modul 98_Departure entwickelt, da können diese Filter arbeiten im Modul bzw. teilweise auch schon im enstprechenden Service weggefiltert werden, des Weiteren habe ich auch noch ein reading bereitgestellt, welches die Zeit zum losgehen bereitstellt, wenn die entsprechende Zeit hinterlegt wird, welche man braucht um vom Haus / Wohnung zur Haltestelle zu kommen.
Allerdings ist das Departure Widget hierfür nicht wirklich kompatibel, da es die Daten in einem JSON Format erwartet, wenn ich das recht in Erinnerung habe, da müsste nochmal drüber nachgedacht werden, ob es hier dann ein Alternatives Widget entworfen werden soll, oder aber ich ein Methode zum Abrufen der Daten im JSON Format, wobei letzteres ich nicht so schön finden würde.
Gruß Constantin
Zitat von: uniqueck am 19 Februar 2017, 16:45:06
Hierfür wurde das Modul 98_Departure entwickelt,
Das Modul funktioniert ja eigentlich mit ein paar Label Widgets schon recht gut. Ich sehe da weg Sinn in einem extra Widget was die Daten nochmal aufbereitet, das macht es doch nur unflexibler in der Darstellung und Anpassung an eigene Oberflächen.
Zitat von: sinus61 am 19 Februar 2017, 21:07:43
Das Modul funktioniert ja eigentlich mit ein paar Label Widgets schon recht gut. Ich sehe da weg Sinn in einem extra Widget was die Daten nochmal aufbereitet, das macht es doch nur unflexibler in der Darstellung und Anpassung an eigene Oberflächen.
Naja damit war ja auch eher die bisherige Darstellung des Departure Widget gemeint, das sieht halt aus wie ein Bushaltestellenschild.
Ich brauche es nicht extra, nur wenn es andere haben wollrn zusammen mit dem Modul.
Gruß Constantin
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Zitat von: Standarduser am 19 Februar 2017, 16:23:06
Endlich ist im Chart-Widget auch LogProxy enthalten (wenn auch rudimentär) und ein Beispiel für die Wettervorhersage mit Proplanta: https://wiki.fhem.de/wiki/FTUI_Widget_Chart#7-Tage-Wettervorhersage_mit_Proplanta
Die Seite ist super geworden! Da hast du ziemlich viel Aufwand rein gesteckt.
Könnten wir die Position von "Datenquellen" mit "CSS Klassen" vertauschen? Dann wär's gleich, wie bei den anderen.
Zitat von: drhirn am 20 Februar 2017, 09:10:31
Könnten wir die Position von "Datenquellen" mit "CSS Klassen" vertauschen? Dann wär's gleich, wie bei den anderen.
klar, mach nur.
Kennt jemand noch eine grundlegende Doku zu Highchart?
Das wollte ich als nächstes machen, hab jedoch nichts richtiges finden können.
Wollte mich mal wieder melden. Bin zur Zeit etwas ruhig. Liegt daran, dass ich beruflich viel zu tun hatte und ich aufgrund von dauernden Angriffen auf die Infrastruktur meines Hosting-Providers nicht auf meine Testumgebung komme.
Werde wieder lästig, sobald das vorüber ist ;)
Zitat von: Standarduser am 19 Februar 2017, 16:23:06
Endlich ist im Chart-Widget auch LogProxy enthalten (wenn auch rudimentär) und ein Beispiel für die Wettervorhersage mit Proplanta: https://wiki.fhem.de/wiki/FTUI_Widget_Chart#7-Tage-Wettervorhersage_mit_Proplanta
Ist echt nicht einfach, wenn man alle 3 (Chart, LogProxy & Proplanta) bisher kaum, oder noch nie benutzt hat.
Am meisten Zeit hat mich das hier gekostet:
"ConstX:(split/\\s/,FmtDateTime(time+86400*2))[0].\\x22_00:00:00\\x22,0,100",
^^ein Eintrag in der columnspec, der <morgen> um 0:00 Uhr eine senkrechte Linie hinzufügt, um die Tage besser voneinander abzugrenzen.
Vielen Dank erst mal für Deine Erklärungen zum Chart Widget. Das stand bei mir schon lange auf der Liste, bin aber bisher nicht dazu gekommen. Ich schau mal ob und was ich da noch ergänzen kann, ich habe inzwischen noch eine ganze Menge Lösungen aus diversen Threads, die man da ja auch zusammenfassen kann. Ich muss zugeben, dass die vielen Möglichkeiten, die ich inzwischen in das Widget eingebaut habe, manchmal ganz schön schwer zu bedienen sind ???. Hier mal ein Beispiel, weil Du ja auch zum Thema Proplanta geschrieben hast.
Noch ne Frage bezüglich "rudimentär": Was genau fehlt denn bei logProxy?
Das mit dem Chart Widget ist super geworden. :)
Was mir noch unklar ist: Was muss ich bei den CSS Klassen setzen?
z.B. chart-background um einen einfarbigen Hintergrund zu bekommen?
Wäre an sich noch interessant die jeweiligen Paramter dazuzuschreiben.
Also z.B. ob es fill, color oder background-color ist
Mann, Mann, Mann,..... Hut ab !!!!!
Das sieht super aus.
Zitat von: Thyraz am 22 Februar 2017, 11:32:26
Das mit dem Chart Widget ist super geworden. :)
Was mir noch unklar ist: Was muss ich bei den CSS Klassen setzen?
z.B. chart-background um einen einfarbigen Hintergrund zu bekommen?
Wäre an sich noch interessant die jeweiligen Paramter dazuzuschreiben.
Also z.B. ob es fill, color oder background-color ist
Es kann eigentlich alles gesetzt werden was css so hergibt (und hier noch mal html und css zu erklären macht wenig Sinn ;)). Ob das dann wirklich einen Einfluss hat, hängt eben vom Zeichenobjekt selbst ab. Also wenn Du z.B. beim chart-background irgend etwas am Font änderst, z.B. die font-size, wirst Du nichts sehen, weil zu dem Hintergrund kein Text gehört, sondern eben nur die Fläche (letztlich ein gemaltes Rechteck) das den Hintergrund darstellt.
Zu Deiner konkreten Frage: Wenn Du den Hintergrund einfarbig und nicht gefüllt haben willst, must Du statt:
fill:url(#gr_bgftui);z.B.
fill: redsetzen. In der urspünglichen Version wird der Hintergrund mit einem Verlauf gefüllt, der im Chart definiert ist, im zweiten Fall eben einfarbig mit rot. Die Farbe kann entweder durch einen für css bekannten Namen angegeben werden (red, green, ...) oder als RGB (z.B. '#AACCAA', also 3 als Hex angegebene Werte zwischen 0 und 256 für die Farbanteile rot grün und blau). Welche Parameter es gibt musst Du in den einschlägigen HTML bzw. CSS Beschreibungen nachschauen. Z.B. unter https://www.w3schools.com/css/ (https://www.w3schools.com/css/) aber da hilft Google prima weiter ;).
Das ist mir schon klar, mir ging es genau um das was du jetzt geschrieben hast:
Das Detailwissen was Charts Widget intern verwendet.
In diesem Fall eben fill.
Das ist ja durchaus was, dass sich im Wiki gut machen würde.
Denn ansonsten bekomme ich das nur raus wenn ich den Sourcecode des Widgets anschaue,
oder wenn ich mich z.B. mit Chrome Developer Tools durch die Seitenelemente klicke.
OK, dann müsste man am besten beschreiben, aus welchen Primitiv-HTML Elementen das chart aufgebaut ist. Das könnte dann wohl am besten ich, der das Ding verbrochen hat :-\
Bevor du da ne Doktorarbeit darüber verfasst:
Mir ging es nur um die Klassen, welche in der Wiki beschrieben sind unter dem Punkt:
Folgende Widget-spezifsche Klassen können zusätzlich in einer eigenen CSS-Datei definiert werden
Größe kann man ja erstmal ignorieren, da man da evtl. wirklich besser mit den Chrome Entwicklertools schaut was da wirklich alles drauf einwirkt.
Schriftart und -größe ist ja auch einfach, hier gibt es ja nicht viele Alternativen bei CSS. ;)
Nur bei den Farben gäbe es eben unterschiedliche Möglichkeiten.
Zitat von: uniqueck am 19 Februar 2017, 21:45:22
Naja damit war ja auch eher die bisherige Darstellung des Departure Widget gemeint, das sieht halt aus wie ein Bushaltestellenschild.
Ich brauche es nicht extra, nur wenn es andere haben wollrn zusammen mit dem Modul.
Gruß Constantin
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Wir befinden uns hier im
Doku-Thread. Es wäre doch schön, wenn die in den Diskussionsbeiträgen angedeuteten Möglichkeiten von Departure_98 (z.B. Filterung, Ausgabe über Label etc.) in einer Anleitung mit einem durchgängigen Beispiel einschl. HTML-Code zusammengefasst dokumentiert werden. Im Wiki könnte das unter dem Titel FTUI_Beispiel_xxx laufen. Alternativ, vielleicht sogar besser könnte das Wiki zu Departure_98 aufgebohrt werden. Das würde dann sicher manchen ins Boot holen.
P.S. Gibt es Neuigkeiten im VRS-Topic?
Zitat von: Thyraz am 22 Februar 2017, 12:48:20
Bevor du da ne Doktorarbeit darüber verfasst:
Mir ging es nur um die Klassen, welche in der Wiki beschrieben sind unter dem Punkt:
Folgende Widget-spezifsche Klassen können zusätzlich in einer eigenen CSS-Datei definiert werden
Größe kann man ja erstmal ignorieren, da man da evtl. wirklich besser mit den Chrome Entwicklertools schaut was da wirklich alles drauf einwirkt.
Schriftart und -größe ist ja auch einfach, hier gibt es ja nicht viele Alternativen bei CSS. ;)
Nur bei den Farben gäbe es eben unterschiedliche Möglichkeiten.
Es ist sogar noch einfacher. :)
Weiter unten im Wikieintrag wird auf css/ftui_chart.css hingewiesen wegen den Linien-Styles.
Dort finden sich ja auch die ganzen Vorgaben für die CSS Klassen wie ich eben gesehen habe.
Wenn man nun oben auch darauf hinweist, dass sich in dieser Datei die Default-Werte dieser Klassen finden,
dürfte damit jeder zurecht kommen.
Zitat von: eki am 22 Februar 2017, 12:30:36
OK, dann müsste man am besten beschreiben, aus welchen Primitiv-HTML Elementen das chart aufgebaut ist. Das könnte dann wohl am besten ich, der das Ding verbrochen hat :-\
Ach du hast das Chart-Widget verbrochen? Sehr geile Arbeit [emoji16][emoji1303]
Mich würde mal interessieren, wie du die Icons da rein bekommen hast. Das wollte ich eigentlich mal angehen und hab im Forum nach einem Beispiel dafür gesucht. Aber da du das ja offensichtlich schon hast, wäre ich dir für deinen Code oder eine entsprechende Ergänzung im Wiki echt sehr dankbar.
Hast du eigentlich auch das Highchart gemacht? Da habe ich gestern mal die ganzen Plot-Styles ausprobiert, und manche sehen echt sehr interessant aus. Vor allem das Pie-Chart ist sicher für viele interessant, die den Anteil an selbst erzeugter Energie im Verhältnis zum Gesamtenergieverbrauch anzeigen wollen.
Mit Highchart habe ich nichts zu tun. Das ist eine externe library (hinter der wahrscheinlich etwas mehr Manpower steckt) die letzendlich nur über das highchart Widget ins FTUI eingebunden wird.
Wenn Du mal Deine "Use Cases" genauer beschreibst (also welche FHEM Daten willst Du wie darstellen) kann ich mal schauen, was noch ins Chart Widget reingebaut werden kann.
Das mit den Icons sprengt wahrscheinlich den Rahmen dieses Threads, schreib mir da mal eine private Nachricht offline und erkläre was Du genau machen willst, dann kann ich evtl. helfen.
So, habe noch die letzten Widgets der Startseite übernommen (Pagetab (https://wiki.fhem.de/wiki/FTUI_Widget_Pagetab), Popup (https://wiki.fhem.de/wiki/FTUI_Widget_Popup) und Circlemenu (https://wiki.fhem.de/wiki/FTUI_Widget_Circlemenu)).
Jetzt sind nur noch Medialist, Classchanger, Eventmonitor und "3rd Party Widgets" offen, wenn ich das richtig sehe.
Cool Pagetab.... oder lieber Pagebutton? :-\
Was soll ich nur nehmen?
Oder vielleicht Link? So hat es setstate in diesem Beispiel gebaut: https://github.com/knowthelist/fhem-tablet-ui/blob/master/examples/mobil/index_nav_fixed_mobil.html
In dem Beispiel gibt es im Link Widget auch die Klassen "default" und "nocache", die fehlen im Wiki (und round und square geben dort eine Fehlermeldung)...
Was sind die Unterschiede einer Menü-Implementierung mit pagebutton, pagetab oder link?
Zitat von: All-Ex am 23 Februar 2017, 20:19:37In dem Beispiel gibt es im Link Widget auch die Klassen "default" und "nocache", die fehlen im Wiki (und round und square geben dort eine Fehlermeldung)...
Ist ergänzt/korrigiert.
Zitat von: Thyraz am 22 Februar 2017, 20:29:50
Es ist sogar noch einfacher. :)
Weiter unten im Wikieintrag wird auf css/ftui_chart.css hingewiesen wegen den Linien-Styles.
Dort finden sich ja auch die ganzen Vorgaben für die CSS Klassen wie ich eben gesehen habe.
Wenn man nun oben auch darauf hinweist, dass sich in dieser Datei die Default-Werte dieser Klassen finden,
dürfte damit jeder zurecht kommen.
Hab ich eingefügt.
Zitat von: eki am 23 Februar 2017, 12:06:05
Wenn Du mal Deine "Use Cases" genauer beschreibst (also welche FHEM Daten willst Du wie darstellen) kann ich mal schauen, was noch ins Chart Widget reingebaut werden kann.
Im Moment hätte ich gerne ein Tortendiagramm. Wie ich schon angedeutet habe, habe ich folgendes Ziel:
Die Warmwasserbereitung wird durch Solarkollektoren auf dem Dach bedient und durch eine Gastherme unterstützt. Es gibt also für diesen Fall 2 Werte:
1. Energie, die zur Warmwasserbereitung aufgewendet wurde, und vom Dach kam
2. Energie, die zur Warmwasserbereitung aufgewendet wurde, und aus der Gastherme kam
Da mein Haus noch nicht fertiggestellt ist, habe ich derzeit noch keine Messwerte. Da ich aber aus dem Bereich Prozessautomatisierung komme, bin ich mir sicher, dass ich diese Werte ermitteln kann ;)
Ein Tortendiagramm würde sich für diese Anwendung nahezu aufdrängen.
@Standarduser: Du hast grad das Label-Widget um ein Beispiel ergänzt. Nur kommt in dem Beispiel kein Label vor ;). Somit rein HTML/CSS und hat nichts mit dem Widget zu tun.
Echt, ne? Oh man!
Ich hatte das in einem Thread hier in Forum gefunden, wo es darum ging, ein Label mit Symbol zu erweitern und fand das wie gemacht für das Wiki. Da muss ich dieses winzige Detail wohl übersehen haben [emoji23]
Naja, wenn man den statischen Text stattdessen über ein Label Widget holen würde könnte es wieder passen. Zumindest ist es ein Anwendungsfall den man für die Nachwelt erhalten sollte.
Möglicherweise passt das auch woanders gut rein.
Muss ich mir mal überlegen, oder jemand anderes übernimmt das mal ;)
Zumindest ist es ein Hinweis wert, wenn das Label statisch bleibt, man kein data-type="label" angeben braucht. Spart Resourcen.
Zitat von: setstate am 25 Februar 2017, 13:44:21
Zumindest ist es ein Hinweis wert, wenn das Label statisch bleibt, man kein data-type="label" angeben braucht. Spart Resourcen.
Gute Idee.
So Freunde, ich habe noch weiter an der Doku gebastelt und werde langsam zufrieden damit.
Großer Punkt, der aber noch fehlt, ist die Geschichte mit den Gestaltungsmöglichkeiten (Gridster, Tabelle, Flex). Wer hat nochmal versprochen, dass er da etwas bastelt? ;)
Ein paar Widgets fehlen auch noch, die meisten scheinen aber von keinem von uns verwendet zu werden.
Wie geht's weiter?
Ich habs jetzt nur mal überflogen, aber sieht echt gut aus.
Zitat... Gestaltungsmöglichkeiten (Gridster, Tabelle, Flex). Wer hat nochmal versprochen, dass er da etwas bastelt?
Ich nicht. 8)
Wie bereits mitgeteilt, habe ich derzeit (und noch ca. 2 Wochen) keinen Zugriff auf meine Testumgebung und bin deshalb eher stiller Beobachter. Den Stand der Doku habe ich mir gerade angesehen. Da ist ja richtig aufgeräumt worden; sauber! Gleich wieder was (über Templates) gelernt.
Wenn ich wieder handlungsfähig bin, werde ich mich noch einmal mit dem CSS-Tester beschäftigen. Im ersten Schritt stelle ich mir vor, halbwegs effizient 80% der Klassen für alle (?) Widgets zu validieren, und dann sehen wir weiter.
Bei der Doku-Kultur ist noch Luft nach oben. Erst jüngst gab es ja einen wohl sehr hilfreichen Beitrag zur Gestaltung von Menüs, der bereits wieder in den Annalen unterzugehen droht:
https://forum.fhem.de/index.php/topic,67141.msg585327.html#msg585327 (https://forum.fhem.de/index.php/topic,67141.msg585327.html#msg585327)
Er wäre es wohl wert, als Wiki-Beispiel konserviert zu werden.
Vielleicht wäre es hilfreich, zu Beginn der FTUI-Doku gerade den Newbees - die ja an ihr nicht mehr vorbeikommen :D - Mut zu machen, an der Doku mitzuwirken. Richtwert: Nach 100 Forumsbeiträgen sei es Ehrensache, seinen ersten Wikibeitrag zu schreiben.
Ja, die Templates sind in der normalen Forums-Diskussion auch an mir vorbei gerauscht ... dabei habe ich immer auf so etwas gewartet :o
Ich werde mal den CSS-Tester, der in seiner bisherigen Form nicht "offiziell freigebbar" ist, so umbauen, dass dabei Templates verwendet werden
Zitat von: Nobby1805 am 02 März 2017, 08:05:55
Ja, die Templates sind in der normalen Forums-Diskussion auch an mir vorbei gerauscht ... dabei habe ich immer auf so etwas gewartet :o
Ich werde mal den CSS-Tester, der in seiner bisherigen Form nicht "offiziell freigebbar" ist, so umbauen, dass dabei Templates verwendet werden
Soweit ich mich entsinne, gab es in bestimmten Konstellationen Probleme mit Templates. Ist hier aber wohl unkritisch, denn mit dem "Tester" werden im ersten Schritt nur "Auffälligkeiten" ermittelt, denen man dann nachgehen wird.
Zitat von: Ulm32b am 01 März 2017, 22:59:58
Bei der Doku-Kultur ist noch Luft nach oben. Erst jüngst gab es ja einen wohl sehr hilfreichen Beitrag zur Gestaltung von Menüs, der bereits wieder in den Analen unterzugehen droht:
https://forum.fhem.de/index.php/topic,67141.msg585327.html#msg585327 (https://forum.fhem.de/index.php/topic,67141.msg585327.html#msg585327)
Er wäre es wohl wert, als Wiki-Beispiel konserviert zu werden.
Der ist schon lange als externer Link auf der Pagebutton-Seite verewigt ;)
Zitat von: Ulm32b am 01 März 2017, 22:59:58
Vielleicht wäre es hilfreich, zu Beginn der FTUI-Doku gerade den Newbees - die ja an ihr nicht mehr vorbeikommen :D - Mut zu machen, an der Doku mitzuwirken. Richtwert: Nach 100 Forumsbeiträgen sei es Ehrensache, seinen ersten Wikibeitrag zu schreiben.
Ja. Und nein. Wenn ich da an so spezielle Mitglieder (300 Post in 2 Monaten und lässt noch immer andere für sich arbeiten) denke, wird mir ganz schwummrig, wenn ich dran denke, dass die an einer Doku mitarbeiten ;)
Zitat von: Nobby1805 am 02 März 2017, 08:05:55
Ja, die Templates sind in der normalen Forums-Diskussion auch an mir vorbei gerauscht ... dabei habe ich immer auf so etwas gewartet :o
Hach, dabei stehen die doch schon ewig auf der GitHub-Seite ;)
Zitat von: Ulm32b am 02 März 2017, 08:24:21
Soweit ich mich entsinne, gab es in bestimmten Konstellationen Probleme mit Templates.
Das war in einer älteren FTUI-Version
Ich bastle gerade an einer Seite zum Gridster-Layout. Aber irgendwie habe ich das Gefühl, dass ich mich gerade verrannt habe. Könnt ihr bitte mal prüfen, ob das für einen Einsteiger eh verständlich ist?
https://wiki.fhem.de/wiki/FTUI_Layout_Gridster (https://wiki.fhem.de/wiki/FTUI_Layout_Gridster)
Danke!
Zitat von: drhirn am 02 März 2017, 16:05:35
Ich bastle gerade an einer Seite zum Gridster-Layout. Aber irgendwie habe ich das Gefühl, dass ich mich gerade verrannt habe. Könnt ihr bitte mal prüfen, ob das für einen Einsteiger eh verständlich ist?
Ich hatte mir das gestern schon mal angesehen und finde es gut und verständlich
Gestern war da auch noch kaum Text ;)
1a beschrieben!
Bei den ersten Sätzen würde ich nochmal etwas im Detail feilen.
aus
Zitat1. Es wird die Anzahl an verfügbaren Spalten und Reihen festgelegt. Dies kann mit den META-Tags gridster_cols und gridster_rows geschehen. Die Größe der Kacheln wird dabei automatisch berechnet.
2. Es wird mit den META-Tags gridster_base_width und gridster_base_height eine fixe Größe für die Kacheln vorgegeben. Eventuell vorhandene Angaben von gridster_cols und gridster_rows werden in diesem Fall ignoriert.
würde ich
Zitat1. Die Anzahl an gewünschten Spalten und Reihen festlegen. Dies geschieht mit den META-Tags gridster_cols und gridster_rows. Die Größe der Kacheln wird dann automatisch berechnet.
2. Eine fixe Größe für die Kacheln vorgeben. Dafür werden die META-Tags gridster_base_width und gridster_base_height verwendet. Eventuell vorhandene Angaben von gridster_cols und gridster_rows werden in diesem Fall ignoriert.
Aber sonst echt klasse!
Ok, geändert.
Ist das alles nicht zu oberflächlich? Kommt mir irgendwie so vor. Aber gut, ich vertraue eurer Expertise.
Hab mal das TTS Widget hinzugefügt
Zitat von: drhirn am 02 März 2017, 17:52:10
Ok, geändert.
Ist das alles nicht zu oberflächlich? Kommt mir irgendwie so vor. Aber gut, ich vertraue eurer Expertise.
Ich weiß schon, was du meinst. Man muss grundsätzlich wissen, worum es geht. Aber die Beispiele veranschaulichen das eigentlich ziemlich gut. Alles andere ist Feintuning.
Zitat von: sinus61 am 02 März 2017, 17:53:56
Hab mal das TTS Widget hinzugefügt
Danke. Könntest Du noch ergänzen, was Pitch und Rate bedeuten?
Hab das mal übersetzt. Ich werde da noch mal mit experimentieren und dann ggfs. Ein paar Hinweise machen.
Zitat von: sinus61 am 02 März 2017, 19:03:22
Hab das mal übersetzt. Ich werde da noch mal mit experimentieren und dann ggfs. Ein paar Hinweise machen.
Super. Vielen Dank.
Jetzt ohne das Widget getestet zu haben, aber Pitch ist normalerweise die Tonhöhe, und Rate die "Abspielgeschwindigkeit". Hoher Pitch + Hohe Rate = Schlümpfe, Niedriger Pitch + Niedrige Rate = Gargamel ;)
Zitat von: drhirn am 02 März 2017, 17:52:10
Ok, geändert.
Ist das alles nicht zu oberflächlich? Kommt mir irgendwie so vor. Aber gut, ich vertraue eurer Expertise.
Super verständlich. Hätte mir am Anfang sehr geholfen, obwohl ich noch immer Anfänger bin.
Vielleicht sollte noch ergänzt werden, wie Elemente in den einzelnen Kacheln positioniert werden, also wie nebeneinander oder untereinander Widgets positioniert werden. Das ist nämlich für Anfänger manchmal sehr überraschend, wie die pötzlich auf dem Schirm erscheinen :o
Hehe :)
Ja, habe ich gerade in Planung. Bin mir aber noch nicht ganz sicher, wie ich das am Besten mache.
Zitat von: drhirn am 03 März 2017, 10:56:11
Hehe :)
Ja, habe ich gerade in Planung. Bin mir aber noch nicht ganz sicher, wie ich das am Besten mache.
"Hehe" find ich gut. Hört sich so "dreckig" an ;D
Das mit der Positionierung Anfängergerecht zu beschreiben ist sicher eine Kunst, aber den Rest hast du doch auch super verständlich erklärt. ;)
Hier das hbox-/vbox-Layout: https://wiki.fhem.de/wiki/FTUI_Layout_Flex
Darf ich euch bitten, wieder drüber zu schauen?
Und falls jemand eine Idee hat, wie man flex-grow einfach erklärt, immer her damit ;)
Super, vielen Dank!
grow ist ja verlinkt, um etwas mehr Licht ins dunkle zu bringen. Meiner Meinung nach sollte das reichen.
Ja, schon. Aber auch da irgendwie unglücklich formuliert finde ich. Ich würde nicht verstehen, dass es da nur um den noch freien Platz geht, den sich die Elemente dann anteilsmäßig teilen, wenn ich's nicht wüsste ;)
So hätte ich das jetzt auch nicht ausdrücken können, aber die Beispiele sagen doch alles.
Es mag ziemlich unsinnig klingen, aber für mein Projekt CSS-Tester wäre es praktisch, wenn man den Namen des Widgets (data-type) über ein reading einlesen könnte, ungefähr so:
<div data-type="select"
data-device="CSS_Tester_Widgetname"
data-items='["symbol","label","button","switch"]'
data-get=""
data-set="">
</div>
<div data-type="label" data-get="CSS_Tester_Widgetname:STATE"></div>
<div data-type="CSS_Tester_Widgetname:STATE" class=""></div>
Wie erwartet funktioniert das so nicht. Kennt jemand einen Hintereingang?
Keine Ahnung, wie das ganze in Summe funktionieren soll.
Wenn Du aber ein und dasselbe Widget 20x auf einer Seite darstellen willst und jede Darstellung einfach mit anderen Klassen versorgt wird, dann könntest Du ja ein Template bauen und den Widget-Namen variabel gestalten.
Soetwas habe ich noch nicht ausprobiert, aber meiner Erfahrung nach ist FTIU nicht sehr wählerisch, was das übergeben von Variablen in ein Template angeht.
Der source code geht hier nicht mehr. Wie kommt man an den Code für die Widgetbeispiele?
https://knowthelist.github.io/fhem/tablet/demo_colorwheel.html (https://knowthelist.github.io/fhem/tablet/demo_colorwheel.html)
In Chrome Rechte Maustaste und Quelltext anzeigen
<!DOCTYPE html>
<html>
<head>
<!--
/* FHEM tablet ui */
/*
* UI builder framework for FHEM
*
* Version: 1.4.4
* URL: https://github.com/knowthelist/fhem-tablet-ui
*
* Copyright (c) 2015 Mario Stephan <mstephan@shared-files.de>
* Under MIT License (http://www.opensource.org/licenses/mit-license.php)
*
*/
-->
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
<meta name="widget_base_width" content="74">
<meta name="widget_base_height" content="71">
<meta name="mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="longpoll" content="0"> <!-- 1=longpoll;0=shortpoll every 30sec -->
<meta name="debug" content="1"> <!-- 1=output to console;0=no output -->
<meta name="demo" content="1"> <!-- 1=demo data;0=normal mode-->
<link rel="stylesheet" href="/fhem/tablet/lib/jquery.gridster.min.css" />
<link rel="stylesheet" href="/fhem/tablet/css/fhem-tablet-ui.min.css" />
<link rel="stylesheet" href="/fhem/tablet/lib/font-awesome.min.css" />
<link rel="stylesheet" href="/fhem/tablet/lib/jquery.toast.min.css" />
<script src="/fhem/pgm2/jquery.min.js" defer></script>
<script src="/fhem/tablet/lib/jquery.toast.min.js" defer></script>
<script src="/fhem/tablet/lib/jquery.gridster.min.js" defer></script>
<script src="/fhem/tablet/js/fhem-tablet-ui.min.js" defer></script>
<title>FTUI Demo Colorwheel</title>
</head>
<body>
<div class="gridster">
<ul>
<li data-row="1" data-col="1" data-sizex="6" data-sizey="5">
<header>WIDGET COLORWHEEL</header>
<!-- place your widget here -->
<div class="left cell">
<div data-type="link" class="left large thin"
data-icon-left="fa-chevron-left"
data-url="demo_widgets.html">
Widgets
</div>
<div class="left-align bigger thin ">Colorwheel</div>
<div class="left-align darker"> Widget</div>
</div>
<div class="container round padding bg-gray gray col-2-3 top-space left left-space left-align ">
<b>Colorwheel</b> is a
color picker widget <br/>
to control RGB color values<br/>
of your light devices
</div>
<div class="bottom absolute bottom-space">
<div data-type="link" class="round left"
data-color="lightgray"
data-icon="fa-code"
data-background-color="orange"
data-url="javascript:void(window.open('view-source:'+location.href))">
View Source Code
</div>
<div data-type="link" class="round right"
data-color="orange"
data-icon="fa-github"
data-border-color="orange"
data-url="https://github.com/knowthelist/fhem-tablet-ui">
Show On Github
</div>
</div>
</li>
<li data-row="1" data-col="7" data-sizex="3" data-sizey="5">
<header>COLORWHEEL</header>
<!-- place your widget here -->
<div class="row">
<div data-type="colorwheel" data-device='dummy2' class="roundIndicator top-space-2x"></div>
<div class="">class="roundIndicator"</div>
</div>
</li>
<li data-row="1" data-col="10" data-sizex="3" data-sizey="5">
<header>COLORWHEEL ON SUBMENUS</header>
<!-- place your widget here -->
<div class="row container round bg-gray padding margin">
<div data-type="switch" data-device='HUEDevice1' data-on-background-color="HUEDevice1:rgb" data-get-on="dim.*|on" data-set-on="on" data-icon="fa-lightbulb-o" class="col-1-4"></div>
<div class="col-1-2">HUE Device 1</div>
<div data-type="symbol" id="starter1" data-device='HUEDevice1' data-get="" data-off-color="HUEDevice1:rgb" data-off-background-color="HUEDevice1:rgb" data-icon="fa-ellipsis-h" data-background-icon="fa-circle-thin" class="small"></div>
</div>
<div class="row container round bg-gray padding margin">
<div data-type="switch" data-device='HUEDevice2' data-on-background-color="HUEDevice2:rgb" data-get-on="dim.*|on" data-set-on="on" data-icon="fa-lightbulb-o" class="col-1-4"></div>
<div class="col-1-2">HUE Device 2</div>
<div data-type="symbol" id="starter2" data-device='HUEDevice2' data-get="" data-off-color="HUEDevice2:rgb" data-off-background-color="HUEDevice2:rgb" data-icon="fa-ellipsis-v" class="small"></div>
</div>
<div class="row container round bg-gray padding margin">
<div data-type="switch" data-device='HUEDevice3' data-on-background-color="HUEDevice3:rgb" data-get-on="dim.*|on" data-set-on="on" data-icon="fa-lightbulb-o" class="col-1-4"></div>
<div class="col-1-2">HUE Device 3</div>
<div data-type="symbol" id="starter3" data-device='HUEDevice3' data-get="" data-off-color="HUEDevice3:rgb" data-off-background-color="HUEDevice3:rgb" data-icon="fa-circle" class="small"></div>
</div>
<div class="container round bg-gray padding margin">
<div data-type="switch" data-device='HUEDevice4' data-get-on="dim.*|on" data-set-on="on" data-icon="fa-lightbulb-o" class="col-1-4"></div>
<div class="col-1-2">HUE Device 4</div>
<div data-type="symbol" id="starter4" data-device='HUEDevice4' data-get="" data-icon="fa-bars" class="small"></div>
</div>
<div data-type="popup" data-height="240px" data-width="240px" data-mode="animate" data-starter="#starter1" class="col-1-6">
<div class="dialog">
<header>RBG COLOR</header>
<div data-type="colorwheel" data-device='HUEDevice1' data-get="rgb" data-set="rgb" class="roundIndicator"></div>
</div>
</div>
<div data-type="popup" data-height="240px" data-width="240px" data-mode="animate" data-starter="#starter2" class="col-1-6">
<div class="dialog">
<header>RBG COLOR</header>
<div data-type="colorwheel" data-device='HUEDevice2' data-get="rgb" data-set="rgb" class="roundIndicator"></div>
</div>
</div>
<div data-type="popup" data-height="240px" data-width="240px" data-mode="animate" data-starter="#starter3" class="col-1-6">
<div class="dialog">
<header>RBG COLOR</header>
<div data-type="colorwheel" data-device='HUEDevice3' data-get="rgb" data-set="rgb" class="roundIndicator"></div>
</div>
</div>
<div data-type="popup" data-height="240px" data-width="240px" data-mode="fade" data-starter="#starter4" class="col-1-6">
<div class="dialog">
<header>RBG COLOR</header>
<div data-type="colorwheel" data-device='HUEDevice4' data-get="rgb" data-set="rgb" class="roundIndicator"></div>
</div>
</div>
</li>
<li data-row="6" data-col="1" data-sizex="3" data-sizey="4">
<header>SMALL</header>
<!-- place your widget here -->
<div data-type="colorwheel" data-device='dummy2' class="small top-space-3x"></div>
<div class="">class="small"</div>
</li>
<li data-row="6" data-col="4" data-sizex="6" data-sizey="4">
<header>COLORWHEEL BIG</header>
<!-- place your widget here -->
<div class="row top-space-2x">
<div data-type="colorwheel" data-device='dummy1' class="big barIndicator col-1-2"></div>
<div class="medium col-1-2">class="big barIndicator"</div>
</div>
</li>
<li data-row="6" data-col="10" data-sizex="3" data-sizey="4">
<header>BACK</header>
<!-- place your widget here -->
<div data-type="colorwheel" data-device='dummy1' class="lineIndicator top-space-3x"></div>
<div class="top-narrow-2x">class="lineIndicator"</div>
</li>
</ul>
</div>
</body>
</html>
super, danke!
Hi Folks,
ein Jahr nach der legendären Doku-Offensive habe ich mir heute den Stand der Dinge angeschaut. Und eine bis dahin offene Doku erstellt:
Swiper ist jetzt ,,drin"(https://wiki.fhem.de/wiki/FTUI_Widget_Swiper (https://wiki.fhem.de/wiki/FTUI_Widget_Swiper)).
Multistatebutton hatte ich im November kurz und schmerzlos (vielleicht ein wenig unkonventionell) erledigt (https://wiki.fhem.de/wiki/FTUI_Widget_Multistatebutton (https://wiki.fhem.de/wiki/FTUI_Widget_Multistatebutton)).
Bei den anderen noch offenen Widgets halte ich mich zurück:
- Button: Den Unterschied bzw. Mehrwert zu Push habe ich noch nicht verstanden.
- Eventmonitor: Noch nicht benutzt.
- Html: Was macht der?
- Medialist: Noch nicht benutzt.
- Notify: Mit der Suchfunktion findet man im Forum keine Infos, weil man vom FHEM-notify überschüttet wird.
- Slideout: Ich nutze kein Smartphone.
Sehr erfreulich ist, dass neue Widgets wie
Scale ebenso geräuschlos wie kurzfristig Eingang ins Wiki fanden. Und bei den neuesten Errungenschaften (
Checklist, Include) wird das wohl auch gelingen.
Von den 48 im Wiki gelisteten internen Widgets sind 42 dokumentiert. Damit liegen wir knapp unter 90%. Geht da noch was?
Notify ist hier kurz beschrieben
https://forum.fhem.de/index.php/topic,60386.0.html
Zitat von: sinus61 am 14 Januar 2018, 21:01:40
Notify ist hier kurz beschrieben
https://forum.fhem.de/index.php/topic,60386.0.html
O.k. Vielen Dank.
Diese wahrlich verschüttete Beschreibung bringt Klarheit. Unter Firefox hat es bei mir auch sofort "gebimmelt". Fully scheint solche Benachrichtigungen aber nicht zu kennen (oder ich habe die Einstellung nicht gefunden). Deshalb möchte ich hierzu vorläufig keine Doku schreiben.
Hi,
hab noch 3 Widgets gefunden, die bislang ebenfalls in der Doku noch nicht erwähnt wurden:
Widget Theme:
https://forum.fhem.de/index.php/topic,69259.0.html (https://forum.fhem.de/index.php/topic,69259.0.html)
Widget Imagecover:
https://forum.fhem.de/index.php/topic,70265.0.html (https://forum.fhem.de/index.php/topic,70265.0.html)
Widget AnalogClock:
https://forum.fhem.de/index.php/topic,50821.0.html (https://forum.fhem.de/index.php/topic,50821.0.html)
Widget FileLog:
https://forum.fhem.de/index.php/topic,63759.msg716731.html (https://forum.fhem.de/index.php/topic,63759.msg716731.html)
Gruß
Mathias