CometVisu - (interner) Beta-Test

[swiss]

Ich meine nicht mal unbedingt, dass die grundconfig zugepflastert werden sollte. Ich beziehe mich viel mehr darauf, dass man alle Widgets im Editor aus der Liste auswählen kann. Weil momentan z.B. der Colorchooser in der Grundconfig nicht zur Auswahl steht. Den muss man zuerst von hand "freischalten". Das finde ich nicht sehr benutzerfreundlich.

[Bodo]

Supi

Hoi

Ja von jedem eins. Rauslöschen ist immer einfacher als neu einsetzen.
Zumindest die wichtigsten.
Und sonst kann man ja in der Demo nachschauen.

[swiss]

Hmmm...

Ich finde eine komplete Liste aller "fertigen Plugins" die direkt im Editor ausgewählt werden können viel benutzerfreundlicher als wenn man von jedem Anwerder der z.B. den colorchooser einsetzen möchte verlangen würde die Config von Hand anzufassen.

Es kann ja immer noch jeder Benutzer selber bestimmen welche Elemente er tatsächlich in der Visu einsetzt.

[Chris M.]

Jetzt kommt Bewegung in die Threads - daher gleich mal ein Cross-Thread-Zitat:

Wie wird denn eigentlich mit den Plugins verfahren? Im Moment ist es ja noch so, das die Plugins manuell im visu_config.xml eingetragen werden müssen. Sind die bis zum release dann schon fix in der config drinn, oder brauchen wir dafür auch noch einen Eintrag?

Das ist ein wichtiger Punkt, für den ich gerne ein Stimmungsbild hätte:

Die etwas größeren, aufwendigeren Widgets sind bewusst als Plugin gestaltet, so dass nur diejenigen damit belastet werden, die die auch brauchen.

Mein aktueller Ansatz ist die Standard-Config möglichst schlank, also quasi leer, zu machen, da diese zum Aufbau der eigenen Visu gedacht ist.
Die Demo-Config dagegen soll alles zeigen, was geht.

Das Problem ist aber, dass zur Zeit der Editor die nicht einfügen bzw. entfernen kann. D.h. jeder der vor Texteditor und SCP o.ä. zurückschreckt, hat keine Chance die zu ladenden Plugins auszuwählen.

=> Sollen wir lieber die Plugins per Default in der Standard-Config aktivieren? (Und was machen wir, wenn mal 100 fette Plugins vorhanden sind?!?)
=> Oder so wie jetzt lassen und auch von den öffentlichen Beta-Testern Texteditor+SCP verlangen?

[Chris M.]

- In der Fusszeile wird die Version nicht angezeigt

Die Version in der Fußzeile ist ein Feature der jeweiligen Config-Datei. In der sagt man nicht nur welche Plugins geladen werden sollen, sondern auch wie die Fußzeile aussieht. (Die Synatx dafür ist - je nach Blickwinkel - eine der riesigen Stärken bzw. Schwächen von XML...)

Lade mal die Demo-Seite http://wiregate/visu/?config=demo da sollte es auftauchen.
Die Standard-Config wirst Du wahrscheinlich ja schon bei Dir angepasst haben und damit wird die vom Paket nicht mehr überschrieben, also auch die Fußzeile nicht mehr angepasst. (Es könnte ja sein, dass Du die Fußzeile schon auf Deine Bedürfnisse geändert hast...)

[JNK]

110% Ack! Wir haben echt schon genug "lokale" sonderlocken (die alle aber keineswegs direkt "gewollt" sind.. sobald ich die Zeit finde und es allgemeiner wird, will ich solche Sachen wie eibread/write-cgi, rrdtool fetchj upstream bringen! Da traue ich mir aber aktuell zu, das einfach noch hier im Griff zu halten..)

Das sehe ich ganz genauso. Ich versuche nur herauszufinden, ob das ein Problem unseres Plugins ist und "einfach" von aussen zu beheben oder ein flot-Problem. Und wenn es das ist, dann sollten wir das nicht selbst fixen, aber je genauer wir wissen warum, um so eher denke ich, wird das dann "richtig" gefixt.

