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

[mschaefer]

Haben die Features neue Softwareprojekte zur Konsequenz? Welche Nachfrage generiert XE2. Was mein Ihr?

[cookie22]

Es wird sicher viele neue Win64/OS X/iOS Projekte geben.

[jaenicke]

Davon gehe ich auch stark aus, auch was iOS angeht. Wer mal für iOS mit den bisherigen Lösungen entwickelt hat, wird sich dessen umso sicherer sein. ;-)

Und die Kosten für ne Delphi XE 2 Starter oder Professional sind im Vergleich zu Apples Preisen ja sehr gering.

[mkinzler]

Zitat:

Und die Kosten für ne Delphi XE 2 Starter oder Professional sind im Vergleich zu Apples Preisen ja sehr gering.

XCode 3 ist kostenlos und xcode 4 kostet 4€

[FredlFesl]

[Blasphemie=ON]Und wieso sollte ich bei Delphi bleiben und nicht vollständig zu VS wechseln?[Blasphemie=OFF]
Die Frage ist ernst gemeint.

[Florian Hämmerle]

Zitat:

Zitat von FredlFesl (Beitrag 1117076)

[Blasphemie=ON]Und wieso sollte ich bei Delphi bleiben und nicht vollständig zu VS wechseln?[Blasphemie=OFF]
Die Frage ist ernst gemeint.

Ist Geschmackssache und jeder sollte das für sich selbst entscheiden.

[jaenicke]

Zitat:

Zitat von mkinzler (Beitrag 1117075)

XCode 3 ist kostenlos und xcode 4 kostet 4€

Dafür kann es auch viel weniger, aber ich meinte eher die teure Hardware. ;-)

Zitat:

Zitat von FredlFesl (Beitrag 1117076)

[Blasphemie=ON]Und wieso sollte ich bei Delphi bleiben und nicht vollständig zu VS wechseln?[Blasphemie=OFF]
Die Frage ist ernst gemeint.

Wenn das alles kann was du brauchst, nimm einfach das. Man sollte sich nie auf eine einzelne Sprache festlegen, sondern immer die nehmen, die für den Anwendungszweck und das Umfeld am besten passt.

Bei mir war das in den meisten Fällen Delphi, aber ich nutze auch Prism, C# und andere Sprachen. ;-)

[Florian Hämmerle]

Wenn man sich keinen Mac leisten kann, dann hat man einen Bekannten mit Mac oder man findet hier im Forum sicher jemanden, der das Projekt schnell durch XCode jägt. Da würd ich mir keine Sorgen machen

[hanspeter]

Zitat:

Zitat von FredlFesl (Beitrag 1117076)

[Blasphemie=ON]Und wieso sollte ich bei Delphi bleiben und nicht vollständig zu VS wechseln?[Blasphemie=OFF]
Die Frage ist ernst gemeint.

Die Frage ist wirklich ernst, zumal mit Prism man nicht mal die Pascalwelt verlassen muss.
Was mir noch nicht klar ist, wird Cooper Bestandteil des Delphipaketes analog Prism oder ist das ein eigenes Produkt von Remobjects?
Ist Cooper der Nachfolger von Prism oder bestehen beide Projekte parallel.
Wenn FireMonkey und VCL nicht kompatibel sind, dann kann ich mit gleichen Aufwand auf WPF oder eine ähnliche Technologie wechseln.
Wir haben zwar GUI und Bussineslogik weitestgehend getrennt. Gerade aber Delphi als Rad-Tool läd durch Klick zu einer Vermischung ein.
Die Frage ist letztendlich
1. Welche Vorteile bringt mir eine native Entwicklung.
2. Will ich und kann ich an den sich mit großer Dynamik entwickelnden DotNet- Bibliotheken vorbei entwickeln.

Gruß Peter

[Florian Hämmerle]

Prism = .net
Cooper = Java / Dalvik
Beiden liegt die Sprache Oxygene / Chrome zu Grunde, was zur Auswirkung hat, das Prism-Projekte je nach Benutzung der Bibliotheken sofort mit Cooper kompilierbar sind.

[Robotiker]

