CometVisu - (interner) Beta-Test

[Chris M.]

Ich denke eher man müßte nochmal genau definieren wofür ein Design überhaupt ist.
- die Optik zu definieren
- Funktionen zu ermöglich/einzuschränken
Meiner Meinung sollte es nur die Optik (eben das Design) betreffen und keine Funktionen.

Das ist zum Glück bereits genau definiert - nur hab ich's im Wiki leider spontan nicht gefunden.

Die CometVisu, wie hier bekannt, besteht aus mehreren Schichten auf dem Client:

1. CometVisu Client - eine JavaScript Bibliothek, die die Kommunikation übernimmt
2. templeteengine.js - die Engine, die auf Widgets zurückgreift und diese nach Config-Datei positioniert.
3. structure_pure.js - die Definition der Widgets (zusammen mit der structure_custom.js für eigene Widgets und den Plugins)
4. Das Design in den CSS.

Alles was auf 1 zurückgreife ist im Grunde eine CometVisu (bzw. nutzt das CometVisu Protokoll) - egal wie's aussieht.
Das Aussehen wird in den Designs (pure, discreet, ...) definiert. Und in den Strukturen - wo es z.Zt. nur "pure" gibt - in Funktion gebracht.

Will man nun eine "andere" Visu gestalten, muss man sich überlegen, wo man angreifen möchte. Wenn mal in Zukunft eine LCARS Visu kommt müsste mindestens 3 evtl. auch 2 angefasst werden (da 4 zu 3 passen muss, 4 natürlich auch)

Wie Julian bereits geschrieben hat, sehe ich ein Default-Design, dass jeweils überschrieben wird, nicht unbedingt als zielführend an.
Was aber Sinn macht (und IIRC schon umgesetzt ist), ist das man lokal eines der Designs überstimmen kann.

[Chris M.]

1000 Posts... Wie gehts nun weiter mit der Cometvisu?

Ich warte immer noch auf den Editor 2.0 (oder auch 1.5 ) - selber konnte ich mich dem Thema noch nicht widmen (Kappa... )

Übrigens: eigentlich wollte ich die CometVisu zum letzten Weihnachten in die öffentliche Beta bringen...

[greentux]

Ja, ich bin immer noch dafür eine Beta zu machen und die Anwender bei der xml zu unterstützen. Ergo, etwas Visu und Editor entkoppeln...

[Chris M.]

Wie sehen die anderen diesen Vorschlag?

[Bodo]

Hoi

Ich hab' keine Ahnung worum es genau geht, aber auf eine Beta warten wohl schon einige.
Das kann natürlich einen Rattenschwanz von Nachfragen nach sich ziehen, wie a geht oder b ...

[Chris M.]

Ich hab' keine Ahnung worum es genau geht

Es geht um die Frage, ob man die Beta öffentlich machen kann/soll/darf/muss/... obwohl der Editor bekannte Einschränkungen hat und man dann per Hand zum Test-Editor für die XML-Datei greifen muss...

[Bodo]

Hmm, schwierige Frage. Wenn der Editor in einem Monat fixbar ist würd' ich's nicht veröffentlichen, wenn es eher noch ein viertel Jahr braucht dann schon.

[greentux]

Es ist ja schon ein paar Monate her.
Die linknx Dateien werden ja auch immer mal wieder im Forum supportet. Ich glaube auch nicht, das sich absolute Laien die Visu antun werden. Da fehlen dann ja schon noch einige Funktionen.
Die stauen sich derzeit in der Featurequeue, weil erst Beta gemacht werden soll, bzw. weil der Editor nicht nachkommt. Diese Verzahnung könnte man ja lösen... Ob dann neue Features eher kämen? Wer weiss.

[netzkind]

Ich kann mir vorstellen, dass man die Visu um die Gruppen erleichtert, die sind grade so der Hauptgrund wieso ich jedes mal verzweifel wenn ich am Editor arbeiten will.

Also Beta ohne Gruppen, dann ist in relativ kurzer Zeit vorstellbar auch den Editor dann up-to-date zu bringen.

Hintergrund ist, dass die Gruppen im Editor nicht funktionieren weil die Funktionsfähigkeit des benutzten jQuery-Plugins das verschieben einfach nicht hergibt. An das Plugin mag ich nicht rangehen (jQuery UI, namentlich dessen drag & drop).

Grüße,
Julian

PS:
Visu ohne Editor veröffentlichen ist meiner Einschätzung nach Selbstmord. Dafür ist der Erwartungsdruck inzwischen zu hoch. Selbst für eine Beta.

[vlamers]

Ich glaube auch nicht, das sich absolute Laien die Visu antun werden.

nur die mit einem übertriebenen Ehrgeiz was neues zu lernen. und die löchern die beta tester dann mit fragen.
Also ich muss sagen dass die CV mit bisschen bearbeiten der XML sogar für den täglichen Gebrauch schon sehr gut läuft. Und so schwierig ist die nachbearbeitung nicht dass sie gut läuft. Meiner Meinung nach wäre eine öffentliche beta Ok. Schwierig wird es imho wenn drastische Änderungen hinzukommen würden.
Gruß

