CometVisu - (interner) Beta-Test

[Chris M.]

So, aus meiner Sicht ist im SVN alles zusammen für ein neues (internes!) Release. D.h. etwas, wo man mal den Package-Mechanismus üben kann, v.a. auch das Ersetzen der Libs durch die Minimized-Versionen.

Spricht noch etwas (außer dem Punkten unten) dagegen?

Eine Sache: Beim laden kommt hier jetzt ein alert Error: "error": Mein Name ist Hase

Ja habe ich auch. Nur kommt das nicht beim Laden, sondern beim Verlassen (inkl. Reload).

Der Fehler selbst wird von dem Client, bzw. dem AJAX-Part erzeugt.

Die genaue Ursache kenne ich nicht - und damit auch nicht, wie ich den verhindern kann.
Vermutung bzgl. Auslöser ist, dass ich alle jQuery-Bibliotheken auf den neuesten Stand gebracht habe und sich das Verhalten geändert hat...

Nebenbei: ich hab den Relaxx auch mal (mit fake-backend) online gestellt, IMHO ne rattenscharfe Sache..
Warum ich das hier schreibe:
Ob/Wie/falls könnte man sowas in die CometVisu integrieren?

Den Relaxx hatte ich auch mal probiert, als ich mein Bad-Radio (Web-Stream via WireGate) eingerichtet hatte. Aber irgendwie konnte ich mich nicht anfreunden...

Ein pauschales und dummes Integrieren könnte per iframe passieren. Ein iframe-Widget hab ich schon seit langem auf meiner internen Planung...
Eine richtige Integrierung sieht aber anders aus. Dazu kenne ich relaxx aber zu wenig.

[makki]

v.a. auch das Ersetzen der Libs durch die Minimized-Versionen.

Vereinfacht ausgedrückt
Variante a)
if -e xy.min.js
cp xy.min.js xy.js
rm xy.min.js # nur im package
(alle vorhandenen min über die eingebundenen bügeln)
b)
if -e xy.min.js
sed /...libs...xy.js/...libs...xy.min.js/g *.?
(alle vorkommen ersetzen wenn eine .min existiert)

Plan b) gefällt mir spontan besser, aber beides ist ein 5-zeiler..

Spricht noch etwas (außer dem Punkten unten) dagegen?

IMHO nicht, Änderungen&der Editor sind cewl und sollte "raus"

Ja habe ich auch. Nur kommt das nicht beim Laden, sondern beim Verlassen (inkl. Reload).

Jep. Dann bin ich insofern beruhigt, das ich auch auf Anhieb keine Idee habe woher das überhaupt kommt..

Den Relaxx hatte ich auch mal probiert,

Naja, es ist halt Browserbasiert, kann alles was man braucht, funktioniert; nebenbei hat man eh noch die 100 Alternativen für mpd-Frontends..
Aber hier interessiert mich ja nur die "perfekt-integrierte" Visu-Lösung.
Ich glaub ich muss den mpd dann mal ein bisschen "entfreaken" (=Projekt #67; Insiderwitz vom Stammtisch gestern), weil die meisten vermutlich garnicht wissen, welch coolen Zuspieler man da nach "apt-get install mpd" + USB-Stick anstecken oder NAS mounten eh schon im Keller hat

Ein pauschales und dummes Integrieren könnte per iframe passieren.

So dumm finde ich das garnicht, es wird ja mehr derlei geben (siehe Feature-Request für einbindung Webseiten); man kann so auch wunderbar mehrere Zuspieler einbinden (mehrere relaxx-Verzeichnisse/configs dümmstenfalls)

Ich stelle mir nur die (vielleicht unbegründete!) Frage: crasht da was, wenn eine komplexe JS-Cometvisu ein anderes komplexes Teil in einem iFrame hochnudelt..

Hintergrund: ich habe mich heute mal hingesetzt und exemplarisch untersucht, was es wirklich bräuchte, damit die CometVisu meine eigene (halbfertige) HS-visu ablösen könnte;
Das mit Abstand komplexeste (bei mir!) ist einfach die Multiroom/Mediensteuerung (bitte wenns geht ohne 1 Woche für 12 Zonen zu klicken ), das andere (mal abgesehen von dem Logik-spezifischen wie Zeitschaltuhr, Meldungsarchiv, Anbindungen etc.) ist Lichter, TFK, Texte -> Kindergarten bzw. geht eh schon das meiste.
Da würde ich allerdings heute einiges grundlegend anders machen als es jetzt ist!


Beispiel (weil es ein gutes ist): Medien/zuspieler-steuerung; nicht die Logikengine bekommt einen connector (kann sie trotzdem haben, ist aber IMHO viel zuviel Aufwand, connector+Visu dazu malen)
sondern ich steuere mit vorhandenen Tools die Zuspieler "nativ", höchstens die Quellen/Zonensteuerung (in diesem Fall anbindung an russound) läuft dann im Backend; der Zuspieler kann genausogut eine Dream, Syno, Squeeze oder sogar iGitt sein.. die haben alle bereits ein funktionierendes Webif..

-> Um diesem Einwand zuvorzukommen: ja das sieht dann leicht "anders" aus, ist so, man kann das - so man will und eben kann - auch perfekt integrieren.
Diese 10% optische Anpassung kosten aber 99% des Aufwandes.
Wenn nicht zwingend notwendig: funktionierts dafür jetzt&gleich&in Zukunft ohne Aufwand. (ich meine: Logikengine parsed nicht das EPG der Dream und in der Visu mache ich 50 info-widget und 30 Senderbilder, die das anzeigen, sondern ich klicke nur auf Dreambox->Sender-EPG..) Und kann nötigenfalls auch gleich die Aufnahme programmieren)

