CometVisu - (interner) Beta-Test

[Chris M.]

Ich denke an so sachen wie ne Visu-Seite duplizieren, kurz mal 50 oder 500 Objekte verschieben/kopieren etc. -> genau das kekst mich am HS z.B. ziemlich an (Stichwort: Klickorgie), das ich das nicht ohne weiteres mit einem einfachen Texteditor kann..

Mal kurz die hier für mich wichtigen Punkte:

Pro XML:

• Syntax und Inhalt ist sauber getrennt - d.h. als Daten-Nutzer muss ich mir keinerlei Gedanken über falsch / kaputt formatierte Config-Daten machen.
• Der (Power-)Anwender kann per XSD seine Syntax überprüfen.
• Ein guter XML-Editor (ich kenne auch keinen, da ich noch nicht gesucht habe) könnte auf Basis der XSD eine ganz komfortable Editiermöglichkeit bieten.
• Man kann ganz leicht Tools bauen, die die XML modifizieren - z.B. für einen Massenimport, da so Themen wie XPath etabliert sind.
  (Mit XSLT gibt's sogar eine eigene Programmiersprache dafür - aber leider dürfte die für viele als Frakshow durchgehen, da die wirklich intelligenten Konzepte dahinter ganz anders als klassische Programmiersprachen sind. Genau so geht das geniale Paradigma der funktionalen Programmierung oft als Freakshow durch - auch ich hatte bei den Informatik-Vorlesungs-Hausaufgaben geflucht - aber das ist ein anderes Thema...
  Freunde klassischer Programmierung dürfen die mächtigen XML-Erweiterungen nutzen, die jede vernünftige Programmiersprache inzwischen bietet. PERL, Python, PHP, ...)
• Wir nutzen den simplen Subset von XML der genau so wie HTML aussieht - was inzwischen auch Hinz und Kunz können (so Scherze wie Namespaces sind da ja draußen, auch wenn ich bei der Status-Bar schon mal versucht war HTML als Subset einzubinden...)

Contra XML:

• XML ist nicht als von Menschen zu editierendes Format gedacht, sondern als Austauschformat für strukturierte Informationen - die von Menschen lesbar sein sollen (also eigentlich genau das, was wir hier brauchen...)
• Es gibt keinen (mir bekannten) guten, freien XML Editor

Pro JSON:

• Simpel, schnell und von JavaScript gut unterstützt
• Leicht editierbar (s.u.)

Contra JSON:

• Schwer editierbar (s.o.) - da keine starres Format existiert, an dem man sich entlang hangeln kann.
  (Das ist wie mit Formularen: wenn's eins gibt, schimpft jeder, dass man da seine Infos irgendwie reinpressen muss - aber wenn's keines gibt und man als Freitext das ganze machen soll ist's noch schlimmer, da man nicht weiß, was man wie schreiben soll und Angst hat die Hälfte zu vergessen...)
• Für die Anwendung ist's eine ganz gefährliche Sache - denn der Anwender kann beliebigen Müll reinschreiben das vom Format überhaupt nicht zu den erwarteten Daten passt (auch wenn's valides JSON ist).
  Hier muss man dringend ein sauberes Parsen des JSON-Objektes (also der Datenstrukturen im RAM) durchführen mit entsprechenden Fehlermeldungen. (Ein ekeliger Job...)

In Summe finde ich die Entscheidung eine Config-Datei als XML zu machen immernoch richtig. Einen Flame-War würde ich diesbezüglich jedoch nicht anzetteln, mit JSON könnte ich auch leben.

[makki]

oder wir wechseln mit dem Format der Config von XML auf JSON.

CSV oder .ini stand nicht auf der Liste ? Sorry, war nur ein Treppenwitz
Ich denke: solange es einen Editor gibt ist das relativ egal, ob das hinten oder vorne als XML, JSON, SQL oder sonstwas abgelegt wird. Wer programmatisch rangeht kommt mit all dem klar, dem Anwender ist das eh wurscht..

Beim "semi-power-user" scheiden sich dann aber die Geister, deswegen mag und mochte ich XML ehrlichgesagt noch nie, weil das ist erstmal totale geekshow, wenn mans im Quelltext sieht und verstehen soll.
Und weils dazu wohl bis dato nicht einen gescheiten Editor auf dieser Erde gibt (Suchen, ersetzen, kopieren, verschieben, alles ganz einfache Dinge ), da bevorzuge ich ein Textfile, das man einfach versteht und mit notepad++ be/ver-arbeiten kann - also dann am ehesten JSON.
Ich denke an so sachen wie ne Visu-Seite duplizieren, kurz mal 50 oder 500 Objekte verschieben/kopieren etc. -> genau das kekst mich am HS z.B. ziemlich an (Stichwort: Klickorgie), das ich das nicht ohne weiteres mit einem einfachen Texteditor kann..

