CometVisu - (interner) Beta-Test

[swiss]

Den Fehler hab ich gemacht

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

[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...

[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

[swiss]

Bei mir funktioniert der Infotrigger bis jetzt problemlos.

[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?

[makki]

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

Makki

[JNK]

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

Gruß,

Der Jan

[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...

[makki]

Fixed (wenn auch vorträglich) ist schöner

Zurück zum Thema, hatte heute schon wieder das Problem "nicht aktualisierender diagrams" - ich vermute es hängt entweder mit Webkit(Chromium) und/oder Suspend/Resume/Verbindungsunterbrechung zusammen aber so ganz genau sicher bin ich mir immernoch nicht; das passiert alle paar Tage mal - eher sporadisch..
-> Sobald ich es genauer eingrenzen kann etwas für den CV-Bug-Thread/Tracker. -> falls jemand vorher hinter die genauen Umstände kommt: sagen

Makki

[greentux]

oha, dann wohl "INVALID" der tracker

[Chris M.]

Schau mal die Widget Demo an, bewege den "Slider" und beobachte die Zahl neben "Info: Slider", insbesondere beim Vorzeichenwechsel, oder wenn die Null wird

[greentux]

Ich habe mal im Tracker einen Wunsch hinzugefügt:
"conditional colored info widgets"

[makki]

Sehe ich auch so

Ok, wens interessiert (muss man nicht lesen, ist aber einfach besser zum tracken oder mal zum nachsehen, auch für "one-man" )
/other/cometvisu-deb

Ne, das ist kein Plugin.

Ein Plugin ist etwas "offizielles" ..

Ok, dann passt das ja so, wird zukünftig nicht mehr angefasst. Und ich weiss wo meine Alpha-Widgets hingehören (hab da noch wettercom und ein anderes, direktes RSS in der Pipeline aber die sind noch unfertiger..)

Makki

[Chris M.]

Soll ich das .deb-Zeugs mal irgendwo einchecken?
Denke aber eher ins eigene SVN

Sehe ich auch so

Nur zu meinem Verständniss, damit ich das richtig hab: designs/structure_custom.js ist ja im Prinzip dasselbe wie ein Plugin, nur das es lokal ist und schwerer, es später in die allgemeine einzubringen?
Also sollte man gehalten sein, das wirklich nur für absolut lokale Sonderlocken zu verwenden die niemals in die CV zurückfliessen sollen(?)

Ne, das ist kein Plugin.

Ein Plugin ist etwas "offizielles" bei dem der User entscheiden kann, ober er den ganzen Bloat haben will oder nicht. D.h. das ist für "dicke" Widgets. Mit den leichtgewichtigen wird der User zwangsbeglückt.

Der designs/structure_custom.js ist wie die visu_config.xml als User-Content anzusehen. Da kann sich jeder selbst austoben, ohne Angst haben zu müssen, dass das mal überschrieben wird.

Da kann man z.B. auch erst mal ein Widget lokal entwickeln, bevor man das öffentlich machen will.

(Ich bin vorhin darüber gestolpert, weil ich ein einfaches Geburtstags-Erinnern-Widget schreiben wollte. Das wird so Quick'n'Dirty inkl. hart codierter Daten, dass ich das so niemals in das SVN schieben würde, höchstens hier in die Code-Schnipsel)

[makki]

Was nun? Soll das noch in die 0.6.0 oder in den post-0.6.0-branch?

Erstmal Danke Ich bin kläglich gescheitert (mit beidem, dem Bug und dem FR)

Nun, IMHO 50:50: Es ist zwar kritisch aber auch wichtig, weil ich die Diagramme eigentlich für eine eminent wichtige Kernfunktion halte (wir erinnern uns warum man meist ein WG hat oder baut.. Temperaturen..)

Definitiv post-0.6: Was mir daran nicht so zusagt, ist das etwas für ein Plugin im Quellcode der CV selbst geändert wird; mein JS/jQ-Know-how ist nahe Null aber entweder sollte es dann ein Standard-Widget, kein Plugin sein.
Oder es gibt irgendeine geniale Methode sich da aus dem Plugin heraus einzuklinken (ich träume jetzt mal kurz: irgendwas wie jedes Plugin sich in einen "scrolltopage"-Event einhängen kann o.ä.)
Weil das wäre generell interessant! Zuwas soll sich ein unsichtbares Widget alle xx sekunden dumm aktualisieren, statt (evtl. konfigurierbar) "as it happens"

dass das Paket die structure_custom.js NICHT verändert

Ok, ist ab dem nächsten Paketrelease ein "conffile" wird also nicht verändert sofern es lokal geändert wurde..

Soll ich das .deb-Zeugs mal irgendwo einchecken? Langsam rentiert es sich
Denke aber eher ins eigene SVN, es kann niemand ernsthaft was damit anfangen, ist ziemlich WG-spezifisch und die hälfte wird auch händisch zusammenkopiert.. Hat also per se wenig mit einem Debian-Package zu tun. (ein "richtiges" .deb dürfte z.B. niemals nicht an der Webserver-config - noch dazu eines spezifischen - rumfummeln; aber das muss es halt damit es "schön" geht..)

Nur zu meinem Verständniss, damit ich das richtig hab: designs/structure_custom.js ist ja im Prinzip dasselbe wie ein Plugin, nur das es lokal ist und schwerer, es später in die allgemeine einzubringen?
Also sollte man gehalten sein, das wirklich nur für absolut lokale Sonderlocken zu verwenden die niemals in die CV zurückfliessen sollen(?)

Makki