CometVisu - (interner) Beta-Test

[Chris M.]

Huch, Popus per GA? Hab ich was übersehen?

Nein.

Popups sind zur Zeit noch eher stiefmütterlich behandelt (ich hab schon seit ein paar Monaten dort nicht mehr in den Code geschaut...), insbesondere weil der Editor keine Möglichkeit hat die mit Inhalt zu befüllen. Ist also etwas Henne/Ei.

[greentux]

Huch, Popus per GA? Hab ich was übersehen?

Zur Releaseproblematik.

Sobald Du für einen Release Feature Freeze machst, mußt Du zwangsläufig branchen, wenn denn in HEAD fröhlich weitergearbeitet werden soll. Oder man hat Merge Windows und stabilsiert dann gemeinsam.
Abwägungssache. Das eine erzeugt mehr Arbeit (Merges zwischen Branche(s) und HEAD), das andere läßt die Neuerungen bei den Entwicklern auf der Platte...

[Chris M.]

Mir fallen gerade 1'000 Dinge ein für was man das gebrauchen kann... (Warnseiten, Adminseiten, Benutzerseiten...)

Wobei wir auch noch die Popups haben.

Aber IMHO ergänzt sich beides sehr gut!

[swiss]

Hab ich dann mal erledigt.

Gruss,

der Jan

Wooow! Das ging ja fix. DANKE Mir fallen gerade 1'000 Dinge ein für was man das gebrauchen kann... (Warnseiten, Adminseiten, Benutzerseiten...)

Genau dass hat mich beim HS immer gestört.

[Chris M.]

Ich wünsche mir bis dahin bitte eindeutige Nummerische Versionsnummern (1..1000 mit Punkten dazwischen )

Da wir für "trunk" im Feature-Freeze sind, habe ich das in post_0.6.0-branch committed. [...]
Ich finde das Verfahren etwas unglücklich, nach der 0.6.0 sollten wir uns über die Frage Release/Branch/Trunk usw. nochmal unterhalten. Ich würde da das "mozilla"-Verfahren glaube ich vorziehen.

Passt beides grob zusammen.

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

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.
=> Bis dahin sind wir unter 0.x...

Die erste öffentliche Version war 0.5.0.
Die öffentliche Beta wird 0.6.0 sein. Die Zwischenschritte zu 1.0.0 sind noch nicht definiert.

Jetzt in der Stabilisierungsphase ist die große Frage wie man mit den Versionsnummern umgeht.
Eine 0.5.99 (gab's bei KDE IIRC)? Finde ich unschön.
Eine 0.6.0-pre und 0.6.0-RC1 / 0.6.0-RC2 fand ich deutlich passender. Dabei habe ich sogar darauf geachtet, dass eine lexikografische Sortierung dafür sorgt, dass die Reihenfolger bzgl. der Neuigkeit erhalten bleibt...

Zum Branch-Verfahren:
Ich bin eigentlich davon ausgegangen, dass wir eine sehr lineare Arbeitsweise haben. D.h. einen Branch gibt es nur für ein Release und ggf. notwendige minimale Korrekturen. D.h. alle arbeiten eigentlich unter HEAD.

Nun stellte sich aber das Problem, dass sich Änderungen angesammelt haben, die erst nach dem Feature Freeze wieder dazu kommen sollten. Also quasi ein Merge Window erforderlich machen würden.

Mir ist nun wichtig, dass maximal viele unter HEAD testen, aber ich will auch keine Weiterentwicklungen auf den Platten versauern lassen, nicht dass ein HDD-Crash kommt

Einen zweiten Wunsch hätte ich aber immernoch fürs finale Release: das minify der JS im release statt das danach im Packerl zu machen (was auch nur bisher zu 50%-> ich machs auch, machs jetzt ja auch halbwegs händisch im packerl..)

Kann ich gerne machen, ich release ja auch inzwischen per Skript, da kann ich das gut einbauen...
Was verwendest Du für's Minify?

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

Ich hab da nochmal eine Frage. Jetzt wo mit Rev. 476 alle DPT gehandelt werden: wäre es nicht sinnvoll in der transform_knx.js folgende Änderung vorzunehmen:

Das "default-decode" kommt z.B. in

DPT1 statt DPT1.001

Alle nicht-spezial-Transformationen werden entfernt (werden ja eh durch den Standard erledigt.

Das würde den Code wahnsinnig aufräumen.

Ja und Nein.

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

[JNK]

Ok mach ich bei Gelegenheit. Hat aber überhaubt keine Eile. Ich habe noch genug mit der Doku im SF zu tun

Hab ich dann mal erledigt.

Gruss,

der Jan

[JNK]

Ich meine die Javascript animation beim seitenübergang. Aber das wird von extern nicht möglich sein, das das Javascript direkt auf dem Client ausgeführt wird.

Achso. Das ist einfach. Habe ich schlichtweg übersehen. Wird gefixt.

Gruss,

der Jan

[swiss]

Ich meine die Javascript animation beim seitenübergang. Aber das wird von extern nicht möglich sein, das das Javascript direkt auf dem Client ausgeführt wird.

Machst Du nen Feature-Request? Dann schau ich mir das mal an. Aber ich will nix versprechen.

Ok mach ich bei Gelegenheit. Hat aber überhaubt keine Eile. Ich habe noch genug mit der Doku im SF zu tun

[JNK]

Funktioniert perfekt Zwar ohne Animation aber das ist egal.

Was für eine Animation?

Würde nur noch fehlen, dass man seiten einrichten könnte auf die ausschliesslich über eine GA zugegrifen werden kann (Adminseite) ohne Link in der Visu.

Machst Du nen Feature-Request? Dann schau ich mir das mal an. Aber ich will nix versprechen.

Gruss,

der Jan

[swiss]

Funktioniert perfekt Zwar ohne Animation aber das ist egal.

Würde nur noch fehlen, dass man seiten einrichten könnte auf die ausschliesslich über eine GA zugegrifen werden kann (Adminseite) ohne Link in der Visu.

[swiss]

Danke

[JNK]

Ist das pageswitch-widget nur bei dir am laufen oder steht es im SVN zum testen bereit?

Da wir für "trunk" im Feature-Freeze sind, habe ich das in post_0.6.0-branch committed. Den findest Du im SVN unter

/CometVisu/tags/post_0.6.0/

Ich finde das Verfahren etwas unglücklich, nach der 0.6.0 sollten wir uns über die Frage Release/Branch/Trunk usw. nochmal unterhalten. Ich würde da das "mozilla"-Verfahren glaube ich vorziehen.

[swiss]

Hallo Jan

Ist das pageswitch-widget nur bei dir am laufen oder steht es im SVN zum testen bereit?

[JNK]

Ich hab da nochmal eine Frage. Jetzt wo mit Rev. 476 alle DPT gehandelt werden: wäre es nicht sinnvoll in der transform_knx.js folgende Änderung vorzunehmen:

Das "default-decode" kommt z.B. in

DPT1 statt DPT1.001

Alle nicht-spezial-Transformationen werden entfernt (werden ja eh durch den Standard erledigt.

Das würde den Code wahnsinnig aufräumen.

Gruss,

der Jan

[makki]

Schwere Geburt
(.deb) Paket für 0.6 rc2 ist raus, Hinweise: Falls eine visu_config.xml vorhanden ist wird diese nicht mit der aktuellen Demo-config überschrieben sondern diese als visu_config_demo.xml abgelegt; aufrufbar mit /visu/?config=demo

Makki