Neuer Style: flex. Flexibel für alle Geräte

[FunkOdyssey]

Ich wundere mich gerade, dass ich an allen Endgeräten immer wieder die Kennzeichnung mit den "neuen Features" sehe und die eigentlich bereits ausgewählten Optionen wieder deaktiviert waren. Kein FHEM-Neustart oder ähnliches durchgeführt. Wird das irgendwie in den Cookies gespeichert?
Update Gerade getestet. Es waren jetzt sogar am gleichen Gerät die Optionen wieder weg und die "Neu-"Kennzeichnung wieder sichtbar.



Eine weitere Auffälligkeit:
Wenn ich auf einem Smartphone das FHEM-Log betrachtet und ans Ende der Seite springe, dann aber z.B. das Smartphone drehe und in den Landscape-Modus wechsel, so springt die Anzeige wieder einen großen Sprung nach oben. Man befindet sich plötzlich weder am Anfang noch am Ende es Logs. Dann heißt es: Scrollen, scrollen, scrollen.
Kann man irgendwie den Fremdeingriff durch das Javascript deaktivieren? Oder ist das bereits die Option "Log-Zeilen umbrechen"?

Ich habe (zum Testen) mal eine Option (disableScrollableTables) hinzugefügt um das Scrollen von den Tabellen zu deaktivieren. Ich habe zudem den "smooth" Effekt von den Tabellen entfernt, evtl. hat das auch schon geholfen. Testet also bitt mal mit und ohne disableScrollableTables.

Ich konnte dies nun einen Tag testen und bin mir sicher, dass damit das Problem gelöst wurde.
Wobei damit nur Tabellen ausgenommen wurden. Versucht man in SVG-Plots über Wischen zu scrollen, klappt es auch nicht immer. So gut wie unmöglich ist ein Scrollen im Querformat des Smartphones.
Der kleine Nachteil ist jedoch, dass man nun diverse Tabellen nicht mehr horizontal scrollen kann.

Ich komme fast nie ans Ende der Seite. Ich muss mich schon richtig anstrengen. Es wird immer wieder ein wenig wieder hochgescrollt.

Dies ist auch unverändert. Das Ende einer Seite lässt sich schlecht erreichen. Ich merke das häufig an den SVG-Plots.

Auf iOS Geräten kann man mit dem Fingertipp auf den oberen Rand, die Webseite wieder hochscrollen . Das funktioniert in Flex irgendwie nicht.

Dieser Fehler ist noch da.

[xanker]

Hey FunkOdyssey,

erstmal vielen Dank für deinen ausführlichen Bericht!

Ich wundere mich gerade, dass ich an allen Endgeräten immer wieder die Kennzeichnung mit den "neuen Features" sehe und die eigentlich bereits ausgewählten Optionen wieder deaktiviert waren. Kein FHEM-Neustart oder ähnliches durchgeführt. Wird das irgendwie in den Cookies gespeichert?
Update Gerade getestet. Es waren jetzt sogar am gleichen Gerät die Optionen wieder weg und die "Neu-"Kennzeichnung wieder sichtbar.

Ja, die Einstellungen werden erstmal als Cookie gespeichert, können dann aber in den Einstellungen global gespeichert werden (im FHEMWEB device). Normal sollten die Cookies eine unendliche Gültigkeit haben.
Zu den "Neu" Kennzeichnungen, es wird ein Einstellung als Neu betrachtet, wenn in der aktuellen Konfiguration die Einstellungen noch nicht vorkommt. Wenn du also an einem Endgerät zwar die neuen Einstellungen vorgenommen hast (oder auch nicht), und dann nicht global speicherst, dann werden die Einstellungen auf anderen Endgeräten auch als Neu angezeigt, da dort ja die Einstellungen noch unbekannt sind. Wenn die Cookies "verloren" gehen bzw. gelöscht werden, wird auf die globalen Settings zurück gegriffen, was bedeutet, dass dann wieder alle noch nicht vorhanden Einstellen als neu gekennzeichnet werden. Evtl. stelle ich das um, dass die Informationen auch im FHEMWEB Device gespeichert werden.
Wenn das mit den Cookies bei dir Probleme macht, du aber dennoch unterschiedliche Einstellungen für deine Endgeräte haben willst, dann müsstest du wohl für jedes Endgerät ein eigenes FHEMWEB Device anlegen und dort jeweils global speichern.