Edit: ja ohne Editor wäre Wahnsinn

Sent from my LG-P920 using Tapatalk

[Chris M.]

Ich kann mir vorstellen, dass man die Visu um die Gruppen erleichtert, die sind grade so der Hauptgrund wieso ich jedes mal verzweifel wenn ich am Editor arbeiten will.

Also Beta ohne Gruppen, dann ist in relativ kurzer Zeit vorstellbar auch den Editor dann up-to-date zu bringen.

OK, das klingt nach einem Plan!

Ich disable die Gruppen und Du bringst Editor für den Rest auf Stand.
(Zeit wäre bis Mitte KW40, vorher will ich kein Release, da ich dann nicht zum antworten kommen könnte...)

Frage: Was ist mit dem ColorChooser? Würde der dann funktionieren? Oder sollten wir als "Experten-Feature" deklarieren? Da's ein Plugin ist, könnten wir sogar ohne releasen...

Mittelfristig würde ich dann endlich den 2D und ggf. 3D Modus einbauen, dann sollte hoffentlich klarer werden können wie der universelle Editor dann aussehen muss.

[greentux]

Die Gruppen aber nicht in der Visu ausbauen oder?

Vl. wäre immer noch überlegenswert, keinen WYSIWYG Editor zu haben, sondern eher eine Art XML Erstellungshilfe
Das wird ja bei 2/3D nicht einfacher.

Tschuldigung, wenn ich so direkt frage: Gibts dann noch jemanden, der sich um die Feature Requests zur derzeitigen Visu kümmert? Ich denke ja, 2D wird auch eine Weile dauern, da wär das ein oder andere Gimmick schon nett...

[Chris M.]

Die Gruppen aber nicht in der Visu ausbauen oder?

Meine Idee war den Widgets eine zusätzliche Eigenschaft namens "Maturity" zu geben die auf "release" (default) oder "development" stehen kann.
Der Editor würde dann alles unter "development" ignorieren - solange nicht global oder per URL-Parameter auf development geschaltet wird.

=> Wenn Du's in Deine XML drinnen hast, wirst Du es sehen und nutzen können - aber der Editor wird es evtl. zerstören wenn Du ihn nutzt...

Vl. wäre immer noch überlegenswert, keinen WYSIWYG Editor zu haben, sondern eher eine Art XML Erstellungshilfe

Daran hatte ich ganz am Anfang gedacht - und gleich dazu geschrieben, das ich keinen Editor brauche und ihn deshalb nicht schreiben werde.

Julian hat dann den Ball aufgenommen und den genialen WYSIWG Editor geschrieben

Das wird ja bei 2/3D nicht einfacher.

Gerade da wird ein grafischer Editor wichtig! Koordinaten eintippen will ich niemanden zumuten.
Bedonders spannend wird es werden, wie man einen Editor für das 3D Gebäudemodell macht

Tschuldigung, wenn ich so direkt frage: Gibts dann noch jemanden, der sich um die Feature Requests zur derzeitigen Visu kümmert? Ich denke ja, 2D wird auch eine Weile dauern, da wär das ein oder andere Gimmick schon nett...

Jeder der will!

Das hier ist Open Source. Da macht jeder freiwillige das was sie/ihn interessiert.
Die langweiligen Themen werden dann oftmals von Firmen erledigt, die damit Geld verdienen wollen.

Ich persönlich mache die Features, die mich auch interessieren oder die schnell mal nebenbei gehen und wo ich einen hohen Nutzen für die Allgemeinheit sehe. Daher ich mein Ziel z.B. die 3D Visu die ich einbauen werde, die 2D Visu wird dabei nebenbei mit abfallen.

[Bodo]

Meine Idee war den Widgets eine zusätzliche Eigenschaft namens "Maturity" zu geben die auf "release" (default) oder "development" stehen kann.
Der Editor würde dann alles unter "development" ignorieren - solange nicht global oder per URL-Parameter auf development geschaltet wird.

Hoi

Sehr gute Idee, vielleicht kann der User auch einzelne Sachen versiegeln mit dem Status "nochange"

[netzkind]

=> Wenn Du's in Deine XML drinnen hast, wirst Du es sehen und nutzen können - aber der Editor wird es evtl. zerstören wenn Du ihn nutzt...

Stimmt, und das muss man auch ganz klar so sagen.

Den Vorschlag von Bodo mit dem "nochange" halte ich für nicht durchführbar, aufgrund dessen wie der Editor funktioniert: der Editor speichert nicht das XML, sondern er "serialisiert" was im Browser zu sehen ist. Was er da nicht kennt, kann er nicht serialisieren, das schafft es dann nicht bis zum serverseitigen Speichervorgang (das PHP) und damit ist es dann einfach weg. Dem PHP jetzt beizubringen das er aus dem ursprünglichen XML das er noch auf der Platte hat bestimmte Äste in das neue XML übernehmen soll dürfte schwer werden, denn was dient als Bezugspunkt im XML wenn sich der Baum massiv geändert hat?
Oder ich habe es anders verstanden als Bodo es meinte

Grüße,
Julin