Das Problem mit der Beschriftung in den Graphen ist im übrigen, dass die Breite und Höhe der Achsenbeschriftung falsch (zu null) berechnet wird, wenn das
Diagramm aktuell nicht angezeigt wird.

Was da genau schief läuft weis ich noch nicht, aber ich bin dran :-)

Gruss,

der Jan

[vento66]

Hi Patrik!

Die Widgeds sind Plugins, Ich habs gerade im Doku Tread geschrieben, nicht das wir hier alles doppelt behandeln...

[swiss]

Kurze Frage...

Ich habe zum testen der "Normalen" CometVisu mal wieder ganz normal über das WG-Webif -> update -> cometvisu ein Update durchgeführt. Da fehlt aber noch einiges. Ist das so gewollt?

z.B.

- Es fehlen die Diagramm-Widget's (inline und popup)
- In der Fusszeile wird die Version nicht angezeigt
- Der Colorchooser steht auch nicht zur Verfügung

Ist einfach das Paket soooo veraltet?

[makki]

Das Problem ist das verschachtelte

Jep, da bin ich auch schonmal drübergestolpert (ohne damals zu verstehen warum..)

Bevor Du aber die jquery.flot.js anpasst, sollten wir das ggf. auf eine neue Version wechseln und/oder nach upstream schieben

110% Ack! Wir haben echt schon genug "lokale" sonderlocken (die alle aber keineswegs direkt "gewollt" sind.. sobald ich die Zeit finde und es allgemeiner wird, will ich solche Sachen wie eibread/write-cgi, rrdtool fetchj upstream bringen! Da traue ich mir aber aktuell zu, das einfach noch hier im Griff zu halten..)

Die Diagramme gehören ja echt zu meinen "Lieblingsfeatures" (und es gibt da ein paar Probleme..)-> wenn es ein Problem in Flot ist (da steige ich aus!) sollten wir versuchen - und ich mach da gerne mit - es "upstream" zu melden/beheben, bevor wir einen lokalen CV-workaround bauen..
Denn genau das, Probleme in jQuery oder Plugins "lokal" zu umgehen ist langfristig IMHO ein Fehler, so anstregend es manchmal ist(!)..

Makki

[Chris M.]

Ich versuche mich gerade am Rendering-Problem der Diagramme, und ich habe einen Verdacht, was das Problem ist, nur müsste ich dazu durch die jquery.flot.js debuggen. Die sehe ich leider im Firebug nicht. Hat jemand eine Idee, woran das liegen könnte?

Das Problem ist das verschachtelte

$("body").append("<script type=\"text/javascript\" src=\"plugins/diagram/flot/jquery.flot.js\"></script>");

Das ist ein bekanntes Problem, und der Chromium ist da nicht besser...

Wenn's nur zum debuggen ist: ändert einfach die index.html und lade das Skript direkt (wahrscheinlich muss dazu die o.g. Zeile entfernt werden)

Bevor Du aber die jquery.flot.js anpasst, sollten wir das ggf. auf eine neue Version wechseln und/oder nach upstream schieben

[JNK]

Ich versuche mich gerade am Rendering-Problem der Diagramme, und ich habe einen Verdacht, was das Problem ist, nur müsste ich dazu durch die jquery.flot.js debuggen. Die sehe ich leider im Firebug nicht. Hat jemand eine Idee, woran das liegen könnte?

templateengine.js und die structure_plugin.js und sowas sind alle da.

gruss,

der Jan

[chriss1980]

Hallo zusammen,

auch wenn ich hier nicht aktiv mithelfe, nur kurz zu meiner beruflichen Erfahrung mit SVN.
Generell sollte unterschieden werden in taggen von Versionen, die freigegeben sind (also als .deb in Repository wandern) und branchen von Versionen als Nebenentwicklungszweig.
Ein Release 0.6.0 sollte also folglich zum einen getaggt (ab da read-only) und, wenn gleichzeitig im trunk weitere Features entwickelt werden, für das bugfixing gebrancht werden. Wenn es nun Bugfix-Releases gibt, so wird einfach aus dem 0.6.0-branch ein entsprechendes 0.6.x getaggt.
Die nächste Version mit neuen Features wird nach gleichem Schema getaggt/gebrancht und im besten Fall wird der 0.6.0-Branch vorher vollständig mit trunk gemergt und verschwindet damit als eigener Pfad aus dem Repository.

