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:

Zitat von mquadrat (Beitrag 1116896)

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:

Zitat von jaenicke (Beitrag 1116922)

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

Zitat von mquadrat (Beitrag 1116934)

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:

Zitat von hanspeter (Beitrag 1116936)

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:

Zitat von Bernhard Geyer (Beitrag 1116924)

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.

[Mavarik]

Hallo Zusammen!

Vielleicht liege ich ja falsch, aber wie üblich klingt das nach dem wie sich Delphi in den letzten Jahren entwickelt hat: Kompatibilität zu bestehenden Source-Code...? Wofür!

Also bleibt es doch bei D2007 :cry:

Mavarik :coder:

[Neutral General]

Wieso?

Was ist denn da nicht kompatibel?

[Mavarik]

Zitat:

Zitat von Neutral General (Beitrag 1116955)

Was ist denn da nicht kompatibel?

Willst Du nur ein paar Stichpunkte oder ne sortierte Liste... LOL

Hast Du mal versucht ein Programm - geschrieben mit D7 - mit dem aktuellen zu kompilieren?

Mavarik

[ehX]

Ihr Miesepeter....;-)

Ich freue mich generell auf die neuen Features. Lange hat man doch danach geschrien (64 Bit / Mac).
Ich hoffe nur, dass FireMonkey dann auch stabil und relativ ausgereift ist, so dass man es auch gleich annehmen kann und es nicht wieder ein Rohrkrepierer wie z.B. Blackfish wird, der nach kürzester Zeit wieder in der Versenkung verschwindet...

Ich denke, wenn XE2 draussen ist, folgt erstmal bei den meisten eine längere Evaluierungs-Phase, bevor man genau sagen kann, welcher Portierungs-Aufwand sich lohnt und welcher nicht.
Bis jetzt kann man doch eh nur die Kristallkugel befragen, solange man nicht vor einer XE2 Beta sitzt..

Und...immerhin ist das hier die Delphi-Praxis...ich bin mir sicher, hier wird man dann als lernwilliger Entwickler sicher bald fündig, was Tipps, Tricks und HowTo's dazu angeht :-)

Edit:

Zitat:

Hast Du mal versucht ein Programm - geschrieben mit D7 - mit dem aktuellen zu kompilieren?

Ja, ich z.B. habe erst ein Delphi 6-Programm auf Delphi 2009 geportet..klar, ein paar Unicode-Sachen mussten umgeschrieben werden, aber generell war das nicht mal so der Horror

[Neutral General]

Zitat:

Zitat von ehX (Beitrag 1116958)

Zitat:

Hast Du mal versucht ein Programm - geschrieben mit D7 - mit dem aktuellen zu kompilieren?

Ja, ich z.B. habe erst ein Delphi 6-Programm auf Delphi 2009 geportet..klar, ein paar Unicode-Sachen mussten umgeschrieben werden, aber generell war das nicht mal so der Horror

Eben... Also man muss halt je nachdem wegen Unicode ein bisschen umstellen. Je nachdem wie sauber man vorher programmiert hat, ist aber nicht mal das nötig.
Also offiziell sind, und bis auf die eventuelle Unicode-Hürde stimmt das denke ich auch, mit Delphi 1 geschriebene Programme genauso unter Delphi XE2 kompilierbar.

[Mavarik]

[QUOTE]Eben... Also man muss halt je nachdem wegen Unicode ein bisschen umstellen./QUOTE]

Ja genau. in 3 Mio Zeilen Source mal eben die Anpassung machen...
Jeden Move überprüfen...

Es wäre so einfach gewesen einfach einen WChar ein zu führen. und Char mit einem Byte zu lassen.

Aber ich glaube das ist der falsche Thread für diese Diskussion!

Mavarik

[Bernhard Geyer]

Zitat:

Zitat von Mavarik (Beitrag 1116968)

Ja genau. in 3 Mio Zeilen Source mal eben die Anpassung machen...
Jeden Move überprüfen...

Und wieviel tausend unpassende Move-Anweisungen für Strings hast du gefunden? Und schon seit Delphi 2/Windows NT sollte klar gewesen sein das ein Character irgendwann mal mehr als 1 byte umfassen wird.

Zitat:

Zitat von Mavarik (Beitrag 1116968)

Es wäre so einfach gewesen einfach einen WChar ein zu führen. und Char mit einem Byte zu lassen.

