CrossVCL tot?

[Uwe Raabe]

Zitat von Bernhard Geyer:

Du meinst nach zweimal Schiffbruch (1. Schiffbruch Kylix, 2. Schiffbruch VCL.NET) könnte es beim dritten mal klappen?
Und dann kann man FMX wieder in die Tonne schmeißen?

Die Tatsache, daß sowohl FMX als auch CrossVCL (und übrigens auch FMXLinux) aus derselben Feder kommen, lässt zumindest Hoffnung aufkeimen.

[mkinzler]

Und auch Turbo Cocoa

[Codehunter]

Zitat von Bernhard Geyer:

Du meinst nach zweimal Schiffbruch (1. Schiffbruch Kylix, 2. Schiffbruch VCL.NET) könnte es beim dritten mal klappen?

Wenn ich es mal anders ausdrücken soll: FMX hat für mich zwei große Nachteile. Das eine ist die arg begrenzte Kompatibilität zu VCL-Komponenten. Man kann bestehende Projekte nur mit großen Mühen portieren. Das zweite ist die geringe Verfügbarkeit komplexer Komponenten wie z.B. Virtual Treeview. Für neue kleine Mobil-Projekte ist FMX nicht verkehrt. Jedoch damit eine große Desktop-Anwendung bauen zu wollen erinnert mich irgendwie an den microsoftschen Versuch, Windows 8 ein gekacheltes Touch-UI zu verpassen. In der Theorie klingts gut, in der Praxis scheiterts jedoch an den Anwendern.

Die CLX an sich war besser als ihr Ruf. Ich hätte sie zwar nicht auf Qt sondern auf GTK aufgebaut, aber sie werden schon ihre Gründe gehabt haben. Die Kylix-IDE dagegen wurde IMHO zu recht verrissen. Wenn ich Wine wollte, hätte ich auch D5 direkt laufen lassen können (das ging tatsächlich!), ebenso die Kompilate.

VCL.NET habe ich nicht genutzt. Ich bin mit .Net allgemein nie warm geworden. Schon zu Spotlight-Zeiten nicht. Zumindest was Delphi betrifft, hatte ich damit recht.

[DieDolly]

Vielleicht war der Kaufpreis auch einfach zu teuer und es gab nicht genug Kunden, um das alles am Laufen zu halten.
Ich finde die Preise waren oder sind jedenfalls übertrieben.

[Codehunter]

Zitat von DieDolly:

Vielleicht war der Kaufpreis auch einfach zu teuer und es gab nicht genug Kunden, um das alles am Laufen zu halten.
Ich finde die Preise waren oder sind jedenfalls übertrieben.

Das ist sicherlich Ansichtssache. Wenn man mit CrossVCL eine bestehende Anwendung mit überschaubarem Aufwand von Win auf Mac bekommt (und die dann auch für den Store zugelassen wird) dann kann sich das schnell rentieren. Für Hobbyprojekte wie in meinem Fall hätte ich vllt. mit Murren noch CrossVCL kaufen wollen, aber ein Enterprise-Delphi mit Sicherheit nicht um für Linux kompilieren zu können. Da nehm ich dann notgedrungen lieber erstmal Lazarus.

[himitsu]

Ich hoffe er baut bei CrossVCL nicht sowas ein, wie im FMX, da ist so einiges sehr besch.. eigenartig.

z.B. bei den buttons kann man einen Style angeben, aber da ist alles doppelt und dreifach drin und extrem unübersichtlich.
Warum nicht zwei eigenschaften für Style-Icon und Button-Style ... ne, da gibt es 80 Mal Pfeil nach links mit dutzenden Varianten wie die Farbe und Ecken aussehn.

[Uwe Raabe]

Zitat von himitsu:

Ich hoffe er baut bei CrossVCL nicht sowas ein, wie im FMX, da ist so einiges sehr besch.. eigenartig.

Was sollte denn in CrossVCL eingebaut werden, was in VCL nicht schon drin ist? Das wäre dann ja nur in CrossVCL nutzbar und konterkariert den gesamten Ansatz einer VCL für andere Plattformen als Windows.

[Stevie]

Zitat von Uwe Raabe:

Zitat von Bernhard Geyer:

Du meinst nach zweimal Schiffbruch (1. Schiffbruch Kylix, 2. Schiffbruch VCL.NET) könnte es beim dritten mal klappen?
Und dann kann man FMX wieder in die Tonne schmeißen?

Die Tatsache, daß sowohl FMX als auch CrossVCL (und übrigens auch FMXLinux) aus derselben Feder kommen, lässt zumindest Hoffnung aufkeimen.

Erinnern wir uns kurz: FMX ist das, was ursprünglich VGScene hieß, irgendwie schon länger ein kommerzielles Produkt von KSDev war, aber nach dem Kauf von Embarcadero über Jahre mit keine Ahnung wie vielen Entwicklern refactored wurd, bis es endlich einigermaßen tauglich war, oder?

[Codehunter]

Zitat von himitsu:

z.B. bei den buttons kann man einen Style angeben, aber da ist alles doppelt und dreifach drin und extrem unübersichtlich.

Das ist einer der Punkte, die auch mir an FMX nicht so gut gefallen. Neben der Tatsache, dass die Namen der Properties und Events mit allen Delphi-Konventionen brechen. Button-Beschriftung heißt "Text" und nicht "Caption", Events beginnen nicht mit "On..." und so weiter.

Zitat von Uwe Raabe:

Was sollte denn in CrossVCL eingebaut werden, was in VCL nicht schon drin ist? Das wäre dann ja nur in CrossVCL nutzbar und konterkariert den gesamten Ansatz einer VCL für andere Plattformen als Windows.

Ganz genau! CrossVCL war/ist ja eigentlich als Backend konstruiert, das regulär erstellte Win32/64-VCL-Anwendungen durch zusätzliche Plattform-Targets für Linux und MacOS verfügbar zu machen.

Zitat von Stevie:

Erinnern wir uns kurz: FMX ist das, was ursprünglich VGScene hieß, irgendwie schon länger ein kommerzielles Produkt von KSDev war, aber nach dem Kauf von Embarcadero über Jahre mit keine Ahnung wie vielen Entwicklern refactored wurd, bis es endlich einigermaßen tauglich war, oder?

Nur vom Refaktorieren wird aber kaum etwas besser. Ich kenne VGScene nicht, daher kann ich mir dazu kein Urteil erlauben. Prinzipiell ist es ja nicht verkehrt, eingetrampelte Pfade auch mal zu verlassen und bestimmte Dinge zu hinterfragen. Die vielen Delphi-(Vor-)Besitzerfirmen brachten jedenfalls kein funktionables Cross-Plattform-UI-Framework zustande, ein Einzelkämpfer dagegen schon. Dass am Ende Feinschliff nötig ist um es praxistauglich zu machen, ist ja nichts ungewöhnliches.

[Rollo62]

Zitat:

dass die Namen der Properties und Events mit allen Delphi-Konventionen brechen

Die paar Unterschiede ...
FMX gibt sich schon sehr viek Mühe VCL kompatibel zu sein, zumindest von dem Framework her.

Man könnte auch sagen das FMX endlich ein bischen konsistentere Bezeichner gewählt hat als VCL.
Das ist nun wirklich das kleinste Problem, und ein Scheinargument.