Für FireMonkey wird viel davon abhängen, wie die Community darauf anspricht. Die Weiterentwicklung von Delphi bedeutet ja auch, das alle, die auf älteren Versionen geblieben sind, in gewisser Weise abgehängt werden.

Die unterschiedlichen Dialekte Delphi, Prism, Cooper, usw. führen zu einer Aufspaltung des Marktes an verfügbaren Komponenten und Code, genauso wie es bei Unicode der Fall war und bei Win64 wohl auch sein wird.

Was Windows only Projekte angeht, ist es wohl sinnvoller abzuwarten, was in Kürze für Windows 8 verkündet wird. Da kommen noch neue Dinge auf uns zu, die in zukünftigen Delphi Versionen auch noch berücksichtigt werden müssen. (Html5/JavaScript/Next Generation COM/neue C++ Tools)

Hier tut sich gerade was
http://blogs.msdn.com/b/b8/

[Bernhard Geyer]

Zitat:

Zitat von Robotiker (Beitrag 1117111)

Für FireMonkey wird viel davon abhängen, wie die Community darauf anspricht. Die Weiterentwicklung von Delphi bedeutet ja auch, das alle, die auf älteren Versionen geblieben sind, in gewisser Weise abgehängt werden.

Wieso das? VCL gibt es auch in XE2 und wird dort 64-Bit Windows ermöglichen

Zitat:

Zitat von Robotiker (Beitrag 1117111)

..., genauso wie es bei Unicode der Fall war und bei Win64 wohl auch sein wird.

Aufspaltung Markt weil manche Komponentenhersteller einfach die Weiterentwicklung eingestellt haben? Wohl eher Markt"bereinigung" in dem manche Komponentenhersteller das Geschäft aufgeben weil sie keine Zukunft sehen und den größeren Anpassungsaufwand scheuen (wohl teilweise bedingt durch schlechten Quellcode der Komponenten).

Zitat:

Zitat von Robotiker (Beitrag 1117111)

Was Windows only Projekte angeht, ist es wohl sinnvoller abzuwarten, was in Kürze für Windows 8 verkündet wird. Da kommen noch neue Dinge auf uns zu, die in zukünftigen Delphi Versionen auch noch berücksichtigt werden müssen. (Html5/JavaScript/Next Generation COM/neue C++ Tools)

Mich machen nix weil MS versucht zwangshaft eine Touchoberfläche als Lösung für alles Anzupreisen? Aber wenn Win8 mit Arm-Unterstützung rauskommt wird es wieder eine "Aufspaltung" des Marktes geben. Die, die ein XE3 mit FireMonkey für Win8-Arm unterstützen (schön wäre auch ein VCL für Win8-ARM) und welche die aufgeben.

[jobo]

Da musste ich aber sehr schmunzeln, der Groschen viel ganz langsam.
Nach Win Touch Unterstützung nun Win8 Arm Unterstützung?! Vor meinem geistigen Auge sah ich Windows User, die wild mit den Armen rumfuchteln. Aber dann drang dieser Prozessortyp in mein Bewusstsein.. schade eigentlich

Oder war gemeint Win8 Arm Unterstützung = Windows für Arme = Windows für Arbeitslose, Studenten und Schüler ? Oder, oder, oder ... ?

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1117121)

Da musste ich aber sehr schmunzeln, der Groschen viel ganz langsam.
Nach Win Touch Unterstützung nun Win8 Arm Unterstützung?! Vor meinem geistigen Auge sah ich Windows User, die wild mit den Armen rumfuchteln. Aber dann drang dieser Prozessortyp in mein Bewusstsein.. schade eigentlich

Oder war gemeint Win8 Arm Unterstützung = Windows für Arme = Windows für Arbeitslose, Studenten und Schüler ? Oder, oder, oder ... ?

:-) Es ist schon der Prozessor gemeint. Bis das "Armfuchteln" der X-Box in Windows einzug hält und wir unser Verzeichnisse ala Minority Report durchforsten können wird es noch etwas dauern (wobei ich denke das es hier schon Implementierungen gibt).

[mquadrat]