Makki

P.S.: Ich persönlich komm mit XML mittlerweile halbwegs klar, nur das hat echt ein bisschen gedauert..

[Chris M.]

Gut das wir drüber geredet haben, ich schau mir das bei nächster Gelegenheit mal an ob sich das so umsetzen lässt

Auch ein Monolog kann da manchmal hilfreich sein

Evtl. hilft da auch die Antwort bei Stack Overflow auf die Frage, die ich mir beim Logik Editor gestellt habe: Where to place interactive objects in JavaScript?

Allgemeingültig sollte die Lösung insofern sein, dass man mit "geringem" Aufwand an "nur einer Stelle" neue Widgets hinzufügen kann (sowohl offizielle, als auch private und Plugins). Außerdem sollten die Widgets leicht erweiterbar sein - z.B. in naher Zukunft um x und y Koordinaten (für die 2D Visu), als auch um ein z bald darauf.
Noch allgemeiner braucht es IMHO nicht zu sein.

Nur zur Sicherheit: die Meta-Infos wie die "attributes" in der aktuellen Struktur habe ich bewusst noch nicht auf die neuen Gegebenheiten angepasst - da die ja von der Editor-Implementierung abhängen.

[netzkind]

Ich saß jetzt wieder mal ein paar Stunden am Editor, aber irgendwie hab ich noch nicht den Weg gefunden auf dem man das so umsetzen könnte dass es dauerhaft und allgemeingültig funktioniert.
Entweder man geht jetzt den Scrum-Weg (Eliminate waste - also nicht allgemeingültig programmieren wenn das kein Erfordernis ist) - oder wir wechseln mit dem Format der Config von XML auf JSON.

Oder, wenn ich das so schreibe: wir wandeln das XML direkt nach dem Ladezeitpunkt in echte Javascript-Objekte um und arbeiten mit denen statt per jQuery auf DOM-Objekte zuzugreifen (major PITA)

Gut das wir drüber geredet haben, ich schau mir das bei nächster Gelegenheit mal an ob sich das so umsetzen lässt

Grüße,
Julian

[Chris M.]

Naja, daher die Frage, ob ich da jetzt vielleicht zu engstirnig ticke 20-30ms statt 500-2000 auf lausiger HW (also keine Core i5-7) finde ich schon als "bringt was"

Finde ich auch.

Denke nicht das das wirklich notwendig ist, ich denke ich packe das - natürlich inkl. Source .deb ins repo

Klar, das geht auch.

Wir sollten nur der diagram-Plugin-Doku einen Hinweis hinzufügen, wo der nicht eingeweihte sieht, wie er dieses Tool bekommt.

[makki]

wenn es uns wirklich was bringt.

Naja, daher die Frage, ob ich da jetzt vielleicht zu engstirnig ticke 20-30ms statt 500-2000 auf lausiger HW (also keine Core i5-7) finde ich schon als "bringt was"

Diesen Fork sehe ich allerdings nicht als Bestandteil der CometVisu - darf aber natürlich gerne im SF mit veröffentlicht werden

Denke nicht das das wirklich notwendig ist, ich denke ich packe das - natürlich inkl. Source .deb ins repo - wir sprechen hier echt von einem depperten 10-Zeiler-Patch, wovon 7 Zeilen kopiert sind trotzdem..

(*) Man darf auch gerne ein Plugin schreiben, dass Werte aus dem HS ausliest.

Hmm, das mag - allein aus der Not - passieren können.. Anderes Thema

Makki

[Chris M.]

Was machen wir eigentlich mit dem Kind?
[...]
Ich hab glaube ich keinen Schmerz damit diese "Variante" von rrdtool 1.3.1 zu verteilen, aber das ist halt schon wieder eine *ziemlich* spezielle Geschichte, von der die Cometvisu dann auch abhängt...

Die CometVisu hängt ja nicht davon ab - das tut lediglich nur das diagram-Plugin. Und die Dependencies der Plugins sind mir relativ egal.(*)

D.h. ich schlage vor, weiterhin bei dem Fork zu bleiben, wenn es uns wirklich was bringt.