Eine weitere Auffälligkeit:
Wenn ich auf einem Smartphone das FHEM-Log betrachtet und ans Ende der Seite springe, dann aber z.B. das Smartphone drehe und in den Landscape-Modus wechsel, so springt die Anzeige wieder einen großen Sprung nach oben. Man befindet sich plötzlich weder am Anfang noch am Ende es Logs. Dann heißt es: Scrollen, scrollen, scrollen.
Kann man irgendwie den Fremdeingriff durch das Javascript deaktivieren? Oder ist das bereits die Option "Log-Zeilen umbrechen"?

Das werde ich mir mal anschauen. Die Option "Log-Zeilen umbrechen" ist nur dafür da, dass beim Log/Eventmonitor die Zeilen nicht über den Rand hinausragen (sondern umgebrochen werden), sodass man nicht horizontal Scrollen muss.

Ich konnte dies nun einen Tag testen und bin mir sicher, dass damit das Problem gelöst wurde.
Wobei damit nur Tabellen ausgenommen wurden. Versucht man in SVG-Plots über Wischen zu scrollen, klappt es auch nicht immer. So gut wie unmöglich ist ein Scrollen im Querformat des Smartphones.
Der kleine Nachteil ist jedoch, dass man nun diverse Tabellen nicht mehr horizontal scrollen kann.

Hast du es auch getestet wenn die Tabellen scrollbar sind? da ich zusätzlich noch den "Smooth" Effekt entfernt habe. Evtl. könnte das auch das Problem gewesen sein. Dass es bei den SVG Plots noch nicht funktioniert, liegt daran, dass ich es bisher nur für die Tabellen (zum Testen) implementiert habe, die SVG Plots haben einen anderen Scroll-Container, da man die minimale/maximale Breite anpassen kann.

Dies ist auch unverändert. Das Ende einer Seite lässt sich schlecht erreichen. Ich merke das häufig an den SVG-Plots.

Meinst du, dass du nicht ans Ende kommst, wenn du "über" einem SVG Plot scrollen musst? Das würde dann ja zu vorigem Problem gehören.

Dieser Fehler ist noch da.

Das ist nicht direkt ein Fehler, sonst von Apple so implementiert, dass dann nur der body gescrollt wird, bei Flex wird aber nur ein div-Container gescrollt. Evtl. stelle ich das dann doch mal um auf body, vielleicht behebt das auch das Scrollproblem. Echt doof, dass Apple/Safari da so bockig ist, mit Chrome/Edge/Firefox funtioniert das nämlich alles wie es soll.

Ich schaue dass ich das heute oder morgen noch implementiere.

Grüße
Sebastian

[FunkOdyssey]

Meinst du, dass du nicht ans Ende kommst, wenn du "über" einem SVG Plot scrollen musst? Das würde dann ja zu vorigem Problem gehören.

Ich ziehe dieses Zitat mal vor. Kommando zurück. Das hat wohl nichts mit einem Plot zu tun, sondern ist grundsätzlich so. Siehe nachfolgende Sätze.

Hast du es auch getestet wenn die Tabellen scrollbar sind? da ich zusätzlich noch den "Smooth" Effekt entfernt habe. Evtl. könnte das auch das Problem gewesen sein. Dass es bei den SVG Plots noch nicht funktioniert, liegt daran, dass ich es bisher nur für die Tabellen (zum Testen) implementiert habe, die SVG Plots haben einen anderen Scroll-Container, da man die minimale/maximale Breite anpassen kann.

Oh, danke für die Aufklärung. Das macht tatsächlich keinen Unterschied, ob ich die Tabellen scrollbar habe oder nicht. Scheinbar seitdem der Smooth-Effekt entfernt wurde, klappt das Scrollen im Hochformat wie gewünscht. Im Hochformat habe ich auch KEIN Problem mit dem Scrollen in oder über den SVG-Plots. Das war eine falsche Beobachtung von mir.

Anhang meiner Unterstreichung der Wörter merkst du worauf ich hinaus will, oder?  Die Probleme, die ich aktuell feststelle, habe ich ausschließlich im Querformat/Landscape-Modus. Und das spielt auch keine Rolle, ob SVG oder Tabelle.

