EDOMI-Releases/Updates | Aktuell: Version 2.03

[timberland]

Das laden über VPN geht auch wesentlich schneller mit den PNG's

[gaert]

Ich hatte zunächst meinen Seitenhintergrund in der Visu als SVG definiert - mit dem Ergebnis, dass bei jedem Seitenwechsel der Hintergrund kurz "flackerte" (also das SVG offenbar neu gerendert wurde). Nach diversen Versuchen habe ich das SVG dann in PNG konvertiert (online-Tool) und nu' ist alles ruhig...

[Stoxn]

Okay, danke für die Info und den Tipp mit dem alternativen Browser. Genau, bei mir muss auch alles immer neu geladen werden und es dauert verhältnismäßig lange, vor allem über VPN.

Ich erstelle jetzt einige Designvorlagen mit PNGs für wiederkehrende Elemente (stand schon lange auf meiner Liste) und vergleiche mal die Ladezeiten.

[timberland]

@Stonx

ich habe nur die SVG's gegen PNG's getauscht und nicht zusätzlich neu geladen. Somit wenn ein SVG getauscht ist, ändern sich alle wo es in der Visu angezeigt wird.
Und was mir noch aufgefallen ist - ich verwende ja Frameless am iPhone - hier bleibt jetzt die Verbindung auch bestehen wenn ich raus gehe und die app wieder starte. Vorher mit den SVG's musste die Visu immer erst geladen werden.
Denke es wird schon einen Grund haben, warum bei iOS keine SVG's zu finden sind.

[wintermute]

Isch auch nisch
Jedenfalls hatte ich immer die selber Flacker-Kandidaten, ich glaube vornehmlich dann, wenn sich Elemente ueberlagert haben, jetzt ist alles ruhig. Aber wie geschrieben: kann sein, dass es nur im Chromium passt...

[gaert]

wintermute

Nach meinen Informationen liegt das "Flackern" bei einem SVG-Hintergrund (je nach Browser) nicht am Cache, sondern an der Art und Weise wie die SVGs gerendert werden. Offenbar werden diese per Default nicht wie Bitmaps quasi im Hintergrund gerendert und dann erst ins DOM eingefügt, sondern "on the fly" nach(!) dem DOM-Aufbau gerendert (ähnlich wie Canvas). Mag sein, dass Chrome dies inzwischen besser handhabt - isch nix wissen...

[Stoxn]

wintermute Besten Dank für den Workaround, Michael.
timberland Das hört sich so schnell an - hast Du eine schnellere Lösung (direkt in der DB?), als alle Bilder einzeln zu ersetzen? Ich hatte anfänglich alle PNGs durch SVGs ersetzt, was schon recht lang gedauert hat. Jetzt habe ich weitaus mehr SVGs in Nutzung.

Sorry, bisl am Thema vorbei.

[timberland]

Darum habe ich gestern wieder auf png's umgestellt. Zumindest auf iOS um einiges flüssiger und performanter als mit den svg's.

[wintermute]

Das hat nichts mit EDOMI zu tun - SVGs werden von den mir bekannten Browsern nicht gepuffert (beim Rendern).

Bei mir (Chromium, OSX) flackert auch ein Grossteil der SVGs, nicht alle, aber doch einige. Weil mir das dann irgendwann doch irgendwie auf den Keks gegangen ist:
-in der Datei /etc/httpd/conf/httpd.conf nach "ExpiresDefault" suchen, in der Zeile drueber folgendes reinschreiben

ExpiresByType image/svg+xml "access plus 1 months"

(kann man auch irgendwo anders in die Datei schreiben, aber da passt es so huebsch hin )
-Webserver neu starten

/etc/init.d/httpd restart

Wie gesagt, im Chromium funktionierts, zu anderen Browsern kann ich grad nix sagen

HTH :: Michael

[NorbertB]

Du kannst die Einträge damit in einen anderen Ordner verschieben.
Sortieren innerhalb eines Ordners ist (noch) nicht möglich. Es wird immer nach ID sortiert.

[nno]

Habe heute erst gesehen, dass es in der Liste der Logikseiten beim Rechtsklick auf eine Logik die Optionen "Element merken" und "Element hierher verschieben" gibt. Sollte es damit möglich sein die Anordnung der Einträge in der Liste zu verändern? Wäre super, habe ein paar Logiken die zusammengehören, würde sie daher gerne untereinander aufgelistet haben. Allerdings funktioniert das Verschieben bei mir mit 1.47 nicht. Die Reihenfolge ändert sich nicht.

[gaert]

Richtig, beim ESF-Import werden nur die Namen "synchronisiert" - steht ja auch in der Hilfe. Und das ist auch besser so, weil das ESF-File nicht wirklich den DPT enthält: Meistens muss man den DPT von Hand anpassen nach dem Import - und das wäre dann bei jeder Aktualisierung (Import) fällig...

[eriche]

Klingt sehr gut
Weil wir gerade beim Import von GA sind.

Mir ist aufgefallen, dass bestehende GA scheinbar bei einem neuen OPC Import nicht mehr angetastet werden.
Ich änderte Datentypen - wäre es möglich beim Import einen 1:1 Vergleich zu machen und sofern etwas anders ist, dem User eine Interaktion zu bieten, wo er selektieren kann was er machen möchte (GA überschreiben, löschen,...).

Beim Visu import denke ich, wenn hier vorrangig interne KO verwendet warden, könnte man diese ja beliebig benamsen.
Nur bei KNX GA wird es problematisch - wenn ich das richtig verstehe.

[STSC]

Ach übrigens... Import/Export ist in Arbeit - allerdings dauert das noch "ein wenig", ist nämlich ziemlich kompliziert im Detail. Den Anfang machen natürlich die Visuelemente - das Problem sind hier z.B. die KOs, denn diese müssen ja ggf. ebenfalls exportiert/importiert werden. Technisch nicht die große Hürde, aber von der "Logik" her etwas sonderbar - Beispiel:

Ein Visuelement setzt per Befehl die GA 0/0/1 auf einen Wert. Dieses KO wird nun exportiert und (optional) auch importiert. Nur dürften die GAs wohl kaum zwischen den einzelnen Nutzern übereinstimmen... Daher ist deren Export eigentlich Blödsinn, andererseits sind u.U. gerade die KO-Befehle interessant im Kontext eines (komplexeren) Visuelements.

Meine Lösung sieht bislang in Etwa so aus: Die KOs werden quasi referenziert (z.B. "@1") und im Abschnitt "comobjects" (provisorisch) dann deklariert. Beim Import wird man dann wahrscheinlich wählen können, ob man die KOs 1:1 übernehmen möchte oder entsprechend anpassen muss (grob gesagt).

Wow, das gefällt mir Darauf warte ich jetzt noch, dann lege ich auch mit der Visu los. Super Arbeit!

Vielleicht noch eine Idee mit den GAs. Vielleicht könnte man so eine Art virtuellen GA Namen verwenden, der auch in der Visu benutzt werden muss. Und in einer Art GA Editor, wo man sich das ganze von der ETS auch importieren kann, wird das ganze verknüpft

[benji]

Das nenne ich mal eine Ansage !!!!