CometVisu - (interner) Beta-Test

[makki]

Zwecks der GA-config: ich denke es sollte beides gehen
- ich werde im nächsten Update den GA-Editor im Webmin reinnehmen, das man dort auch manuell eintragen kann
- für auf die schnelle ist es sicher schön, wenn man im Editor trotzdem einfach eine GA eingeben kann

Makki

[vento66]

Danke makki. aber hatte es schon hinbekommen (langsam wirds mit mir und dem Pinguin )
@Chris jetzt kann man (ich) bei den slidern keine negativen Werte mehr eintragen es kommt immer die Meldung "min Value invalid"

[makki]

Na, das zu erklären ohne mir selbst zu widersprechen wird gaanz schwierig

Also, kurzgesagt: das Package ist erstmal nur manuelles zusammengefummel, irgendwo zwischen Alpha&Beta, damits schnell und erträglich einfach geht..
Fürs nächste Package schreib ichs mal auf die Wunschliste, ein teufelskreis

Das Package tut im moment folgendes (was es "eigentlich" nicht darf)
- ln -s für eibread/write-cgi
- am Webserver rumfummeln
-> dieser Part hat ja eigentlich nichts mit der CometVisu zu tun sondern ist convinience-tuning und gehörte ins wg-patch, eib-clients-cgi etc.
- php's etc müssten in cgi-bin bzw. usr/share etc.pp.

Mein Vorschlag wäre eh erstmal ein .tar.gz des svn/branch-Stands.
Das minifien gehörte - kleiner Meinungswandel - eher in den Release-Prozess. Ich meinte ja eher, das ihr euch damit nicht aufhalten braucht.

@vento: ja, ist klar:

apt-get update; apt-get install cometvisu

Wie man das zukünftig handhabt ist noch offen, wenn die config mal keine strukturellen Änderungen mehr erfährt, gehört die eigentlich raus und so keine vorhanden - eine default angelegt.. (oder der Editor lässt sich mit einer leeren config starten ->?)

Makki

[vento66]

Hi Makki

Beim Installieren kommt noch ein Fehler bezüglich der geänderten visu_config.xml Und die schreibrechte für die visu_config.xml fehlen auch noch....

[makki]

Package ist draussen..
was tut:
- minify (s.u.)
- gzip mit cache (mod_compress war eh schon aktiv) von html,xml,js,ttf,css; das passiert ohne irgendwas "on the fly"
- funktionieren hoffentlich

Zum Rest später, hab Hunger

Makki


minify.sh