just my 2c
Christian

[netzkind]

PS @Julian: Was ich jetzt noch gerne hätte, wäre dem Editor sagen zu können, welchen "Datentyp" ich bei Variant erwarte ähnlich den normalen Attributen. Dann könnte man da auch Listen hinterlegen, die dem Endanwender deutlich weiterhelfen könnten...

Hm, da müsste man dann einiges an den structure_*.js ändern - derzeit gibt man ja nur an dass man address haben will. Zusätzlich muss der Editor darauf reagieren und select anstelle der inputs anbieten.
Geht sicher irgendwie, aber ich hab leider (wie man auch an meiner Beteiligung hier merkt) meinen Kopf derzeit mit ganz anderen Dingen voll

Wenn jemand anderes da bei will, dann ab dafür!

Grüße,
Julian

[greentux]

(einziges Missverständniss: wenn ich einen Fix habe, dann wird der so wie ich das kenne in trunk commited und dann in die branch gemerged aber ich bin da wirklich auch nur halbwissender laie!)

So sollte es sein. In der Praxis ist es meistens andersrum, da das Release Prio hat wird dort gefixt und anschliessend gesammlet nach HEAD (Trunk) also in den Upstream Zweig übertragen.

Die nächste Version, die abgespalten wird, sollte dann 0.7.0 heissen, 0.6.1 wäre aus meiner Sicht ein Bugfix zur 0.6.0, der aus dem 0.6.x Branch kommen müsste... Wenn man so einen Bugfixrelease machen möchte.

[makki]

Zu Benamungsschemata und Branch-Verfahren bin ich gerne offen für Diskussionen.

Nun, was SVN angeht bin ich glaube ich Halb-Anfänger wie wir alle, bei .debs vielleicht ambitionierter Intermediate (nicht-nummerische Upstream-Nummern sind jedenfalls rückblickend nicht so ganz praktisch.. das weiss ich aber auch erst seit ich es mit -preX und -rcY mal ausprobiert habe )
-> das mit den branches ist glaub ich gut
(einziges Missverständniss: wenn ich einen Fix habe, dann wird der so wie ich das kenne in trunk commited und dann in die branch gemerged aber ich bin da wirklich auch nur halbwissender laie!)
Ausserdem fehlen uns hierzu wie Chris schon anmerkte evtl. dann doch deutlich die Resourcen, mehrere releases so zu pflegen..
(beim WG halte ich das ja ähnlich/nicht anders obwohl es technisch vorgesehen&möglich wäre beta&release zu unterscheiden: no way das organisatorisch mit vertretbarem Aufwand zu machen!)

-> kann dazu neben dem aktuellen Modell nur einbringen: lieber ein "trunk" als 3, irgendwer muss es vor dem release dann aber aufwändig testen!

(ich glaube ich hatte die Frage schonmal gestellt: hat jemand Erfahrung mit automatischen Testroutinen für sowas? das wäre IMHO ein essentieller Beitrag! Fehler dürfen passieren, aber bitte nur 1x, beim 2. mal sollte das Makefile den finden.. Beim transform_knx würde ich das auch übernehmen aber ohne Vorlage.. AFAIR sind z.B. 90% des codes von sqllite nur testroutinen..)
Mag aus meinem Mund komisch klingen, aber wenn man Testroutinen fürs WG hat, dann auch für den Rest und hier viel schlimmmer: tausende mögliche Clients!?

Mein aktueller Standpunkt:
Zu den Namen:
Eine 1.0... wollte ich erst vergeben, wenn's für die Masse stabil und nutzbar ist, so wie die für mich essentiellen Features (d.h. auch 2D und 3D!) hat.

Jede OSS die etwas auf sich hält und jünger als 10J ist hat 0.x Vielleicht ein Form von Respekt, understatement oder Hohn ggü. "Profis" wo nach vielen Jahren in Version 11.0.1.152 immernoch jeden Tag der Browser von Millionen Anwendern wegen diesem Stück Sch** abkachelt (so bei mir gerade, genau hier, der Fehler war natürlich im anderen Tab, eine AW 2x zu schreiben macht keinen Spass und treibt den Blutdruck enorm..)