Probleme im Querformat:
- Ich erreiche häufig das Seitenende nicht. Wische ich dann am Rand über den (vermutlich) Body-Tag ganz langsam, so erreiche ich das Ende. Aber nicht über die Wischgeste über den normalen Inhalt.
- Das Scrollen blockiert ganz oft. Ich komme ab und zu per Wischgeste nicht runter. Aber sehr häufig per Wischgeste nicht mehr nach oben. Dann muss ich kurz ins Hochformat wechseln. Dann ist das wieder möglich.

[xanker]

Oh, danke für die Aufklärung. Das macht tatsächlich keinen Unterschied, ob ich die Tabellen scrollbar habe oder nicht. Scheinbar seitdem der Smooth-Effekt entfernt wurde, klappt das Scrollen im Hochformat wie gewünscht.

na das ist doch schon mal ein Teilerfolg
Ich habe die Option disableScrollableTable und alle "Smooth-Effekte" enternt, außer vom Hauptcontent, da es dort nötig ist, da sonst (auf iOS) nur so weit gescrollt wird wie man den Finger bewegt.

Probleme im Querformat:
- Ich erreiche häufig das Seitenende nicht. Wische ich dann am Rand über den (vermutlich) Body-Tag ganz langsam, so erreiche ich das Ende. Aber nicht über die Wischgeste über den normalen Inhalt.
- Das Scrollen blockiert ganz oft. Ich komme ab und zu per Wischgeste nicht runter. Aber sehr häufig per Wischgeste nicht mehr nach oben. Dann muss ich kurz ins Hochformat wechseln. Dann ist das wieder möglich.

Warum das im Querformat nicht klappt  ist schon merkwürdig. Könntest du bitte mal testen ob es einen Unterschied macht wenn du die Seite schon im Querformat öffnet, also nicht im Hochformat und dann auf Querformat wechseln.

[FunkOdyssey]

Warum das im Querformat nicht klappt  ist schon merkwürdig. Könntest du bitte mal testen ob es einen Unterschied macht wenn du die Seite schon im Querformat öffnet, also nicht im Hochformat und dann auf Querformat wechseln.

Ich öffne hier die Seiten bereits und ausschließlich im Querformat.

[FunkOdyssey]

Das hat nichts mit den colspans zu tun, die werden nur bei Readingsgroup modifiziert. Das Problem ist, dass ich der devState Zelle erlaube bis zu 180px breit zu werden, sodass idR. die webcmds untereinander stehen (bei ungleichen devStates), zumindest solange nach rechts genug Platz ist. Ist das nicht der Fall, wird erst die devState Zelle geschrumpft und dann die Zelle mit dem Device-Namen.
Wenn du willst, dass sich die devState Zelle nicht auf 180px vergrößert, musst du folgendes bei Additional CSS hinzufügen:

Code Auswählen Erweitern

table.block[id^=TYPE] > tbody > tr > td:nth-child(2), #ddtable .odd > td:nth-child(2), #ddtable .even > td:nth-child(2) { max-width: fit-content; max-width: -moz-fit-content; }
Hinweis: vorab noch ein Update machen, da ich gerade noch hinzugefügt habe, dass die semi-colns automatisch escaped werden.

Das klappt leider nicht. Ich habe die Spalten mal eingefärbt.

[xanker]

Ich öffne hier die Seiten bereits und ausschließlich im Querformat.

Ich habe gerade mal ein System Update von dem mir zur Verfügung stehenden iPhone 4s gemacht und siehe da: es zeigen sich die gleichen Problemen - die wohl gemerkt, davor nicht aufgetreten sind. Was auch immer Apple da angestellt hat. Jetzt kann ich das aber immerhin durchtesten und hoffentlich beheben.

[xanker]

Das klappt leider nicht. Ich habe die Spalten mal eingefärbt.

Hmm, stimmt, in dem Fall reicht das nicht aus da die erste Spalte erst kleiner wird wenn in den restlichen kein Platz mehr ist. Zum Verständnis: Die Zeilen einer Gruppe sind Flex-Container, was bedeutet, das die Spalten einer Zeile unabhängig von einer anderen Zeile sind, nur so ist es auch möglich dass die Webcmds in der Mobilansicht in eine neue Zeile "springen".
Man könnte zwar per Javascript sicherstellen, dass das Tabellenverhalten so lange wie möglich eingehalten wird, aber ich glaube das könnte die Performance beeinträchtigen (ich werde es mal testen).
Zwei andere Lösungsvorschläge:
- maximale Breite der ersten Spalte verringern:

