Hauptmenü

Neuer Style: f18

Begonnen von rudolfkoenig, 07 Januar 2018, 14:51:18

Vorheriges Thema - Nächstes Thema

mi.ke

Klasse, so funktioniert es hervorragend.

Herzlichen Dank!

Ich gestehe, "Copy for forum.fhem.de" hatte ich mir bis dato gar nicht angesehen und immer die Kommandozeile genutzt, werde dies aber in Zukunft ändern.
FHEM 31310 | Mini PC N100, RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN / WAN (VPN).
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 5 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-*, MQTT2, ZigBee, AMAD, PCA301, arlo, Aqara,

cwagner

Ich benutzte seit langem und mit großer Begeisterung F18. Nun habe ich erstmals einen weblink (iframe) eingebaut und wollte diesen in meinem Dashboard an die gewünschte Stelle mit der Funktion 'Dragging active' an die gewünschte Stelle ziehen. Ups: alle Elemente haben den Kreuzcursor zum Skalieren der Fläche und den zweiten zum Verschieben. Nur Weblink nicht. Ich habe sicherheitshalber alle Beispiele aus der cmdRef nachgebaut, überall fehlen die Kreuzcursors. Beifund: Das gilt auch für die Pin-Nadel (mit Ausnahme der Befehlsoption cmdList).
Was mache ich falsch, wo kann ich mir ein Ei auf die Schiene genagelt haben?

Christian
320 Devices in MariaDB: Lambda WP an Ecolink-Speicher, FBH, Solarthermie, kontroll. Lüftung mit WRG und Erdwärmetauscher
HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM ESP3), MQTT2, Shelly, SMA (eC2, PV, HM, HS)
DOIF (Perl/uiTable), PID20,Micropelt IRTV, SolarForecast auf PI5

rudolfkoenig

Danke fuer den Hinweis, weblink iframes/images habe ich wohl vergessen zu testen bzw. anzupassen.
Das habe ich jetzt nachgeholt.

cwagner

Hmh, erstmal danke, dass Du Dich um mein Thema so schnell gekümmert hast.

Habe aus dem repo die Version heruntergeladen
Mit meinem iframe und mit dem fhem.de-Beispiel aus der Hilfe habe ich es ausprobiert.

Beide hatten weder den aktivierten Hide-Pin noch die Kreuzcursors.
In einem Raum, in dem ich alle Positionen mit dem Ø gelöscht hatte, stand das Element dann artig weiter unten auf der Seite, mit dem nächsten aktualisieren sprang es in die linke obere Ecke. Das macht es in allen Räumen, wo ich es platziert habe.
Das passiert grundsätzlich in allen Räumen, auch welchen, der weblink als einziger haust.

Und noch eine Beobachtung. In der bisherigen Version konnte ich Größenvorgaben einfach Leerzeichen getrennt hinter die URL stellen:  width="570" height="170" frameborder="0"

In der neuen Version wird das nicht beachtet, ich muss die Angaben in das attribut htmlattr eintragen, dann werden sie durchgeführt.

Hätte ich noch irgendeine lib oder sonstige Info aktualisieren müssen?

Christian
320 Devices in MariaDB: Lambda WP an Ecolink-Speicher, FBH, Solarthermie, kontroll. Lüftung mit WRG und Erdwärmetauscher
HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM ESP3), MQTT2, Shelly, SMA (eC2, PV, HM, HS)
DOIF (Perl/uiTable), PID20,Micropelt IRTV, SolarForecast auf PI5

rudolfkoenig

ZitatHabe aus dem repo die Version heruntergeladen
Was genau?
Geaendert wurden mehrere Dateien (f18.js und 98_weblink.pm).

cwagner

#515
Danke für den Hinweis.
Wie dumm von mir, hätte ich ja erkennen müssen, dass auch die f18.js geändert ist! Die habe ich jetzt nachgeladen (f18.js 31626 2026-09-07 13:08:56).Zusammen mit der 98_weblink.pm 31626 2026-09-07 13:08:56 habe ich zunächst keine Veränderung feststellen können, um mich dann zu erinnern, dass auch bei plots der Kreuzcursor für das Diagramm unten am Device-Namen hängt.

Also attribut nodetaillink auf 0 und mit dem Kreuzcursor das Element in drei Räumen unterschiedlich platziert und gespeichert. Position ist persistent.

nodetaillink wieder auf 1 und die Räume aufgerufen. Der weblink ist wieder versprungen und zwar jeweils an Position oben links.

Die anderen Elemente meines Dashboards, mit Ausnahme der gplots haben ja alle eine "Dachzeile", die nicht linken (hilfreich gegenunerwünschten Aufruf der Detailansicht), entweder mit der Gruppen-Namen oder dem Device-Typen.
Also habe ich einen Gruppentitel vergebe et voilá:
Mit Gruppentitel habe ich auch einen Größen-Cursor und oben Verschiebecursor, mit Detaillink wenigstens einen Schiebecursor unten am Element.
Ohne Gruppe und ohne Detaillink gilt das beschriebene Verhalten.

OK, ich könnte jetzt mit dem Gruppentitelleben, hätte dann den Positionierungsvorteil und muss nur aus den anderen Elementen ein paar Pixel Hähe rausschwitzen.

Christian
320 Devices in MariaDB: Lambda WP an Ecolink-Speicher, FBH, Solarthermie, kontroll. Lüftung mit WRG und Erdwärmetauscher
HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM ESP3), MQTT2, Shelly, SMA (eC2, PV, HM, HS)
DOIF (Perl/uiTable), PID20,Micropelt IRTV, SolarForecast auf PI5

