Von M wie Meikel am Fr, 9. Februar 2007 um 10:13 #
> Ich wundere mich ja immer noch, dass Sun damals nicht Tk aus GUI-API in Java eingebaut hat, sondern das (alte) AWT, das ja einige Zeit danach schon durch Swing ersetzt werden musste, programmiert hat.
Hmm, mag ja sein, dass Tk ein paar interessante Konzepte unter der Haube hatte, aber es ist in meiner Erinnerung weder besonders mächtig gewesen und definitiv ziemlich häßlich. Auch war der Port nach Perl lange Zeit ein ziemlicher Krampf. Das hat IMHO schon einige selbstgemachte Gründe, dass Tk nicht über längere Zeit erfolgreich geworden ist.
Dass mit Java 1.2 dann Swing kam, hat wohl weniger mit den technischen Möglichkeiten von AWT zu tun gehabt, sondern wohl eher politische Gründe. Da gibt es Geschichten, dass ehemalige Smalltalk-Entwickler bei Sun sich mit ihrer Idee durchgesetzt haben, dass man plattformabhängigke GUIs nicht direkt auf den Plattformwidgets aufsetzen sollte. Wer weiß, wie ein ständig aktualisiertes AWT heute aussehen würde.
Und dass Dritte so etwas wie SWT, Cocoa-, Qt- oder GTK-Bindings entwickeln, liegt ja nicht an Sun. Swing ist der gesetzte Favorit und da scheint sich in absehbarer Zeit auch nichts dran zu ändern.
Tk war nie für grosse Applikationen gedacht, es war dazu dazu Scripte mit ner simplen GUI (Konfig-Auswahldialoge,... ) zu verheiraten. Der Krampf mit Tk geht schon los wenn man die einzelenen Komponenten auffhübschen oder erweitern will, da wird der einst kompakte Code schnell unübsichtlich und auch zunehmend sperriger, da merkt man dann was in Tk alles fehlt. Deshalb gab es schnell zig inoffizielle Erweiterungen.
Sun tat gut daran sich von Tk fern zu halten oder man hätte ne Entwicklertruppe dafür abgestellt die das nochmal komplett überarbeitet. Tk ist über all die Jahre auch deshalb nicht grossartig weiterentwickelt worden weil die Leute fehlen, kein Vergleich zu dem was Sun an Personal an Swing abbestellte, obwohl da auch vieles schnell zusammengebastelt wurde. Im Java Developers Journal gab es eine Umfrage an die Entwickler von Java (Gosling, einige die mit der Swingentwicklung zu tun hatten,...) was sie an Swing anders machen würden wenn sie es nochmal komplett neu entwickeln könnten. Interessant bei den Antworten ist, dass vieles was damals als Vorteil von Swing heute von den Swingvätern eher als Nachteil gesehen wird, gleichzeitig aber die Fanboys immer noch diese "Vorteile" von Swing propagieren.
Dass mit Java 1.2 dann Swing kam, hat wohl weniger mit den technischen Möglichkeiten von AWT zu tun gehabt, sondern wohl eher politische Gründe. Da gibt es Geschichten, dass ehemalige Smalltalk-Entwickler bei Sun sich mit ihrer Idee durchgesetzt haben, dass man plattformabhängigke GUIs nicht direkt auf den Plattformwidgets aufsetzen sollte. Wer weiß, wie ein ständig aktualisiertes AWT heute aussehen würde.
AWT kann und konnte früher bestimmte Dinge nicht. So warend und sind Icons in Buttons nicht möglich. Das liegt dadran, daß AWT nur das anbietet, was das jeweilige Betriebssystem auch native kann. Um sich stärker von der Abhängigkeit der Plattform zu lösen, hatte Netscape früher die Internet Foundation Classes (IFC) erstellt. Sun fand die Idee prima und hatte dann zusammen mit Netscape Swing entwicklet.
Und AWT und Swing sind nun mal die beiden Extreme unter Java. AWT besteht nur aus nativem Look and Feel. Swing hingegen besteht (wenn es das MetalLookAndFeel ist) nur aus plattformunabhägigem Look and Feel. Und die plattformanhängigen LAFs wurden nur wegen des Erfolgs fon SWT nachgeschoben.
Hmm, mag ja sein, dass Tk ein paar interessante Konzepte unter der Haube hatte, aber es ist in meiner Erinnerung weder besonders mächtig gewesen und definitiv ziemlich häßlich. Auch war der Port nach Perl lange Zeit ein ziemlicher Krampf. Das hat IMHO schon einige selbstgemachte Gründe, dass Tk nicht über längere Zeit erfolgreich geworden ist.
Dass mit Java 1.2 dann Swing kam, hat wohl weniger mit den technischen Möglichkeiten von AWT zu tun gehabt, sondern wohl eher politische Gründe. Da gibt es Geschichten, dass ehemalige Smalltalk-Entwickler bei Sun sich mit ihrer Idee durchgesetzt haben, dass man plattformabhängigke GUIs nicht direkt auf den Plattformwidgets aufsetzen sollte. Wer weiß, wie ein ständig aktualisiertes AWT heute aussehen würde.
Und dass Dritte so etwas wie SWT, Cocoa-, Qt- oder GTK-Bindings entwickeln, liegt ja nicht an Sun. Swing ist der gesetzte Favorit und da scheint sich in absehbarer Zeit auch nichts dran zu ändern.
es war dazu dazu Scripte mit ner simplen GUI (Konfig-Auswahldialoge,... ) zu verheiraten.
Der Krampf mit Tk geht schon los wenn man die einzelenen Komponenten auffhübschen oder erweitern will,
da wird der einst kompakte Code schnell unübsichtlich und auch zunehmend sperriger, da merkt man dann
was in Tk alles fehlt. Deshalb gab es schnell zig inoffizielle Erweiterungen.
Sun tat gut daran sich von Tk fern zu halten oder man hätte ne Entwicklertruppe dafür abgestellt die das
nochmal komplett überarbeitet. Tk ist über all die Jahre auch deshalb nicht grossartig weiterentwickelt worden weil die Leute fehlen, kein Vergleich zu dem was Sun an Personal an Swing abbestellte, obwohl da auch vieles schnell zusammengebastelt wurde.
Im Java Developers Journal gab es eine Umfrage an die Entwickler von Java (Gosling, einige die mit der Swingentwicklung zu tun hatten,...) was sie an Swing anders machen würden wenn sie es nochmal komplett neu entwickeln könnten.
Interessant bei den Antworten ist, dass vieles was damals als Vorteil von Swing heute von den Swingvätern eher als Nachteil gesehen wird, gleichzeitig aber die Fanboys immer noch diese "Vorteile" von Swing propagieren.
AWT kann und konnte früher bestimmte Dinge nicht.
So warend und sind Icons in Buttons nicht möglich. Das liegt dadran, daß AWT nur das anbietet, was das jeweilige Betriebssystem auch native kann.
Um sich stärker von der Abhängigkeit der Plattform zu lösen, hatte Netscape früher die Internet Foundation Classes (IFC) erstellt. Sun fand die Idee prima und hatte dann zusammen mit Netscape Swing entwicklet.
Und AWT und Swing sind nun mal die beiden Extreme unter Java.
AWT besteht nur aus nativem Look and Feel.
Swing hingegen besteht (wenn es das MetalLookAndFeel ist) nur aus plattformunabhägigem Look and Feel. Und die plattformanhängigen LAFs wurden nur wegen des Erfolgs fon SWT nachgeschoben.