Code Auswählen Erweitern

table.block[id^=TYPE] > tbody > tr > td:not([informid]):nth-child(1), #ddtable .odd > td:nth-child(1), #ddtable .even > td:nth-child(1) { max-width: 350px;}
z.B. auf 250px;
- oder die unnötigen on/off webcmds entfernen, man kann ja auf das devState Icon klicken

Edit Ich will anmerken, dass der anderen CSS Code trotzdem nötig ist!

[FunkOdyssey]

Danke für deine Mühe, aber ich werde das lassen.
Das DevStateIcon rutscht sonst zu weit nach links und ist optisch nicht mehr rechts ausgerichtet im Smartphone-Hochformat.

[xanker]

Danke für deine Mühe, aber ich werde das lassen.
Das DevStateIcon rutscht sonst zu weit nach links und ist optisch nicht mehr rechts ausgerichtet im Smartphone-Hochformat.

Man kann halt nicht alles haben Aber ich werde das wie gesagt mal testen, das Tabellenverhalten so lange beizubehalten, solange kein Webcmd in eine neue Zeile springt.

Zu dem Scrollbug: Problem identifiziert...und man kann eigentlich nur sagen, dass das ein Bug von Apple ist. Im Landscape Modus gibt Safari die falsche Seitenhöhe an, anstatt von Unterkante der URL Eingabe bis unterer Bildschirmrand, wird die URL Eingabe nicht abgezogen. Das bedeutet so lange die URL Eingabe sichtbar ist, geht der Seiteninhalt unter dem Bildschirmrand weiter (in Höhe der URL Eingabe). Das ist grundlegend erstmal kein Problem, das Problem besteht nun darin, dass Safari durch das nach unten Scrollen bei einem <div> Container NICHT die URL Eingabe ausblendet, daher siehst du immer den unteren Teil der Seite nicht. Die URL Eingabe wird nur ausgeblendet wenn der body gescrollt wird. So ein quatsch! Das macht nur Safari so...
Das Problem besteht jedenfalls schon länger, hier ein Bericht von 2017: https://github.com/alvarotrigo/fullPage.js/issues/2637

Ich stelle gerade alles auf einen scrollbaren body um, das hat aber noch ein paar Nachwehen die ich erst beseitigen muss...

Edit: Das Problem besteht übrigens auch beim f18 Style wenn man Menü/Header auf fixed setzt... Und das wird auch bei jeder anderen Webpage bestehen die keinen scrollbaren body nutzt. Da muss Apple eigentlich was dagegen tun!

[xanker]

Ich öffne hier die Seiten bereits und ausschließlich im Querformat.

Also, ich habe jetzt was commited und es funktioniert auch, aber es ist nicht wirklich optimal. Ich hatte zuerst alles auf einen scrollbaren body umgestellt, dann funktioniert das Scrollen (wie erwartet) super, leider führt das aber zu sehr merkwürdigem Verhalten wenn man per Javascript zu einem Element scrollen will, was mehrfach genutzt wird (zum Attr-Feld, zum Plot control, zu devSpecHelp, usw.). Aus irgendwelchen Gründen gibt mir Javascript nicht immer die korrekte Position von einem Element an, weswegen er dann nicht zur richtigen Position scrollt. Also habe ich alles wieder rückgängig gemacht und nach eine Alternative gesucht.

Dabei ist mir aufgefallen, dass das Landscape Problem (also dass der URL Bereich nicht ausgeblendet wird) durch den Fix zustanden kommt welchen ich für das von Maui beschrieben "Kleben" implementiert habe. Dabei habe ich dann herausgefunden wodurch dieses Kleben zustande kommt: wenn man nach ganz oben bzw. ganz unten scrollt und dann weiter scrollt, will Safari den body scrollen (auch wenn er nicht scrollbar ist) und dabei läuft im Hintergrund die Smooth/Bounce Animation auch wenn optisch davon nichts zu sehen ist (und ich habe auch keine Möglichkeit gefunden das zu deaktivieren). Erst wenn die Animation vorbei ist, kann man wieder scrollen, und genau das ist dann das Kleben. Durch den Fix hatte ich weiteres Scrollen einfach verboten, was dann aber im Landscape zu dem von dir beschriebenen Problem führt.

