[FHEM Tablet-UI] Dokumentation (Diskussionsthread)

[drhirn]

Edit: Wer schon mal selbst schauen will ... html anbei

Ein > zu viel nach dem abschließenden </ul>

[Nobby1805]

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 ?

[Ulm32b]

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 ?

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

Ich nehme dann noch SYMBOL.

[Ulm32b]

Symbol ist drin, puh.
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.

[Nobby1805]

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 

[drhirn]

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.

[Nobby1805]

@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

[drhirn]

Ach, Mist, jetzt weiß ich, was ich noch vergessen habe
Danke für's Erinnern!

[drhirn]

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?

[Ulm32b]

... 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.

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.

[Standarduser]

@drhirn:
Label-Widget: Bist Du Dir sicher, dass die Erläuterung der RegEx für data-substitution richtig ist?

Im Wiki steht

RegEx, 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:

Code Auswählen Erweitern

> 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.js

Das 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...

[Ulm32b]

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.

[Nobby1805]

tragt mich mal für klimatrend ein, das ist das einzige offene Widget das ich noch verwende ...

[drhirn]

@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.

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.

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.

[drhirn]

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.