Was sind eigentlich "native Controls"? Meint man damit solche, die ursprünglich auf der MFC basieren und quasi per Subclassing an Delphi angepasst wurden? Wo wie das bei den meisten "alten"
VCL-Controls ist? TPageControl, TButton usw... Oder meint man damit Controls, die Zeichnen und Messagehandling komplett selbst übernehmen? So wie Toolbar 2000 und deren Ableger?
Das mit "nativen Controls" ist doch nur Augenwischerei. Schaut man mal bei Lazarus vorbei, dann hat man dort verschiedene Zwischenlayer, die die eigentlichen LCL-Controls vom Betriebssystem abstrahieren. Auch TPageControl und TButton. Sind das dann "native Controls" oder nicht?
Ich glaube, wir würden in der Hinsicht noch ewig das Haar in der Suppe suchen und uns um Definitionen streiten. Worum es doch geht ist: Was ist dein Projekt, was ist deine Aufgabe und womit kannst du das am effektivsten und zukunftssichersten lösen?
Zu Kylix-Zeiten dachten auch viele, die unixoiden Desktops wären die Zukunft. Manche Komponentenentwickler sind sogar auf den Zug aufgesprungen. Man was hab ich an
CLX-Brei aus den TSynEdit-Sourcen rausoperiert...
Aus meiner Sicht hat Delphi in seiner jetzigen Form im Mobile-Bereich nichts zu suchen. Warum? Man schaue sich doch nur Windows 8 (Non-RT) mal an: Es ist das selbe in Grün, nur anders herum gedacht. Du bringst die Konzepte von Desktop und Mobilgerät nicht plattformübergreifend zusammen. Dafür sind die Parameter zu verschieden. Displaygröße in Relation zur Pixeldichte und damit der Anzahl von Pixeln pro Millimeter zum Bsp: Ab einer gewissen Auflösung sind Mobilgeräte praktisch unbedienbar weil die Controls zu fitzelig werden. Also fängt man an, die GUIs zu skalieren. Feine Sache, die Schriften sind dann super kantengeglättet und edel vom feinsten. Nur was hat man damit rein technisch gewonnen? Nüschts.
Umgekehrt taugen die Bedienkonzepte von Mobilgeräten nichs auf dem Desktop. Niemand schreibt einen Roman per Touchscreen, sondern man wird immer eine Tastatur benutzen. Ebenso war Windows Mobile (der Vorgänger von Phone 7) die Übertragung von Desktop-Bedienkonzepten auf ein Mobilgerät. Es funktionierte genausowenig. Nicht mal die allzu oft als Beispiel angeführte Firma Apple hat die Bedienkonzepte zwischen MacOS und iOS vereinheitlicht. Das Look'nFeel ja, aber nicht die Bedienung. Da bildet bis heute iTunes die Schnittstelle. Sie werden schon wissen warum.
Ich wage daher die Prophezeiung, dass vereinheitlichte Bedienkonzepte entweder grandios scheitern werden oder aber die bisher gewohnte Dynamik und Komplexität von Desktop-Anwendungen radikale Rückschritte erfahren wird.
Niemand käme auf die Idee, mit einem Ferrari 458 Spider einen Pflug über den Acker zu ziehen. Umgekehrt würde niemand mit einem John Deere 9510R auf die Autobahn fahren. Und das obwohl beide annähernd gleich viel PS haben.
Unterschiedliche Geräteklassen brauchen unterschiedliche Bedienkonzepte. Unterschiedliche Bedienkonzepte brauchen unterschiedliche
GUI-Frameworks. Und unterschiedliche
GUI-Frameworks baut man idealerweise in unterschiedliche Entwicklungsumgebungen. So wie das Werkstatt-Tor für einen John Deere ein bissi größer sein dürfte als das für einen Ferrari Spider.
Ich stelle gar nicht in Abrede, dass Mobilgeräte die Zukunft sind. Aber sie werden niemals den Desktop vollständig verdrängen. Warum also sollte man nicht hergehen und sagen: Hier gibts ein "Delphi for Desktop", hier ein "Delphi for PHP" und dort ein "Delphi for Mobile".
Fazit: Für mich geht Emba mit dem Konzept der "Eierlegenden Wollmilchsau"-
IDE den falschen Weg.