CometVisu - (interner) Beta-Test

[Chris M.]

Das hier steht noch in meinem Backlog:

@Chris: erleuchte mich doch bitte bzgl. #845 - einen fixen delay fürs erste laden der diagrams (RRD's) fände ich ziemlich unsmart aber sie sollten warten bis der client initial fertig ist, weil das sieht blöd aus und bremst doch gehörig..

Da ich ehrlich gesagt spontan nicht weiß, was ich dazu sagen soll, bzw. was gefragt ist und das im Zweifel nur verloren geht: bitte einen Feature Request draus machen, dann können wir nach der 0.6 wieder drüber sprechen, da's dann keiner vergessen hat...

[JNK]

Siehe #1204: indirekt ist das gefixt im post-0,6.0, weil nur refresht wird, wenn das Diagramm sichtbar ist.

Gruß,

Der Jan

[makki]

Jep, das meinte ich; FR #3338493 gibts im Zweifel auch dazu damits nicht untergeht..

Makki

[Chris M.]

Wie hier im ChangeLog zu lesen und vor ein paar Postings hier im Thread auch: der Infotrigger hat einige Änderungen hinter sich => bitte eigene Config anpassen und ausgiebig testen!

Gab's keine Probleme oder keine Tests?

[swiss]

Bei mir funktioniert der Infotrigger bis jetzt problemlos.

[makki]

infotrigger: Eher keine Tests fürchte ich, bin davon ausgegangen das es an meiner config liegt, zum tieferen suchen war noch keine Zeit.
Bei relative sendet er scheinbar garnichts mehr(?)

Makki

[Chris M.]

infotrigger: Eher keine Tests fürchte ich, bin davon ausgegangen das es an meiner config liegt, zum tieferen suchen war noch keine Zeit.
Bei relative sendet er scheinbar garnichts mehr(?)

Die Config-Änderung ist nicht abwärtskompatibel. Daher mal bitte gegen die aktuelle Syntax prüfen.

Genau wegen solchen Punkten bohre ich nach. Wenn jeder meint, dass es vermutlich geht nur die lokale Config halt gerade nicht mag, haben wir das Risiko, dass wir im Zweifel ein Paket rausgeben, wo das Paket grottig ist und alle lokalen Configs eigentlich funktionieren würden...

[swiss]

Den Fehler hab ich gemacht

Aber jetzt funktioniert die aktuelle Version mit korrekter Syntax (Ist auch dem Handbuch zu entnemen)

[Chris M.]

Release 0.6.0-RC4

Jetzt ist's ernst: Relase 0.6.0-RC4 ist hochgeladen!

Das heißt für uns Entwickler: das SVN(*) ist eingefroren. Bitte keine Check-Ins ohne vorherige Diskussion!

Das heißt für alle (Beta-)Tester: bitte noch mal alles testen.
Entweder jetzt schon das Paket oder das hoffentlich bald von Makki erzeuge Debian-Paket. Wer SVN nutzt, kann natürlich jetzt schon updaten.

Die -RC3 habe ich übrigens quasi übersprungen, da kaum dass die im SVN angekommen war, ich noch gemerkt hatte, dass die XSD veraltet war

--
(*) Natürlich nur der CV trunk

[makki]

infotrigger

Die Config-Änderung ist nicht abwärtskompatibel. Daher mal bitte gegen die aktuelle Syntax prüfen.

Nee, den Fehler hab ich gemacht: den source nicht gelesen
-> variant="relative" fehlte bei der GA

Finde ich aber mindestens "deutlich unschön" das man den da händisch reintipsen soll; das ist doch doppelt gemoppelt/ging vorher auch ohne(?)
Man wird bei relative (z.B. 0/1 für lauter/leiser, hoch/runter, ...) ja eh niemals den zuletzt gesendeten Wert zur Anzeige bringen wollen sondern den Status, also kann man das "relative" doch auch einfach vom widget übernehmen odrr?

Makki