Diesen Fork sehe ich allerdings nicht als Bestandteil der CometVisu - darf aber natürlich gerne im SF mit veröffentlicht werden, damit jeder leichten Zugriff drauf hat.


--
(*) Man darf auch gerne ein Plugin schreiben, dass Werte aus dem HS ausliest. Das Plugin würde ich natürlich auch im SVN sehen - ohne dass wir einen HS mitliefern würden...

[makki]

rrdfetch

Was machen wir eigentlich mit dem Kind? Ist cool und schnell, alles wunderbar. Aber genau genommen ein fork vom rrdtool

Upstream besteht ein gewisser Wille (ich hatte das auch schon auf rrd-devel gepostet), allerdings eher in richtung xport statt fetch (20fache Datenmenge zu übertragen..) aber das würde wenn nur in die (10x langsamere wegen irgendwelcher lustiger libcairo-schiessmichtot und daher IMHO keine Option) v1.4 einfliessen, nicht in die 1.3.1 die man in Debian stable grad so hernimmt.

Ich hab glaube ich keinen Schmerz damit diese "Variante" von rrdtool 1.3.1 zu verteilen, aber das ist halt schon wieder eine *ziemlich* spezielle Geschichte, von der die Cometvisu dann auch abhängt...

Wie steht ihr (Chris, Julian) dazu? SuperSonderlocke machen und dafür klein,schön,schnell oder? Jedenfalls könnte man ein billiges shellscript wie in v0.1 machen das mit dem orginal rrdtool funzt, aber dann ists halt eher a***langsam und macht IMHO unterm Strich keinen Spass..

Das ist Fluch und Segen von OSS zugleich, wenn einem was nicht passt ändert man's halt (hier ja nur das ausgabeformat)

Makki

P.S.: Wenn der liebe Gott mal gnädig ist, bekomme ich das auch noch hin, den Wert vor dem Popup anzuzeigen

[Chris M.]

Um einen weiteren untergegangenen Beitrag zu bergen...

Um mal kurz wieder ein Lebenszeichen zu geben:

ich bin leider nicht wie erwartet über Weihnachten zur Anpassung des Editors an den aktuellen SVN-Stand gekommen.

Das ist einer der Unterschiede zwischen kommerziell und privat: das kann ich gut nachvollziehen und hoffe(!) dass Du nun wieder wieder etwas mehr dazu kommst.

Da der aktuelle Source aber im SVN liegt wäre ich niemandem böse der sich auch daran versuchen will. Dann bitte kurze Info, nicht dass da mehrgleisig Energie verwendet wird

