Metro Anwendungen mit Delphi erstellen

[mjustin]

Hallo,

normalerweise arbeite ich eher im Serverumfeld, daher ist mir Windows 8 eher am Rande aufgefallen ... doch nachdem ich etwas mehr gelesen habe, stiess ich auch auf die neuen Metro Anwendungen, und frage mich natürlich, ob und wie man als Delphi Entwickler auf diesem Gebiet auch etwas machen kann, ohne die vertrauten IDE verlassen zu müssen.

Unter Getting started with Metro style apps fand ich Informationen zu den unterstützten APIs.

Zur Auswahl stehen demzufolge:

1. Windows Runtime - eine neue native API
2. ein HTML / CSS Subset
3. eine Windows Library für JavaScript
4. .NET für Metro Anwendungen
5. eine Untermenge der Win32 und COM APIs

Die erste und die letzte Alternative sind aus Delphi vermutlich problemlos über native Aufrufe nutzbar. Ob die aktuelle VCL noch funktioniert, wenn sie nur auf eine Untermenge der Win32 API zugreifen kann, oder ob diese Einschränkung es notwendig macht, eine ganz neue VCL Variante zu erstellen, ist die Frage. Sind eventuell schon native Metro-kompatible Komponenten für Delphi angekündigt oder erschienen?

[RWarnecke]

TMS hat das TMS Metro Controls Pack herausgebracht, vielleicht ist das ja was für Dich.

[vagtler]

Naja, das hat jetzt allerdings nichts mit Metro-Anwendungen zu tun. Damit kann man wohl eher Metro-Look-a-Likes erstellen.

[Robotiker]

Hallo,

Zitat von mjustin:

Die erste und die letzte Alternative sind aus Delphi vermutlich problemlos über native Aufrufe nutzbar.

die COM-Interfaces für WinRT unterscheiden sich von den alten COM-Interfaces. Da ist auf jeden Fall einiges an Arbeit angesagt.

Was die Typen von Apps angeht, kann man die Auswahl offenbar auf drei Typen zusammenfassen:

• Html5 und JavaScript basiert
• XAML und eine .net Sprache
• Native Anwendungen (bei MS C++) mit XAML oder DirectX (auch kombiniert)

Die Struktur der nativen Anwendungen spricht eher gegen die Verwendung der VCL, FireMonkey könnte über DirectX gehen. Was ich noch mehr als Problem sehe, ist dass das aysonchrone API-Modell der WinRT überhaupt nicht zur Programmlogik klassischer Delphi (und C# und C++) Anwendungen passt.

[USchuster]

Ich habe es selbst nicht ausprobiert, aber vielleicht helfen die Blog Einträge von Thom Gerdes (damals noch Delphi R&D) und sein Beispiel bei GitHub.

[Robotiker]

Ja das sieht interessant aus und bestätigt meine Vermutungen in Bezug auf FireMonkey.

Btw. das ist das Blog von einem der Entwickler, von dem kürzlich im Emba Forum die Rede war, dass er gegangen ist.

[mjustin]

Zitat von Robotiker:

die COM-Interfaces für WinRT unterscheiden sich von den alten COM-Interfaces. Da ist auf jeden Fall einiges an Arbeit angesagt.

Sie sicher binärkompatibel und aus Delphi ansprechbar? Besteht der wesentliche Unterschied nur im asynchronen API Design, oder gibt es andere gravierende Neuerungen?

Thom Gerdes hat anscheinend schon einige Arbeit in Delphi-Wrapper der neuen API gesteckt, wie man in http://www.thomgerdes.com/2011/12/wr...in-delphi.html nachlesen kann:

• Delphi unit Winapi.Winrt- Übersetzungen der globalen WinRT APIs
• AllWinRt für alle Enumerations, Records, und Interfaces für Windows Metadata Dateien.
• WinRtHelpers mit Helper Klassen (TInspectableObject, TWindowsString)

[Robotiker]

Zitat von mjustin:

Sie sicher binärkompatibel und aus Delphi ansprechbar? Besteht der wesentliche Unterschied nur im asynchronen API Design, oder gibt es andere gravierende Neuerungen?

Ich kannte die Arbeiten von Thom Gerdes nicht, sieht in der Tat aus, als ob sie da schon recht weit sind.

Die asynchrone API würde ich nicht unterschätzen. Wenn man sich die ganzen Beispiele anschaut, wo Metro Apps etwas laden, dann sieht man da immer Konstrukte mit async/await (C#) und task<> (C++). Da wird Delphi auch entsprechende Gegenstücke benötigen, sonst dürfte das Portieren von Codebeispielen nicht ganz trivial sein.

Ein anderer Punkt ist, dass Apps, wenn sie nicht sichtbar sind, spätestens nach 5 Sekunden der Saft abgedreht wird. Sie müssen dann ihren Zustand speichern und beim Fortsetzen wieder herstellen. Das dürfte allerlei Auswirkungen auf das Programmmdesign haben.

[mquadrat]

Gab vor ewigen Zeiten mal einen Post bei Google+ von Thom Gerdes mit einem Proof-Of-Concept. Ich nehme mal an, das deckt sich mit den Sachen auf die hier schon hingewiesen wurde. Also eine Direct-X basierte Anwendung, die dann eben von Firemonkey mit einem Metro-Skin gerendet wird.

Damals wurde noch gegrübelt (genau genommen, ich habe gegrübelt) ob Direct-X basierte Metro-Anwendungen im Store zugelassen werden. Von euch hat nicht zufällig jemand die Guidelines gelesen? Müssten ja jetzt verfügbar sein.

[Robotiker]

Soweit ich das damals verstanden habe, sind reine DirectX-Anwendungen auch bei der Developer Preview schon als eigener Anwendungstyp und damit auch für den Shop vorgesehen gewesen.

Ein Problem war, dass das reine DirectX-Anwendungen waren, ohne z.B. Dialoge in XAML zeichnen zu können.

Das haben sie geändert:

Zitat:

We heard you. With the Consumer Preview, you can now smoothly integrate XAML and DirectX 11 in the same Metro style app to create a fast and fluid experience. For example, you can now create a DirectX game and use XAML to process input, create graphics for heads-up displays and menus, or bind to your app’s data model.

http://blogs.msdn.com/b/windowsappde...ld-part-1.aspx

Setzt FireMonkey nicht auf DirectX 9 auf ? Eine der Erklärungen im Netz warum es kein XNA für Metro unter Windows 8 gibt, ist das dort nur DirectX 11.1 unterstützt wird.