P.S.: Packerl folgt, ich will aber vorher noch etwas rausfinden, das mir Micha (vento) gestern zeigte und das via GPRS (Kemmern halt..) auch deutlich nachvollziehbar war: beim switchen der Designs mit wird (bisher nur eine Vermutung, scheint ne Webkit-spezifische Sache zu sein) trotz cache usw. was nachgeladen, das gefühlt ewig dauert..
Ich bau mir jetzt zum generellen testen solch widriger Umstände mal ein Wlan mit Traffic-shaping auf 56kps

[Chris M.]

-> variant="relative" fehlte bei der GA

Finde ich aber mindestens "deutlich unschön" das man den da händisch reintipsen soll; das ist doch doppelt gemoppelt/ging vorher auch ohne(?)
Man wird bei relative (z.B. 0/1 für lauter/leiser, hoch/runter, ...) ja eh niemals den zuletzt gesendeten Wert zur Anzeige bringen wollen sondern den Status, also kann man das "relative" doch auch einfach vom widget übernehmen odrr?

Siehe Tabelle unter: SourceForge.net: CometVisu/infotrigger (Deutsch) - Open Automation

Das variant="relative" kann man im relativen Modus nicht weg lassen, denn sonst kann das Widget nicht unterscheiden, ob die Adresse für den Status oder für die Buttons ist.
(Genauer, entweder variant="relative" oder variant="absolute" kann man weg lassen, müsste noch mal im Code nachlesen welches, aber das sorgt für noch mehr Verwirrung. Daher die dringende Empfehlung im change="relative" Modus immer die Variant mit angeben!)

P.S.: Packerl folgt, ich will aber vorher noch etwas rausfinden, das mir Micha (vento) gestern zeigte und das via GPRS (Kemmern halt..) auch deutlich nachvollziehbar war: beim switchen der Designs mit wird (bisher nur eine Vermutung, scheint ne Webkit-spezifische Sache zu sein) trotz cache usw. was nachgeladen, das gefühlt ewig dauert..
Ich bau mir jetzt zum generellen testen solch widriger Umstände mal ein Wlan mit Traffic-shaping auf 56kps

Keine Ahnung was und wo's klemmt. Aber Designtoggle ist kein Feature der CometVisu (sondern ein Hack für die Widget Demo) und daher für mich kein relevanter Anwendungsfall.
Oder wie oft steht einer vor der Visu und Toggelt die Designs durch, weil ihm Langweilig ist oder gerade die Wand anders gestrichen wurde...

[makki]

.. denn sonst kann das Widget nicht unterscheiden, ob die Adresse für den Status oder für die Buttons ist.

Hab ich vielleicht unverständlich geschrieben, aber genau das gemeint: bei relative fällt mir kein Anwendungsfall ein, wo man jemals den Wert der "sendenden GA" zur Anzeige bringen wollen wird! Ergo ists obsolet:
-> bei absolute ists klar (da muss man den variant nicht angeben, sonst hätten bei mir beide Fälle gestern nicht funktioniert..)
-> bei relative ist die Sache für mich auch klar(*): Default ist: nur anzeigen der hörenden (readonly) GA's.
*Vielleicht hab ich heute zuviel "reine KNX-Lehre" gefrühstückt, aber für mich gibts immer eine Schalt- und eine Status-GA (sei es nun Lautstärke, Rolladen oder Dimmwert), würde mich auch bereiterklären es (post 0.6 natürlich) zu ändern; wer Spass dran hat kann den variant ja dann trotzdem anders eingeben aber default sollte man IMHO nicht müssen..

Keine Ahnung was und wo's klemmt. Aber Designtoggle ist kein Feature..

Ich auch noch nicht so genau und Sonnenklar: es ist blödsinn sich in den Flur zu stellen und Designtoggle zu drücken.
Aber es sieht halt blöd aus. Ich sags nur ungern, aber hier gehts rein um die Leute aus der Marketingsabteilung
Der erste Kontakt mit der CV wird regelmässig u.a. mit dem (coolen!) Designtoggle stattfinden und der sollte halt genauso ratz-fatz sein wie später im echten Leben damit; nötigenfalls ehrlichgesagt auch gerne halb-gefaked..
-> Ich will aber jedenfalls möglichst noch rausfinden - deadline morgen - woran es liegt und damit ob sich das mit vertretbarem Aufwand abstellen lässt..

Makki

[Chris M.]

