CometVisu - (interner) Beta-Test

[makki]

In der Firebug-Konsole kommt bei mir nichts aber das RSS-Plugin würde ich als hochgradig unfertig einstufen, es sieht grausam aus weil man auch definitiv am CSS noch was machen muss -> +1 für nicht defaultmässig aktiv..

Makki

[JNK]

So, zu dem Diagramm-Axislabel-Bug:

Ich habe das jetzt rausgefummelt. Das Problem liegt m.E. nicht bei flot sondern in der jquery.

Was passiert ist folgendes:

Flot versucht die Breite (oder Höhe) der Axis-Labels zu ermitteln, in dem mit makeDummyDiv (Z. 850) ein "DummyDiv" aus z.B.

"<div style="position:absolute;top:-10000px;width:10000px;font-size:smaller"><div class="xAxis x1Axis"><div class="tickLabel" style="float:left;width:40px">20:00</div><div class="tickLabel" style="float:left;width:40px">0:00</div><div class="tickLabel" style="float:left;width:40px">4:00</div><div class="tickLabel" style="float:left;width:40px">8:00</div><div class="tickLabel" style="float:left;width:40px">12:00</div><div class="tickLabel" style="float:left;width:40px">16:00</div><div class="tickLabel" style="float:left;width:40px">20:00</div><div class="tickLabel" style="float:left;width:40px">0:00</div><div style="clear:left"></div></div></div>"

erzeugt wird und davon die Breite bzw. Höhe weiterverarbeitet wird. Die Höhe in obigem Beispiel liefert

1. wenn das Diagramm gerade "sichtbar" ist: "20px"
2. wenn das Diagramm nicht "sichtbar" ist: "0px".

Das führt dann dazu, dass der Platz für die Axis-Labels falsch berechnet wird und sie landen im Grid.

Der String oben wird von flot erzeugt und mit $(...) an jquery übergeben. Der Übergabewert ist in beiden Fällen identisch. Das Rückgabe-Objekt unterscheidet sich: Ist das Diagramm sichtbar, ist das Attribute z.B. clientHeight auf "20px", wenn nicht auf "0px".

Daraus kann man wohl schliessen, dass jquery das unterschiedlich behandelt. Wieso, weiss ich nicht.

Jetzt stellt sich die Frage, was dagegen getan werden kann, ohne am jquery rumzupatchen.

Gruss,

der Jan

[Chris M.]

das RSS-Plugin würde ich als hochgradig unfertig einstufen

OK, dann kommt das einfach nicht in die Standard-Config und Demo-Config.

Jetzt stellt sich die Frage, was dagegen getan werden kann, ohne am jquery rumzupatchen.

Da ich nicht so tief in der Analyse bin wie Du, kann ich kaum helfen. Ich weiß nur, dass jQuery Mechanismen zum Erweitern anbietet, evtl. kann man sich darüber einklinken. Oder rausfinden, an welcher Stelle es genau klemmt und das upstream schicken...

[JNK]

So, ich hab da nochmal weitergesucht. Das Problem ist ein klein wenig komplizierter und ich fürchte fast so ohne weiteres gar nicht zu lösen.

Was passiert ist folgendes:

• wir übergeben "diagram" an flot.plot
• flot.plot verwendet das als "placeholder"
• wie oben beschrieben wird ein dummyDIV erzeugt
• dieses dummyDiv wird (anders als oben geschrieben) mit $(...) noch richtig erzeugt
• egal ob sichtbar oder nicht, sind height und width 0
• dieses Objekt wird dann mit "appendTo(placeholder)" verbunden
• das ist das Problem, ist "placeholder" nicht sichtbar, sind alle heights und width 0, und die in dem dummyDIV bleiben das auch, ist "placeholder" sichtbar, werden height und width von dummyDIV auch richtig berechnet

Man kann das Problem vielleicht "umgehen", wenn man in "scrollTo" die Diagramme refresht, die sich auf der gerade angezeigten Seite befinden. Schön ist das nicht, würde aber das Problem beheben. Gleichzeitig könnte man
das "refresh" nur durchführen, wenn das Diagramm auch sichtbar ist, das würde FR 3338493 quasi miterledigen.

Ich guck mir das heute abend oder so mal an.

Gruss,

der Jan

[Chris M.]

Man kann das Problem vielleicht "umgehen", wenn man in "scrollTo" die Diagramme refresht, die sich auf der gerade angezeigten Seite befinden.

Finde ich einen guten Vorschlag. Wenn's nicht sichtbar ist, interessiert's nicht. Und wenn man's gerade in die Sichtbarkeit holt, will man auch die aktuellen Werte haben...

[JNK]

Ich habe das so wie angedeutet mal implementiert. Das funktioniert auch ganz gut, das Problem mit den Axis-Labels ist weg. Allerdings sieht meine
"scrolltopage" jetzt so aus:

  $('#'+page_id).css( 'display', '' );                         // show new page
  main_scroll.seekTo( $('.page').index( $('#'+page_id)[0] ), speed ); // scroll to it
  var divpage=$('div', '#'+page_id);
  for( var i = 0; i<divpage.length; i++) 
  {
    if( divpage[i].className == 'diagram_inline') 
    {
      refreshDiagram(divpage[i]);
    }
  }

Das Durchlaufen der Seiteninhalte braucht natürlich Zeit, ich weiss nur nicht, wie ich das optimieren kann.

Der zusätzliche Zeitaufwand hält sich allerdings in Grenzen, ich habe das mit 10x zwischen Visu-Startseite und einer Unterseite wechseln ausprobiert, für die ursprüngliche Variante brauche ich im Schnitt 8.7 ms, für die neue 9.6 ms, also ca. 10%.

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

Gruss,

der Jan

[Chris M.]

ausprobiert, für die ursprüngliche Variante brauche ich im Schnitt 8.7 ms, für die neue 9.6 ms, also ca. 10%.

So wenige ms sollten doch nicht wirklich wahrnehmbar sein, oder?

Wichtig ist nur, dass es flüssig ist und gewollt aussieht...

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

Ich wäre für post - schließlich ist es nicht kriegsentscheidend und gerade diese Stelle halte ich für kritisch, die würde ich im Freeze nicht mehr anfassen

[JNK]

Ok, dann committe ich das mal dahin. An dem FR bin ich noch dran, da würde ich gerne erst noch etwas probieren.

Gruss,

der Jan

[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

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

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

[greentux]

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

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

oha, dann wohl "INVALID" der tracker

[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