MCML

MCML (Media Center Markup Language) ist eine Beschreibungssprache, die – wie etwa auch XAML – auf XML aufbaut. Eine sehr einfache MCML sieht z.B. so aus:

<Mcml xmlns="http://schemas.microsoft.com/2006/mcml"
      xmlns:cor="assembly://MSCorLib/System">

  <UI Name="Default">
    <Properties>
      <Color Name="MyColor" Color="White"/>
    </Properties>
    <Locals>
      <cor:String Name="MyString" String="Machts gut und Danke für den Fisch"/>
    </Locals>
    <Rules>
      <Default Target="[MyText.Content]" Value="[MyString]"/>
    </Rules>
    <Content>
      <Text Name="MyText" Color="[MyColor]" Font="Calibri, 24"/>
    </Content>
  </UI>
</Mcml>

Am Anfang steht der XML Namespace. (xmlns). Der erste (http://schemas…) muss immer so lauten und identifiziert das Dokument als MCML-Dokument. Der zweite angegebene Namespace mit der (im Dokument) internen Bezeichnung “cor” verweist auf MSCorLib/System. Dies sind ist der Namespace für die grundlegenden Klassen, wie etwa String, int, etc. also – vereinfacht ausgedrückt – all das, was man in C# zur Verfügung hat, ohne weitere Namespaces einzubinden.

Als nächstes folgt das UI Element: UI steht für “User Interface”. Im Prinzip besteht eine MCML-Datei immer aus einem User Interface. Es gibt auch noch ein paar wenige, andere mögliche Elemente, aber diese sind erst einmal uninteressant. Das User Interface wiederum ist nur ein Container für die eigentlich darzustellenden Elemente. Vergleichbar wäre dies etwa mit dem BODY-Tag auf einer HTML-Seite oder WINDOW in einer XAML-Datei.

Da wir nicht nur malen wollen, sondern irgendwann auch auf die Elemente zugreifen wollen sollten alle Elemente einen eindeutigen Namen bekommen. In diesem Fall hat das UI den Namen “Default“.

Es folgen nun die Properties. Properties sind globale Variablen. Sie gelten nicht nur in der aktuellen MCML, sondern in der gesamten Instanz. Änderungen an Properties werden automatisch abgespeichert und sind beim nächsten Start wieder verfügbar.

In diesem Beispiel setzen wir die Property “MyColor” auf “White”
Es folgen die “Locals”. Der Locals-Bereich definiert alle lokalen Variablen, die für die UI gelten. Im obigen Beispiel ist dies der String “MyString”.

Im Anschluss folgen die “Rules”, die Regeln. Im Prinzip ist dies der (vereinfachte) Programmiercode, der hinter dem Fenster steckt. Eine Regel ist im Prinzip immer vom Format <Bedingung> <Aktion> bzw. IF (Bedingung) THEN (Aktion). Es gibt einige Arten von Bedingungen, die uns noch im Laufe des Projekts über den Weg laufen werden. Eine dieser Standardbedingungen ist “Default“: Diese Bedingung besagt, dass diese Bedingung immer erfüllt ist. Sie ließe sich z.B. mit IF (1==1) übersetzen. Im obigen Beispiel weise ich also standardmässig MyText.Content den Wert von MyString zu.

Im C# – Code wäre die Entsprechnung für die bisherigen Markup-Elemente also folgende:

partial class UI_Default {
  public Color MyColor=new System.Color.White;
  private string MyString="Machts gut und Danke für den Fisch";
  If (1==1) {
    MyText.Content=MyString;
  }
}

Man sollte sich nicht dadurch verwirren lassen, dass “MyText” an dieser Position eigentlich nicht deklariert ist. Wir befinden uns schließlich nicht wirklich in einer Klasse oder Methode, sondern in der MCML-Definition. Vergleichbar ist dies mit einer WinForms-Anwendung. Auch hier kann ich im Quellcode auf die GUI-Element zugreifen, weil die Elemente “versteckt” in der Datei klasse.Designer.cs vorhanden sind. (Um dies zu verdeutlichen habe ich auch als Beispiel die “partial class UI_Default” verwendet.

Natürlich kann man alles, was im “Rules”-Bereich steht stattdessen auch direkt im Code erledigen. Allerdings hat die Verwendung von “Rules” drei klare Vorteile:

1. können Änderungen ohne Neucompilierung des Projekts durchgeführt werden

2. kann dem (versierten) Anwender erlaubt werden, einfache Änderungen an der MCML durchzuführen, um das UI-Objekt seinen Wünschen anzupassen.

3. bieten sich noch viel mehr Möglichkeiten, als hier (bisher) aufgezeigt, z.B. sehr angenehmes DataBinding, welches sich kaum vom DataBinding in XAML unterscheidet.

Bleiben nur noch die sichtbaren Elemente, hier bisher nur der Text MyText mit den Eigenschaften MyColor und der festen Fonteigenschaft. (Der Content wurde ja bereits im Rules-Bereich festgelegt). Und das Ergebnis ist folgendes:

Deutlich zu erkennen ist, dass der Text ohne unser Zutun zunächst horizontal und vertikal zentriert wurde. Wird das Fenster verkleinert fallen weitere Sachen auf, z.B. dass am Rand der Text automatisch “verblasst”.

So. Das war doch mal was. Eine ganze Seite lesen, nur für ein popeliges “Hallo Welt”

Da schon sehr früh erkennbar war, dass dieser Weg bisweilen ein wenig steinig ist, habe ich mich entschlossen meine Umwege und auch die kleinen Erfolge hier kundzutun:

Grundlegendes

1. Visual Studio 2008

Die kostenlose Express Edition von C# gibt es dort: HIER zum downloaden. Die Installation ist unspektakulär und wird hier nicht weiter erwähnt. Wichtig ist nun die Installation auf jeden Fall VOR der Installation des folgenden SDKs durchzuführen, da ansonsten entsprechende Projekteigenschaften nicht existieren.

2. Das Vista Media Center SDK:

Auch diese Installation bedarf zunächst keiner großen Erklärung. Nach Erfolgreicher Installation hat das MediaCenter die neuen Optionen MCL Preview Tool, sowie MCML Samples unter den Online Medien.

Des weiteren befinden sich nun auch im Studio zwei neue Projektoptionen:

Mit diesen lassen sich eigentlich sofort neue Projekt im MCML-Format anlegen. Doch was ist MCML eigentlich? MCML ist die “Media Center Markup Language”, eine Beschreibungssprache ausschließlich für die “Fenster” des Mediacenters: Dies hat also mit der Programmierung zunächst einmal nichts zu tun, sondern ist quasi die Konkurrenz zu XAML.

Für die Funktionalitäten bietet die Media Center-SDK ein Framework (Microsoft.Mediacenter).

[Update: Bitte den ersten Kommentar anschauen, da erkläre ich, warum diese Passage durchgestrichen ist]

Da ich jedoch keine weitere Markup-Sprache nutzen wollte, sondern meine Fenster im XAML erstellen wollte, unter anderem (aber nicht nur) weil es dafür bereits einen sehr guten Designer (Expression Blend) – wiederum von Microsoft, aber leider nur als Betaversion kostenlos – gibt, ging meine Suche etwas weiter. Ob es später einmal eine Express Edition geben wird steht in den Sternen – bisher sieht es nicht danach aus. Keine Angst übrigens vor dem “Beta”. Die zu diesem Zeitpunkt aktuelle 2.5 March 2008 Preview läuft absolut stabil und ohne böse Überraschungen.

Doch zunächst zurück zum Studio. Unabhängig von der verwendeten Markup-Language (MCML oder XAML) muss das Projekt auf jeden Fall signiert werden, um im Media Center ausführbar zu sein. Dies ist allerdings recht einfach:

Einfach auf “Projekt – (name des Projekts) Eigenschaften” Klicken und den linken Reiter “Signierung” auswählen. Dort dann den Haken bei “Assembly signieren” setzen und unter “<neu>” einen beliebigen, tunlichst eindeutigen Namen vergeben. Das wars dann schon.

Wer will kann nun bereits das Programm starten und bekommt automatisch ein “Hello” präsentiert. Um die Suche zu vereinfachen: Die Fensterdefinitionen im MCML-Format sind im automatisch angelegten Ordner “Markup” gespeichert.

-*-

XBAP

Bevor ich nun mit der Technik fortfahre möchte ich einige Fallstricke erwähnen, die mich eine Zeitlang aufgehalten haben. Und zwar ist dies im Wesentlichen, die richtigen Suchbegriffe bei Google zu finden. “MCE” für Media Center Edition ist leider völlig falsch, da es bei Vista ja keine Media Center Edition mehr gibt, sondern nur die Anwendung Media Center. Auch XAML und WPF führen zu keinem guten Ergebnis, letztendlich ist das Zauberwort zur XAML-Integration im Media Center “XBAP Media Center”.

Doch was ist XBAP überhaupt? XBAP bedeutet XAML Browser Application. Dem Mediacenter wird die XAML-Datei also zukünftig als Website “untergejubelt”.

Auf dieser Seite finden sich ein paar nette Applikationen für das Media Center; Zum Beispiel ein Bildschirmkeyboard, welche auch gut als Beispiel für eigene Anwendungen dienen können.

Wird nun z.B. das Keyboard-Beispiel im Studio gestartet, so erscheint das zunächst wirr aussehende Keyboard im Browser. Das Previewprojekt für den Browser nennt sich “xtest” und ist als Startobjekt ausgewählt. Um eine direkte Vorschau im Mediacenter zu ermöglichen muss stattdessen das Projekt “MCE_Test” gestartet werden. Das Keyboard versteckt sich hinter dem “<a”, alles andere ist nur schmückendes Beiwerk.

Für dieses Projekt wurde bereits der notwendige Schlüssel erstellt. Wenn es das Ausgangsprojekt für eigene Projekte werden soll, muss also ein anderer Schlüssel (wie oben beschrieben) erstellt werden.