New FHEM Tablet UI

[setstate]

Bei Github gibt es eine ganze Menge kleine Änderungen von nesges und setstate.
- Pfad zum FHEM geändert http://forum.fhem.de/index.php/topic,36122.msg287509.html#msg287509
- Fix gegen ungewolltes Senden an FHEM http://forum.fhem.de/index.php/topic,34233.msg288247.html#msg288247
- RegEx beim Symbol Widget http://forum.fhem.de/index.php/topic,34233.msg287600.html#msg287600
- widget_select: data-alias (ermöglicht die Verwendung von Aliasen für Items)
- widget_circlemenu: data-circle-radius / data-item-diameter

[nesges]

Danke!

[mc-hollin]

Da die Einführung von Templates sehr guten Anklang gefunden hat hätte ich noch eine Idee für eine Erweiterung.

Aus meiner Sicht ist es für Einsteiger erst etwas verwirrend das Gridster mit den Widgets zu konfigurieren.
Hier wäre doch eine Editseite mit Drag und Drop und Resize optimal.
So wie hier: https://rawgit.com/ManifestWebDesign/angular-gridster/master/index.html#/dashboard
Es könnten so alle Seiten online aufgebaut werden und zusätzlich über eine Auswahl der Templates gefüllt werden.
Die editierten Designs sollten hierbei serialisiert werden.

Ich hab mich mal daran versucht...
Naja die Einarbeitung in jQuery überwiegt noch die Zeit der Programmierung 
Aber vielleicht gibt es ja den einen oder anderen der so was schon mal realisiert hat.

[setstate]

Das Thema Editor ist durchaus interessant, gerade für Einsteiger und Nicht-HTML-CSS-Entwickler

Für mich war das aber für FTUI nie ein Ziel. Für mich war der Ansatz wie bei Bootstrap http://de.m.wikipedia.org/wiki/Bootstrap_%28Framework%29 völlig ausreichend für dieses UI, zumal die Erstellung ja eine einmalige Sache bleibt, liegt der Focus eher bei der Benutzung und Aussehen.

Wenn sich Leute finden, die einen Editor bauen wollen, würde ich toll finden und unterstützen. Das Resultat muss aber auch so einfach wie möglich benutzbar werden. Nicht wie beim Editor vom Floorplan, wo ich nach kürzester Zeit die Lust an der Klick-Orgie verlor, weil die vielen Angaben  (besonders x und y) sowas von mühselig zu finden waren und am Ende das Aussehen trotzdem nicht befriedigend ausfiel.

Ein Editor müsste auf FTUI Widget Ebene arbeiten, also all die Attribute anbieten, die ein Thermostat, Switch, Symbol braucht. Das Edit und Delete Icon dürfte nur im Editmode erscheinen, nicht dauerhaft im Betrieb. Die Details könnte man aber noch abstimmen...

[mc-hollin]

...
Wenn sich Leute finden, die einen Editor bauen wollen, würde ich toll finden und unterstützen. Das Resultat muss aber auch so einfach wie möglich benutzbar werden. Nicht wie beim Editor vom Floorplan, wo ich nach kürzester Zeit die Lust an der Klick-Orgie verlor, weil die vielen Angaben  (besonders x und y) sowas von mühselig zu finden waren und am Ende das Aussehen trotzdem nicht befriedigend ausfiel.

Ein Editor müsste auf FTUI Widget Ebene arbeiten, also all die Attribute anbieten, die ein Thermostat, Switch, Symbol braucht. Das Edit und Delete Icon dürfte nur im Editmode erscheinen, nicht dauerhaft im Betrieb. Die Details könnte man aber noch abstimmen...

Kann ich mich nur anschließen. War ja auch der Grund warum ich hier gelandet bin und total begeistert bin.
Ich hatte eigentlich nur an einen Editor gedacht, der das Design von Gridster erleichtert.
Also eher ein AddOn auf Gridster. Dann würde sich die Hauptarbeit nur noch auf die Erstellung der Templates konzentrieren.
Gerade am Anfang baut man doch öfters mal die Anordnung der Widgets um.

