CometVisu - (interner) Beta-Test

[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

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

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

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]

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

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, 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

[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

[vento66]

Ja der RSS fällt auch mal gern über die Grenzen des Widgets drüberraus... Ich denke aber das der RSS reader jetzt nicht am Anfang mit dabei sein muss.
Oder getreu Apple: Erst mal nur als Beta.

[greentux]

Makki hatte damals erwähnt, das das RSS "mal eben nebenbei" entstanden ist. Vermutlich muss er es noch "schön" machen...

[Chris M.]

Mangels aktiver Nutzung des RSS-Plugins meinerseits: Ist folgendes normal?

Im Firefox kommt (bei Makkis Demo-Seite) immer in der Firebug-Konsole diese Fehlermeldung:

$(rss).rssfeed is not a function
[IMG]chrome://firebug/content/blank.gif[/IMG] linktarget: rss.data("linktarget") struct...1230832 (Zeile 104)

In Zeile 104 steht übrigens:

linktarget: rss.data("linktarget")

Wobei mit auffällt, dass in allen Zeilen drüber um das rss.data() jeweils ein eval() steht...

Die 0.6.0 sollte zumindest bei der normalen Nutzung fehlereintragsfrei sein...

[greentux]

Bis 100 fette Plugins da sind, kann der Editor damit umgehen.
Pro aktivieren.

[Chris M.]

Nö, das hat im Cookie IMHO auch nichts verloren - der Design-Wechsel-Button ist auch nur ein Trick und kein Feature!

Das Design gehört in's äußerste <pages> Element in das Attribut "design":

<pages xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" design="discreet" xsi:noNamespaceSchemaLocation="visu_config.xsd">

Nun kannst Du problemlos für mobile Geräte eine eigene Config erstellen (was sich sogar meist empfiehlt. Da lassen sich ein paar Plugins sparen und ein paar von den obskureren Bedien- und Infomöglichkeiten wie EVG Ausfall, und so das Datenvolumen und die Akku-Laufzeit optimieren)

[vento66]

Ist es möglich das zuletzt verwendete Design über ein Cookie zu speichern? Gerade bei mobilen Devices ist es immer schlecht, dann erst das Design zu wechseln.

[vento66]

full ack