CometVisu - (interner) Beta-Test

[netzkind]

[IMG]
Ich sehe durchaus die Möglichkeit das im Code zu hinterlegen. Z.B. in extra Einträgen im .data() - die halt nur dann mit abgelegt werden, wenn auch Editieren erlaubt ist.

Ich glaub wir reden hier aneinander vorbei.
Ich meine eine Liste aller widgets (slider, image) welche die Template-Engine unterstützt - egal ob der User sie bislang schon nutzt oder nicht.

Deinen Vorschlag verstehe ich eher als eine Auflistung der bislang in der config genutzten widgets/Aktoren.

Unabhängig vom gegenseitigen verstehen stopf ich mein Hirn grade mit XSD voll und schraub da mal was zusammen. Netter Nebeneffekt: wenn einem versierten User die Visu mal nicht geht, kann er seine Config gegen das XSD parsen und schauen wo der Hase im Pfeffer ... oder wir stellen dafür ein webif zur Verfügung (mit PHP/DOMDocument ein leichtes).
Gilt natürlich nur solange die Config nicht doch mal in eine DB umzieht

Grüße,
Julian

[makki]

Hola, jetzt gehts langsam rund

Damit der Editor eine Chance hat mitzuhalten denke ich sollte er dynamischer werden. Dazu brauchts eine zentrale Definition welche widgets alles erlaubt sind, und welche Attribute die haben.

Klingt schlüssig, eine (wie auch immer geartete) "Definitionsdatei" für Widgets macht IMHO Sinn, damit man das nicht immer in Visu&Editor doppelt pflegt.

Ich denke wer widgets selbst entwickelt ist entweder eh so drauf so drauf wie ihr und findet X* "normal"
oder hat schon verdammt viel trocken Brot vor bzw. hinter sich, ein XSD macht hier das Kraut nicht fett (ausserdem wird man sich das von vorh. Widgets ja abschauen können..)

Makki

[Chris M.]

Hola, jetzt gehts langsam rund

Damit der Editor eine Chance hat mitzuhalten denke ich sollte er dynamischer werden.

Meine Rede

Dazu brauchts eine zentrale Definition welche widgets alles erlaubt sind, und welche Attribute die haben.

Ich sehe durchaus die Möglichkeit das im Code zu hinterlegen. Z.B. in extra Einträgen im .data() - die halt nur dann mit abgelegt werden, wenn auch Editieren erlaubt ist.

Vorschlag wäre ein Eintrag namens "meta" oder "edit" der seinerseits ein Objekt/Hash mit allen möglichen Attributen enthält und die wieder aus einem Objekt/Hash bestehen mit den Meta-Informationen wie ob es optional ist, Datentyp, Wertebereich, ...

[netzkind]

Hola, jetzt gehts langsam rund

Damit der Editor eine Chance hat mitzuhalten denke ich sollte er dynamischer werden. Dazu brauchts eine zentrale Definition welche widgets alles erlaubt sind, und welche Attribute die haben. Ich denke spontan an ein XSD, wobei das für den User der seine Visu selbst um eigene Widgets erweitern will dann erst mal ein hartes Brot wird.

Gegenvorschläge?

Ohne zentrale Definition wüsste ich nicht wie ein Editor widgets kennen sollte die der User nicht selbst in seiner visu_config.xml nutzt.

Grüße,
Julian

[Chris M.]

image und/oder webcam (wie image aber mit automatischem Reload)

Initales <image> ist jetzt drinnen, "width" und "height" sind als optinale Attribute bekannt.

Was braucht's noch für den universellen Einsatz?

Ein "refresh" wäre leicht möglich. Braucht's evtl. noch ein "trigger" bzw. "address" das das Bild bei eintreffen eines Paketes neu lädt?
Oder gar ein "dynamisches" Bild, bei dem der "src" per Bus-Paket ganz oder teilweise verschickt wird?

Da sind jetzt Leute mit Visu-Erfahrung gefragt...

[vento66]

der Break fügt in der Zeile in der 2. Spalte einen Platzhalter mit Rahmen ein, in der 2.Zeile einen Platzhalter ohne Rahmen. Damit verschiebt sich das Element wieder in die nächste Spalte.

[vento66]

aber dass brauch ich ja keinem erzählen, da ja sicher jeder die SVN-Commit Mailingliste Abonniert hat...

Naja jetzt schon

[Chris M.]

@Nils der workaround funzt!

Ein vermutlich noch "besserer" (eigentlich hässlicherer...) Workaround wäre, ein Phantasie-Tag zu verwenden, z.B.

<schiessmichtot />

Aber damit wir das nicht brauchen, gibt's jetzt <break /> im Subversion - aber dass brauch ich ja keinem erzählen, da ja sicher jeder die SVN-Commit Mailingliste Abonniert hat...

[Chris M.]

Anderes Tag das wir noch brauchen könnten:
image und/oder webcam (wie image aber mit automatischem Reload)
Spätestens dann geht das floaten aber nicht mehr wirklich gut.

Nicht nur das, ich will auch noch ein universelles iframe-Tag - aber dann ist's mit dem aktuellen Layout ohne extra Massnahmen wirklich Sense.

[vento66]

@Nils der workaround funzt!

Ich bin im Moment noch nicht mal traurig drüber, da jetzt auf dem Iphone das Trennelement die Optik von den Dimmern nicht so zusammengeklatscht wirken lässt.

[NilsS]

<text>&nbsp;</text>.

besser

<text>&# 160 ;</text>

ohne leerzeichen.

die entität nbsp gibts nicht

[netzkind]

Ein leerer <text> </text> wird nur als schmales Element angezeigt ...

Probiers mal mit <text>&nbsp;</text>.
Aber nur bis das linebreak-Tag kommt, das sollte dann schon sinnvoller sein.

Anderes Tag das wir noch brauchen könnten:
image und/oder webcam (wie image aber mit automatischem Reload)
Spätestens dann geht das floaten aber nicht mehr wirklich gut.

Grüße,
Julian

[vento66]

Ein leerer <text> </text> wird nur als schmales Element angezeigt, es muss da schon was drinn stehen ansonsten wird die rechte Spalte nur um ein paar pix nach unten verschoben

[netzkind]

Und die richtige Lösung ist natürlich ein <br>-Tag, den es aktuell aber noch nicht gibt

Ein linebreak-Tag würde ich unterstützen. Die Darstellung auf kleinen Endgeräte (Bildschirmbreite <= 480px) ist nämlich einspaltig - zusätzliche Widgets zur Zwangssortierung würden da dann wieder eher der Reihenfolge hinderlich sein.

Grüße,
Julian

[Chris M.]

Ist es auch möglich einen Platzhalter zu definieren? Ich hab bei mir jetzt mal 3 Slider aus dem DMX Spielwahn auf eine Seite gepackt. Da wäre es ganz schön wenn diese 3 Slider untereinander angeordnet werden

Man könnte mal schaun ob ein leerer <text> als Platzhalter funktioniert (allerdings würde dann wohl ein leerer Rahmen erscheinen...)
Die nächste Alternative wäre ein <line>, da das immer vorne anfängt - aber man hat halt trennende Linien dazwischen.

Die offizielle Lösung ist aktuell, einfach die Widgets passend zu sortieren, also z.B.

<..><dim><toggle><dim><toggle><dim><toggle><...>

was dann am Bildschirm ein Layout ergeben würde wie:
Und die richtige Lösung ist natürlich ein <br>-Tag, den es aktuell aber noch nicht gibt (aber um genau so etwas in Erfahrung zu bringen gibt es ja den Beta-Test )