(Das sind alles keine Show-Stopper, das ist alles mehr "was würde ich intuitiv erwarten")
@peuter weißt Du warum https://travis-ci.org/github/CometVisu/CometVisu/builds/688240562 nicht durchläuft? Aktuell bekommen wir den Bug nicht aus dem 0.11.2 Container raus...
(Außerdem sollten wir mal über ein 0.11.3 Service Release nachdenken. Und über den Build-Prozess, der bestehende Release-Container nicht mehr überschreibt nur weil man was in den Branch committet. Und wie man mehr Zeit/Tag bekommt ;) )
(Außerdem sollten wir mal über ein 0.11.3 Service Release nachdenken. Und über den Build-Prozess, der bestehende Release-Container nicht mehr überschreibt nur weil man was in den Branch committet. Und wie man mehr Zeit/Tag bekommt ;) )
Ich glaube mich zu erinnern, dass die in Travis benutzt Linux-Version zu alt war und man die neueren Chrome-Versionen darin nicht mehr nutzen konnte. Ich versuche gerade mal mit
dist: xenial (was wir im develop-branch nutzen).Um beim Build-Prozess fällt mir momentan nur ein, ein neues Release nur noch über Tags zu machen. d.h. man setzt den 0.11.3 Tag und erst dann gibt es einen neuen Container/Release (in allen Branches != develop).
Die Screenshots auf der Homepage-Doku sind leider kaputt
Ich tue mir gerade etwas schwer beim Testen.
Compile funktioniert schon mal ;)
Aber wenn ich da eine "alte" Config in
lib_version="8" öffne, sollte das doch laut Code irgendwie nach 9 konvertiert werden? Bei mir passiert nichts, auch heißt es beim Check, dass alles passt
Also da sollte dann ein Dialog kommen der auf eine veraltete Version hinweist und darin ein Link der dann den Manager öffnet, das Upgrade vornimmt und Dir die vorgenommenen Änderungen anzeigt, die kannst Du dann wiederum einfach abspeichern lassen oder erstmal selbst überprüfen (wonach Du dann selbst speichern musst). Das hat eigentlich auch funktioniert, hab ich ja sicherlich 50mal gemacht. Sicher, dass in der geladenen Config auch die Version 8 steht? Mir passiert das gerne mal dass ich was in source/resource/config ändere und mich dann wundere dass nichts passiert, weil ich nicht neu kompiliert (bzw. nicht dem Compiler mit —watch anhatte) und somit die Änderungen nicht ins Compiler-Verseichnis kopiert wurden.
Ansonsten wäre das schon die Hauptsache die da getestet werden müsste. Halt alles was mit fehlerhaften Configs zu tun hat und ggf. noch auf die alten PHP-Dateien verweisen würde (Config-Check, Upgrader, usw.). Auch mal eine Config mit fehlerhafter Syntax laden (also invalides XML, so dass der XML Parser des Browsers auf die Nase fällt), dann sollte auch eine Fehlermeldung kommen und ein Link auf der die Config im Text-Editor des Managers öffnet und direkt zum ersten Fehler springt.
Beim Upgrader habe ich jetzt nur die letzten beiden Versionen implementiert (also ab 7) für ältere müsste man weiterhin den PHP-Upgrader nutzen. Ich wusste einfach nicht ob noch so alte Versionen im Umlauf sind, dass sich das lohnt, da ältere Versionen zu implementieren.
@peuter beim Versuch https://knx-user-forum.de/forum/supportforen/cometvisu/1517419-anf%C3%A4ngerfrage-widget-anpassen#post1517419 nachzustellen ist mir mit dem neuen Compiler aufgefallen/passiert:
- Compiler läuft mit Watch
- per
vim source/resource/config/media/custom_switch.cssdie CSS Datei angelegt und befüllt - Compiler meldet
Cannot find library for config/media/custom_switch.css cv ll compiled/source/resource/config/media/zeigt, dass die Datei nicht übernommen wurde
- Config öffnen
- dort Manager öffnen
- dort eine andere Config öffnen (geht auch nur unkomfortabel indirekt über Burger-Menü -> Öffnen mit... -> Konfiguratio...)
- die wird nun nicht statt der ersten oder statt dem Manager sondern im Manager über der ersten geöffnet
- der (wegen falscher Lib auch erwartete) Dialog hat nun einen Bug, s.o.
=> Ich denke wir sollten hier wieder die klare Zweiteilung einführen, entweder CV oder Manager.
Dabei spricht ja nichts dagegen, dass Strg+M hier den Link aufruft
Das zusammen zu wursteln gibt nur eine Komplexität die uns keinerlei Mehrwert liefert
Es wäre deutlich mehr Arbeit, das nun wieder künstlich zu trennen als die paar Bugs zu fixen die da noch drin sind. Es liefert momentan noch keinen allzu großen Mehrwert (außer dass sofern ich das richtig erinnere einige Daten für die Dataprovider direkt aus dem geladenen Code der CometVisu entnommen werden, z.b. welche Plugins/Designs es gibt). Durch die momentane nahtlose Integration hat man aber in der Zukunft mehr Möglichkeiten.
Ich habe jetzt folgende Anpassungen vorgenommen:
- Es gibt einen extra Button zum Öffnen einer Config, diese wird dann nicht mehr als Tab im Manager sondern in einem neuen Fenster geöffnet, damit sollte das Problem der verschachtelten Navigation behoben sein und zudem das Öffnen besser zugänglich sein
- Die fehlerhafte URL zum Ignorieren der falschen Lib ist gefixt
Komisches Problem: wenn ich im Manager auf den XML-Editor gehe, so funktioniert das bei meiner Test-Umgebung bei 3 von 4 Configs:
Nur bei test_slider geht es nicht, gleichzeitig kommt die (untere) 404 Meldung.
D.h. der möchte anscheinend die falsche Config öffnen
Dabei gibt es zwischen den Dateien für mich keinen nachvollziehbaren Unterschied:
das sollten wir aber besser abfangen, sonst bekommen wir das nicht supportet
@peuter zur Info: bei cometvisu/cometvisuabstractbase habe ich etwas erweitert:
- Der Apache-Access-Log kann über
ACCESS_LOGdeaktiviert werden (hatte früher die TWS voll und überlaufen lassen; ist dort zwischenzeitlich anders gelöst, aber wir haben ja auch andere Anwender) - der Healthcheck ist jetzt implementiert
- über
STOP_ON_BAD_HEALTHlässt sich bereits beim ersten mislungenen Health checke der Container beenden. Und somit über die Docker config automatisch wieder starten. (Ein Auto-Starten basierend auf dem Health Status kann Docker leider noch nicht)
Das ganze dürfte dann ab den nächsten Container-Bauen im produktiven Bereich ankommen
@peuter der Qx Compiler macht einen komischen Fehler: Er läuft mit Watch, dann erzeuge ich mit Inkscape eine SVG im Projekt - und dann kommt eine Beschwerde wie
Beende ich den Compiler und starte ihn wieder neu (aktuell mit
Cannot find library for plugins/clock/clock_template2.svg. Die Datei wird auch nicht kopiert.Beende ich den Compiler und starte ihn wieder neu (aktuell mit
npx qx compile -c --clean --watch), dann passt es mit dieser Datei.
@peuter ich versuche gerade (endlich...) das Clock-Plugin fertig zu machen und dazu die Doku zu schreiben. Wenn ich die Screenshots lokal erzeugen will gibt's einerseits bei
grunt screenshots in der Konsole Fehlermeldungen (CSS Regel funktioniert nicht). Zum anderen zeigt der Firefox bei grunt screenshotsManual diese Fehlermeldung, die evtl. damit auch zu tun haben kann
Hattest Du nicht die Library-Version hoch gesetzt?
Vermutlich müsste nun irgendwo ein Template o.ä. angepasst werden.
Wo wäre dass denn?
@peuter nächste Frage :) - ich will gerade das ControllerInput Plugin (Bestandteil vom ceramic Design) wieder zum Laufen zu bringen. Scheitere aber daran, dass die Datei
Wo kommt denn her, dass die
/resource/plugins/controllerinput/index.js geladen werden soll, die es nicht gibt und daher natürlich einen 404 wirft. Die ControllerInpus.js wird weiter oben erfolgreich geladen.Wo kommt denn her, dass die
controllerinput/index.js geladen werden soll? Die haben wir bei keinem unserer Plugins...
Das ist das Fallback auf die "alte"-Variante vor der Qx-Umstellung. Damit werden Plugins geladen die dem System komplett unbekannt sind. Damit ist es weiterhin möglich, dass jemand mit einem lokal installierten Release der CometVisu ein eigenes Plugin entwickelt. Du musst vermutlich einfach den Part für das Plugin deklarieren, irgendwo hier: https://github.com/CometVisu/CometVisu/blob/develop/compile.json#L54 ?