Bei 5 Slidern mit der gleichen GA und im Mittelteil kontinuierliche Verstellung
Bei mir (nach Patch, vorher nicht ausprobiert) eher weiteres Langweilen.
Relevant können hier höchstens mobile Geräte sein und ihre Batterielaufzeit
Da wäre es mal spannend zu checken, ob Chrome inzwischen der Performance-Problem gelöst hat das der Flow-o-Mat verursacht hat(te?).
Wenn der Fluss angeschaltet ist, ist die Last deutlich hoch. Da hatte ich alles ausprobiert. Und am Schluss ein Bug Report / Ticket geschrieben.
Kann ja sein, dass die das wegen einem anderen Ticket gelöst haben
Oh ja,
/?config=demo_flat#id_11_ treibt immer noch die CPU hoch
Hast Du eventuell eine Idee, wie man zuverlässig checken kann, dass ein neuer Nightly-Build nötig ist. Bisher prüft der auf Änderungen innerhalb der letzten 24h. Das funktioniert nur leider nicht, wenn das nur ein Merge war und die eigentlichen Änderungen schon älter. Eigentlich müsste man sich den Commit ID des letzten Nightly Builds irgendwo speichern und damit vergleichen, aber ich wüsste gerade nicht wie/wo.
Wir sollten unbedingt bei der Online-Demo die Trick-O-Matic-Seite durch die der demo_flat ersetzen. Die aktuell sieht so nach Spielzeug aus...
1 reply
Evtl. können die neuen GitHub Actions hier irgendwie helfen?
Ich benutze Bintray auch nur hier, das war damals das einzige was ich gefunden habe. Und mit den Github-Actions kenne ich mich gar nicht aus. Ich weiß nicht ob die da bessere Analysemöglichkeiten haben, vermute aber nicht denn letztendlich muss man in beiden Fällen die Info aus git rausbekommen.
so selten wie wir ein Merge haben ist das effizienter
Sobald man regelmäßig mehrere Merges pro Tag hat ist natürlich Nightly wieder effizienter
Wenn man den Dateinamen der Archive nur mit einem Datum versieht und die Zeit weglässt, dann hätte man zumindest immer nur einen Build pro Tag, weil der immer überschrieben würde, falls es mehrere Merges am Tag gibt. Dann hätte wir zwar immer noch Build die man eigentlich nicht braucht, weil da keine Änderungen an der Applikation selbst gemacht wurde, aber so oft kommt das nun auch nicht vor.
@peuter hast Du eine Idee warum bei https://sentry.io/organizations/cometvisu/issues/1664945124/events/cb885a6afc5647cda39299724fe887e8/ die Source Maps nicht mögen?
@ChristianMayer Mit #1024 sind, bis auf die Icons, nun alle Submodule aus dem Projekt raus. Mit dem dort enthaltenen Compiler Update kommt es allerdings beim Kompilieren zu Warnungen. Dazu habe ich bereits ein Ticket aufgemacht (qooxdoo/qooxdoo-compiler#690). Da das nur Warnungen sind, die keine negative Auswirkungen haben, denke ich können wir für den Moment damit leben, bis das gefixt ist.
Ich wollte mir auch mal https://forum.timberwolf.io/viewtopic.php?f=37&t=2139 (insb. das Ergebnis in den letzten Beiträgen) ansehen, bin aber noch nicht dazu gekommen
Da das wohl auf eine Änderung zurück geht, die Du für OpenHAB gemacht hattest, weißt Du evtl. schneller was da nun richtig ist
Ja der Fix sollte dafür sorgen, dass auf JSON geparsed werden kann bei den ein Linefeed innerhalb der Werte ist, also z.B.
{
"key": "wert
mit LineFeed"
}Aber der eigentliche Fehler lag in einer fehlerhaften openHAB Konfiguration und konnte anderweitig gelöst werden. Da der Fix nun eigentlich nicht mehr nötig ist und scheinbar mehr Probleme macht als er löst, können wir den gerne wieder reverten.
@peuter mit dem neuen Manager gibt's drei kleine Unschönheiten: Wenn ich eine normale Seite offen habe, den Manager öffne, dort bei den Configs:
- doppelt klicke, öffnet sich der Editor statt die Konfig selbst (was ich intuitiv erwartet hätte)
- Rechtsclick -> Öffnen mit... -> Kofiguratio... => Hier sollte der Name ausgeschrieben sein (bzw. vermutlich das Menü-Fenster halt bisschen größer sein)
- Rechtsclick -> Öffnen mit... -> Kofiguratio... auswähle, dann öffnet sich die Konfig im Sub-Fenster des Managers (= der Fehler). Nun kann ich in der Konfig eine weitere Instanz des Manager öffnen, und rekursiv weiter machen :)
Also das sich die Config als Tab im Manager öffnet ist zunächst einmal Absicht (was nicht heißen soll, dass die Absicht über jeden Zweifel erhaben ist). Aber die urspüngliche Idee dabei was ,dass das als Vorschau benutzt werden solle ggf. dann später mit automatischem Reload, wenn man an der Config Änderungen vorgenommen hat. Diesen Rekursionspfad müsste man natürlich unterbinden.
Und für den Doppelklick > Editor gilt eigentlich das selbe, ich hätte gedacht, dass ich im Manager eher Dinge editieren möchte und daher das als Default genommen. Aber darüber kann man diskutieren, im Grunde gibt es Argumente für beide Varianten. Mir fällt es schwer da jetzt einer den Vorzug zu geben, wenn Du der Meinung bist, dass das Default-Verhalten "Ansehen" und nicht "Editieren" sein sollte, können wir das gerne ändern.
Und für den Doppelklick > Editor gilt eigentlich das selbe, ich hätte gedacht, dass ich im Manager eher Dinge editieren möchte und daher das als Default genommen. Aber darüber kann man diskutieren, im Grunde gibt es Argumente für beide Varianten. Mir fällt es schwer da jetzt einer den Vorzug zu geben, wenn Du der Meinung bist, dass das Default-Verhalten "Ansehen" und nicht "Editieren" sein sollte, können wir das gerne ändern.
Neben meinem intuitiven Gefühl wie ich es erwartet hätte, gibt es aber auch ein Argument für Ansehen: Einfache Aktionen sollen unschädlich sein, potentiell schädliche sollen nicht einfach sein
Ansehen ist unschädlich, Editieren kann schaden verursachen
Daher: Klick = Ansehen. Editieren = kein simpler klick mehr
Und für's ansehen/vorschau hätte ich die einfach in einem neuen Fenster (Tab) geöffnet. Schneller ist eine Vorschau nicht geschlossen als die bekannten Mechanismen des Betriebssystems/Browsers zu verwenden
(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