CometVisu - (interner) Beta-Test

[Chris M.]

Label zu breit? Bildschirm zu schmal?

Viel kann man nicht machen, wenn der Platz benötigt wird.
Oder gibt's wo noch ungenutzten Raum? (Screenshot?)

Ach ja, je nach Design kann's natürlich unterschiedlich aussehen.

[JNK]

infotrigger

Hallo zusammen,

ich habe folgendes Problem mit dem infotrigger:

die rechte (also actor)-Hälfte ist so breit, dass das Widget umgebrochen wird und somit das Label über und nicht links neben der Anzeige steht. Das betrifft alle Designs und zwar sowohl FF7 als auch Chrome. Der Label-Teil wird als 299 px breit angegeben, der actor-Teil als 376 px.

Das Problem löst sich, wenn man die Breiten von .switchPressed, switchUnpressed und .switchInvisible in der basic.css von 5em auf 3.5 em reduziert. Aber das macht ja irgendwie keinen Sinn.

Erstaunlicherweise ist mir das vorher nie aufgefallen. Hat jemand eine Idee, wie ich debuggen könnte, was das eigentliche Problem ist?

gruss,

der Jan

[makki]

=> Fang doch einfach an mit dem was Du weist, dann müssen die Kenner der Internas nur noch die Lücken auffüllen.

Full ack, es ist erheblich einfacher und schneller mal schnell was nachzutragen oder zu ergänzen, wenn schon Fleisch da ist als hier ein langwieriger Vorschlag/Review-Prozess zwischen eine handvoll leuten..
Und eine unvollständige Doku ist besser als keine..

bzgl. "doxygen für JS" hab ich auch schonmal gesucht aber kam da nicht so recht zum Ziel. Wäre für Widgets und Plugins sicher optimal sowas! (source-comment schreibt man IMHO viel eher als eine sep. Doku in Wiki&Co)

Geht das in der Statuszeile nur, wenn das Widget auch platziert wird? Ich hätte es nämlich eigentlich gerne nur da, aber solange ich nicht auch ein entsprechendes Widget auf der Seite platziere erscheint nur ein "-".

jqclock: ja, ich hatte das zwar mal erwähnt, das es mind 1x irgendwo als Widget drin sein muss aber dann wieder verdrängt Ich weiss schlicht nicht wie ich (irgendwas) ohne/ausserhalb VisuDesign_Custom.prototype.addCreator- create in einem Plugin aufrufe/initialisiere(? ist bestimmt ganz einfach)
Mache gleich mal nen Bug dafür auf damit es nicht untergeht.

Makki

P.S.: hab mal im SF-tracker eine Group 0.6.0 angelegt damit man explizit trennen kann was in die erste Beta muss und was (in die bereits vorhandene) "after 0.6" gehört.

[Chris M.]

Ja, aber die könnte man ja gleich im richtigen Format schreiben. Dann gibt's das ohne Mehraufwand.

[greentux]

Ich würds nicht übertreiben. Ein paar Zeilen Kommentare (hier und da ja auch schon vorhanden) reichen, damit non-DEVs sich da einlesen können... Es sollte dann nur vollständig dastehen, was implementiert ist.

[Chris M.]

Hier wollte ich immer mal JavaDoc oder wie auch immer das Standard-Tool nochmal heißt (so wie Doxygen nur für JavaScript...) verwenden.

Mein großes Problem:
Ich hab damit noch nie gearbeitet und keine Zeit gehabt mich da einzulesen.

=> Wer hier Erfahrung hat (oder die sich angelesen hat...) bitte einbauen.
Sobald ich spicken kann, würde ich mich bei den weiteren Widgets mit dem Befüllen beteiligen...

Wenn's geht noch vor der 0.6.0...

[greentux]

Zukünftige Widgets könnten ggf etwas Minimaldoku im Sourcecode enthalten... Ich habs mir dort etwas angesehen, ist aber mühselig als nicht-Dev.