Also ich sehe das anders, als die meisten hier. FireMonkey ist definitiv der Nachfolger der VCL. Die VCL wird IMHO in wenigen Jahren das Schicksal von WinForms teilen.

Ist die erweiterte Datenbindung eigentlich für VCL und FireMonkey bestätigt? Oder nur für eins der beiden?

Man wird sich bei Neuentwicklungen definitiv zwischen Prism und Delphi+FireMonkey entscheiden müssen. Jemand ne Ahnung ob ein Oxygene for ObjectiveC geplant ist? :lol:

[Robotiker]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1117117)

Wieso das? VCL gibt es auch in XE2 und wird dort 64-Bit Windows ermöglichen

Genau deswegen. Weil aber nur ein Teil der Delphi-Entwickler auf die neuen Versionen wechselt, ist die Community dann eben zahlenmäßig kleiner.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1117117)

Wohl eher Markt"bereinigung" in dem manche Komponentenhersteller das Geschäft aufgeben weil sie keine Zukunft sehen und den größeren Anpassungsaufwand scheuen (wohl teilweise bedingt durch schlechten Quellcode der Komponenten).

So kann man das natürlich auch nennen. Aber genau das wollte ich mit meinem Posting ausdrücken.

Die Anzahl der Delphi-Entwickler hat in den letzten Jahren abgenommen. Die Fülle an neuen Möglichkeiten führt jetzt dazu, dass sich die verbliebenen weiter verteilen.

Eine (vielleicht die wichtigste) Stärke von Delphi ist die starke Community und die Vielzahl an verfügbaren Code und Komponenten. Das wird durch die neuen Entwicklungen deutlich heterogener werden.

[Bernhard Geyer]

Zitat:

Zitat von mquadrat (Beitrag 1117123)

Also ich sehe das anders, als die meisten hier. FireMonkey ist definitiv der Nachfolger der VCL.

Wir haben schon zwei Nachfolgertechniken kommen und gehen sehen CLX und VCL.NET. Glücklicherweise habe ich nach relativ kurzer Testzeit mit "bringt uns aktuell nix" diese beiseite gelegt.

[mquadrat]

Delphi will Cross-Plattform sein (FireMonkey), Delphi will in den Bereich der verteilten Architekturen (DataSnap, Cloud-Services). Ich würde unter Umständen sogar so weit gehen, zu sagen, dass das der letzte Versuch ist neue Entwickler zu gewinnen. Klappt das wieder nicht, dürfte sich Delphi endgültig in der Abteilung Legacy-Unterstützung einordnen mit den entsprechenden Folgen für die Entwicklung.

Aber das wird die Zeit zeigen ;)

Wir werden mit unserer Software noch geraume Zeit auf die VCL festgenagelt sein. XE2 wird trotzdem gekauft, da 2007 einfach in die Jahre kommt. Und ein halbwegs funktionierendes Error Insight ist ja alleine schon ein Kaufgrund :-)

[mkinzler]

Zitat:

Ist die erweiterte Datenbindung eigentlich für VCL und FireMonkey bestätigt? Oder nur für eins der beiden?

Für beide, wie auch die Skinningfunktionalität ( vcl styles)

Zitat:

Wir haben schon zwei Nachfolgertechniken kommen und gehen sehen CLX und VCL.NET. Glücklicherweise habe ich nach relativ kurzer Testzeit mit "bringt uns aktuell nix" diese beiseite gelegt.

FireMonkey ist aber was ganz anderes, hier wird nicht versucht die VCL auf Biegen-und-Brechen auf eine andere Plattform zu bringen, sondern bietet eine echte Alternative, die eher mit WPF vergleichbar ist.

[Lemmy]

Zitat:

Zitat von mquadrat (Beitrag 1117129)

Ich würde unter Umständen sogar so weit gehen, zu sagen, dass das der letzte Versuch ist neue Entwickler zu gewinnen. Klappt das wieder nicht, dürfte sich Delphi endgültig in der Abteilung Legacy-Unterstützung einordnen mit den entsprechenden Folgen für die Entwicklung.