Makki

[Chris M.]

Vereinfacht ausgedrückt
Variante a)
if -e xy.min.js
cp xy.min.js xy.js
rm xy.min.js # nur im package
(alle vorhandenen min über die eingebundenen bügeln)
b)
if -e xy.min.js
sed /...libs...xy.js/...libs...xy.min.js/g *.?
(alle vorkommen ersetzen wenn eine .min existiert)

Plan b) gefällt mir spontan besser, aber beides ist ein 5-zeiler..

Ich bin auch eher für Variante b (ohne da tief drüber philosophiert zu haben).

Nur bisschen mehr sollte es dann schon noch sein (ggf. in Einzelschritten und daher etwas später):
- das JS der CometVisu minimieren (sollte aber auch nur ein Aufruf sein)
- dafür sorgen, dass der Web-Server die Dateien gz-Komprimiert überträgt (ggf. geht es die gleich als gz abzulegen - dann sparen wir auch noch den Overhead die zur Laufzeit komprimieren zu müssen)

[vento66]

Guten Morgen!

So ich habe jetzt mal die Visu aus dem svn installiert, und siehe da das ändern von widgets mit GA's funktioniert, zumindest mit FF und IE. Der Chrome stellt sich immer noch quer. Sowohl unter Win7 als auch unter Ubuntu 10.10.

Auch sollten die Unterschiede zwischen den Designs noch angepasst werden.
Im discreet design weden die Beschriftungen und Elemente mittig auf das Widget zentriert, im pure Design werden sie oben ausgerichtet. Auch sind die Schaltzustände im discreet design mittig auf den Button, im pure Design sind sie links ausgerichtet.
ausserdem sollten 2 nebeneinander liegende Widgets auch die selbe Höhe haben. In der Testvisu ist das widget mit dem counter nicht so hoch wie das widget mit dem Logo der CometVisu links daneben.

[Chris M.]

So ich habe jetzt mal die Visu aus dem svn installiert, und siehe da das ändern von widgets mit GA's funktioniert, zumindest mit FF und IE.

Sehr schön!

Der Chrome stellt sich immer noch quer. Sowohl unter Win7 als auch unter Ubuntu 10.10.

Hm, mist.

Auch sollten die Unterschiede zwischen den Designs noch angepasst werden.
Im discreet design weden die Beschriftungen und Elemente mittig auf das Widget zentriert, im pure Design werden sie oben ausgerichtet.

Ja, das müssen noch ein paar Dinge, die das discreet richtig macht, in's pure übernommen werden. Das sehe ich aber v.a. vor der öffentlichen Beta - die zweite interne sollte das noch nicht treffen.

Bzgl. den Error-Alerts: mein Versuch noch vor dem Seitenwechsel den laufenden AJAX-Request zu beenden hat gestern Abend keine Besserung gebracht. Jetzt muss ich erst mal nach FFB zum Brunch. Sollte als kein Heinzelmännchen dieses Thema lösen, komme ich erst heute Abend wieder dazu.

[makki]

hmm, mit dem editieren siehts bei mir auch nicht so toll aus, Ok drücken is nich:

elem.attributes is undefined
http://172.17.2.65/visu/lib/jquery.js
Line 1788

Ich spiel mich inzwischen mal mit dem flot aber bisher mag das alles nicht so wie ich will

Makki

[Chris M.]

Bzgl. den Error-Alerts: mein Versuch noch vor dem Seitenwechsel den laufenden AJAX-Request zu beenden hat gestern Abend keine Besserung gebracht.

Den Grund konnte ich immer noch nicht finden - und damit auch nicht beheben.
Aber: ich werfe jetzt einfach kein Alert mehr, wenn es uns nicht mehr interessieren kann (da Verbindung beendet, oder - wie in diesem Fall relevant - der readyState auf COMPLETED ist).
=> diesbezüglich könnten wir releasen
(Und hoffentlich findet noch jemand den wahren Grund... Fehler verstecken statt zu beheben macht mich nervös)

hmm, mit dem editieren siehts bei mir auch nicht so toll aus, Ok drücken is nich:

elem.attributes is undefined
http://172.17.2.65/visu/lib/jquery.js
Line 1788

Habe ich auch - und sollte vorm zweiten Beta behoben werden, den so ist der Editor z.Zt. nicht nutzbar

Wenn's behoben ist, werde ich eine 0.5.1 releasen

[netzkind]

Habe ich auch - und sollte vorm zweiten Beta behoben werden, den so ist der Editor z.Zt. nicht nutzbar

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.

Grüße,
Julian

[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

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

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

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

[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

[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

[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