Hab ich vielleicht unverständlich geschrieben, aber genau das gemeint: bei relative fällt mir kein Anwendungsfall ein, wo man jemals den Wert der "sendenden GA" zur Anzeige bringen wollen wird! Ergo ists obsolet:
-> bei absolute ists klar (da muss man den variant nicht angeben, sonst hätten bei mir beide Fälle gestern nicht funktioniert..)
-> bei relative ist die Sache für mich auch klar(*): Default ist: nur anzeigen der hörenden (readonly) GA's.
*Vielleicht hab ich heute zuviel "reine KNX-Lehre" gefrühstückt, aber für mich gibts immer eine Schalt- und eine Status-GA (sei es nun Lautstärke, Rolladen oder Dimmwert), würde mich auch bereiterklären es (post 0.6 natürlich) zu ändern; wer Spass dran hat kann den variant ja dann trotzdem anders eingeben aber default sollte man IMHO nicht müssen..

Vorab: Wenn was am Verhalten der config geändert wird, dann müssen wir das jetzt, vor der 0.6.0 machen.

Du brauchst aber den Variant eben um zwischen "Schalt-GA" (-> variant="relative") und "Status-GA" (-> variant="absolute") zu unterscheiden. Ich wüsste auch nicht, wie das anders gehen soll.
Was aber tatsächlich nicht optimal ist, ist dass die auch "relative" und 2absolute" heißen. Wahrscheinlich würde ich die nun "switch" und "display" nennen...

[Designtoggle]
-> Ich will aber jedenfalls möglichst noch rausfinden - deadline morgen - woran es liegt und damit ob sich das mit vertretbarem Aufwand abstellen lässt..

Meine Vermutung: das Einbinden der Schriftart bei Alaska. Die muss sich erst durch die Leitung quälen...

Das ist übrigens der Grund, warum ich beim Pure ganz bewusst auf eine Schriftart gesetzt habe, die nach allgemeinem Verständnis auf den meisten Endgeräten per Default ist...
Dennoch finde ich es gut, wenn Alaska seine eigene Schriftart nutzt - denn es gibt genug Anwendungen wo die paar Millisekunden (im lokalen Netz) schnurz sind. Und im Zweifel nutzt man halt Alaska an der Wand und Pure auf dem Smartphone.

[makki]

Vorab: Wenn was am Verhalten der config geändert wird, dann müssen wir das jetzt, vor der 0.6.0 machen.

Nein, an der config wird&soll es nichts ändern, nur wenn die config sagt variant="" sollte es IMHO nen sinvollen default geben.

Was aber tatsächlich nicht optimal ist, ist dass die auch "relative" und 2absolute" heißen. Wahrscheinlich würde ich die nun "switch" und "display" nennen...

Womit auch geklärt wäre, warum ich die initial genau andersrum benannt habe: ist eine Frage der Sichtweise: absoluter Wertversand (jetzt absolute) kann man auch als relative Wertänderung betrachten
Auch egal, der AW muss es kapieren und das steht ja jetzt schön in der Doku.

Meine Vermutung:

Es sind - wie so oft - mindestens 2 Ursachen. Aber bevor ich Vermutungen in den Raum stelle -> lieber erstmal die Detailanalyse machen (die TTF sind zwar definitiv Teil des Problems, nur sollten die ja trotzdem gecached werden.. meine Baustelle..)
Wenn dem so ist wie ich denke, klar ist es im 100MBit LAN total egal, sollte man zumindest eben darauf hinweisen..

Makki

[Chris M.]

Was aber tatsächlich nicht optimal ist, ist dass die auch "relative" und 2absolute" heißen. Wahrscheinlich würde ich die nun "switch" und "display" nennen...

Womit auch geklärt wäre, warum ich die initial genau andersrum benannt habe: ist eine Frage der Sichtweise: absoluter Wertversand (jetzt absolute) kann man auch als relative Wertänderung betrachten
Auch egal, der AW muss es kapieren und das steht ja jetzt schön in der Doku.

Wer ist noch dafür hier die Bezeichnung zu ändern (SVN ist ja frozen, daher Änderung nur nach Abstimmung...)?

Ein neues Release ist ja gleich gemacht und wir wären etwas mehr Poka Yoke...