:shock: Pressemitteilung noch nicht gelesen? seit 2008 eine jähliche Steigerung um 15%... Was soll da heißen "Letzter Versuch" - das ist doch schon gelungen...

http://delphi-insider.blogspot.com/2...phi-reaps.html

[mquadrat]

Zitat:

Zitat von Lemmy (Beitrag 1117132)

Zitat:

Zitat von mquadrat (Beitrag 1117129)

Ich würde unter Umständen sogar so weit gehen, zu sagen, dass das der letzte Versuch ist neue Entwickler zu gewinnen. Klappt das wieder nicht, dürfte sich Delphi endgültig in der Abteilung Legacy-Unterstützung einordnen mit den entsprechenden Folgen für die Entwicklung.

:shock: Pressemitteilung noch nicht gelesen? seit 2008 eine jähliche Steigerung um 15%... Was soll da heißen "Letzter Versuch" - das ist doch schon gelungen...

http://delphi-insider.blogspot.com/2...phi-reaps.html

Da geht es um die Verkäufe nicht um die Anzahl der Entwickler. Viele auf älteren Versionen dürften zwecks Unicode neue Versionen gekauft haben. Ich sage ja nicht, dass sich mit Delphi kein Geld verdienen lässt. So wie es auch in Zukunft noch haufenweise C++/WinForms Entwickler geben wird, wird es auch Delphi-Entwickler geben. Die Frage ist, ob sich Delphi auch in neu aufgesetzten Projekten behaupten kann.

[jaenicke]

Zitat:

Zitat von mquadrat (Beitrag 1117123)

FireMonkey ist definitiv der Nachfolger der VCL. Die VCL wird IMHO in wenigen Jahren das Schicksal von WinForms teilen.

Das glaube ich eigentlich nicht, denn FireMonkey ist kein direkter Ersatz. Es kann viele Sachen viel besser, kann aber dafür andere Sachen nicht, die die VCL kann. Dazu gehört direkter Zugriff auf die Common Controls von Windows.

Gut, das will man oft auch nicht unbedingt, aber in einigen Fällen macht das Sinn. Für die normale Entwicklung unter Windows werde ich auch weiterhin die VCL benutzen. FireMonkey werde ich für Projekte benutzen, die eine schönere / angepasste Oberfläche haben sollen oder die andere Features von FireMonkey nutzen können. Da habe ich auch ein paar Projekte im Sinn.

Und bei FireMonkey darf man auch nicht vergessen, dass die Grafikkarte benutzt wird, die bei vielen älteren Business PCs ein wenig schwachbrüstig sein dürfe.

Zitat:

Zitat von mquadrat (Beitrag 1117133)

Die Frage ist, ob sich Delphi auch in neu aufgesetzten Projekten behaupten kann.

Was uns angeht definitiv ja. ;-)

[mquadrat]

Warten wir ab ;)

Bei uns wird als erstes der Umstieg von Rave auf Fastreport anstehen. Danach der Umbau der Infrastruktur von Selbstgestrickt auf Verwendung von DataBinding und das Entkoppeln von GUI und Geschäftslogik. Danach das Entfernen von sovielen Fremdkomponenten wie möglich. Und dann kommt der Schritt auf FireMonkey, vielleicht in Verbindung mit der Einführung von MVVM.

Außer wir verlieren vorher die Nerven :-D

[Florian Hämmerle]

Die neuen Features eröffnen auch neue "Experten"-Gebiete. Bisher gab es ja die "Experten", die sich mit Delphi allgemein sehr gut auskannten, auf Konferenzen sprachen, etc. Das war alles VCL / Win32. Für neue interessierte, engagierte Programmierer könnte XE2 auch der Beginn einer neuen "Karriere" sein. Plötzlich gibt es jemanden, der auf dem Gebiet FireMonkey anerkannt ist, etc. Bin schon gespannt, wer in 12 Montagen auf Fragen zu den neuen Features die besten Antworten hat :)

[Lemmy]

Zitat:

Zitat von mquadrat (Beitrag 1117133)