Nicht unbedingt. Wieviel Mannmonate hätte Borland mehr gebraucht gegenüber der jetzigen Lösung. Und wieviel Quellcodeanpassungen wäre in den Quellcodes alle anderen Komponentenhersteller gegenüber der jetzigen Lösung mehr nötig gewesen. Ich habe mit D6 eine Unicodeportierung in der Art "Neue StringType = WideString" gemacht. Ist nicht gerade wenig Arbeit. Hättes es D2009 schon gegeben (und Win9x nicht nötig gewesen) hätten wir uns einige Wochen Arbeit gespart.

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1116949)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1116924)

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.

Das ist aber besch****. Also entweder oder? Ich hoffe auf ein ähnliche Unit wie bei VCL2NET in der Mischbetrieb .NET und VCL.NET möglich war.

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1116968)

Es wäre so einfach gewesen einfach einen WChar ein zu führen. und Char mit einem Byte zu lassen.

Nur weil viele eben den Programmierfehler gemacht haben Metatypen statt der konkreten Typen zu benutzen, hätte man jetzt alle anderen durch eine schlechtere Umsetzung leiden lassen sollen? Das halte ich für keine gute Lösung.

Wer konsequent LongInt, AnsiString, AnsiChar usw. benutzt hat wo es wichtig ist was genau für ein Typ dahinter steckt, der hat auch relativ wenige Probleme hinsichtlich einer Umstellung auf Unicode oder 64-Bit.

Wir haben unsere Anwendung auch innerhalb sehr kurzer Zeit von Delphi 5 auf XE umgestellt und mussten danach hauptsächlich an Hardwareschnittstellen oder direkten Speicherzugriffen nachbessern. Das waren aber zu einem großen Teil Programmierfehler, weil ein falscher Datentyp verwendet wurde. In zugekauften Komponenten genauso wie in eigenen Codes.

[Florian Hämmerle]

Zitat:

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

Dabei ging es aber um einen neuen Compiler bzgl. dem neuen C++-Standard, der da gerade freigegeben und veröffentlicht worden ist ;)

[QuickAndDirty]

ähm DelphiXE2 unterstützt absichtlich kein Android und Linux?

OK....

[himitsu]

Zitat:

Zitat von Mavarik (Beitrag 1116956)

Zitat:

Zitat von Neutral General (Beitrag 1116955)

Was ist denn da nicht kompatibel?

Willst Du nur ein paar Stichpunkte oder ne sortierte Liste... LOL

Hast Du mal versucht ein Programm - geschrieben mit D7 - mit dem aktuellen zu kompilieren?

Mavarik

Delphi ist ja so weit noch Abwärtskompatibel.
Ältere Programmcodes laufen in aktuellen/neueren Delphis.
(OK, abgesehn schlechtprogrammierte Altcodes, welche z.B. PChar verwenden, obwohl AnsiChar gemeint war, was seit Unicode dann knallt ... genauso wie Pointer bald größer ist und man damals falsch gecastet hat)

Von Aufwärtskompatibel hat keiner was gesagt.
(z.B. Generics wird man schlecht in D3 zum Laufen bekommen)



Gut, wenn VCL <> Firemonky, dann wird es wohl etwas schwerer ein VCL-Programm auf den Mac zu portieren. :gruebel:

Zitat:

ähm DelphiXE2 unterstützt absichtlich kein Android und Linux?

Ich dachte ja mal, da Linux noch vor Mac kommt, wo doch Borland schon etwas vorgearbeitet hatte.
Ich nutze zwar kaum/kein Linux, aber ich denke mal, daß ich eher an ein Linux kommen würde, als an einen Mac, womit Linux (mir) eher geholfen hätte. :cry:

[Insider2004]

Zum Nachdenken:

-Ist Firemonkey als Ersatz für die VCL geplant?
NEIN!

-Marktanteile Desktop OS
Windows 87%
Mac 5%
iOS 3%
Linux 0.9%

Die Musik spielt weiterhin bei Windows (wenn man Geld verdienen will/muss)

[himitsu]

Und wie sieht es mit den Server-Systemen aus?
Ich glaub mit <1% kommt man dort nicht ganz hin.

[Uwe Raabe]

Zitat:

Zitat von Insider2004 (Beitrag 1117024)

Zum Nachdenken:

