Nein, dass es überall gleich "aussieht" ist ein Problem.
Das es überall gleich aussehen muss ist für manchen (Firma, Cooperate Design - "Unsere Webseite hat Lila als Hauptfarbe - wir wollen auch Lila Buttons") ein Problem.
Und wie ich sehe kann man bei FM auch ohne Custom-Theme arbeiten. Wenn hier der native Look nur (gut) Emuliert wird - was solls. Solange diese Emulation nicht permanent 100% CPU-Load verursacht ...
Es benutzt keine nativen
API's.
Ega. Solange es sich gut anfühlt.
Mac-User verwenden einen Mac gerade WEIL er sich anders bedient als ein Windows-PC.
Und was macht das anders aus? Das man nur eine Maustaste hat und bald mit 200 Fuchtel-Gesten den Mac bedient? Ich denke 90% der User werden nicht konkret die Unterschiede die von vorteil sind bis auf allgemeine Aussagen definieren können. Und diese Aussagen werden sich primär auf das
OS und nicht auf eine Anwendung beziehen.
Linux-User customizen ihre Oberfläche bis ins kleinste Detail, und eine Anwendung hat sich da gefälligst anzupassen.
Und. Sollen sie doch. Wenn diese 1% der PC-Gemeinde (die oft auch nur kostenlose open-source Lösungen akzeptiert) mein Programm nicht will - was solls.
Eine Anwendung, die nicht in der jeweiligen Plattform sauber integriert ist, wird nicht angenommen.
Das Akzeptier ich. Sie darf sich nicht als Fremdkörper anfühlen (So wie manche Adobe-SW heutzutage auf Windows). Aber ob sie nun native
API's verwendet um einen Button zu zeichnen oder nicht - wird bis auf Technikverliebte keinen Interessieren. Es wurde doch auch schon ein paar FM-Apps für iOS gezeigt und sie sahen nicht schlecht aus.
Das haben schon viele Firmen ausprobiert, sind daran gescheitert, und nun liefert Embarcadero auch noch ein Tooling, das genau diesen massiven Fehler propagiert und Entwickler dazu verleitet viel Zeit (und damit Geld) in eine Codebasis zu stecken die unter 100%iger Garantie nicht angenommen werden wird.
Diese 100% Garantie sehe ich nicht.
Die Anforderung nach Webbrowser und Mediaplayer ist dann auch gleich wieder ein Zeichen, dass die Technologie hinter Firemonkey nicht verstanden wurde. Es gibt nunmal keinen überall verfügbaren Systemintegrierten Browser. Was ist mit embedded systemen? Headless Linux-Systeme, die z.B. ihre X-Oberfläche nur über
ssh-tunnel an remote X-Window-Systeme schicken?
Ich denke nicht das de Fragesteller einen Browser für eine "Oberflächen-Loses" System haben will. Und TWebBrowser hätte bei einer Delphi-Consolenanwendung auch nix verloren.
Jede Plattform hat ihre eigenen, individuellen Eigenheiten, und die wollen bedacht werden. Deswegen sagt Marc ja auch zu Oxygene / Prism: Ja, es läuft mit MonoTouch, ja, man kann iPhone-Anwendungen damit schreiben, ja, sie benutzen sogar im Hintergrund die nativen
API's und abstrahieren nur minimal (viel weniger als FM), aber um Himmels willen, nehmt lieber Objective-C.
Und wieder Anfangene für jede Plattform eigenen Code zu schreiben (und zu pflegen) Objective-C für iOS, .NET für Windows Phone, Java/Dalkin für Android und dann nach Delphi für
Win32.
Tests haben auch ergeben dass die inhaltlich exakt gleiche Anwendung in Objective-C und in FM geschrieben fast ausschliesslich in der Objective-C-Variante gute Bewertungen erhält und heruntergeladen wird. Die nahezu identische FM-Version geht in der Versekung unter. FM ist die falsche Technologie, und wer auf ein totes Pferd setzt reitet ziemlich flott in den Untergang.
Echt? Beispiel? Schaut gleich aus und lässt sich gleich bedienen. Oder hatte die FM-Version aufgrund der noch vorhandenen Einschränkungen doch einige Visuelle und Spürbare Nachteile?