Da geht es um die Verkäufe nicht um die Anzahl der Entwickler. Viele auf älteren Versionen dürften zwecks Unicode neue Versionen gekauft haben. Ich sage ja nicht, dass sich mit Delphi kein Geld verdienen lässt. So wie es auch in Zukunft noch haufenweise C++/WinForms Entwickler geben wird, wird es auch Delphi-Entwickler geben. Die Frage ist, ob sich Delphi auch in neu aufgesetzten Projekten behaupten kann.

Und die Anzahl der Verkäufe hat nichts mit der Anzahl der Entwickler zu tun die auf über 2 Mio weltweit geklettert ist? Naja... Und bzgl. neue Projekte: So wie es (für mich) aussieht hat Emba den Punkt erreicht an dem zumindest mit der aktuellen Zahl der Verkäufe eine Weiterentwicklung von Delphi möglich ist und Geld verdient wird - die neuen Projekte kommen dann von alleine. Denn (und hier bin ich sicher) es gibt ausreichend Entwickler, die Delphi immer noch vorziehen...

Grüße

[Florian Hämmerle]

Zitat:

Zitat von mquadrat (Beitrag 1117151)

Entkoppeln von GUI und Geschäftslogik.

Was habt ihr die letzten Jahre da so getrieben? :shock:

[mquadrat]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1117155)

Zitat:

Zitat von mquadrat (Beitrag 1117151)

Entkoppeln von GUI und Geschäftslogik.

Was habt ihr die letzten Jahre da so getrieben? :shock:

Von altem Code nach Möglichkeit die Finger gelassen :D Aber selbst die neueren Sachen müssen geändert werden, da ich langfristig auf MVVM gehen will.

[Florian Hämmerle]

Zitat:

Zitat von mquadrat (Beitrag 1117158)

Zitat:

Zitat von Florian Hämmerle (Beitrag 1117155)

Zitat:

Zitat von mquadrat (Beitrag 1117151)

Entkoppeln von GUI und Geschäftslogik.

Was habt ihr die letzten Jahre da so getrieben? :shock:

Von altem Code nach Möglichkeit die Finger gelassen :D Aber selbst die neueren Sachen müssen geändert werden, da ich langfristig auf MVVM gehen will.

Irgendwann holt es jeden ein. Dann wünsch ich dir da schon mal viel Erfolg und Durchhaltevermögen :)

[mquadrat]

Danke ;) Ich hoffe die Zahl der WTF / Minute wird nicht ganz so hoch ausfallen wie ich befürchte

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1117130)

FireMonkey ist aber was ganz anderes, hier wird nicht versucht die VCL auf Biegen-und-Brechen auf eine andere Plattform zu bringen, sondern bietet eine echte Alternative, die eher mit WPF vergleichbar ist.

War CLX wohl auch ein "Biegen und brechen"-Ansatz? Bei VCL.NET war es das (mit allen Nachteilen).

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1117138)

Dazu gehört direkter Zugriff auf die Common Controls von Windows.

Will man das?

Zitat:

Zitat von jaenicke (Beitrag 1117138)

Und bei FireMonkey darf man auch nicht vergessen, dass die Grafikkarte benutzt wird, die bei vielen älteren Business PCs ein wenig schwachbrüstig sein dürfe.

Und worauf setzt die VCL/WinForms/GDI auf? Auch auf die Grafikkarte. Solange hier FireMonkey sich keine groben Bugs erlaubt ist kein Problem zu erwarten. Wir selbst setzen seit Jahren mit den Elpack-Kompos alternative Kompos ein die nicht auf die Win32-Controls aufsetzen. Einzig die Theming-Engine von Windows wird (wenn man nicht das native Theming der ElPack-Kompos verwendet) zur performance-Steigerung verwendet. Seit 2 Jahren verwenden wir eigens Theming. Hat einiges Optimierungsarbeiten benötigt (Doublebuffering und Co. helfen viel) damit es Problemlos auch auf alten PC läuft.

[mkinzler]

Ja CLX war der Versuch eine Windows-Gui-Plattform auf qt abzubilden. Hätte damals auch halbwegs funktionieren können, hätte man nach dem ersten auch die weitere Schritte unternommen.

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1117167)