[tomster]

Ach, weil's mir gerade einfällt für die iPad-Nutzer (vielleicht funzt es auch bei Android; kann es gerade nicht testen).

Wenn man das Tablet-UI im Safari aufruft, dann greift dort das sog. "Elastic Scrolling" (wie man es vielleichtvon "Pull-to-Refresh" kennt). Das kann bei der Eingabe von Temperaturwerten im Thermostat-Widget manchmal zu unerwünschtem "Wegscrollen" führen, wenn man ein bissl daneben toucht.
Man kann das bestimmt eleganter einbauen, aber ich hab mir in die index.html folgende Zeilen gepackt:

Code Auswählen Erweitern


<script>
function BlockMove(event) {
  // Tell Safari not to move the window.
  event.preventDefault() ;
}
</script>
<body ontouchmove="BlockMove(event);" >

Damit bleibt das gesamte UI wie festgenagelt und nix kann mehr verrutschen.

[Marie]

@ tomster: das war das was fehlte...aber wo baue ich das in die Index.html ein?

LG. Marie

[setstate]

Aber damit funktionieren doch einige Widgets garnicht mehr? Dimmer, Thermostat
Ich versuche, die Oberfläche 100% in Höhe und Breite zu bauen, damit kein scroll nötig ist.
Auf dem Telefon sieht das anders aus. Dort muss mehr Platz zum Touch+Move bleiben.
Eine Mobil-Seite mit eigenem Theme anzubieten, ist mein nächstes Ziel, womit ich gestern schon begonnen habe. Vielleicht stolpere ich dann auch über dieses Thema. Für mobile Devices gibt es unterschiedliche Events, mit denen man die Absicht des Users erkennen kann. Touchstart, touchmove, touchend. Aber dann wartet man beim Klick auf einen Switch einige Millisekunden, um auf den Move zuwarten. Wenn kein Move folgt, ist es ein Klick. Diese Verzögerung hat mir auch nicht gefallen, deshalb reagiere ich schon auf touchstart.

[tomster]

@ tomster: das war das was fehlte...aber wo baue ich das in die Index.html ein?

Im Header des Quelltexts nach:

Code Auswählen Erweitern


        <script type="text/javascript" src="/fhem/tablet/lib/fa-multi-button.min.js"></script>
<script type="text/javascript" src="/fhem/tablet/js/fhem-tablet-ui.js"></script>

<!-- Enable this lines for usage with WebViewControl --><!--
<script type="text/javascript" src="/fhem/pgm2/cordova-2.3.0.js"></script>
<script type="text/javascript" src="/fhem/js/webviewcontrol.js"></script>
<script type="text/javascript">var wvcDevices = {'12345': 'Tablet'}; var wvcUserCssFile="webviewcontrol.css"</script>
--><!-- End for WebViewControl -->

</head>
<body>

<!-- available class: container,left,right,cell,narrow,darker,big,bigger,small,thin,large,wider -->
suchen und durch:

Code Auswählen Erweitern


<script type="text/javascript" src="/fhem/tablet/lib/fa-multi-button.min.js"></script>
        <script type="text/javascript" src="/fhem/tablet/js/fhem-tablet-ui.js"></script>

        <!-- Enable this lines for usage with WebViewControl --><!--
        <script type="text/javascript" src="/fhem/pgm2/cordova-2.3.0.js"></script>
        <script type="text/javascript" src="/fhem/js/webviewcontrol.js"></script>
        <script type="text/javascript">var wvcDevices = {'12345': 'Tablet'}; var wvcUserCssFile="webviewcontrol.css"</script>
        --><!-- End for WebViewControl -->
[color=red]<script>
        function BlockMove(event) {
                        // Tell Safari not to move the window.
                        event.preventDefault() ;
                        }
</script>
</head>
<body ontouchmove="BlockMove(event);">[/color]

<!-- available class: container,left,right,cell,narrow,darker,big,bigger,small,thin,large,wider -->
ersetzen.