Dabei habe ich sogar darauf geachtet, dass eine lexikografische Sortierung dafür sorgt, dass die Reihenfolger bzgl. der Neuigkeit erhalten bleibt...

Theoretisch gut, in der Praxis bringt apt* da aber einige - nennen wir es mal Eigenheiten - mit. Ich mag ja perl.. meistens.. hier nicht..

Was verwendest Du für's Minify?
jsmin

Als wir seinerzeit (ca. 30-80 Seiten zurück) darüber sprachen habe ich mir alle angesehen, drei blieben übrig, eins war schrott (#3: Name vergessen, das menschliche Hirn kann das ja zum Glück: unrelevantes einfach wieder automatisch löschen) ein anderes in Java, das war objektiv wenige % besser funktionierte aber Java-typisch erstmal nicht und gab stattdessen seitenlange Exception: in.ist.mir.egal.ob.du.das.kapierst.will.ich.garnic ht.wissen.warum.der.programmierer.ein.gaskopf.ist. der.fehler.nicht.sauber.abfängt.im.Source.stehts.v ielleicht.wenn.du.den.auch.hast.und.lesen.kannst

Das fiel also auch aus, daher fiel die Wahl auf jsmin; das recht alt, recht ehrlich, verständlich. Aber alt ist nicht zwangsweise schlecht weil das kann auch bedeuten das es da einfach mal jemand richtig gemacht hat Und das gab bisher keine Probleme..

+

#!/bin/bash

for FILE in $( find ../var/www/visu/ ! -name *.min.js -name *.js ); do
        echo "Process $FILE"
        FILENAME=`basename $FILE`
        BASEPATH=`echo $FILE | sed 's/\.[^\.]*$//'`
        #echo "baspatch $BASEPATH"
        if [ ! -e $BASEPATH.min.js ]; then
                echo "NO minified for $FILE - creating"
                jsmin < $FILE > $BASEPATH.min.js "(c) see LICENSE or according non-minified versions shipped with this package"
        fi
        # Now replace all occurences in include 
        #FIXME: look on path also!
        sed -i s/$FILENAME\.js/$FILENAME\.min\.js/g ../var/www/visu/*.html

WG_custom_debian_packages/cometvisu-0.6-rc2/DEBIAN/minify.sh

Den Rest mache ich - wo es sich rentiert (ich hab das echt mal ausprobiert..) wirklich ganz von hand..

Diese Änderung würde ich aber gerne erst nach 0.6.0 machen...

Klar, prio hat das keine, ich beantrage aber schonmal das das finale release von 0.6 -> 0.6.1+=(nummer-danach-beliebig) heisst. Weil 3-4 haben meine teils verzweifelten versuche, apt zu überlisten runtergeladen (ich kenne nur die IP, nicht den User) und es ist einfacher die Nummer hochzuzählen als den 4 zu erklären warum das update nicht ging.. Ist auch egal (jeder der eine 0.6>rc1 [menschliche lesart] hat ist bei -rc2)
Mein interner Nummernzwang legt mir das aber auch auf

Ja und Nein.
Gerade so Feinheiten wie Einheiten werden wir so nicht abhandeln können.

Definitiv, aber dafür müsste man DPT's konsequent umsetzen (was zwar IMHO sinnvoll wäre - bisher aber absolut niemand so macht, also keine Hektik..) Aber das wäre ein Killer-feature, das die Visu automatisch weiss, das es sich da um einen 2byte DPT9 in °C handelt, nur weil man das einmal in der ETS eingestellt hat.. (ehrlich, für was sind die DPTs sonst gut? um zu wissen ob man eins oder zwei Byte vom bus wertfrei zu lesen sollte EIS auch reichen..
Ich mache weiter, steter Tropfen höhlt den Stein und jeder der es noch nicht verinnerlicht hat, denkt mal dran, warum DPT's mit impliziten Datentyp+Einheit eigentlich verdammt hilfreich wären - wenn es denn irgendwer nutzen täte..(also in einfach: man beim empfänger vorher wüsste das es sich hier nicht nur um 2 byte sondern um einen DPT9.001 float mit der Einheit °C handelt und das nicht erst zusammenklicken müsste..)

Makki