Und worauf setzt die VCL/WinForms/GDI auf? Auch auf die Grafikkarte.

Aber nicht hardwarebeschleunigt.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1117167)

Zitat:

Zitat von jaenicke (Beitrag 1117138)

Dazu gehört direkter Zugriff auf die Common Controls von Windows.

Will man das?

Nicht immer, aber manchmal, habe ich doch geschrieben.

[mquadrat]

QT wechselt ja jetzt auch das GUI-Framework, bzw. macht QML zum Standard.

Gibt's für FireMonkey eigentlich auch eine Markup-Language? Würde das automatische Generieren erleichtern.

[Stevie]

Zitat:

Zitat von mquadrat (Beitrag 1117151)

Danach der Umbau der Infrastruktur von Selbstgestrickt auf Verwendung von DataBinding und das Entkoppeln von GUI und Geschäftslogik. Danach das Entfernen von sovielen Fremdkomponenten wie möglich. Und dann kommt der Schritt auf FireMonkey, vielleicht in Verbindung mit der Einführung von MVVM.

Ich bin mal gespannt, wie sehr dieses Bewusstsein in der Delphi Community insgesamt Einzug halten wird. Sprich 1mal Businesslogik implementieren und xmal Oberflächen für verschiedene Plattformen und Anwendungsgebiete und dann zusammen stecken. Insgesamt ein Vorgehen, was viele Vorteile bringt.

[TiGü]

Solange es kein Gegenstück zu MS Expression Blend geben wird, wird FMX hinter den Möglichkeiten von WPF bleiben.
Und sei es allein nur wegen Zeitersparnis beim Designen von Effekten.
Mit der Hand programmiert, wie in diesen einen Video zu sehen, oder in den Struktur-Treeview gezogen und im Objektinspektor editiert ist nicht zeitgemäß.

Worüber ich mich sehr freue, ist die Möglichkeit der VCL-Styles.
Alte Programme kriegen einen frischen Look.
Ich hoffe das wird konsequent und gut umgesetzt.
Auch so, dass das Programm zur Laufzeit von den Benutzer im Aussehen geändert werden kann.
Die Möglichkeit eigene VCL-Styles zu editieren wäre traumhaft.

[Ralf Kaiser]

Zitat:

Zitat von TiGü (Beitrag 1117246)

Die Möglichkeit eigene VCL-Styles zu editieren wäre traumhaft.

Es war irgendwo (bitte frag jetzt nicht wo, ich meine, dass es in einem der Beiträge war die Marco Cantu gebloggt hat) die Rede von einem Style-Editor.

[generic]

Ihr diskutiert hier die ganze Zeit über Oberflächen.
Meint ihr nicht auch das die Zeit von der VCL/FMX/Winforms/WPF vorbei ist?

HTML5/Javascript kann alles und ist Plattform unabhängig.

[Florian Hämmerle]

Zitat:

Zitat von generic (Beitrag 1117267)

Ihr diskutiert hier die ganze Zeit über Oberflächen.
Meint ihr nicht auch das die Zeit von der VCL/FMX/Winforms/WPF vorbei ist?

HTML5/Javascript kann alles und ist Plattform unabhängig.

aber nicht propietär..

[Insider2004]

Ich würde jetzt nicht soviel auf Firemonkey geben! Manche hören sich an, als würde jetzt der Messias kommen. Firemonkey ist noch reine Frickel-Software. Das ist jetzt innerhalb eines halben Jahres zusammengebastelt worden und stammt von einem russischen Projekt. Ich würde jetzt keine Wunder erwarten. Wir können froh sein, wenn einem das Programm nicht alle 10 Sekunden um die Ohren fliegt. Das Ding ist bestimmt 10 Jahre von der VCL-Stabilität entfernt. Von den Funktionen her bestimmt auch. Emba hat leider wiedermal den Fehler gemacht, 2 Frameworks aufzusetzen (anders ging es wahrscheinlich auch gar nicht). Lazarus LCL ist da weit voraus. Das ist von Design her schon Cross implementiert.