[JNK]

jqclock (Uhr-Widget) ist submitted.

Optional auch in der Statuszeile z.B. (wichtig ist nur id="jqclock_status"):
...
<status type="html"><![CDATA[
- <a href="check_config.php">Check Config</a>
<div class="jqclock" id="jqclock_status" lang="de" date="true">-</div>
<div style="float:right;padding-right:0.5em">Version: SVN</div>
]]></status>
...

Geht das in der Statuszeile nur, wenn das Widget auch platziert wird? Ich hätte es nämlich eigentlich gerne nur da, aber solange ich nicht auch ein entsprechendes Widget auf der Seite platziere erscheint nur ein "-".

Gruss,

der Jan

[Chris M.]

Das mit den "geheimen" Parametern ist genau das Problem das ich lösen möchte.
=> Fang doch einfach an mit dem was Du weist, dann müssen die Kenner der Internas nur noch die Lücken auffüllen.

Den Artikel hier im Forum sehe ich (wie schon mal geschrieben) mehr als allgemeine Info über die CometVisu.
Die Dokumentation selbst gehört IMHO dann in's SF Wiki.

[swiss]

Ich arbeite gerne an der Doku mit aber das Probelem ist, dass meistens nur die Entwikler selbst alle Einstellungen und Möglichkeiten im Detail kennen. Ich habe mal versucht einen Lexikonbeitrag für das Forum vorzubereiten muss aber gesteehn dass gerade bei der Beschreibung der Parameter noch einige Fragen offen bleiben

Vieleicht wäre es mal eine Möglichkeit, dass ich den Vorabzu für den Lexikoneintrag hier in Unterforum in einem neuen Thema eröffne und dann jeder drüber schauen und Imputs geben kann. Wenn dann alle Parameter klar sind kann man daraus dann das Wiki füllen. Das kann dan sehr viel deteilierter und mit Screenshots erfolgen.

Was haltet ihr von diesem Vorschlag?

[Chris M.]

Das war auch nicht unbedingt so gedacht in 0.6.0 zu müssen, dafür gibts ja doch schon eine release-branch..

Ich hatte gehofft, das es einen Branch gibt.

OK, das war schlecht (ok, gar nicht) von mir kommuniziert.

Mein aktuelles vorgehen ist:
Alle Entwicklung findet unter trunk statt. Jedes Release wird davon weg gebrancht. Im Branch findet nur noch die Arbeit für's entsprechende Release statt, was so 1-2 Dateien betrifft.
Wenn tatsächlich später mal ein gravierendes Problem in einem Release auftreten sollte und man nicht ein neues aus trunk ableiten möchte (z.B. weil schon inkompatible Änderungen bzgl. Config-Datei drinnen sind), dann könnte man aus einem branch den (Bugfix-)Nachfolger ableiten.

Was ich nicht geplant hatte, war dass an der nächsten Version gearbeitet wird, wenn die alte noch nicht draußen ist. Dazu habe ich unsere Ressoucen als zu limitiert eingeschätzt - wenn sich jeder nämlich gleich auf's neue stürzt, hat man niemanden mehr, der das langweilige Bugfixing im alten übernimmt. => Es wird gar kein Release geben können

Um hier einen Kompromiss hin zu bekommen, habe ich jetzt unter

https://openautomation.svn.sourceforge.net/svnroot/openautomation/CometVisu/tags/post_0.6.0

einen branch / tag erzeugt. Hier kann man schon mal Code einbauen der nach der 0.6.0 in den trunk wandern soll...

Wie oben geschrieben, bitte verantwortungsvoll damit umgehen und primär die Bogs beheben damit das Release endlich raus kann!

An alle Nicht-Entwickler:
Was wir für die öffentliche Beta gut gebrauchen könnten, wäre eine Erweiterung des Benutzerhandbuch um Details für jedes Widget. (Z.B. auf der Seite XML-Elemente)
Dabei stelle ich mir für jedes Widget einen Screenshot (bzw. Screenshot-Ausschnitt) vor, so wie die im Editor sichtbaren Parametern und deren Bedeutung.

