KSDev (VGScene, DXScene, ImageFX) von Embarcadero gekauft

[mjustin]

Wie auf der Webseite von KSDev (http://www.ksdev.com/) zu lesen ist, hat Embarcadero die Rechte an den KSDev Produkten gekauft, die Weiterentwicklung der Produkte wird eingestellt zugunsten der Entwicklung eines neuen Anwendungsentwicklungs-Frameworks:

Zitat:

While at Embarcadero we are not bringing VGScene, DXScene, or ImageFX code forward. I am working on a very exciting next generation App Development project that will go beyond what the KSDev products were providing. It is safe to say that similar functionality of these frameworks will be made available in future Embarcadero development products. I believe it will be well worth the wait.

Für das neue Framework ist ein Betatest geplant, Interessenten können sich laut Angaben auf der Webseite per Mail anmelden.

[mkinzler]

Siehe auch http://www.delphipraxis.net/1079817-post20.html
Die Frage ist, was mit den Kunden passiert, welche lebenslangen Support gekauft haben.

[Sir Rufo]

Dabei kommt es wohl auf die vertraglich festgelegte Definition von "lebenslang".

Weil insofern undefiniert ist, auf wessen Leben das bezogen ist.

Unternehmen, Produkt, Lizenznehmer, Zivilisation, Planet?

[mkinzler]

Es wird schon das Produkt gemeint gewesen sein, und dessen Ende ist der 13.01.2011.
Wer das Angebot von ksdev angenommen hat, wird jetzt nicht gerade happy sein

[Sir Rufo]

Das kann ich mir gut vorstellen, allerdings haben sich einige wohl von dem Begriff "lebenslanger Support" blenden lassen.

Beim nächsten Mal also eine vertraglich zugesicherte Dauer in konkreten Zeitangaben, zugesicherter Response- und Fixtime, sowie Konventionalstrafen bei Nichterfüllung.

Geht der Anbieter pleite steht man allerdings genauso dumm daher.

man kann so etwas also nie verhindern, nur ein wenig erschweren.

[Insider2004]

Hab mir die Komponenten gerade angeschaut. Kann mir irgendwie nicht vorstellen, wie daraus ein Qt-Ersatz werden kann. Aber Emba wird schon wissen, was es will. Von mir aus können die jetzt soviel probieren und forschen wie sie wollen, solange die VCL für Win32 nicht kaputtentwickelt wird.

hier gibts eine Beschreibung (nicht mehr über die Homepage erreichbar):
http://www.ksdev.com/vgscene/index.html
die vorkompilierten Demos sind ganz informativ:
http://www.ksdev.com/download.html

[mkinzler]

VGScene gibt es auch für Linux.

[Insider2004]

Komischerweise habe ich von dem Zeugs noch nie vorher etwas gehört??? Sind euch die KSDev bekannt? Wie kommt Emba auf diese Komponenten jetzt plötzlich?

[mkinzler]

Waren eigentlich bekannt.
VGScene ist ja auch sehr weit entwickelt und sieht gut aus; nur der Entwurf einer Oberfläche damit ist etwas hakelig.

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

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

[Lemmy]

Zitat:

Zitat von Insider2004 (Beitrag 1080052)

Die Manager bei Borland waren damals heilfroh, dass dann plötzlich .net kam und das ungeliebte CLX-Qt-Linux vom Tisch war.

das habe ich anders in Erinnerung...

Und dass in der 64Bit nicht alles so rosig laufen wird klar, und dass es genügen Nörgler aus allen mglichen dunklen Ecken treiben wird ist so sicher wie das Amen in der Kirche.

Grüße

[hanspeter]

Glücklicher Weise neu begonnenes Projekt mit ImageFx gerade noch rechtzeitig gestoppt.
Hier ist die Entscheidung gefallen und das Projekt wird auf .Net aufgesetzt.
Ob das gut geht?
Anbieter teuerer Komponenten verschwinden urplötzlich und ersatzlos vom Markt.
Für die Richtung und Zukunft der Delphi Entwicklung läßt sich da einiges ahnen.
Wenn ich dann bei XE2,3 oder 4 vor der Frage stehe:
Portiere ich mein VCL-Win32 Delphi-Programm nach XE... oder nach Net und der Aufwand ist etwa gleich hoch, wie entscheide ich mich dann?

Gruß Peter

[mquadrat]

Ich gehe davon aus, dass die W32 VCL auch weiterhin angeboten wird. MFC gab es ja nach Einführung von WPF auch noch. Das wichtigste an XE2 wird sein, dass alles was auch schon in XE ging immer noch geht :-) Und da bin ich eigentlich zuversichtlich.

Auf jeden Fall muss ein Statement von Emba her, ob die VCL in der jetzigen Form bestehen bleibt oder ob sie komplett abgelöst wird. Außerdem eine grobe Vorschau auf das, was denn dann jetzt kommt. Als Entwickler muss man ja schon ein bisschen voraus planen ;) Natürlich sollten sie nichts erzählen, von dem sie nicht überzeugt sind, dass sie es hinbekommen, aber das Problem, das ich aktuell sehe ist dass die Gerüchteküche brodelt. Und da ist eine extreme Streuung drin. Das verbreitet einen haufen Unruhe. Keiner (kaum einer) weiß was aber alle reden mit (mich eingeschlossen :D ).

So und nun wieder zurück an die Arbeit. Für's tratschen wird ja wahrscheinlich keiner von uns bezahlt.

[QuickAndDirty]

zunächst mal...ich finde es gut das sie den Mann Eingekauft haben und nicht wieder so einen Scheiß machen wie die Komponenten der nächsten Version beizulegen... Ich kann auf Komponenten die dann in der übernächsten Version weg sind verzichten!

Die machen das genau richtig, in dem Sie alles selbst entwickeln und zur Not Köpfe die das tun einkaufen. Je weniger wackelige Abhängigkeiten zu dritten diese IDE hat desto besser!
Egal was mit QT, .NET, WinAPi, GTK+,GTK+Cairo, WX, EFF , VGScene passiert...deren eigene XVCL wird denen keiner unterm Hintern wegziehen können. Aus meiner Sicht ist das langfristig richtig gedacht.

UND Ich hoffe das Layout Manager von vorne rein wie bei VGscene, dabei sein werden...

[papajong]

KSDev wird wohl von Embarcadero weiterentwickelt!
http://www.ksdev.com/forums/viewtopic.php?f=3&t=987

[AndreFM]

Endlich mal Licht am Ende des Tunnels :-)