FDT versus FlashDevelop

[Martin Kraft]

Ich bin wahrhaftig kein Fan von .net - aber im Fall von FlashDevelop macht es sich überaus positiv bemerkbar, dass insbesondere die GUI auf nativen Windowstechnologien aufsetzt:

Die Funktionen der Nutzeroberfläche (Panelverwaltung, Menus, Tabs etc.) sind absolut ausgereift. Ruckler, Hänger, Grafikfehler oder gar GUI-Abstürze, wie ich sie bei anderen Crossplattformentwicklungen erlebt habe, sind mir in FD bisher noch nicht begegnet.

Die Integration in .net ermöglicht es zudem, die eigentliche Anwendung ziemlich schlank und performant zu halten. Der FlashDevelop-Installer ist nicht mal 10 MB groß, während z.B. Eclipse gut das 10fache auf die Wage bringt. Zur Laufzeit ist der Unterschied im Ressourcenverbauch nicht mehr ganz so eklatant, aber immer noch deutlich spürbar.

[Nico B.]

Was ich nur nicht verstehe ist, wieso der Flashbuilder (funktionsmäßig) Flashdevelop so dermaßen hinterherhinkt bzw. es erst langsam kompensieren kann...

Das eine ist kostenlos, dass andere kostet eine gute Stange Geld... Das trifft bei mir nur auf Unverständnis. (Vor allem da der Builder jetzt auch nicht erst 2 Wochen alt ist)

[Omega Psi]

Ich glaube es hindert niemand ambitionierte Entwickler bei den Jungs mitzumischen und einen COCOA oder GTK Port zu implementieren... ran an die Tasten!

[echo5-7]

Zitat von _kweso

wofür würde man denn den multiinstanz-mode benutzen? um in mehreren projekten gleichzeitig arbeiten zu können? oder hat das noch einen anderen grund?

du arbeitest an einem projekt, kunde ruft an, sagt er will schnell dieses und jenes, oder irgendwas geht nicht. da ist es doch praktisch einfach ein anderes fenster aufzumachen. oder du warstest auf feedback während du an einem anderen projekt arbeitest.

[_geo_]

Bezügl. Probleme mei mehreren Entwicklern: Ich hatte mal ein FD Projekt das ein 2ter mit FDT mitentwickelt hat. Da sind dann die Projekkofigurationen irgendwie durcheinander geraten und wir mussten das dann per Hand lösen. Frag mich aber nimmer was genau, is mindestens über n Jahr her. Seither hatte ich kein FD Projekt mehr mit mehreren Entwicklern.

Bei mehreren Leuten mit Flashdevelop gabs auch mal Probleme dass man die Projekte nicht kopieren konnte weil die Pfade teilweise absolut waren, weiß aber nicht ob das heute noch genauso ist.

lg

[Omega Psi]

Das ist der Grund, warum man keine Projektkonfigurationen ins SCM eincheckt.

[_geo_]

Wenn halt alle ALLES einchecken hilft das auch nur wenig wenns einer nicht macht :-/

Würd mich sowieso mal interessieren wie machtst du/ihr das. Ich hab nun immer die pers. config files etc. auf ignore (und das auch bei allen die drann mitarbeiten), für die config files gibts dann ein "Template" an dem jeder was ändern kann. Gibts ein update am Config Template muss man die Änderung selbst in seine pers. config nachziehen.

Was das Problem beim FD mit FDT war, dass wir dachten wir könnten die mit einchecken weil es ja unterschiedliche IDEs sind ... ging dann aber trotzdem nicht.

lg

[Omega Psi]

Ich würde gar keine IDE spezifischen Konfigurationen einchecken. Das einzige was man einchecken sollte sind Source- und Build Dateien sowie Libraries, wenn man keine Repository beseitzt. Alles andere erzeugt mehr Arbeit, als man möchte. Ein Projekt über existierende Sourcen zu stülpen, die einigermaßen sauber strukturiert sind, kostet i.d.R. weniger Zeit, als schiefe Konfigurationsdateien zu pflegen. Das heisst, man kann getrost alles auf ignore setzen

[_geo_]

danke, ab sofort gibts was mit der Keule wenn wieder einer IDE Daten einchecken will

[Omega Psi]

Das ist halt meine Präferenz. Ich kenne genug Projekte, wo es anders läuft. ... und bei allen war das eine der Senken für Produktivität.