-Ist Firemonkey als Ersatz für die VCL geplant?
NEIN!

-Marktanteile Desktop OS
Windows 87%
Mac 5%
iOS 3%
Linux 0.9%

Die Musik spielt weiterhin bei Windows (wenn man Geld verdienen will/muss)

Das ist vollkommen richtig! Ich sehe FireMonkey auch nicht als Ersatz für die VCL, sondern als eine Alternative, wenn man (auch) für Mac & Co. entwickeln will/muss.

[Insider2004]

Zitat:

Zitat von himitsu (Beitrag 1117025)

Und wie sieht es mit den Server-Systemen aus?
Ich glaub mit <1% kommt man dort nicht ganz hin.

Da habe ich keine Zahlen. Aber die Zahl der Serversysteme dürfe im Vergleich zu der Zahl der Desktopsysteme gegen Null gehen. Für mich als Desktop-Entwickler spielt das aber sowieso keine Rolle.

[jaenicke]

Zitat:

Zitat von QuickAndDirty (Beitrag 1117022)

ähm DelphiXE2 unterstützt absichtlich kein Android und Linux?

Nicht absichtlich, sondern weil die Unterstützung eben erst noch implementiert werden muss.

Android kommt ja offenbar noch per Update hinterher, aber Linux war (wie auch letztes Jahr auf den Delphi-Tagen schon angesprochen) für XE 3 (oder später) geplant. Das war für XE 2 sowieso nie vorgesehen.

Und zumindest Privatnutzer werden ohnehin kaum bereit sein für Linuxsoftware Geld auszugeben, nachdem sie genau wegen der Kosten (in 95% der Fälle, die ich kenne) zu Linux gewechselt sind. Für Firmensoftware kann das aber natürlich durchaus interessant sein, wenn die Anschaffungskosten des Systems insgesamt z.B. einfach nur billig sein sollen.

Denn ob Delphi auf Serverseite unter Linux eingesetzt werden wird... mal schauen...

[mkinzler]

Android-Unterstützung wird auch eher über Cooper-Integration kommen.

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1117023)

Zitat:

ähm DelphiXE2 unterstützt absichtlich kein Android und Linux?

Ich dachte ja mal, da Linux noch vor Mac kommt, wo doch Borland schon etwas vorgearbeitet hatte.
Ich nutze zwar kaum/kein Linux, aber ich denke mal, daß ich eher an ein Linux kommen würde, als an einen Mac, womit Linux (mir) eher geholfen hätte. :cry:

Mir auch...vor allem, weil das ja so der erste Schritt in Richtung Android gewesen wäre. Etlchiche unserer Kudnen haben Linux server...das hätte unseren Diensten echt was gebracht!!!

Aber etliche Kunden haben auch 64 Bit ....das bringt auf ganzer Front etwas!

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1117025)

Und wie sieht es mit den Server-Systemen aus?
Ich glaub mit <1% kommt man dort nicht ganz hin.

EBEN!

Und Linux ist der erste Schritt Richtug Android Unterstützung...

[Florian Hämmerle]

Zitat:

Zitat von mkinzler (Beitrag 1117033)

Android-Unterstützung wird auch eher über Cooper-Integration kommen.

Hab ich auch das Gefühl. Wobei ja ab XE2 nicht mehr von Delphi Prism sondern nur noch von Prism gesprochen wird. Also kein Delphi Cooper sondern wenn, nur Cooper.

[QuickAndDirty]

Zitat:

Zitat von jaenicke (Beitrag 1117031)

Zitat:

Zitat von QuickAndDirty (Beitrag 1117022)

ähm DelphiXE2 unterstützt absichtlich kein Android und Linux?

Nicht absichtlich, sondern weil die Unterstützung eben erst noch implementiert werden muss.

Android kommt ja offenbar noch per Update hinterher, aber Linux war (wie auch letztes Jahr auf den Delphi-Tagen schon angesprochen) für XE 3 (oder später) geplant. Das war für XE 2 sowieso nie vorgesehen.

Und zumindest Privatnutzer werden ohnehin kaum bereit sein für Linuxsoftware Geld auszugeben, nachdem sie genau wegen der Kosten (in 95% der Fälle, die ich kenne) zu Linux gewechselt sind. Für Firmensoftware kann das aber natürlich durchaus interessant sein, wenn die Anschaffungskosten des Systems insgesamt z.B. einfach nur billig sein sollen.

