Delphi-PRAXiS - Delphi 10.2 LINUX Entwicklung

Mir war CrossVCL bis dato nicht bekannt und habe erst heute davon erfahren. Habe mir die Videos angeschaut. Der erste Gedanke: Heureka! Der zweite Gedanke: Star Citizen for Business. Dritter Gedanke: Mist - Linux Compiler gibts erst ab Architekt.

Dann fing ich an darüber zu philosophieren, was hat Eugene Kryukov bewogen, ein solches Projekt anzugehen? Dass er etwas auf dem Kasten hat, das hat er ja schon bewiesen. Aber die VCL X-Plattform zu machen, das wirkt erstmal so aberwitzig. Vorallem angesichts der Entwicklungszeit, die zuvor schon in CLX und FMX geflossen ist. Gerade das Kylix-Desaster hätte eigentlich Warnung genug sein sollen.

Allerdings ist inzwischen die VCL auch nicht mehr die selbe wie sie vor gut 20 Jahren zu Kylix-Zeiten war. Die wilden API-Calls innerhalb der visuellen Komponenten sind weitgehend verschwunden. Alles wurde zentralisiert, auch oder gerade wegen der Theme Engine. Deshalb denke ich an der Stelle schon, dass es möglich ist mit der heutigen VCL sowas zu bauen. Die Entwicklungsumgebung (Delphi) an sich muss doch gar nicht auf Linux oder MacOS laufen. Das war auch so ein Fehler der damals bei Kylix gemacht wurde.

Um mal ein Beispiel aus der Praxis zu bemühen: In München wird gerade mit viel Aufwand das LiMux-Projekt beerdigt, das zuvor jahrelang mit viel Aufwand gepäppelt wurde. Gescheitert ist es dem Vernehmen nach vorallem an Fachanwendungen, die von kleinen Softwareschmieden geliefert wurden und die keine Möglichkeit hatten, diese mit vertretbarem Aufwand nach Linux zu portieren. Mit Wine läuft eben vieles, aber nicht alles.

In der Regel waren das Datenbank-Frontends mit komplexen Reportgeneratoren. Mal angenommen (ich weiß es nicht!), diese Anwendungen wären mit Delphi erstellt und Softwareschmiede XYZ hätte nur in ein Delphi Architekt und eine CrossVCL-Lizenz investieren müssen. Sagen wir mal 5000 Euro Investition, um ein Millionenprojekt zu retten. Wäre das nicht wirtschaftlich sinnvoll gewesen?

Ich finde das gerade deshalb so interessant, weil ich in letzter Zeit einige Experimente mit Linux beim Endkunden mache. Dabei geht es weniger um fallspezische Lösungen. Vielmehr hat mich interessiert, wie ganz normale Büroanwender reagieren, wenn sie statt einem Windows ein Linux (Mint 18.2) vorgesetzt bekommen. Dabei war ich ganz erstaunt, wie "änderungstolerant" die Leute geworden sind. Vor 10, 15 Jahren war das undenkbar. Bis Windows XP waren die Denkmuster festgefahren. Aber seitdem verändert sich Windows rasant, insbesondere Win10. Die Leute haben sich daran gewöhnt, dass sich Startmenü & Co. von einem Tag zum anderen verändern können, wenn über Nacht mal wieder ein großes Update eingespült wurde. Auf einmal bleibt der Kulturschock aus, wenn sie plötzlich vor einem Linux sitzen.

Viele Business-Delphi-Anwendungen sind dröge Datenbank-Frontends. Seit Jahr(zehnt)en gewachsen, am Markt etabliert und stabil. Warum bei sowas noch mal mit viel Aufwand bei 0 (oder 10) anfangen, zig hundert Stunden investieren und X-Plattform (FMX) bauen, wenn man mit überschaubaren Beträgen so etwas wie CrossVCL verwenden könnte? Die Kunden mit ganz viel Geld können die Anwendung dann nativ auf ihrem Mac laufen lassen, die Kunden mit ganz wenig Geld setzen Linux ein und alle dazwischen verwenden Windows.

Mal ehrlich, gibt es nicht viele Delphianer, die seit vielen Jahren VCL-Anwendungen schreiben und schlicht keine Lust haben, von Grund auf mit FMX noch mal neu zu lernen? Seit Jahren dreht sich diese Diskussion doch schon im Kreis. FMX ist ein tolles Framework und es funktioniert inzwischen auch recht gut. Allerdings ist eben allein schon das Benennungsschema der Properties im Objektinspektor so fundamental anders, dass man anfangs ungemein viel Zeit in der Onlinehilfe verbringt. Mein "Lieblingszitat" ist da inzwischen: "Embarcadero Technologies verfügt zurzeit über keine zusätzlichen Informationen. Bitte unterstützen Sie uns bei der Dokumentation dieses Themas, indem Sie Ihre Kommentare auf der Diskussionsseite eingeben.".

Aber auch abseits persönlicher Befindlichkeiten gibt es handfeste Argumente gegen eine Portierung bestehender Anwendungen nach FMX. Das treffendste ist immer die Geldfrage. Wenn man viele Mannstunden aufwendet, um ein Programm auf den Mac zu bekommen, nur um dann festzustellen dass es an einer bescheidenen Komponente scheitert, die mal zugekauft war und nicht mehr supportet wird. Da würde mir mein Chef mit dem nackten Arsch ins Gesicht springen. Wenn nicht Android und iOS das Ziel sind sondern ausdrücklich Desktop-Anwendungen, dann spricht nicht viel für eine FMX-Migration.

Dass die jahrelang gerade aus Richtung Redmond propagierte Konvergenz aus Mobil und Desktop gescheitert ist, das haben die Leute bei Microsoft inzwischen selbst einsehen müssen: "Of course we'll continue to support the platform.. bug fixes, security updates, etc. But building new features/hw aren't the focus." (Joe Belfiore über Windows 10 Mobile). Unter diesem Paradigma könnte man auch FMX sehen: Als Framework für mobile Anwendungen definitiv ja, als Grenzgänger zwischen Mobil und Desktop dagegen nicht. Das wollen die Nutzer schlichtweg nicht weil Maus- und Touchbedienung eben zwei völlig verschiedene Konzepte sind. Der Versuch, diese zu vereinen, wird IMHO scheitern - siehe eben Windows 10 Mobile, aber auch RemixOS (Android), Unity (Ubuntu Linux), Chrome OS oder die jüngsten iTunes-Updates. Die Zeichen stehen im Moment eher auf Trennung zwischen Mobil und Desktop statt auf Vereinigung.

In einem eng abgesteckten Rahmen finde ich das Projekt CrossVCL sehr faszinierend. Fokus ausschließlich auf den Desktop, auf Businessanwendungen, DB-Frontends usw. Dass es inzwischen einen VST-Port gibt, finde ich ja schon mal ganz toll. Nur müsste der mit dem Main-Branch gemerged werden. Sonst ist all die Müh' vergebens wenn das nächste VST-Update von JAM Software kommt. Dass z.B. UniDAC von Devart wunderbar X-Plattform funktioniert weiß ich schon aus eigener Erfahrung. Deshalb sind X-Plattform-DB-Aware-Komponenten ja so wichtig.