KSDev (VGScene, DXScene, ImageFX) von Embarcadero gekauft

[AndreFM]

Ja, mir war es schon bekannt und bin eigentlich ein nicht so glückliche Kunde. Seine Kompos waren schon gut, aber haben immer noch viel Bugs. Jetzt kann ich nur zur Seite legen da nichts mehr davon wird Super füer Eugene die Kohle von viele Kunde in seiner Tasche hat und jetzt kriegt er extra vom Embarcadero....

[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 von 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

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 von 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

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 von mkinzler:

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 von Robotiker:

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 von Robotiker:

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)