Ich habe das nun so implementiert, dass der Fix nur im Hochformat angewendet wird, aber nicht im Querformat. Wenn man nun den Content nach ganz unten scrollt, muss man kurz warten (aufgrund der Animation) und dann kann man das fehlende Stück nach unten scrollen. Selbiges gilt dann auch wenn man wieder nach oben scrollt. Wenn du es testet, wirst du merken was ich meine.

Das ist keine optimale Lösung, aber aktuell die beste. Und genau genommen sollte Apple das einfach mal so implementieren wie es alle anderen auch machen...aber das wird wohl nichts...

[FunkOdyssey]

Ich habe deine Commits ständig im Blick und auch direkt getestet.
Mit deiner Beschreibung verstehe ich das auch und habe das auch wirklich direkt gesehen. Wenn man das nicht weiß, dann ist es erst ein wenig komisch.

Du bist wirklich unermüdlich mit deinen Features und Bugfixing. Danke.

Ehrlich gesagt finde ich die Lösung nicht wirklich gut. Es bremst halt. Man fühlt sich fremdgesteuert. Und man kann dadurch auch immer noch nicht nach oben springen.
Aber ich kann dich verstehen. Bei mir waren es früher die ständigen IE-CSS-Hacks, die mich genervt haben.

[xanker]

Ich habe deine Commits ständig im Blick und auch direkt getestet.
Mit deiner Beschreibung verstehe ich das auch und habe das auch wirklich direkt gesehen. Wenn man das nicht weiß, dann ist es erst ein wenig komisch.

Du bist wirklich unermüdlich mit deinen Features und Bugfixing. Danke.

Ehrlich gesagt finde ich die Lösung nicht wirklich gut. Es bremst halt. Man fühlt sich fremdgesteuert. Und man kann dadurch auch immer noch nicht nach oben springen.
Aber ich kann dich verstehen. Bei mir waren es früher die ständigen IE-CSS-Hacks, die mich genervt haben.

Das hat mich durchaus ein paar Stunden gekostet heute 
Wenn ich nur wüsste warum mir Javascript oder genauer gesagt Jquery nicht den korrekten Offset angibt (evtl. hat das irgendwas mit den CSS columns zu tun). Wenn der body scrollbar ist, dann funktionert alles bestens mit dem Safari, auch dass man nach oben springen kann.

Edit: Und was auch noch ein Problem ist: durch das iOS Update funktioniert das Remote-Debugging nicht mehr
https://github.com/RemoteDebug/remotedebug-ios-webkit-adapter/issues/138

Somit kann ich jetzt nicht mal mehr debuggen, sondern nur noch optisch testen.

[Hellspawn]

Hallo und guten Morgen,

ich habe jetzt folgendes Phänomen (unter iOS und Safari auf dem Mac) :

Code Auswählen Erweitern

flex.js line 1785:
TypeError: undefined is not an object (evaluating 'data.Results[0].Attributes')


Wenn ich nun eine Device anwähle wird es mir mit
"please define first" quittiert.

Aber: Ich finds immer noch klasse

[xanker]

ich habe jetzt folgendes Phänomen (unter iOS und Safari auf dem Mac) :

Code Auswählen Erweitern

flex.js line 1785:
TypeError: undefined is not an object (evaluating 'data.Results[0].Attributes')


Der Fehler ist sehr merkwürdig. Zur Erklärung: In dem Codeblock wird ein jsonlist2 vom aktuellen FHEMWEB device gemacht und danach das columns Attribut ausgelesen um die Gruppen Sortierung zu erhalten. Die einzige Möglichkeit, dass dieser Fehler auftritt ist, dass das FHEMWEB Device nicht definiert ist, was ja nicht sein kann 
Wie ist denn der Name von deinem FHEMWEB Device?

Wenn ich nun eine Device anwähle wird es mir mit
"please define first" quittiert.

Das ist noch merkwürdiger, würde aber zu obigem Fehler passen, dass das FHEMWEB Device nicht definiert ist. Das klingt irgendwie so als ob mit deinem FHEM was nicht in Ordnung ist, evtl. mal einen neustart machen?!

Aber: Ich finds immer noch klasse

Das freut mich


Edit: Ich habe dennoch mal einen Check eingebaut ob das jsonlist2 dem entspricht, was erwartet wird. Auch wenn das eigentlich nicht nötig sein sollte