CometVisu - (interner) Beta-Test

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

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

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

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

Wie sehen die anderen diesen Vorschlag?

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

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

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

[greentux]

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

[ctr]

Wer ein neues Design entwickelt, sollte die volle Kontrolle haben und sich nicht damit beschäftigen müssen, erst mal alte Definitionen zu überschreiben. Zumal es echt nervig ist, wenn sich die Dinge anders verhalten als man es definiert hat, nur weil einem ein altes System zu zwischen die Beine grätscht.

Ich bin sogar der Ansicht: wer ein neues Design entwickelt soll das bitte vollumfänglich planen, inklusive aller Elemente. Und wer ein neues Element entwickelt, sollte alle bestehenden Designs vervollständigen, oder dafür Sorge tragen dass der ursprüngliche Entwickler der Designs weiß dass er das tun sollte. Sonst haben wir bald nurnoch unvollständige Designs.

Dieser Ansatz hat durchaus seine Vorteile aber damit erzwingt man eine starre Maintainer-Struktur. Das mag in komplexen Umgebungen (Linux Kernel/Treiber) sehr sinnvoll sein ist aber meiner Meinung nach bei so einem Projekt kontraproduktiv, da Du damit verhinderst das jemand mal schnell einen Bugfix oder auch eine Erweiterung comitted die er bei sich selbst zu laufen hat.

Ich z.B. möchte ein Design nutzen, ich weiß noch nicht welches und ich bin gern bereit mehrere auszuprobieren und meine Änderungen (wenn ich sie denn für sinnvoll erachte) zu commiten. Ich möchte mich aber weder mit jedem einzelnen Design-Maintainer vorher absprechen müssen, noch für eine kleine Erweiterung einen kompletten Fork starten, noch Änderungen (zwangsläufig und sofort) für alle Designs (selbst) nachziehen.

Ist mein Ansatz nun naiv?

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. Wenn ich aber in der visu_config.xml eine Funktion "styling" nutze, muß ich mich doch auch darauf verlassen können, dass das im Design irgendwie Beachtung findet. *Wie* es umgesetzt wird (z.B. leichte Farbschattierungen) mag dem Design überlassen sein, aber solange es *nicht* definiert ist (z.B. bestimmte Farben) sollte es doch auf einen "sinnvollen" Default-Wert gehen und damit meine ich nicht weiß...

[netzkind]

ja man könnte doch aber auch mit anderen variablen arbeiten, dann kann es immernoch jedes Design anders umsetzen (oder auch nicht wenn es paßt, was den Arbeitsaufwand erheblich reduzieren sollte).
Geht es nicht eventuell sogar mit Prioritäten? Wie verhält sich ein Include wenn eine Variable aus zwei verschiedenen CSS herkommt? Wird die erste, letzte oder irgendeine Definition benutzt?

Könnte man, aber das scheint mir nicht zielführend:
Wer ein neues Design entwickelt, sollte die volle Kontrolle haben und sich nicht damit beschäftigen müssen, erst mal alte Definitionen zu überschreiben. Zumal es echt nervig ist, wenn sich die Dinge anders verhalten als man es definiert hat, nur weil einem ein altes System zu zwischen die Beine grätscht.

Ich bin sogar der Ansicht: wer ein neues Design entwickelt soll das bitte vollumfänglich planen, inklusive aller Elemente. Und wer ein neues Element entwickelt, sollte alle bestehenden Designs vervollständigen, oder dafür Sorge tragen dass der ursprüngliche Entwickler der Designs weiß dass er das tun sollte. Sonst haben wir bald nurnoch unvollständige Designs.

Was die Frage mit der Priorität angeht: das ist bei CSS relativ umfangreich gelöst. Die Prio wird dabei nach Genauigkeit des Selektors sowie Ort und Reihenfolge der Definitionen sortiert, kann stellenweise aber per !important überdreht werden.

Grüße,
Julian

[ctr]

ja man könnte doch aber auch mit anderen variablen arbeiten, dann kann es immernoch jedes Design anders umsetzen (oder auch nicht wenn es paßt, was den Arbeitsaufwand erheblich reduzieren sollte).
Geht es nicht eventuell sogar mit Prioritäten? Wie verhält sich ein Include wenn eine Variable aus zwei verschiedenen CSS herkommt? Wird die erste, letzte oder irgendeine Definition benutzt?

Mir geht es dabei (der globalen Variante) gar nicht so sehr um die Farben sondern um z.B. Icons aber auch darum gleiche (Mindest-)Vorraussetzungen in allen Designs zu haben.

Edit: Jetzt gehts komischerweise auch mit blue, hing wahrscheinlich noch was im Cache...

[Chris M.]

Julian hat's schon gut beschrieben

Davon abgesehen würde es eventuell Sinn machen für solche (und eventuell auch andere Zwecke?) eine globale/Designübergreifende Include-Datei mit CSS Definitionen zu haben.

Nein, das macht leider keinen Sinn, da jedes Design diese Farben anders umsetzen kann. Eines würde z.B. die Schriftfarbe anpassen, das andere den Hintergrund.

Was aber Sinn macht, wäre ein paar Farbnamen zu definieren die jedes Design implementieren sollte.

Wie wäre es mit:

• Rot
• Grün
• Blau
• Gelb
• Cyan
• Magenta

[Chris M.]

Juhu! Das ist Post 1000 in diesem Thread!

[ctr]

Also das mit den Ranges macht so selbstverständlich Sinn, danke für das Beispiel, das werde ich am WE gleich mal in alle Wikis/Dokus etc einpflegen die nicht rechtzeitig auf dem Baum sind ;-)

Die erste Antwort trifft schon eher den Kern meiner eigentlichen Verwirrung:
Ich habe sowohl mit alaska_slim als auch discreet_slim getestet und bei einem Textfeld (!) klappt die Zuweisung der Textfarbe mit Styling wunderbar, aber eben nur für red und green und nichts anderes.
Nun finde ich aber nicht die Stelle an der das in einem CSS definiert ist (bzw an der Stelle an der ich denke das es definiert wird, wird gleichzeitig auch blue usw. definiert und die gehen NICHT)...

Davon abgesehen würde es eventuell Sinn machen für solche (und eventuell auch andere Zwecke?) eine globale/Designübergreifende Include-Datei mit CSS Definitionen zu haben. Wenn man darüber auch Grafiken einbinden kann (das sollte doch mit CSS "background-image" gehen?) käme ich meinem Ziel von dynamischen Icons ja auch etwas näher :-)