[greentux]

Ich hatte gehofft, das es einen Branch gibt.

Zum PM:
Ich hätte gern für den Flur, der normalerweise Argus gesteuert ist, einen Switch, wo man
- "Licht ein"
- "Licht aus"
- "Licht Auto" togglen kann.
Momentan habe ich zwei Switche dafür (siehe Screenshots im SF Bereich).
Wenn ich auf "Licht ein" gehe, sollte einmal der PM gesperrt werden und der Aktor EIN bekommen. Klar kann man das im PM hinterlegen (Aktion bei Sperre EIN -> Aktor EIN). Spätestens wenn das bei "Licht aus" auch so sein soll, gehts dann irgendwie nicht mehr via Aktor (oder ich übersehe gerade etwas).

[makki]

Das war auch nicht unbedingt so gedacht in 0.6.0 zu müssen, dafür gibts ja doch schon eine release-branch..

Makki

[Chris M.]

Ist mir grad so gekommen:
Wenn man nun einige wiederkehrende config-snipplets/pages hat, wäre es doch schön diese irgendwie in visu_config* zu "includen".

Ja, bitte Feature-Request, damit wir's nicht vergessen. Nicht für 0.6.0.

P.S.: einen hab ich noch weil ich grad drin war

Es ist höchst unbefriedigend, wenn ich hier einbremsen muss (mich selbst eingeschlossen) - aber wird sind gerade in der Endphase und damit Feature-Freeze für die 0.6.0

Gerade bei Features die man selber braucht und die ungefährlich wirken ist die Versuchung leider sehr groß.

Vorschlag: Änderungen bitte nur noch um Fehler zu beheben - dazu zählen auch Useability-Bugs (bei denen der Übergang zum neuen Feature leicht verschwimmen kann).
Sollte man doch noch ein neues Feature haben und dringen einbauen wollen, dann bitte nebenwirkungsfrei, d.h. wenn man an jeglichen vorher existierenden Configs nichts ändert, dass der neue Code dann nicht ausgeführt wird.
Alles andere bitte vorher hier absprechen oder in einem Fork, den man nach der 0.6.0 wieder zusammenführen kann.

[makki]

Ja, der Toogle schaltet eine GA beliebig um; also je nach mapping und Möglichkeiten des DPT 0/1/400/.. , 10/30/50/.. oder leer/mittel/voll/übergelaufen

Ich verwende das aktuell in der HS-Visu recht oft (allerdings braucht man dort zu jedem Button eine zus. Logik )

Für die PM-Sperre ist wohl Multitrigger eher der Freund, wobei wir hier halt auch immer ganz hart an der grenze zur Logik schrammen (die IMHO in der Visu nichts verloren hat) -> der Toggle bedient hier primär nicht KNX-Teile.

-> Bei meinen PM "bediene" ich sowieso nur das Sperrobjekt, der Rest ist in der Appl des PM hinterlegt und das ist so auch nicht ganz falsch..
Aber wenn Du näher beschreibst was es machen soll und warum genau es nicht mit "normalem" KNX geht, kann man mal sehen; bin mit dem toggle eh noch nicht ganz zufrieden..

Makki

P.S.: einen hab ich noch weil ich grad drin war
jqclock (Uhr-Widget) ist submitted.

Optional auch in der Statuszeile z.B. (wichtig ist nur id="jqclock_status"):
...
<status type="html"><![CDATA[
- <a href="check_config.php">Check Config</a>
<div class="jqclock" id="jqclock_status" lang="de" date="true">-</div>
<div style="float:right;padding-right:0.5em">Version: SVN</div>
]]></status>
...

CSS ist wie immer noch nicht wirklich optimal

P.P.S: demo-config für infotrigger/relative, toggle und jqclock folgt noch ins SVN wenn das sich etwas gesettled hat.