KWin Effekte in Windows Vista

Es gibt seit einer Zeit einen Feature Request um KWin auf die Microsoft Windows Plattform zu portieren (siehe Bug 182700) und wir haben im Geheimen mit der Portierung nach Microsoft Windows Vista begonnen. Und heute sind wir froh verkünden zu können, dass es mit KDE 4.3 ein erstes Release for die Microsoft Windows Plattform geben wird.

Natürlich ist die Portierung einer Anwendung, welche so eng mit der X11 Plattform verzahnt ist, keine einfache Aufgabe. Daher haben wir uns entschlossen keine Fenstermanager Funktionen in der ersten Version bereitzustellen. Es wird nur Compositing Unterstützung geben. Microsoft erlaubt den Zugrif auf Vista’s Aero Funktionen und daher mussten wir nur ein Direct3D Backend implementieren. KWin’s Compositing Unterstützung ist sehr modular und es gibt mit OpenGL und XRender bereits zwei Backends. Daher war das Hinzufügen von Direct3D Unterstützung nicht schwierig. Also haben wir eine neue scene_direct3d.cpp Datei angelegt, welche das Compositing genauso handhabt wie die bereits existierende scene_opengl.cpp.

Eine kompliziertere Aufgabe werden die EffectWindows, welche ein Fenster in den Effekten darstellen. In der bestehenden Implementierung sind diese mit X Clients verzahnt: managed, unmanaged und deleted Clients. Diese Typen haben eine Elternklasse TopLevel. Also mussten wir eine neue Client Implementierung namens WindowsWindow erstellen. Wir sind nicht in der Lage diese Fenster zu verwalten, da – wie gesagt – die Portierung der Fenstermanager Funktionen zu schwierig ist. Für die Effekte ist also alles transparent, nichts ändert sich. Wenn ein EffectWindow in X11 angesprochen wird, dann ist es ein managed oder unmanaged client, in Microsoft Windows ein WindowsWindow.

Natürlich erlaubt unsere Effekte API Zugriff auf die Fensterverwaltung. Es wäre lachhaft, wenn man den Würfel hat, aber die Arbeitsfläche nicht darüber wechseln kann. Da die Microsoft Windows Plattform das Konzept der virtuellen Arbeitsflächen nicht kennt, können wir natürlich diese API Aufrufe nicht bereitstellen. Also mussten we einen WindowsEffectsHandler Implementation erstellen welche Zugriff auf all die Funktionen auf Grund der API Kompatibilität bereitstellt und Standardwerte zurückliefert. effects->numberOfDesktops() wird immer 1 zurückliefern. Daher werden Effekte welche effects->numberOfDesktops() > 1 voraussetzen nicht funktionieren. Daher keinen Würfeleffekt 🙁

Wir haben nun einen Punkt in der Portierung erreicht, in dem wir zuversichtlich sind alle wichtigen Effekte portiert zu haben bis zum Hard Freeze. CoverSwitch und FlipSwitch funktionieren bereits, auch kleinere Effekte wie MagicLamp und die MinimizeAnimation sind fast fertig (wir haben immer noch Probleme die Icon Position zu ermitteln).

Ich denke mal es ist Zeit einen Screenshot vom aktuellen Stand zu zeigen. Da FlipSwitch einer der ersten Effekte war, welcher 3D in KWin verwendet, habe ich diesen Port als erstes fertiggestellt und hier ist er:
KWin FlipSwitch in Windows Vista

Leider hat sich niemand vom KWin Team für die Windows 7 Beta Lizenz beworben, daher waren wir bisher nicht in der Lage mit der kommenden Windows Version zu testen. Wir hoffen, dass Microsoft die Chance in einem guten und funktionieren Compositor für ihre Plattform sieht und hoffen, dass sie uns alle benötigte Hilfe inklusive Lizenzen für die neue Version bereitstellt.

6 Replies to “KWin Effekte in Windows Vista”

  1. Mit Abstand der beste Aprilscherz! Mir wärs glaube ich erst morgen aufgefallen, wenn ich nicht nochmal vorbeigeschaut hätte 😉

    Sehr schön.

  2. “WindowsWindow”…… Genial xD

    Apropos: es gibt wirklich ein Programm, mit dem man mehrere Arbeitsflächen unter Windoof haben kann, mit 3D-Würfel-Flächenwechsel. Daran hab ich gemerkt, das es ein Scherz ist, weil wenn ihr das nicht hin bekommt, warum dann die andern? 😛

    Aber WindowsWindows is einfach der Hammer xD

  3. @mogli: das Problem wäre nicht der Würfel, sondern wie ich im Post sogar geschrieben habe die enge Verzahnung von X11 mit KWin. Um den Würfel zu haben, müsste man das Konzept der Arbeitsflächen portieren – das wäre ein Rewrite.

    Daher ist der Scherz eigentlich schon in der Übersicht erkennbar. KWin zu portieren und zu supporten wäre schwieriger als einen neuen WM mit den gleichen Features zu schreiben.

  4. Da ich den Artikel von dir erst heute lese, dachte ich: “What the f…, gehts denen noch gut? Warum machen die sich die Arbeit und portieren da herum? Späterstens beim Screenshot 🙂 wusste ich, dass ich doch noch in einen Aprilscherz gelaufen bin…

    Sehr guter Scherz.

Comments are closed.