Denn ob Delphi auf Serverseite unter Linux eingesetzt werden wird... mal schauen...

Ich hätte bräuchte es Serverseitig!

[Florian Hämmerle]

Zitat:

Zitat von QuickAndDirty (Beitrag 1117037)

Zitat:

Zitat von himitsu (Beitrag 1117025)

Und wie sieht es mit den Server-Systemen aus?
Ich glaub mit <1% kommt man dort nicht ganz hin.

EBEN!

Und Linux ist der erste Schritt Richtug Android Unterstützung...

Ne Java&Dalvik...

[QuickAndDirty]

Zitat:

Zitat von mkinzler (Beitrag 1117033)

Android-Unterstützung wird auch eher über Cooper-Integration kommen.

Ja Ja...unter Cooper entwickelte Android Apps sind reine Dalvik Programme!
Man kann aber für Android auch Native Programme schreiben und auch hybride. Hätte das sehr begrüßt.

[QuickAndDirty]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1117040)

Zitat:

Zitat von QuickAndDirty (Beitrag 1117037)

Zitat:

Zitat von himitsu (Beitrag 1117025)

Und wie sieht es mit den Server-Systemen aus?
Ich glaub mit <1% kommt man dort nicht ganz hin.

EBEN!

Und Linux ist der erste Schritt Richtug Android Unterstützung...

Ne Java&Dalvik...

Das geht doch Cooper schon an. Es geht aber auch nativ!

[mkinzler]

Zitat:

Und Linux ist der erste Schritt Richtug Android Unterstützung...

Android verwendet zwar Linux als Basis, darauf läuft aber eine modifizierte Java-Laufzeit. Android-Programme sind deshalb keine Linuxprogramme sondern Java-Programme. Da es den Oxygene-Compiler von Remobjects, der Basis für Prism ist, bald auch als Java-Version (Cooper) gibt, ist es wahrscheinlicher, dass dieser verwendet wird, und keine native Lösung.

[Florian Hämmerle]

Android-OS setzt auf Linux auf. Die Apps sind aber keine nativen Linux-Anwendungen sondern speziell für die Dalvik-RT compiliert.

Anwendungen für Linux sind nicht gerade attraktiv, da der Großteil der Linux-User nicht im Sinn hat, für ein Programm zu zahlen.

[Lemmy]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1117053)

Anwendungen für Linux sind nicht gerade attraktiv, da der Großteil der Linux-User nicht im Sinn hat, für ein Programm zu zahlen.

Seh ich nicht so - ich bin immer bereit für ein Programm zu bezahlen - es muss aber eben ein Gegenwert da sein. Wenn ich ein OPenSource-Programm bekomme, das ich lizenztechnisch einsetzen kann, das die Aufgabe gleich gut oder besser macht als die Bezahlprogramme für 1000€ muss ich nicht lange überlegen.

Grüße

[jaenicke]

Zitat:

Zitat von mkinzler (Beitrag 1117033)

Android-Unterstützung wird auch eher über Cooper-Integration kommen.

Geplant ist eine native Anbindung, wie auch für Linux. Wann die dann tatsächlich kommt, ist noch nicht klar, aber vermutlich nach Cooper, vielleicht in XE 3. Dennoch soll es eine eigenständige Lösung sein.

Zitat:

Zitat von Lemmy (Beitrag 1117058)

Seh ich nicht so - ich bin immer bereit für ein Programm zu bezahlen - es muss aber eben ein Gegenwert da sein.

Da bist du aber die riesengroße Ausnahme. Hier in den Delphi Foren mag das ein wenig anders sein, zumindest nach dem was so geschrieben wird, aber meine Erfahrung im privaten Umfeld ist eine gänzlich andere (insbesondere bei Linuxnutzern)...

[marcoX]

Zitat:

Zitat von jaenicke (Beitrag 1117062)

Da bist du aber die riesengroße Ausnahme. Hier in den Delphi Foren mag das ein wenig anders sein, zumindest nach dem was so geschrieben wird, aber meine Erfahrung im privaten Umfeld ist eine gänzlich andere (insbesondere bei Linuxnutzern)...

Dann muss man sich das Geld eben anders holen :) Durch Werbung, Spenden, Supportverträge etc.

Es gibt ja auch im Linux-Bereich genug kommerzielle Firmen, die auf dieser Schiene fahren.