CometVisu - (interner) Beta-Test

[JNK]

Ich hätte da noch was GANZ wichtiges:

In eigentlich allen widgets ist das Label in einem Label-Element, im diagram-plugin im text-content. Das ist ein Riesenproblem, wenn man das nochmal erweitern will, weil der text-content von Elementen mit verwurstet wird bei der Label-Erzeugung.

Aufgefallen ist mir das, weil ich diagram-popup erweitern wollte um die Anzeige des aktuellen Werts (FR# 3128533), wenn man ein <address>GA</address>-Element einfügt, dann steht im Label nicht mehr nur der text-content sondern "text-contentGA".

Das sollten wir vor der öffentlichen Beta auf jeden Fall ändern, weil es die zwingend eine Änderung der config-Datei erfordert, wenn man das ändert.

Gruss,

der Jan

[Chris M.]

Stimmt, da scheint die Umstellung vor einiger Zeit vorübergegangen zu sein

Da ich auch dafür bin, die Config-Syntax vor der 0.6.0 sauber zu haben, bin ich auch für eine Änderung. In dem Zusammenhang würde ich Infotrigger auch anfassen, wie neulich diskutiert.

Wer ist noch dafür - oder wichtiger: wer ist dagegen?

(Ergebnis wäre ein neuer RC...)

[daviid]

wir können ja doodeln

nein quatsch bin auch dafür, im Moment hält sich die Zahl der bteroffenen Nutzer noch in Grenzen.

[swiss]

Jup auch dafür.

[Chris M.]

Das waren ausreichend Dafür-Stimmen, v.a. da keiner dagegen war

0.6.0-RC5 ist jetzt im SVN, Paket gleich hochgeladen. Wann das Debian-Paket zur Verfügung steht, wird Makki sicherlich schreiben...

Bitte unbedingt den geänderten Infotrigger testen (Variant heißt jetzt "button" und "display")

Außerdem bitte die Labels bei den Diagrammen testen - hier war die Änderung nicht ganz so trivial!

[JNK]

Außerdem bitte die Labels bei den Diagrammen testen - hier war die Änderung nicht ganz so trivial!

Als Reviewer hätte ich angemerkt, dass Du in diagram.data auch auf labelElement hättest zurückgreifen können, statt nochmal $p zu durchsuchen. Aber der Rest sieht gut aus und entspricht dem, was ich lokal gemacht habe.

Gruß,

Der Jan

[makki]

Paket ist raus, werde testen..

Makki

[Chris M.]

Als Reviewer hätte ich angemerkt, dass Du in diagram.data auch auf labelElement hättest zurückgreifen können, statt nochmal $p zu durchsuchen.

Bitte dir merken und nach der 0.6.0 ändern. Wichtig war mir halt, dass die Config-Syntax passt

[Chris M.]

Da es langsam Zeit wird zu bestimmen, wo die Diskussionen weitergehen: Bitte Umfrage https://knx-user-forum.de/knx-eib-fo...cometvisu.html ausfüllen!

[makki]

Bis Einigkeit besteht wo, mach ich mal hier weiter :
Mindestens unser Karl und ich wünschen sich einen "Connected-bommel" o.ä. in der Statuszeile, der anzeigt ob connectivity zum Server da ist, rot/grün, ganz einfach eigentlich.. (Mein Chumby hängt sich fast täglich ab, um das zu debuggen und meine suspendete Note/Netbooks auch ab und an)

Ein 4-Zeiler, wenn ich nur wüsste: wie komme ich aus einem Widget o.ä. an die Variablen/stati in lib/cometvisu-client.js this.xhr oder des watchdog?

Makki

[Chris M.]

Mindestens unser Karl und ich wünschen sich einen "Connected-bommel" o.ä. in der Statuszeile, der anzeigt ob connectivity zum Server da ist, rot/grün, ganz einfach eigentlich.. (Mein Chumby hängt sich fast täglich ab, um das zu debuggen und meine suspendete Note/Netbooks auch ab und an)

Ein 4-Zeiler, wenn ich nur wüsste: wie komme ich aus einem Widget o.ä. an die Variablen/stati in lib/cometvisu-client.js this.xhr oder des watchdog?

Die sind in der globalen Variable "visu".

Aber Vorsicht:

• Wenn wir auf mehrere Verbindungen gleichzeitig gehen werden (z.B. 1x zum KNX, 1x zur LogicEngine, ...) dann werden wir die globale Variable zu einem globalen Array (o.ä.) erweitern müssen - und es wird eine Hand voll Connected-Bommel geben müssen
• Evtl. wirst Du nicht an alle interessanten Daten per "visu" heran kommen - dank Closures sind die nämlich ordentlich weg gekapselt (so dass eben nicht ein wildgewordenes Widget Schindluder damit anstellt )
  => Evtl. musst Du hier eine Get-Funktion schreiben, die aus der Closure den relevanten wert erzeugt.
  Aber wenn Du schon so weit bist, kannst Du eigentlich gleich ein Event draus bauen, das aufgerufen wird, wenn keine Verbindung mehr besteht...

[swiss]

Hmmm...

Was ich auch noch für einen sehr wichtigen Schritt halte ist, dass man über den Webeditor Plugin's Styling's und Mapping's verwalten kann. Könnte man dazu nicht Die gleiche Maske verwenden, die auch bei den GA's zu einsatz kommt? Dann könnte man recht einfach z.B. Mappings anlegen, ändern und löschen.

Plugin's sind etwas schwiriger. Da würde ich mir etwas in der Art wie die Dateiverwaltung hier im Forum wünschen. (Upload im Browser).

[makki]

Ok, werd auf die Basis mal meine Lernkurve ansetzen

kannst Du eigentlich gleich ein Event draus bauen, das aufgerufen wird, wenn keine Verbindung mehr besteht...

Das war eigentlich auch meine erste Idee, geht in jQuery ja nun irgendwie (für jemanden der sich damit auskennt zumindest..) aber dafür muss man im Core rumfummeln..
Aber löst auch das "Problem" mehrerer Backends schonmal präventiv: für den AW/Betrachter der Visu ist es ja sekundär, was "nicht geht" sondern IMHO in diesem Fall nur, das etwas nicht aktuell ist.
(Unabhängig von dem Chumby-Problem (Webkit), da hat man halt von aussen ca. 0-Debugging-Möglichkeit, also muss es ins JS; meiner ist da eher wurscht aber das könnte ja auch auf Tablet-xy passieren..)

@swiss: ja das wär schon schön aber mit meinem limitierten Know-How fiele mir dafür aktuell nur ein Button zusätzlich zu +/save/help ein, um den Editor für mappings/stylings (und vielleicht auch plugins, ..) aufzurufen.

Makki

[swiss]

@swiss: ja das wär schon schön aber mit meinem limitierten Know-How fiele mir dafür aktuell nur ein Button zusätzlich zu +/save/help ein, um den Editor für mappings/stylings (und vielleicht auch plugins, ..) aufzurufen.

Genau so häte ich das auch vorgeschalgen. Ein Button z.B. "Einstellungen" der auf eine weitere Seite verlinkt in der nach und nach weitere relevante Einstellungen für die CometVisu eingestellt werden könen.

Beginnen würde ich mit:

• Mapping
• Styling
• Plugin installierne und verwalten

Später wäre noch schön, wenn man weitere Möglichkeiten hätte wie z.B.

• Start Design auswählen
• Name der Startseite mit einem Textfeld beeinflussen
• Satusleise bearbeiten

Damit wären den normalen Anwendern sehr geholfen. Vor allem das installieren von neuen Plugins über den Web-Editor finde ich sehr wichtig, damit ein Angendeer auch neue Plugins installieren kann ohne die Config von Hand anfassen zu müssen.

[Chris M.]

Im Grunde brauchen wir eine Möglichkeit um neben den Einstellungen in den Seiten (wie's der Editor jetzt anbietet) Einstellungen Über den Seiten, bzw. über der äußersten Seite vornehmen zu können. Eben einfach auf die Meta-Ebene gehen - was für einen eingebetteten Editor vom Prinzip erst mal schwierig ist... Das zeigt sich auch bei dem Thema Widgets von einer auf eine andere Seite zu verschieben.
(Das ist nichts gegen den aktuellen Editor - der ist super! Aber das ist eine Limitierung im aktuellen Ansatz, die einfach gelöst werden muss)

Allgmein zur Editor-Weiterentwicklung:
Hier wird bald noch ein großer Schritt kommen müssen, wenn die 2D und 3D Seiten kommen werden.
2D ist ziemlich trivial aus Sicht der Template-Engine, d.h. schnell mal implementiert, und den Status des 3D kann man sich im SVN ansehen (-> JSFloorPlan), da bin ich z.Zt. dran.
Da 2D im Grunde nur ein um eine Dimension reduziertes 3D ist, will ich beides aber erst gemeinsam bringen, bzw. 2D vom 3D ableiten, so das die Schnittstellen konsistent sind.