KSDev (VGScene, DXScene, ImageFX) von Embarcadero gekauft

[Florian Hämmerle]

Was ich mich frage: Für was braucht Emba diese Komponenten, wenn sie doch eh früher oder später ne ganze GUI crossplatform machen müssen. hätten sie gleich ihre eigenen nehmen können, anstatt fremde zu nehmen :S

mfg Florian

[Bernhard Geyer]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1079938)

Was ich mich frage: Für was braucht Emba diese Komponenten, wenn sie doch eh früher oder später ne ganze GUI crossplatform machen müssen. hätten sie gleich ihre eigenen nehmen können, anstatt fremde zu nehmen :S

Vieleicht ist der Komponentenkauf eine Art Antrittsprämie bei Embaracadero. Und wenn er auch keinen Support mehr leisten muss (darf?) kann er sich zu 100% auf den neuen Job konzentrieren.

Ist jedoch schade für die Anwender. Die Lizenzkosten werden verglichen mit den internen Kosten der Umstellung/Integration auf dieses Framework vernachlässigbar sein.

[Insider2004]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1079938)

Was ich mich frage: Für was braucht Emba diese Komponenten, wenn sie doch eh früher oder später ne ganze GUI crossplatform machen müssen. hätten sie gleich ihre eigenen nehmen können, anstatt fremde zu nehmen :S

mfg Florian

Allen Bauer hat gesagt, die VCL ist total Windows-lastig. Daraus eine Cross-VCL zu schnitzen ist aussichtslos. Deshalb wird jetzt eine neue Cross-VCL gebastelt. Da sie nichts hatten und seit Jahren diesen Trend verschlafen haben, wurde jetzt einfach auf Einkaustour gegangen. Ob das ganze Ding später so gut wird, die Win-VCL abzulösen, wird sich zeigen. Wohl eher nicht. Meine Befürchtung ist, dass die Win-VCL und die Cross-VCL unterschiedlich reagieren und aussehen werden und der Programmierer wieder die ganze Arbeit hat (ifdefs etc).

[mkinzler]

Man hätte das damals bei der CLX richtig durchziehen sollen.

[Robotiker]

Zitat:

Zitat von mkinzler (Beitrag 1079977)

Man hätte das damals bei der CLX richtig durchziehen sollen.

Die CLX baute auf Qt, dessen Hersteller damals noch eine kleine Firma war.

Heute gehört es zu Nokia, die wiederum bei mobilen Anwendendungen mit Intel kooperieren. Deren C++ Compiler steht zumindest indirekt unter Linux und Windows in Konkurrenz zum C++ Builder. Dann sind da noch die Gerüchte in den letzten Wochen über eine Annäherung von MS und Nokia, deren Chef ja von Microsoft kommt.

Sind also nicht die besten Voraussetzungen, um darauf ein neues Framework hochzuziehen.

An WxWidgets hat man sich schon beim C++ BuilderX die Finger verbrannt. Technisch ist das sowieso eher eine portable MFC, nichts für VCL-Entwickler.

So betrachtet bleibt im nativen Bereich doch nicht viel übrig, als das sie selber etwas entwickeln.

[Bernhard Geyer]

Zitat:

Zitat von Robotiker (Beitrag 1079985)

Die CLX baute auf Qt, dessen Hersteller damals noch eine kleine Firma war.

Heute gehört es zu Nokia, die wiederum bei mobilen Anwendendungen mit Intel kooperieren. Deren C++ Compiler steht zumindest indirekt unter Linux und Windows in Konkurrenz zum C++ Builder.

Ich denke das aktuelle Problem mit Nokia ist das überhaupt nicht klar ist was mit irgendwelchen Betriebssystemen/Tool/Compilerern sein wird. Es kann schon sein das Morgen neben Symbian auch MeeGo abgekündigt wird und auf Android und/oder WP7 gesetzt wird. Dazu ist dann kein QT mehr nötig so das man die entsprechende Abteilungen auch gleich zum Monatsende kündigen kann.

Zitat:

Zitat von Robotiker (Beitrag 1079985)

So betrachtet bleibt im nativen Bereich doch nicht viel übrig, als das sie selber etwas entwickeln.

Die Frage ist aber ob genügend Manpower/Durchhaltevermögen vorhanden ist um das konsequent und stabil durchzuziehen. Zwar vermutlich mehr als bei Borland, aber ob das für MacOS/Linux/Android/WP7/WebOS/BlackBerry/Bada/MeeGo-Support reicht ...

[mkinzler]

Wobei das Problem bei CLX imho nicht an Qt lag, sondern der Tatsache, dass man nur das implemnetiert hat, was direkt abbildbar war. Und den Rest auf Folgeversionen verschoben hat ( was trotz 3 Version von Kylix nie der Fall war).
Spätestens bei der Umstellung auf .Net hätte man das das Fortsetzen sollen ( anstatt auf die Win32-lastige INVOKE Variante zu setzen)

[Insider2004]

Die Manager bei Borland waren damals heilfroh, dass dann plötzlich .net kam und das ungeliebte CLX-Qt-Linux vom Tisch war. Diesen Aufwand wollte man nicht spendieren. Die dachten alle, super, jetzt gehen wir aufs .net-framework und brauchen nichts mehr investieren. Dass dann .net den Bach runterging ist zum Totlachen.

[mquadrat]

Also irgendwie ist das ja unklug von Emba. Ich hätte ja zumindest das Bug-Fixing nebenher laufen lassen (x Stunden / Woche) und dann einen kostenpflichtigen Konverter von den Komponenten auf das kommende Emba Framework angeboten. Oder den Konverter als Feature der Enterprise. So schneidet man den Migrationspfad ab und vergrault die Personen / Firmen / Projekte, die eigentlich die idealen Testkandidaten gewesen wären.

Vorausgesetzt die Komponenten waren tatsächlich gut durchdacht (kenne sie persönlich nicht). Wenn es nur um den Entwickler ging, dann macht es natürlich Sinn, damit man kein konkurierendes Framework im Weg hat. Die Cross-Platform GUI muss ja schon mitten in der Entwicklung sein. Wäre sonst ein sehr sportlicher Zeitplan :-)

Aber irgendwie bin ich skeptisch. Neue Compiler, neues GUI-Framework (das damit übrigens die Hoffnung auf eine VCL 2 zerschmettert) evtl. mit neuen Sprachfeatures um MVVM sinnvoll umsetzen zu können. Da muten sie sich ganz schön viel zu.

[Memnarch]

Wieso werde ich das Gefühl nicht los, dass alle Berufsflamer mit dem erstem release vom 64bit compiler + neuer VCL ersatz genügend futter finden werden :twisted:.

@MQuadrat: Ich bin einfach mal gespannt was da für ne suppe gekocht wird o.O. Natürlich wird davon nichts von anfang an 100% funktionieren, die frage ist eher: Wie tüchtig wird man sein, diese Fehler zu beseitigen :)


MFG
Memnarch