Text2Skin Skineditor

Trotz, dass die Dokumentation zum Text2Skin-Plugin super ausgearbeitet ist und es keine Probleme bereiten sollte, eigene Skins zu erstellen, wollte ich mich trotzdem damit beschäftigen. Meine Problem war bisher, dass man ja ständig im VDR testen muss, ob die Darstellung passt. Ich bastle daher im Moment einen Editor in Java (damit es auch unter Windows klappt), welches die Displays schonmal in einer Voransicht zeichnet. Momentan kann der Editor aber nur skin-Dateien laden und in einem Editorfenster mit Syntaxhighlighting anzeigen. Gezeichnet wird noch nix.

Damit der Spaß, der am Ende produziert wird auch halbwegs einer Norm entspricht habe ich ein XML-Schema erstellt, welches Skins validieren soll.

Ich habe das Schema mit 3 Skins getestet, habe aber noch ein paar Schwierigkeiten mit den "Regeln":

• Das Element List darf Unterelemente enthalten, aber sind das alle Elemente, die zum Beispiel auch in Block vorkommen dürfen?
• Window definiert die Zeichnungsfläche auf dem Schirm --> muss Window dann zwangsweise zu Beginn eines Displays definiert werden?
• bei Item habe ich das gleiche Problem wie bei Punkt 2
• großes Problem: welche Attribute sind optional, welche pflicht?!
• Der Wertebereich der Koordinaten ist laut Wiki im Bereich der Auflösung von SDTV, gelten andere Werte für HDTV? (+-1920 V bzw. +-1080 H)

Ich wäre über jede Hilfe dankbar.

// edit: neue Version des Schemas angehängt.

Ein paar Restriktionen sind mir noch aufgefallen, wo ich mir unsicher bin:

die BPP-Angabe ist im Wiki auf 4 und 8 Bit beschränkt, allerdings sind ja theoretisch bis zu 32bit möglich. Wird die Farbtiefe von Text2Skin begrenzt, oder ist die Angabe im Wiki nur so zu verstehen, dass 4 und 8 Bit "üblich" sind?

Und dann noch etwas:

ich würde mich freuen, wenn ich so viele Skins wie möglich zugeschickt bekommen könnte. Wenn's geht auch schon jene, die mit der Optimierung von chr13 lauffähig sind.

So... Prüfungen sind fast vorbei und der Editor nimmt Gestalt an.

Nochmal zum XML-Schema. Ich habe jetzt einige Datentypen eingeschränkt und die Attributdefinitionen entsprechend gesetzt. Ich werd sicherlich noch weitere Anpassungen machen, aber ich muss mir das alles erst einmal genauer ansehen.

Ich habe zum Beispiel folgene Probleme:

- marquee, text, blink verlangen kein "font"-Attribut. Hier würde ich gerne einen Defaultwert im Schema setzen oder das Attribut als Pflicht annehmen

- marquee verlangt auch kein Delay für die Bewegung. Gleiches prinzip wie oben.

Leider kann man mit Schema keine mutual exclusions schreiben, um zu verhindern, dass x,y bzw. x1,x2,y1,y2 gleichzeitig auftreten

Das aktuelle Schema habe ich angehängt.

Wenn das Skin-Plugin ordentlich performant geschrieben ist, dann müsste es nur marginal langsamer sein, als direkt implementierte Skins. Es wird ja lediglich das XML-File eingelesen und entsprechend ausgewertet. So wie ich in dem Thread für den Performance Patch gelesen habe, sollen T2S-Skins sogar schneller sein als direkte Skins.

Ich komme mal wieder nicht weiter. Ich möchte nun das Schema für die SkinXML auf Version 1.1 von Text2Skin zu bringen, auch wenn bei mir selbst noch 1.0 des Plugins läuft. Allerdings handelt es sich bei den Dateien, die ich gefunden habe nur um Templates
Leider lassen diese sich verdammt schlecht (mit anderen Worten: unmöglich) in ein XML-Schema quetschen ohne vorher geparst zu werden.

Ich habe den Thread [ANNOUNCE] text2skin Optimierung durchgeforstet und bin auch Brougs Entwicklungen am Engima-Skin durchgegangen, finde aber nirgends heraus, wie der Parser generell arbeitet. Ich weiß nicht, wie ich mit den %XXXX%-Variablen in den Templates umgehen soll.

Vielleicht kann mir da jemand weiterhelfen.

So, ich würde dann jetzt gerne mal anfangen "Features" zu sammeln, die das Programm unterstützen soll.

Folgendes geht bis jetzt:

• Kompatibel mit Version 1.0 des Plugins
• Syntaxhighlighting
• Bearbeitung der einzelnen Displays im separatem Tab
• Bearbeitung der .color- und .trans-Dateien
• Inspektorbaum zum einfacheren Navigieren im Skin

Folgende Dinge sind von mir jetzt noch geplant:

• Vorschau des Displays
• Conditioneditor
• Kompatibilität mit Version 1.1 des Plugins

auch wenn die Frage jetzt etwas blöd klingt: Zählen eigentlich bei den 32 bit die Alphawerte mit rein? Es wird ja für das OSD eine Farbpalette angelegt und da müssten diese Farben ja auch reinzählen?

Das ruht erstmal... zwei Großbaustellen sind doch zu viel.

Aber das mit TrueColor-OSD ist doch mal ne tolle Nachricht.