Delphi XE3?

[Insider2004]

Leider laufen VCLs nicht in FMX. Das Interface ist unnötigerweise völlig inkompatibel.

[MEissing]

Zitat von Insider2004:

Leider laufen VCLs nicht in FMX. Das Interface ist unnötigerweise völlig inkompatibel.

Unnötigerweise?

Die VCL ist seit Delphi 1 nur und ausschliesslich auf Windows optimiert/lauffähig/fixiert.... Versuche von CLX und VCL.Net unterstützen retrospektiv diese Aussage.

Controls, Messages, Events.... das ist durch-und-durch Windows (bei der VCL). Die Notwendigkeit etwas Anderes zu machen, was den normalen Delphientwickler aber dennoch recht schnell produktiv arbeiten lässt (sooo groß ist der Unterschied zwischen VCL und FireMonkey auch nicht. MonkeyGroomer, Mida etc zeigen ja auch, das man es (weitgehend) automatisiert konvertieren kann), gleichzeitig verlangst Du ("so wie QT") aber weitgehende Kompatibilität?

[mkinzler]

Zitat:

Leider laufen VCLs nicht in FMX. Das Interface ist unnötigerweise völlig inkompatibel.

Man soll also nicht MS hinterherlaufen, aber dabei MS weiterhin hinterherlaufen.

Du widersprichst dir selbst. VCL ist nun mal eine Technologie, die währrend ihrer Entwicklung stark mit dem Windowsbetriebssystem verbunden wurde. Diese wieder zu Trennen wäre unnötig kompliziert ( obwohl es für das Scheitern der CLX/VCL.Net auch andere Gründe gab). Ich erhoffe mir ja für FireMonkey eine Mischung der Konzepte von SWT/Qt und VGScene (FMX/I), nähmlich die Integration von nativeb Bestandsteilen wo möglich ( wie in fm2 mobile)

[Insider2004]

Zitat von MEissing:

Zitat von Insider2004:

Leider laufen VCLs nicht in FMX. Das Interface ist unnötigerweise völlig inkompatibel.

Unnötigerweise?

Die VCL ist seit Delphi 1 nur und ausschliesslich auf Windows optimiert/lauffähig/fixiert.... Versuche von CLX und VCL.Net unterstützen retrospektiv diese Aussage.

Controls, Messages, Events.... das ist durch-und-durch Windows (bei der VCL). Die Notwendigkeit etwas Anderes zu machen, was den normalen Delphientwickler aber dennoch recht schnell produktiv arbeiten lässt (sooo groß ist der Unterschied zwischen VCL und FireMonkey auch nicht. MonkeyGroomer, Mida etc zeigen ja auch, das man es (weitgehend) automatisiert konvertieren kann), gleichzeitig verlangst Du ("so wie QT") aber weitgehende Kompatibilität?

Das ist mir alles bekannt. Was ich meine ist, das teilweise OnShow oder OnClick events fehlen bei manchen Komponenten. Es ist unmöglich seinen VCL code da irgendwie zu portieren. Das muss doch nicht sein. Ich hoffe, irgendwer bei EMBA erbarmt sich noch und macht die Interfaces wenigstens gleich zu VCL.

Ein anderes Beispiel ist z.b. dass aus .Caption plötzlich .Text wurde. Man hat nur einen Haufen Arbeit damit.

[jaenicke]

Zitat von Insider2004:

Ein anderes Beispiel ist z.b. dass aus .Caption plötzlich .Text wurde. Man hat nur einen Haufen Arbeit damit.

In den meisten Anwendungen dürfte der GUI-Layer den kleinsten Teil des Codes ausmachen. Und wenn dort dann etwas angepasst werden muss, betrifft dies ja nicht den restlichen Code. Sofern man die GUI nicht zu stark verdrahtet hat.
Und, sorry, aber wer das macht, der ist selbst schuld.

[cookie22]

Das Problem an FMX ist einfach, dass die Programme weder unter Windows noch unter OS X aussehen wie native Programme.

Zweitens weiß man leider, wie schnell hochgelobte Technologienen bei Delphi wieder abgeschossen werden. Das haben wir einfach schon viel zu oft erlebt.

Mit FMX wäre ich mehr als Vorsichtig.

Beruhen die sogenannten Metrostyle Apps von XE 3 auf FMX? Oder wie hab ich mir das vorzustellen?

[jaenicke]

Zitat von cookie22:

Das Problem an FMX ist einfach, dass die Programme weder unter Windows noch unter OS X aussehen wie native Programme.

Das hat Java ja auch nicht wirklich geschadet...
Wobei das bei OS X mit den Designjüngern natürlich schon noch etwas anders ist als bei Linux oder Windows.

[Bernhard Geyer]

Zitat von cookie22:

Das Problem an FMX ist einfach, dass die Programme weder unter Windows noch unter OS X aussehen wie native Programme.

Ist das nicht mittlerweile irrelevant? Vor allem auf Windows ist das doch mittlerweile sch*** egal. Viele erfolgreiche Programme sind deshalb so erfolgreich weil sie sich nicht strikt an (sich alle 2 Jahre ändernde) GUI-Styleguids halten. Mittlerweile brechen doch praktisch 100% alle Webbrowser z.B. dem dem Styleguid bezüglich Menu/TabControl-Layout.

Zitat von cookie22:

Zweitens weiß man leider, wie schnell hochgelobte Technologienen bei Delphi wieder abgeschossen werden. Das haben wir einfach schon viel zu oft erlebt.

Das stimmt leider. CLX/VCL.NET oder generell der Nicht-Oxygen-Pascal-Port.

[bernau]

Zitat von Bernhard Geyer:

Ist das nicht mittlerweile irrelevant? Vor allem auf Windows ist das doch mittlerweile sch*** egal. Viele erfolgreiche Programme sind deshalb so erfolgreich weil sie sich nicht strikt an (sich alle 2 Jahre ändernde) GUI-Styleguids halten. Mittlerweile brechen doch praktisch 100% alle Webbrowser z.B. dem dem Styleguid bezüglich Menu/TabControl-Layout.

Jep. Das sehe ich auch so. Möchte nicht wissen, wie viele Delphi-Entwickler Skin-Komponenten einsetzen, damit die Software "anders" aussieht.

Zu OSX sage ich mir: Lieber ein Programm, welches nicht 100% Native aussieht (mit FMX), als kein Programm. Anderes als Delphi kann und will ich nicht nutzen.

[Insider2004]

Zitat von jaenicke:

Zitat von Insider2004:

Ein anderes Beispiel ist z.b. dass aus .Caption plötzlich .Text wurde. Man hat nur einen Haufen Arbeit damit.

In den meisten Anwendungen dürfte der GUI-Layer den kleinsten Teil des Codes ausmachen. Und wenn dort dann etwas angepasst werden muss, betrifft dies ja nicht den restlichen Code. Sofern man die GUI nicht zu stark verdrahtet hat.
Und, sorry, aber wer das macht, der ist selbst schuld.

Das ganze Delphi-Konzept beruht darauf, dass GUI und Code stark verdrahtet sind. Deine Betrachtung ist rein theoretisch und mit Delphi nicht zu vereinbaren. Das geht vielleicht in der MFC von MS.