Aber damit funktionieren doch einige Widgets garnicht mehr? Dimmer, Thermostat
Ich versuche, die Oberfläche 100% in Höhe und Breite zu bauen, damit kein scroll nötig ist.
Auf dem Telefon sieht das anders aus. Dort muss mehr Platz zum Touch+Move bleiben.

Ich hab zwar bislang nur das Thermostat-Widget probiert, aber das funktioniert bei mir weiterhin.
Mir ging's nur darum zu verhindern, dass ein Touch-Event mit dem Finger nur ein bisserl neben z.B. dem Thermostat-Widget dazu führt, dass man das Elastic Scrolling ausführt und nicht die Einstellung am Widget vornimmt. Wenn der BlockMove aber Auswirkungen auf die Widgets hat, muss ich es halt wieder entfernen.

[tomster]

Ach ja, ich gehe derzeit davon aus, dass man ohnehin fast für jedes Device (Tablet, Smartphone oder Computer) ein eigenes HTML-Set erstellen muss, weil zum Einen gridster selbst, zum Anderen die Widgets nicht ausreichend "responsive" sind/ sein können.
Klar, der BlockMove-Event ist auf dem Handy eher kontraproduktiv, aber auf dem Micker-Display gehört in meinen Augen sowieso weniger Klicki- äähh- Touchibunti hin, als eine vernünftige Menüstruktur. In den Untermenüs wär dann immer noch genug Platz für die Widgets. Aber halt nur für ein Thermostat und nicht für eine ganze Thermostat-Armada...

[tomster]

Was mir übrigens gerade aufgefallen ist, seit ich mir vorhin ein iPad ausgeliehen habe:
Wenn ich mir die UI-URL als Bookmark auf den Homescreen lege und darüber aufrufe, dann wird das UI nur alle paar Aufrufe korrekt angezeigt. Ich muss dann die Web-App wieder schliessen und (einige Male) neu starten. Manchmal wird gridster nicht geladen, manchmal stimmen die Formatierungen nicht, etc.
Über Safari direkt habe ich kein Problem.
Kann das jemand reproduzieren?

[setstate]

Das hatte ich vor kurzem auch: http://forum.fhem.de/index.php/topic,34507.msg284946.html#msg284946
Heute Morgen funktionierte es auf dem gleichen iPhone alles wieder. Kann nur an einem geänderten FHEM Modul liegen. Ich habe an phone oder FTUI nix geändert dafür.

[stromer-12]

Heute ist mir aufgefallen, das das Symbol-widget nicht mehr meine offenen Fenster anzeigt.
Ausserdem ist mir aufgefallen, wenn ich das UI per IP von meinen Laptop aufrufe fehlen die Slider.

fhem und ui sind aktuell.

[nesges]

Heute ist mir aufgefallen, das das Symbol-widget nicht mehr meine offenen Fenster anzeigt.
Ausserdem ist mir aufgefallen, wenn ich das UI per IP von meinen Laptop aufrufe fehlen die Slider.

fhem und ui sind aktuell.

zeig mal dein symbol HTML, bitte. Ich hab da ziemlich radikal umgebaut, evtl was übersehen.

[nesges]

Ach ja, ich gehe derzeit davon aus, dass man ohnehin fast für jedes Device (Tablet, Smartphone oder Computer) ein eigenes HTML-Set erstellen muss, weil zum Einen gridster selbst, zum Anderen die Widgets nicht ausreichend "responsive" sind/ sein können.

Mit Client-abhängigen Viewport-Einstellungen und CSS Zoom kann man da schon einiges erreichen, sofern die Displayausrichtung und das Breitenverhältnis bei den Clients (einigermassen) gleich sind. Ich nutze hier das gleiche UI auf einem 7" Tablett, einem 10" Tablett, einem Smartphone und den Destop-PCs. Ich löse die Clienterkennung zwar serverseitig mit PHP, das sollte aber auch mit JS nachzubauen sein. Schau dir mal ui.php Zeile 32ff an.