Ich werde mich da nicht drum kümmern, da ich momentan am GLE sitze (neben dem 19"-Rack aufräumen, Fotos bearbeiten, damit bald mehr als nur ein Bild an der Wand hängen kann, Markise kaufen, ... )

[makki]

Bei der float Codierung auf etwas bewährtes und debugtes zurückzugreifen ist sicher Sinnvoll

Das sah ich genauso, sowas schreib ich nicht selber weil da sind 10 Fehler vorprogrammiert.
Ebenso wie ich es nicht mehr ungesehen kopiere (siehe DPT9 - mh) ohne ein Testskript das mal 15k-Werte durchgeht

Bei dieser Klasse hab ich jedoch das mit den Copyright-Bedingungen nicht ganz verstanden...

Doch ich denke schon (auch wenns dämlich gemacht ist.. aber da bin ich mittlerweile ganz gut im Saft ), 1:1 mit Author usw. rüberkopieren sollte ok sein, es gäbe auch noch drei alternativen (wovon eine schon wieder satte Fehler hat..)

Lieber gleich zusammenfassen, wir sprechen hier ja nicht von hunderten Zeilen.. Ich comitte das morgen mal, was davon nicht gefällt kann man dann gerne nullen.
Das "neue" jsmin fügt jeweils nur einen C-Verweis auf die ja mitaugelieferte nicht-minified-Version ein, ich denke das ist moralisch und rechtlich 100% safe..

Makki

P.S.: Ob das mit dem DPT14 gerade bei dem am besten aufgehoben ist, der eine Mantisse immernoch für ne unerklärliche Sonderform des Mantelrochens hält = ?

[Chris M.]

War die Frage zu dumm oder ging das unter ?

Vermutlich untergegangen...

Bei der float Codierung auf etwas bewährtes und debugtes zurückzugreifen ist sicher Sinnvoll (wir brauchen hier kein zweites PHP - wobei die ja wohl genau deshalb auf die Nase gefallen sind...). Bei dieser Klasse hab ich jedoch das mit den Copyright-Bedingungen nicht ganz verstanden...

Bei externen dependencies (wie bei dieser Klasse) würde ich die auch getrennt ablegen. Das Optimieren auf niedrige Datei-Anzahl kann man dann später per cat vor dem Komprimieren machen, wenn die ...min.js erzeugt werden.

Das mit compatibility.js -> helper.js können wir gerne machen.

[makki]

Andere Frage, DPT14: beim coding-style bin ich noch sehr wackelig:
ist ja ne rechte sauerei mit dem DPT14, ich hab eine kleine Klasse gefunden die man aber mittelfristig vermutlich an mehr Stellen als nur dem transform_knx brauchen kann.
Nur den Teil in transform_knx reinwuschteln oder separat das ganze Ding?
Würde es Sinn machen, für universellen Kleinkram eine allgemeine helper.js (die dann auch gleich compatibility.js enthielte) zu machen?

War die Frage zu dumm oder ging das unter ?

Makki

[Chris M.]

Soweit ich mich erinnere war der Counter dazu da, etwas Übersicht zu behalten, wie viele Betas da draussen laufen. Finde ich auch ok.

Der Counter ist eigentlich nur dazu da zu zeigen, dass ein Bild alle x Sekunden neu geladen wird.
Das mit der Anzahl der aktuell aktiven Visu ist eher ein interessanter Nebeneffekt - verlässlich ist der überhaupt nicht, denn sobald man seine eigene Visu designt, fliegt der typischer Weise ja raus... (Wenn ich das wirklich wissen wollte, würde ich einen Web-Bug einbauen...)

Nur könnte die doubleclick Geschichte etwas Bedenken hervorrufen, was denn dort im Hintergrund getrieben wird...
[...]
[Edit: Sehe gerade, dass kommt vom Einbinden der Sourceforge Seite ins iFrame Widget...

Richtig gesehen, die SourceForge Seite im iframe ist schuld.
Das ist auch nur da, um das iframe-Widget zu demonstrieren (und die SF Seitenaufrufe / Projektaktivität zu "tunen" - wobei das, wenn man's genau nimmt, eigentlich vollkommen egal ist). Doubleclick ist da zwar doof - aber da das bei der eigenen Visu ja auch sicher rausfliegt, denke ich, dass wir das den Usern zumuten können.

[luigi4711]

Hab's nach längerer Zeit auch endlich mal wieder geschafft auf den aktuellen SVN Stand zu aktualisieren. Aufgefallen ist mir, dass mein NoScript Blocker plötzlich Sourceforge.net und doubleclick.net beim Demo Widget anzeigt.

Ich vermute mal, das hängt mit dem Counter zusammen, der in der Demo drin ist!?
Soweit ich mich erinnere war der Counter dazu da, etwas Übersicht zu behalten, wie viele Betas da draussen laufen. Finde ich auch ok.

Nur könnte die doubleclick Geschichte etwas Bedenken hervorrufen, was denn dort im Hintergrund getrieben wird...



luigi

[Edit: Sehe gerade, dass kommt vom Einbinden der Sourceforge Seite ins iFrame Widget...
Hab ich zu Unrecht den guten Zähler verdächtigt.... ]

[Chris M.]

Für mich ist " 0 = gefahrloser Zustand " die einheitliche Regel beim Beschalten von Aktoren

Das Problem bei dieser Annahme ist, dass nicht immer klar ist, was der "gefahrlose Zustand" ist.

Der gefahrlose Zusand eines Wasseranschlusses oder gar Gas-Ventils dürfte geschlossen sein (also müsste 0 = geschlossen sein).
Der gefahrlose Zustand einer Fluchttüre dürfte offen sein (also müsste 1 = offen sein).

Genau so leicht lassen sich Gegenbeispiele finden. (Müsste nicht die Gas-Versorgung offen = 0 sein, damit im Winter keiner erfriert?!?)

Letztendlich kann man sich das hereindichten (bzw Standard-Nachvollziehen) sparen. Da ist definiert was was ist - und nun muss man damit passend umgehen.
Dem Visu-Anwender ist es nämlich egal ob da eine 0 oder eine 1 dahinter steht - das was er liest und sieht muss passen.
(Und dem KNX Parametrierer, äh, Programmierer, ist's auch egal - die Polarität des Sperrobjektes muss passen. Und wenn die sich überall außer in einem Aktor drehen lässt, dann macht man's halt so um den einen, mit der minderbemittelten Applikation, auch glücklich zu machen)