rudolfkoenig

Alternativ wird detaillink versteckt mit dem CSS:

Fuer alle iframe/image weblinks:
div.label { display:none; }
odern nur fuer Einzelne:
div[data-name=Room_<raumName>_<iframeName>] {display:none;}

Sidey

Hallo Rudi,

in f18 werden Positionen, die man im Raum per Drag & Drop oder Größenänderung setzt, falsch gespeichert, wenn man dabei gescrollt hat. Nach dem nächsten Laden liegt das Element um den Scroll-Betrag zu weit oben (und teilweise links). Bei mir endeten Elemente so mit negativem top (z. B. -600) komplett oberhalb des sichtbaren Bereichs.

Reproduktion

Einen Raum mit f18-Layout öffnen, in dem so viele Elemente stehen, dass die Seite scrollt.
Etwas nach unten scrollen (z. B. 500 px).
Ein Element über den Pfeil-Griff verschieben (oder die Größe ändern).
Es steht optisch korrekt, aber im styleData steht top um den Scroll-Betrag zu klein, z. B. optisch 880 px, gespeichert 380 px.
Seite neu laden: Das Element springt um 500 px nach oben.

Ursache
In f18.js (f18_makeDraggable, Funktion save()) wird die Position mit $(el).position() ermittelt.
div#content ist position:fixed; overflow:auto und damit der Offset-Parent der Elemente. jQuery position() berücksichtigt den Scroll-Offset (scrollTop/scrollLeft) des Offset-Parents nicht. Das CSS-top des Elements stimmt, nur der gespeicherte Wert ist um scrollTop zu klein. Die gespeicherten oTop/oLeft sind nicht betroffen, weil sie als Differenz zweier position()-Werte denselben Fehler herausrechnen.

Getestet mit f18.js Revision 31726 in Chromium.

Das Problem lässt sich beheben:

--- a/www/pgm2/f18.js
+++ b/www/pgm2/f18.js
@@ function save()
   {
     var nep = $(el).position();
+    var c = $("div#content");   // position() ignores the scroll offset of the offset parent
     var cw = $(comp).width();
     var svg = $(comp).find(">svg");
     if($(svg).length==1 && $(svg).attr("id").indexOf("SVGPLOT")==0) // Forum #126070
       cw = $(svg).width();
     f18_setAttr("Pos."+$(el).attr("data-name"), {
-      left:nep.left, top:nep.top,
+      left:nep.left+c.scrollLeft(), top:nep.top+c.scrollTop(),
       width:cw, height:$(comp).height(),
       oTop:cp.top-ep.top, oLeft:cp.left-ep.left
     });
   }

Es handelt sich hierbei um einen KI generierten fix.


Bereits falsch gespeicherte Positionen korrigiert das natürlich nicht, die muss man einmal neu setzen.

Grüße Sidey
Nutze: SIGNALDuino, Homematic, Raspberry Pi, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt, tasmota

Maintainer von: SIGNALduino, SD_WS*, fhem-docker, alexa-fhem-docker, fhempy-docker, WebAuth, fhem-mcp, midea-mqtt, whatsmeow-mqtt, alexa-cookie-service
https://github.com/sidey79?tab=repositories

rudolfkoenig

Danke fuer den Hinweis, ich habe den Fix eingecheckt.

schwatter

Nabend Rudolf,

mir ist bewusst, du hast auch weiterhin kein Cumulative Layout Shift (CLS). Aber hier ein weiterer Versuch
es ins SVN zu bekommen. Standard ist es aus. Aktivierbar unter "f18 special" mit "Hide page until loaded".

f18.js
--- a/www/pgm2/f18.js
+++ b/www/pgm2/f18.js
@@ -21,6 +21,18 @@
 };
 var f18_isday;
 
+// CLS: optional (per browser, default off, see "f18 special"):
+// hide the page until window.load, but at most 3 seconds.
+(function() {
+  var h = document.documentElement, on = false;
+  try { on = localStorage.getItem("f18hold") == "true"; } catch(e) {}
+  if(!on)
+    return;
+  h.classList.add("f18hold");
+  var release = function() { h.classList.remove("f18hold"); };
+  $(window).on('load', release);
+  setTimeout(release, 3000);
+})();
 $(window).resize(f18_resize);
 $(document).ready(function(){
   f18_room  = $("div#content").attr("room");
@@ -469,6 +481,7 @@
     appendTo = "table#f18ts";
 
     addHider("serviceWorker", true, "WebPush", f18_swToggle, true);
+    addHider("f18hold", false, "Hide page until loaded<br>(avoids layout jumps, this browser only)", null, true);
     addHider("rightMenu", false, "MenuBtn right<br>on small screen",f18_resize);
     addHider("savePinChanges", false, "Save pin changes");
     addHider("showDragger", false, "Dragging active", function(c){

f18style.css
--- a/www/pgm2/f18style.css
+++ b/www/pgm2/f18style.css
@@ -1,5 +1,7 @@
 @import url("dashboard_style.css");
 
+html.f18hold body { opacity: 0; }
+body { transition: opacity .15s ease-in; }
 body,input,select,textarea { font-family:Arial, sans-serif; font-size:16px;}
 td {padding: 0;}
 textarea, .ui-dialog.ui-widget textarea { font-family:Courier; }

Gruß schwatter