Was ist FireMonkey?

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1147919)

Wer will, der kann auch ganz gerne noch mit D2 arbeiten. (nur D1 ist seit Win7 x64 nicht mehr nutzbar, da keine 16 Bit mehr unterstützt werden)

Delphi 2007 sollte es schon sein, damit die gröbsten Fehler, die seit XP und vor allem Vista auftreten, behoben sind. Wobei ich schon gesehen habe, dass es bei mit Delphi 7 geschriebenen Anwendungen auch mal zwei Versionen gibt: bis XP und ab Vista. Und das nur wegen der bis Delphi 2005 fehlerhaften Randberechnung. ;-)

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1147919)

Es geht nur um die wenigen Projekte, welche wirklich mal mehr als 2-3 GB RAM benötigen.
Und um Plugins/DLLs, welche in andere Prozesse rein sollen, welche 64 Bit ist ... mit einer 32 Bit DLL kann man in einer 64 Bit App nichts anfangen.

Wir hatten schon den ersten Kunden mit dem Wunsch (Anforderung?) das wir doch bitte die Apps in 64-Bit bereit stellen sollten. Er will eigentlich nur noch 64-Bit Anwendungen einsetzen auch wenn hier kein Vorteil gegeben wäre. :roll:

Zitat:

Zitat von himitsu (Beitrag 1147919)

Aber ansonsten ist alle davor nutzbar, jenachdem welche Features man gerne nutzen möchte.
Wer will, der kann auch ganz gerne noch mit D2 arbeiten.

Das D2 noch keine COM/ActiveX-Unterstützung hatte würde man hier doch mittlerweile auf viel Verzichten.

[Darlo]

Zitat:

Zitat von bernau (Beitrag 1147930)

Daumen hoch für Firemonkey.

:thumb:

Ich will Firemonkey auch nicht mehr missen. Wenn die Startzeiten unter iOS noch besser werden und es TWebbrowser und TMediaPlayer
gibt, werde ich komplett umsteigen.

[Bernhard Geyer]

Zitat:

Zitat von Darlo (Beitrag 1147953)

... und es TWebbrowser und TMediaPlayer

Da TWebBrowser auf ActiveX und IE und TMediaPlayer auf die ActiveX-Schnittstelle vom Windows Media-Player aufsetzt dürfte es hiermit ein Problem bei portabler Portierung geben...

Eine alternative wäre wohl wenn delphichromiumembedded einen portable implementierung liefern würde.
Und Mediaplayer kannst du kicken wenn du diese mittels HTML5-Seite realisierst die du in delphichromiumembedded lädst.

[Phoenix]

Zitat:

Zitat von bernau (Beitrag 1147930)

Neee. Firemonkey ist der richtige Schritt. Genau auf sowas habe ich gewartet. Mir ist es egal, ob das Programm sich nicht Windows-Like oder Mac-Like anfühlt. Schön ist es doch, daß es auf jeder Plattform gleich aussieht. [...]
Daumen hoch für Firemonkey.

Zitat:

Zitat von Darlo (Beitrag 1147953)

Ich will Firemonkey auch nicht mehr missen. Wenn die Startzeiten unter iOS noch besser werden und es TWebbrowser und TMediaPlayer
gibt, werde ich komplett umsteigen.

Nein, dass es überall gleich "aussieht" ist ein Problem. Es benutzt keine nativen API's. Mac-User verwenden einen Mac gerade WEIL er sich anders bedient als ein Windows-PC. Linux-User customizen ihre Oberfläche bis ins kleinste Detail, und eine Anwendung hat sich da gefälligst anzupassen.

Eine Anwendung, die nicht in der jeweiligen Plattform sauber integriert ist, wird nicht angenommen. 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.

Oder anders gesagt: Jeder, der seine Anwendungen mit FM entwickelt wird zwangsläufig massivste Absatzprobleme erfahren. Das Zeug ist ganz einfach nicht an den Mann zu bringen.

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?

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.

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.

[TiGü]

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

Habt ihr die intern gemacht oder ist das eine öffentliche Studie? Wenn letzteres, dann bitte einen Link dazu!

[bernau]

Zitat:

Zitat von Phoenix (Beitrag 1147970)

Nein, dass es überall gleich "aussieht" ist ein Problem. Es benutzt keine nativen API's. Mac-User verwenden einen Mac gerade WEIL er sich anders bedient als ein Windows-PC. Linux-User customizen ihre Oberfläche bis ins kleinste Detail, und eine Anwendung hat sich da gefälligst anzupassen.

Habe ich andere Erfahrungen mit gemacht.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

Eine Anwendung, die nicht in der jeweiligen Plattform sauber integriert ist, wird nicht angenommen. 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.

Oder anders gesagt: Jeder, der seine Anwendungen mit FM entwickelt wird zwangsläufig massivste Absatzprobleme erfahren. Das Zeug ist ganz einfach nicht an den Mann zu bringen.

Auch hier deine persönliche Meinung. Oder kannst du das irgenwo belegen?

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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?

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.

Bei solchen Sachen hast du immer ein Problem. Egal ob mit FM, Oxygene, oder sonst was. Irgendwo müssen Abstriche gemacht werden. Viele Platformen zu bedienen bedeutet kleinster gemeinsammer Nenner. Wenn das berücksichtigt wird, dann gibt's weniger Probleme.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

Ach. Habe noch nie ein Vergelichstest in dieser Art gesehen. Hast du einen Link? Firemonkey gibt's noch nicht so lange. Geschweige die damit erstellten Programme. Wie können dann jetzt schon seriöse Vergleiche durchgeführt werden?

Habe irgendiw das Gefühl, daß du deine RemObjects-Brille auf hast und alles andere verteufelst.

[MEissing]

Zitat:

Zitat von Phoenix (Beitrag 1147970)

Deswegen sagt Marc ja auch

Wer ist dieser "Marc"? Muss man den kennen?

GD&RVF

[jaenicke]

Zitat:

Zitat von Phoenix (Beitrag 1147970)

Mac-User verwenden einen Mac gerade WEIL er sich anders bedient als ein Windows-PC. Linux-User customizen ihre Oberfläche bis ins kleinste Detail, und eine Anwendung hat sich da gefälligst anzupassen.

Bei beiden habe ich bisher eher eine andere Erfahrung gemacht. Beim Mac ging es fast allen, die ich kenne (gut, sind nur 14 Leute) nur darum, dass erstens ein Apfel drauf ist, weil es cool ist und zweitens darum, dass man sich um nicht viel kümmern muss und es einfach läuft.
Und bei Linux höre ich eher, dass die Oberfläche zwar nicht schön aussieht, aber einfach nur funktioniert und genau das auch das wichtigste ist. sprich: Wie es aussieht, ist egal. Daher ja auch der Ausdruck "Klickibunti" für Windows.

Ich weiß nicht woher du deine Ansicht hast, aber mit denen der Personen, die ich kenne, stimmen diese absolut nicht überein.

Und was FireMonkey angeht:
Wir werden ziemlich sicher mittelfristig in der Firma auch in diese Richtung gehen, aber das erfordert natürlich erst einmal viel Planung.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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 ...

Zitat:

Zitat von Phoenix (Beitrag 1147970)

Es benutzt keine nativen API's.

Ega. Solange es sich gut anfühlt.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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.

Zitat:

Zitat von Phoenix (Beitrag 1147970)

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?