Welche Konsequenzen zieht ihr aus den Features für XE2?

[mquadrat]

Hallo zusammen,

wenn ich mir die Feature-Liste von XE2 aus dem anderen Thread so durchlese drängt sich die Frage nach den Konsequenzen auf. Bei der VCL bleiben oder auf FireMonkey wechseln? Versuchen Rave zum Laufen zu kriegen oder auf Fastreport wechseln?

Kompletter Rewrite oder Operation am offenen Herzen?

Wenn man sowieso dran ist, auch gleich einen ORM einbauen? Welchen?


So viele Ideen, so wenig Zeit

[Uwe Raabe]

Das muss sicher jeder für sich entscheiden. Ich werde meinen Kram als erstes an 64-Bit anpassen, das wird am schnellsten gehen.

Eine Portierung auf FireMonkey kommt einem Neu-Design der Oberfläche gleich, da viele visuelle (Fremd-)Komponenten für FMX nicht verfügbar sein werden und sich FMX-Anwendungen ganz anders verhalten werden. OSX und iOS sind eben ganz andere Betriebssysteme und man muss sich da erstmal von der Windows-Sicht lösen.

Ob es sich rechnet, bestehende Projekte zu portieren ist ganz einfach von der Nachfrage abhängig. Ich habe zwar schon ein paar Anfragen von Mac-Usern, die meine Anwendungen bisher in Fusion oder Parallels ausführen, aber ob die den Aufwand wieder reinbringen? (Was? Das kostet extra? Nee, lass mal. Läuft doch auch so.)

Bei neuen Projekten ist das natürlich etwas ganz Anderes. Allein schon, um mit FMX zurecht zu kommen, ist eine intensive Nutzung sicher unvermeidlich. Am Anfang wird es sicher etwas schwerfällig und ungewohnt sein und es wird auch eine Weile dauern, bis sich ein brauchbares Ecosystem gebildet hat, wie es die VCL hat.

Wenn wir wollen, das FMX nicht "den Bach runter geht", dann müssen wir es auch annehmen.

[jaenicke]

Zitat von mquadrat:

Kompletter Rewrite oder Operation am offenen Herzen?

Solange man die GUI nicht mit der Business-Logik, Datenzugriffen usw. vermischt hat, muss man für FireMonkey ja "nur" die GUI neu schreiben, und das geht ohnehin nur mehr oder weniger komplett. Man kann höchstens einen Teil der Logik der GUI übernehmen.

[Bernhard Geyer]

Zitat von jaenicke:

... und das geht ohnehin nur mehr oder weniger komplett.

Das wäre die Frage: Ist eine Mixed-Betrieb zwischen VCL und FireMonkey möglich? Würde eine Umschreiben auf neues GUI-Framework dahingehen erleichtern das man immer noch ein Auslieferfähiges Produkt hat statt Monate nix liefern zu können.

[mquadrat]

Aber gerade bei Legacy-Projekten dürfte oft nicht sauber gekapselt sein.

[hanspeter]

Erst mal abwarten, wie es mit der Stabilität aussieht.
Dann ist interessant, ob die VCL thread-sicher geworden ist.
Ob der alte hinderliche Zopf BPL abgeschnitten ist.
Ob de Sprache selbst modernisiert und zu Prism kompatibel ist.
Dann warte ich noch die Richtungsdisskussion zu Windows 8 ab.
Mit Firemonkey ist mir das Risiko zu groß.
Ich habe wieder ein Framework eines einzelnen Herstellers und wenig professionelles Umfeld/ Toolproduzenten.
Wenn ich die Oberfläche ohnehin neu aufsetzen muss, dann ist mir WPF oder eine Web-Oberfläche lieber.
Der Aufwand einer Umstellung auf Prism dürfte nicht wesentlich größer sein und mit DotNet bzw. den Prism-Nachfolger erreiche ich mehr Zielplattformen.
Wir werden wohl eine Starterversion (so sie es dann gibt) kaufen, um ein "Gefühl" für die neuen Möglichkeiten mit nativen Delphi zu bekommen.
Danach erfolgt dann der Richtungsentscheid Delphi nativ oder Prism/.Net.

Gruß
Peter

[mquadrat]

Die Details zu Windows 8 sollen ja auf der Build-Konferenz kommen. Aber das ganze Thema HTML5 Apps wird sich ja fast ausschließlich im Consumer-Bereich abspielen. Ich denke es wird auch keine Einschränkungen im Windows Marketplace geben, die natives Delphi aus dem Rennen nehmen werden.

[hanspeter]

Zitat von mquadrat:

Die Details zu Windows 8 sollen ja auf der Build-Konferenz kommen. Aber das ganze Thema HTML5 Apps wird sich ja fast ausschließlich im Consumer-Bereich abspielen. Ich denke es wird auch keine Einschränkungen im Windows Marketplace geben, die natives Delphi aus dem Rennen nehmen werden.

Ich verspreche mir zumindest, das die Richtung in der Oberflächenentwicklung im Mainstream klar wird. Ob die üblichen Komponenten nun auf dem Deskop oder in einem Browserfenster dargestellt werden, ist zumindest optisch fast gleich. Also WPF/Silverlight/Browser. Ich möchte zum Rest der Welt wenigstens im Ansatz kompatibel bleiben und mich nicht auf eine völlig probitäre Oberfläche einlassen. Mir geht es auch nicht darum, ob natives Delphi aus dem Rennen genommen wird, sondern darum welche Vorteile bringt es mir und meiner Entwicklung, wenn ich bei nativen Delphi bleibe.
Ich hoffe ja das der neue Compiler effektiveren (schnelleren) Code als der alte erzeugt und die Kompilate, entgegen den Trend der letzten Jahre, auch wieder mal kleiner werden.
Nachtrag
Wenn ich die Features-Liste durchlese, dann ist ein 64 bit Compiler und ein OSX Compiler angekündigt. Bedeutet das, das der 32 bit Compiler der alte ist?

Peter

[Robotiker]

Zitat von hanspeter:

Bedeutet das, das der 32 bit Compiler der alte ist?

Zumindest der C++ Compiler ist noch der alte, kann aber trotzdem für Mac übersetzen.
Könnte also bei Delphi ähnlich sein.

DavidI hat ja letztens nur geschrieben, dass sie an einem neuen C++ Compiler arbeiten. Dürfte also erst in XE3 oder XE4 kommen.

[Stevie]

Zitat von Bernhard Geyer:

Das wäre die Frage: Ist eine Mixed-Betrieb zwischen VCL und FireMonkey möglich?

Nein, entweder deine Anwendung ist VCL, oder sie ist FireMonkey.