#!/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
	fi
	# Now replace all occurences in include 
	#FIXME: look on path also!, be more careful
	sed -i s/$FILENAME\.js/$FILENAME\.min\.js/g ../var/www/visu/*.html
done

[Chris M.]

Also, die Demo-Visu ist jetzt Release-Stand (würde ich dann auch so belassen)
Die trunk-Version hier (dito, ist zum testen/machen einfacher)

Du meinst das ./debian-Verzeichnis ? Macht IMHO wenig Sinn, weil das ist&wird niemals ansatzweise legal; ich befummle z.B. die config des Webservers, das ist illegal³ - aber nun notwendig damit halt "einfach" lüppt.. ein Teufelskreis..
Wer sich das wiregate-repo einträgt, der bekommt eine explizite Warnung, auf sf würde ich solche Pakete nicht stellen, denn wer sich von dort was installiert hat nunmal zu wissen, das er noch den Webserver konfigurieren muss.. das Backend ist nicht bestandteil des offiziellen bcusdk/eibd (derzeit auch gut so, weil teilw. schrott [-> hints zum segfault?])
Den Knoten wird man zwar irgendwann auflösen können, aber nicht von hier auf gleich..
Zum Backend: nach den Worten& berechtigten Bedenken von mkoegler würde ich daraus dann eh ein sep. eib-clients-cgi.deb o.ä. machen..

Ich meine ein Package, dass genau das installiert, was im Repository ist (+ minimized, etc.). Das Backend ist doch schon jetzt in einem anderen Package, oder?

Hat dieses Package denn irgendwelche Querwirkungen? Welche?
(Ich denke hier immernoch an andere Anwender, die kein WireGate und evtl. nicht mal einen KNX haben. Die müssen sich zwar selber um's Backend kümmern, aber den Client könnten die trotzdem per Package installieren.
Und das Anbieten im SF Download hat den Vorteil, dass Nicht-Debian-Nutzer sich dieses Package per alien trotzdem installieren können)

[Chris M.]

Jetzt muss ich mal dumm fragen: in der branch ist jetzt jquery 1.4.2 aber nicht die minified-version
Was soll nun ins Package:
- selber jsmin,
- die nicht-minified
- oder die von jquery angebotene minified-Version (1.4.2 natürlich) ?

Makki

Die minified der 1.4.2 hatte ich auch die Schnelle nicht mehr bekommen und daher die normale zur minified erklärt. Das ist aber auch egal - denn das Skript soll nur auf das .min schauen und dumm machen. Dass es hier betrogen wird, ist egal.
Ziel hinter diesem Release ist es, den Release-Prozess zu üben. Wenn nämlich das nächste Release das für's öffentliche Beta ist, sollte der Prozess ja schon mal getestet worden sein.

(=> In's Package soll die .min die im inneren nicht minimized ist)

Nachtrag:
Wenn jemand sich die Mühe macht eine 1.4.2 in minimized zu finden, dann darf er die natürlich gerne im Branch drüberspielen...

[makki]

Jetzt muss ich mal dumm fragen: in der branch ist jetzt jquery 1.4.2 aber nicht die minified-version
Was soll nun ins Package:
- selber jsmin,
- die nicht-minified
- oder die von jquery angebotene minified-Version (1.4.2 natürlich) ?

Makki

[netzkind]

Wäre es evt. sinnvoll eine Möglichkeit zu haben über den Editor eine GA selbst eintragen zu können !?

Wäre möglich, ich hab da schon eine Idee.
Ich denke an ein schmaleres Eingabefeld, und rechts daneben ein Button mit [...] um die Select-Liste zu öffnen. Ich denke das sollte relativ intuitiv zu bedienen sein.

Ich kann gerne heute abend mal schauen welches Zeitkontingent ich von meiner Regierung für die Weiterentwicklung bekomme

Grüße,
Julian

[luigi4711]

Frage für den Editor Modus:

Im Moment kann ich nur vorgegebene GA's aus einem Drop-Down Feld auswählen (was auch im Allgemeinen sehr praktisch ist). Das müssten die sein, die man im WG über den ETS Import reinladen kann, richtig? Wäre es evt. sinnvoll eine Möglichkeit zu haben über den Editor eine GA selbst eintragen zu können !? Vielleicht hab ich hier nen Spezialfall (auch weil ich noch im Testaufbau bin und die ETS4 GAs noch nicht eingelesen werden), aber im Umkehrschluss bedeutet es ja auch, dass evt. für eine GA, die nicht bereits bekannt ist, der User auf die Command line muss das XML File editieren, oder aber für evt. eine einzelne neue oder gänderte GA einen kompletten Import macht.

luigi

[makki]

Also, die Demo-Visu ist jetzt Release-Stand (würde ich dann auch so belassen)
Die trunk-Version hier (dito, ist zum testen/machen einfacher)

Bei den SVN-Commits zwischendrin hatte ich schon Sorge dass das Release ohne Editor rausgehen soll

da hätte ich aber auch gemosert Der Editor ist ja nun nicht ganz unerheblich, für "normalos" zu sehen&verstehen, das hier eben am Ende des Tages eben kein XML-File im notepad editiert werden soll.. Uns ist das allen vermutlich deutlich klar, aber das soll man auch sehen und spüren können

=> Das Release 0.5.1 ist da! Das Packagen mag beginnen...

Aber nimmer heute, ich hab mir nach dem Datenblatt dieses Spielzeugs mit rauchendem Kopf gerade mal ein Bier aufgemacht

(Und den Upload auf der SF-Seite nicht vergessen! )

Du meinst das ./debian-Verzeichnis ? Macht IMHO wenig Sinn, weil das ist&wird niemals ansatzweise legal; ich befummle z.B. die config des Webservers, das ist illegal³ - aber nun notwendig damit halt "einfach" lüppt.. ein Teufelskreis..
Wer sich das wiregate-repo einträgt, der bekommt eine explizite Warnung, auf sf würde ich solche Pakete nicht stellen, denn wer sich von dort was installiert hat nunmal zu wissen, das er noch den Webserver konfigurieren muss.. das Backend ist nicht bestandteil des offiziellen bcusdk/eibd (derzeit auch gut so, weil teilw. schrott [-> hints zum segfault?])
Den Knoten wird man zwar irgendwann auflösen können, aber nicht von hier auf gleich..
Zum Backend: nach den Worten& berechtigten Bedenken von mkoegler würde ich daraus dann eh ein sep. eib-clients-cgi.deb o.ä. machen..

Kannst ja auch mal schaun, was jQuery.tools verwendet.

Mach ich. Gut&böse ist immer definitionssache es gibt so 5-10 Gebote, danach zählt für mich nur noch ob es funktioniert..

(Wenn Du nur ein einfachaches Widget als Frame brauchst, den Du dann füllen kannst, gib mir bescheid was Du brauchst)

Das wäre indeed eine Sache, weil daran bin ich am Sonntag gescheitert.. Den flot hab ich ja nachweislich schonmal ans laufen gebracht, wie ich aber function xy aufrufe wenn man irgendwo auf das Widget drückt wollte mir mit vertretbarem Aufwand nicht gelingen; iFrame wäre das zweite (oder dasselbe?!) ich denke aber das man den flot so wie in der alten Demo mit vorhandenem jquery-"popup" macht.
Wenn das geht, werde ich dann wieder hilfe brauchen, damit sich das designtechnisch einfügt
-> naja, ich werde mich realistisch da mittelfristig auch primär am Spielfeldrand halten aber ein paar zeilen gehen vielleicht ab&an..

(*) Meine SVN-Checkin-Policy ist, dass man nur was einchecken darf, was dann auch läuft (bzw. das nichts kaputt macht). D.h. ich verstoße hier gegen meine eigene Regel. Das habe ich mir nicht leicht gemacht, ich finde es aber in diesem Fall gerechtfertigt.

IMHO völlig Ok, sonst kann man nicht effizient weiterentwickeln, dafür gibts ja release und trunk..
Da sehe ich dann schon viel mehr meine Rolle, zu sehen, was für Anwender taugt und was eher nicht

Makki

[Chris M.]

Bei den SVN-Commits zwischendrin hatte ich schon Sorge dass das Release ohne Editor rausgehen soll

Das wäre ja ein Schuss in's Knie...

Man wird das backend für 1.4.4 irgendwie umbauen müssen.
Bis 1.4.2 war es jQuery möglich auf Objekteigenschaften auf die gleiche Art und Weise zuzugreifen wie auf die Eigenschaften von DOM-Objekten (per .attr("name")). Das funktioniert wohl seit 1.4.3 nicht mehr.

Ich bin viel zu wenig im Editor-Code drinnen, als dass ich das bewerten könnte - aber um per "name" auf Objekteigenschaften zuzugreifen gibt's doch seit Anfang an die Notation MyObject['name']...

[netzkind]

Hi Chris,

Ich hab keinen Grund auf 1.4.4 zu setzen - außer dass es die aktuellste Version war als ich die Bibliotheken etwas aufgeräumt habe.

Für's Release habe ich einen Kompromiss gemacht:

• Das Release 0.5.1 hat jQuery 1.4.2 und funktioniert damit
• HEAD ist weiterhin auf jQuery 1.4.4 - und da sollte auch der Fehler behoben werden, dazu ist es ja auch HEAD... (*)

Bei den SVN-Commits zwischendrin hatte ich schon Sorge dass das Release ohne Editor rausgehen soll

Man wird das backend für 1.4.4 irgendwie umbauen müssen.
Bis 1.4.2 war es jQuery möglich auf Objekteigenschaften auf die gleiche Art und Weise zuzugreifen wie auf die Eigenschaften von DOM-Objekten (per .attr("name")). Das funktioniert wohl seit 1.4.3 nicht mehr.

Der Editor läuft so dass er beim "ok"-klicken ein Objekt erzeugt mit all den Eigenschaften wie sie im XML stehen würden wenn es ein DOM-Objekt aus dem XML wäre. Dadurch konnten die Creator unverändert drauf zugreifen.

Das funktioniert mit 1.4.4 schlicht nicht mehr, und ich hab es nicht geschafft in jQuery on-the-fly DOM-Objekte zu erzeugen welche die gleichen Eigenschaften und Methoden haben wie die vom Laden des XML.

Kurzform: für ein Upgrade auf 1.4.4 muss da noch richtig Zeit investiert werden.

Grüße,
Julian

[Chris M.]

Ich nehme an es liegt an der SVN-Revision 146 - und damit am Upgrade an jquery 1.4.4.
Falls es keinen trifftigen Grund gibt wieso wir das brauchen bin ich für downgrade, und dann kann jemand in Ruhe testen wie der Editor anzupassen ist damit er mit 1.4.4 läuft.

Für ein Release sollte 1.4.4 ja dann auch eher nicht notwendig sein würde ich annehmen.

Ich hab keinen Grund auf 1.4.4 zu setzen - außer dass es die aktuellste Version war als ich die Bibliotheken etwas aufgeräumt habe.

Für's Release habe ich einen Kompromiss gemacht:

• Das Release 0.5.1 hat jQuery 1.4.2 und funktioniert damit
• HEAD ist weiterhin auf jQuery 1.4.4 - und da sollte auch der Fehler behoben werden, dazu ist es ja auch HEAD... (*)

=> Das Release 0.5.1 ist da! Das Packagen mag beginnen... (Und den Upload auf der SF-Seite nicht vergessen! )

Zwecks dem min/gz übrigens: minify für die js hab ich schon eingefummelt, bringt aber IMHO aktuell nicht so wirklich den riesen-Knüller (wir sprechen echt über eine einstellige Anzahl von ms via 3G..)

Kannst ja auch mal schaun, was jQuery.tools verwendet. Auch wenn die bisschen als die bösen Jungs des jQuery gelten, schlecht muss es ja nicht sein...

(Übrigens: nicht nur die Übertragung wird schneller, sondern auch das Parsen des Browsers...)

gz kann man machen, macht auch viel Sinn; das mit dem cachen der .gz kann der lighty (&apache etc..) schon selber.

Gut, glaube ich gerne.

P.S.: Flot: es würde.. (auch haben will!)

Du weißt ja, bei OSS bestimmt der, der den Code schreibt
Außerdem ist ja jetzt wieder die Entwicklung freigegeben... (Wenn Du nur ein einfachaches Widget als Frame brauchst, den Du dann füllen kannst, gib mir bescheid was Du brauchst)

(*) Meine SVN-Checkin-Policy ist, dass man nur was einchecken darf, was dann auch läuft (bzw. das nichts kaputt macht). D.h. ich verstoße hier gegen meine eigene Regel. Das habe ich mir nicht leicht gemacht, ich finde es aber in diesem Fall gerechtfertigt. Und jeder der HEAD nutzt, muss sich im klaren sein, dass es solche Phasen geben kann (wenn auch jeder sich, s.o., anstrengen soll, dass das nicht passiert - aber wir sind halt Entwicklung)

[makki]

und damit am Upgrade an jquery 1.4.4.

Ich halte mich da mangels Ahnung meinungsfrei, das macht ihr mal aus und sagt bescheid was rein soll.
bzw.: schiebt ins SVN; nebenbei nochmal: ich finde das ja extra-super-klasse-mega-komfortabel mit dem SVN!


Zwecks dem min/gz übrigens: minify für die js hab ich schon eingefummelt, bringt aber IMHO aktuell nicht so wirklich den riesen-Knüller (wir sprechen echt über eine einstellige Anzahl von ms via 3G..)
gz kann man machen, macht auch viel Sinn; das mit dem cachen der .gz kann der lighty (&apache etc..) schon selber.

Makki

P.S.: Flot: es würde.. (auch haben will!) aber des aufrufen habe ich heute nach 3h aufgegeben, ich glaub ich warte auf ein Widget als kopiervorlage, das anklickbar eine Funktion o.ä. startet