ich finde Eclipse echt gut! Der Funktionsumfang ist enorm und es gibt mittlerweile allerlei Plugins für andere Programmiersprachen, als Java.
Mein einziges Problem mit Eclipse ist aber immer noch die Performance. Dabei meine ich nicht speziell die Startzeiten, oder den Speicherverbrauch. Mein Problem ist, dass Eclipse ganz leicht beim Tippen hinterherhängt. Ich persönlich möchte, dass das Programm, in dem ich schreibe wirklich genau dann reagiert, wenn ich tippe und nicht einige Millisekunden später. Es ist wirklich nur leicht verzögert, aber das nervt mich, wenn ich damit arbeiten möchte. Es ist halt nicht so schnell, wie z.B. das Tippen in Kate, oder Gedit. Solange das nicht der Fall ist, ist es für mich nutzlos.
Hat jemand eine Idee, wann sich das ändern soll? Ich habe bereits 1,4 GHz und 512 MB Ram. Das sollte doch reichen für sowas :)
danke für den Tipp! Ich habe in den Einstellungen einen Punkt "QuickDiff" gefunden. Weiß noch nicht genau, wofür der ist. Der scheint wohl irgendwie während ich Tippe bereits die Syntax zu prüfen. Ich habe den Punkt nun deaktiviert und siehe da: Es ist schon ne Ecke schneller!
mmh.. und was kann das Teil, was Netbeans nicht kann? (sorry - fand die Seite was unübersichtlich um ordentlich Features vergleichen zu können - aber vielleicht kennst du sie ja?) thx & cya
Von Kai F. Lahmann am Mi, 29. Juni 2005 um 15:36 #
muss ich dir widersprechen. Die CPU ist Eclipse extrem egal. Selbst ein K6-2/500 oder ein auf 600MHz gedrosselter Pentium M reichen, solange genug RAM da ist!
Also mit dem Bittorrent Protokol. Das würde solche Engpässe vermeiden und ihnen einiges an Bandbreite sparen. Da Azureus auch Java ist sollte sich das doch integrieren lassen.
Auf Yoxos kann das ganze auch runtergeladen werden: http://www.yoxos.com/yoxos/doc/bs37/ oder direkt http://yoxos-update.com/eclipse/eclipse-SDK-3.1-win32.zip
weiß jemand von Euch wo man das Language Pack für Deutsch runterladen kann? Die haben ja immer noch nicht gelernt als Basissprache auf Deutsch umzustellen... :(
Und überhaupt: Gibt es mitterlerweile Bestrebungen die IDE auf eine vernünftige Basis wie SWING umzustellen? Gibt es da irgendwo ein Projekt?
> Und überhaupt: Gibt es mitterlerweile Bestrebungen > die IDE auf eine vernünftige Basis wie SWING > umzustellen? Gibt es da irgendwo ein Projekt?
Oh mein Gott, das wird hoffentlich nie passieren. SWT ist ja schon nicht so toll, aber Swing ist unterirdisch. (ich spreche aus der User-Perspektive, nicht über APIs) Die Widgets sind hässlich, die Usability ist schrecklich... Dann lieber SWT.
> Die Widgets sind hässlich, die Usability ist schrecklich... Dann lieber SWT. Wieso sollte Swing hässlich sein, SWT aber nicht? Beide verwenden Gtk+, wenn sie es vorfinden. Wer Motif wählt, braucht sich nicht zu wundern.
Falsch Swing verwendet eine GTK ähnliche Theme.. und SWT GTK direkt.. was ein großer Unterschied ist. Swing wird nicht deine Theme komplett verwenden sondern bestenfalls eine kaputte Kopie davon, wohingegen SWT deine Desktoptheme annimmt, da es seine Widgets direkt von GTK zeichen lässt.
Mal davon abgesehen ist Swing träger und langsamer als SWT
> wohingegen SWT deine Desktoptheme annimmt, da es seine Widgets direkt von GTK zeichen lässt. Du willst doch nicht behaupten, dass Eclipse wirklich nach Gtk+ aussieht. Nautilus z.B. sieht komplett anders aus. Eclipse übernimmt also praktisch gar nichts.
Es wäre evtl. nützlich wenn du mir erzählen würdest was du unter "wie gtk aussieht" verstehst.. SWT verwendet GTK wo es geht und wo es nicht geht hat es eigene GTK Widgets entworfen, das ist aber auch ganz klar da SWT das kleinste Gemeinsame Vielfache von einer Handvoll Widgets APIs bedienen muss.
Trotzdem IST SWT unter Linux GTK/Motif nativ und Swing ist nur eine Theme, so wie eine Pixmap theme unter GTK.. einfach nur Grafiken.
Gruß Waldgeist PS: Jetzt kommt es drauf an ob du den Unterschied zwischen Aussehen und Technik kennst.. ich weiss ja nicht ob du Programmierer bist, oder ein Anwender der nach dem Aussehen urteilt.
> Es wäre evtl. nützlich wenn du mir erzählen würdest was du unter "wie gtk aussieht" verstehst.. Dass für die Schaltflächen etc. die jeweiligen Gtk+-Widgets genutzt werden. Dass der GtkFileChooser bzw. der GtkFileSelector genutzt wird. Dass die Symbolleiste sich genauso wie die von anderen Gtk+-Anwendungen verhält. ...
> SWT verwendet GTK wo es geht und wo es nicht geht hat es eigene GTK Widgets entworfen, das ist aber auch ganz klar da SWT das kleinste Gemeinsame Vielfache von einer Handvoll Widgets APIs bedienen muss. Ja eben, Eclipse verwendet zum großen Teil eigene "Gtk-Widgets".
> ich weiss ja nicht ob du Programmierer bist, oder ein Anwender der nach dem Aussehen urteilt. Programmierer, allerdings habe ich mir den Source von Swing noch nie angeschaut. Keine Lust, mich bei Sun zu registrieren.
> Unter MacOSX sieht Eclipse auch nicht völlig richtig aus, da es einer anderen Designfamilie abstammt (eher Windows). Zumindest in dem Punkt sind wir uns einig. :-) Eigentlich sieht Eclipse nirgendwo richtig aus.
Genauso ist es aber. Eclipse nutzt noch ein paar eigene Zeichnungen, grundsätzlich aber das SWT. Schau mal auf die Farben und die Menüs. Ausserdem kannst du wohl kaum Nautilus mit einer IDE vergleichen. Swing sieht imho unter GTK sehr schlecht aus, wenn ich mir SWT dagegen ansehe. Unter Windows gehts mit Swing einigermassen, aber die Performance ist schon nicht optimal. Wenn du ein Java-Programm entwickelst, das in andere VB oder C# Projekte (jaja ich weiss, aber hab das selber schon erfahren müssen) eingegliedert werden soll und niemand einen Unterschied von aussen merken soll, dann kommst du wohl kaum um SWT herum.
Von Martin Röhricht am Mi, 29. Juni 2005 um 14:57 #
> Du willst doch nicht behaupten, dass Eclipse wirklich nach Gtk+ aussieht. > Nautilus z.B. sieht komplett anders aus. Eclipse übernimmt also praktisch > gar nichts
Das stimmt doch überhaupt nicht. Natürlich arbeitet Eclipse unter Linux mit dem GTK, wenn Du die entsprechende Version (und nicht Motif) geladen hast. Informiere Dich doch mal vorher genauer. Eclipse hat schlicht und ergreifend noch einige eigene Widgets entworfen, was man als Nutzer des SWTs übrigens auch tun kann. Bitte bitte lies mal ein bißchen was über das SWT, bevor Du hier solche Sprüche abziehst.
> Natürlich arbeitet Eclipse unter Linux mit dem GTK, wenn Du die entsprechende Version (und nicht Motif) geladen hast. Hab ich was anderes behauptet?
> Eclipse hat schlicht und ergreifend noch einige eigene Widgets entworfen, was man als Nutzer des SWTs übrigens auch tun kann. Genau darauf will ich doch hinaus. Guck dir nur mal die Registerkarten an, die unter keinem OS nativ aussehen, weil Eclipse da eben was eigenes nutzt. Das hat natürlich den Vorteil, dass sich die Oberfläche beim Wechsel von Windows auf Linux kaum ändert.
Vergleich doch mal die Tabs: http://actsofvolition.com/images/screenshots/clearlooks/clearlooks-scroll2.png http://blog.fubar.dk/archives/100-percent-native-eclipse-2.png In beiden Fällen wird das Gtk+-Theme "Clearlooks" genutzt.
Mit Swing sieht es natürlich wesentlich düsterer aus, weil es überhaupt nur mit 2 Gtk+-Engines umgehen kann, nämlich den beiden, die in der Java Runtime implementiert sind: pixmap und bluecurve. SWT dagegen kann auf alle Engines zurückgreifen, da es die native Implementation der Gtk+-Bibliothek nutzt.
Von Martin Röhricht am Mi, 29. Juni 2005 um 08:17 #
> Und überhaupt: Gibt es mitterlerweile Bestrebungen die IDE auf eine > vernünftige Basis wie SWING umzustellen? Gibt es da irgendwo ein Projekt?
Nein, da gibt es kein Projekt und das wird es auch nie geben. SWT wurde genau wegen Eclipse entwickelt und das ist auch gut so, denn AWT bietet zu wenig Möglichkeiten und Swing ist nicht nur langsamer, sondern bietet auch kein natives Look & Feel des GUI. SWT ist schon sehr genial und wie Du auf die Idee kommst es biete keine vernünftige Basis bedarf wohl einer genaueren Erläuterung.
Genau das ist es. Technik muß verstanden werden. SWING ist überall gleich. SWT ist nicht in der offiziellen Java-VM von Sun und somit vollständig unbrauchbar. Mann sieht es ja schon bei der nötigen Installation. Ein SWING-basiertes Eclipse könnte aus einem jar-File auf allen Plattformen gestartet und genutzt werden. Aber Eurer "Verständis" sehe ich ja... Ihr labert hier nur Nonsens über Look & Feel das ohnehin niemanden interessiert.
Von Martin Röhricht am Mi, 29. Juni 2005 um 15:05 #
> SWING ist überall gleich. SWT ist nicht in der offiziellen Java-VM von Sun > und somit vollständig unbrauchbar. Mann sieht es ja schon bei der nötigen > Installation. Ein SWING-basiertes Eclipse könnte aus einem jar-File auf allen > Plattformen gestartet und genutzt werden.
Warum soll SWT unbrauchbar sein, nur weil es nicht in der Java-VM von Sun ist? Du benötigst nur die entsprechende SWT-Bibliothek und fertig -- Eclipse läuft hier auch ohne irgendeine Installationsorgie unter Windows, Linux und MacOS X und ist mit SWT entwickelt.
> Aber Eurer "Verständis" sehe ich ja... Ihr labert hier nur Nonsens über Look > & Feel das ohnehin niemanden interessiert.
Den Nonsens erzählst Du gerade hier. Natürlich ist den Leuten das Look & Feel wichtig, sogar der großen Mehrheit der Benutzer und ganz besonders denjenigen, die nicht häufig mit einem PC intensiv zu tun haben. Genau aus diesem Grund entstand auch SWT, weil die Benutzer mit dem Aussehen von SWING nicht zufrieden waren.
> Swing ist nicht nur langsamer, sondern bietet auch kein natives Look & Feel des GUI. Das ist falsch. Swing verwendet unter Windows die Win32-API und unter Linux Gtk+.
Und von der Langsamkeit von Swing verglichen mit SWT hab ich auch noch nichts gemerkt. NetBeans 4.1 läuft hier jedenfalls sogar schneller als Eclipse 3.0.
Von Martin Röhricht am Mi, 29. Juni 2005 um 09:03 #
>> Swing ist nicht nur langsamer, sondern bietet auch kein natives Look & Feel des GUI. > Das ist falsch. Swing verwendet unter Windows die Win32-API und unter Linux Gtk+.
Wie bitte? Du verwechselst in Deinem Posting gerade SWT und Swing. Eine Swing Applikation sieht ungefähr so aus: http://pages.infinit.net/chanaan/images/nertec-SerView6Client.jpg (hier wohl noch mit JRE < Java 5), während Du bei SWT unter Linux zwischen Motif und GTK2 wählen kannst und unter Windows und MacOS X die jeweiligen nativen Bibliotheken nutzt.
Nein, verwechsel ich nicht. SWT muss speziell für das jeweilige Toolkit neu kompiliert werden. Deshalb gibts auch keine "Plattformunabhängigkeit" bei Eclipse. Swing kann das native Look & Feel liefern. Das Gtk+ Look & Feel gibt es aber erst mit ner aktuellen Java VM.
SWT greift direkt auf die vorhandenen Libs zu und unterstützt Gtk+ also soweit möglich. Dafür sind Anwendungen, die SWT verwenden, überhaupt nicht "plattformunabhängig", was ja eigentlich der Vorteil von Java ist.
Swing kann ebenfalls Gtk+ verwenden, enthält allerdings noch keine vollwertige Implementierung, weshalb nicht alle Engines genutzt werden können, sondern derzeit nur pixmap und bluecurve.
Mein Vorposter hat behauptet, ich würde Swing mit SWT verwechseln, was nicht stimmt, da ich nie behauptet hab, SWT würde kein Gtk+ verwenden.
Hätte ich Swing und SWT verwechselt, hätte ich quasi behauptet, NetBeans würde auf SWT aufbauen.
Von Bernhard Walle am Mi, 29. Juni 2005 um 10:38 #
Ja, aber du darfst kein eigenes Gtk Theme verwenden sondern nur das Standardtheme mit anderen Farben und Bluecurve. Siehe http://java.sun.com/j2se/1.5.0/docs/guide/swing/1.4/Post1.4.html.
Im Prinzip ein riesiger Hack, um dem Verhalten von Gtk auf einigen Systemen möglichst nahe zu kommen. Gtk wirklich nutzen wie SWT es tut, tun die nicht, nur nachbilden. Und das macht es in meinen Augen unbrauchbar.
Eine Gtk Applikation auf meinem Rechner sieht deutlich anders aus als eine Swing-Anwendung im Gtk-Look. Da nehme ich gleich das Standard-Theme von Swing (das neue blaue, nicht das alte lila), das passt besser!
Du bist immernoch links schuldig, die zeigen das Java in der aktuellen Version GTK Controlls verwendet. Die gtkrc auszuwerten nützt nicht viel. Schlieslich arbeiten sogar KDE und GTK auf solchen wegen zusammen. Das ist kein Wunderwerk. Dennoch nutzt KDE kein gtk
Seit wann wertet KDE die .gtkrc aus? KDE kann eine für Gtk+-Anwendungen erzeugen. Java 1.5 dagegen wertet sie aus und beschwert sich sogar, dass die industrial-engine nicht unterstützt wird. Daher sieht die Swing-Anwendung in solchen Fällen auch bescheiden aus. Da hast du deinen Link: http://ubuntuforums.org/archive/index.php/t-5197.html
"Seit wann wertet KDE die .gtkrc aus? KDE kann eine für Gtk+-Anwendungen erzeugen."
Jein, es geht noch einiges mehr, wenn du kannst GTK mit einer qt pixmap engine laufen lassen. Und auch noch einige andere "Tricks" anwenden. Vieles davon wurde integriert, um Fremdanwendungen in KE besser zu integrieren.
"Java 1.5 dagegen wertet sie aus und beschwert sich sogar, dass die industrial-engine nicht unterstützt wird"
Es ist durchaus möglich das er das Theme unterstützt, aber dein Link sagt nichts darüber aus ob es auch GTK nutzt. Die engine oder sogar nur das stile das die Oberfläche zeichnet, macht noch lange nicht GTK aus. Das GTK unter meinem Linux nutzt die "qt themes", deswegen ist es aber immernoch kein Qt selbst ;)
Theme != Lib
Mein StarOffice sieht auch wie mein Qt aus, aber eben auch nur durch den Trick der Zeichenengine.
Zu der Windows Control Api, Qt und GTK gehört aber WESENTLICH mehr als der Look. Schon beim "Feel" nützt es nicht viel. Nicht zu vergessen das es hier ja um speed ging, und da leidet Swing ja auch noch an ganz anderen stellen (auch wenns wohl inzwischen wesentlich besser geworden ist)
Java nutzt kein GTK sondern wertet nur die .gtkrc aus um, mit Hilfe von in Java geschriebenem Code, GTK nachzuzeichnen. Der ganze Code befindet sich in der rt.jar (/com/sun/java/swing/plaf/gtk). Das ganze hat *nichts* mit GTK zu tun ausser das es so aehnlich aussieht (es werden noch nicht mal die draw calls delegiert). Fuer Windows gilt dasselbe (/com/sun/java/swing/plaf/windows).
> Das GTK unter meinem Linux nutzt die "qt themes", deswegen ist es aber immernoch kein Qt selbst Du hast aber den Qt-Look. Feel lass ich mal weg, da Java-Anwendungen z.B. nicht einmal das Pasten mit Mittelklick unterstützen und somit selbst zu xlib "inkompatibel" sind.
Hast du dir mal NetBeans 4.1 mit Java2 5.0 auf Windows angeschaut? Da sieht überhaupt nichts nach Swing aus, obwohl NetBeans Swing nutzt. NetBeans sieht aus wie eine native Windows-Anwendung.
Gleiches unter Windows, auch mit diversen anderen Anwendungen, die mit Java 1.4 einfach grässlich aussehen.
Es gibt unter Swing Styles, welche das Look & Feeld lokaler Anwendungen imitieren, wie es auch Qt tut. Das macht Swing aber noch lange nicht zum nutzer der Windows Controls. Ansonsten bitte Quelle angeben, wo man nachlesen kann das Swing inzwischen die Windows Controls nutzt. Ein "es sieht so aus" reicht nicht
Ob Swing unter Windows Win-Controls nutzt, kann ich dir nicht sagen. Unter Linux bekomme ich jedenfalls beim Start einer Java-Anwendung einige Gtk+-Fehlermeldungen, die darauf schließen lassen, dass die libgtk+ via JNI geladen wurde. lsof wird da sicher näher Auskunft geben.
mit Swing werden alle GUI Elemente in der VM selbst gezeichnet, d.h. es werden keine OS eigenen Widgets/Controls benutzt. Das ist ja auch der Vorteil von Swing gegenüber von SWT. Die einzigen Heavyweight Komponenten von Swing sind JFrame, JDialog, JWindow, and JApplet, d.h. diese benutzen BS spezifische Aufrufe.
Das soll schneller laufen? Entweder hat sich seid der letzten Version dort etwas in riesigen Sprüngen getan oder ich leide langsam an Alterswahnsinn Eclipse (gerade die 3.1) läuft bei mir nicht mehr merklich langsamer als eine ganz normale App (bei der ganzen Plug-gerei schon erstaunlich). Auch das Look&Feel von Swing ist eigentlich eher eine Sache, die vermieden werden sollte. Das genannte Azureus baut IMAO auch auf SWT auf und das vermutlich auch nicht ohne Grund.
NetBeans läuft (mindestens) genauso schnell wie Visual Studio und letzteres ist mit Sicherheit eine native Anwendung. Eclipse läuft wesentlich langsamer, was aber höchstwahrscheinlich am Virenscanner liegt, der ständig die zig JAR-Archive entpacken muss.
Unter Linux spüre ich zwischen beiden keinen Unterschied.
Eben jene scheinen irgendwie verschwunden zu sein. Zu meinem SWT Projekt hab ich jetzt einfach die neuste swt.jar hinzugefuegt,kompiliert auch fein. Starte ich es jetzt allerdings aus der SWT run configuration herraus:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-pi-carbon-3123 in java.library.path
Ich habe den Eindruck, das die Versionen vor M6 diese Konfiguration besser automatisiert haben. Wie ist denn nun die Vorgehensweise ?
ich finde Eclipse echt gut! Der Funktionsumfang ist enorm und es gibt mittlerweile allerlei Plugins für andere Programmiersprachen, als Java.
Mein einziges Problem mit Eclipse ist aber immer noch die Performance. Dabei meine ich nicht speziell die Startzeiten, oder den Speicherverbrauch. Mein Problem ist, dass Eclipse ganz leicht beim Tippen hinterherhängt. Ich persönlich möchte, dass das Programm, in dem ich schreibe wirklich genau dann reagiert, wenn ich tippe und nicht einige Millisekunden später. Es ist wirklich nur leicht verzögert, aber das nervt mich, wenn ich damit arbeiten möchte. Es ist halt nicht so schnell, wie z.B. das Tippen in Kate, oder Gedit. Solange das nicht der Fall ist, ist es für mich nutzlos.
Hat jemand eine Idee, wann sich das ändern soll? Ich habe bereits 1,4 GHz und 512 MB Ram. Das sollte doch reichen für sowas :)
Gruß
Mike
Schau doch mal genau nach.
Grüße,
Sebastian
danke für den Tipp! Ich habe in den Einstellungen einen Punkt "QuickDiff" gefunden. Weiß noch nicht genau, wofür der ist. Der scheint wohl irgendwie während ich Tippe bereits die Syntax zu prüfen. Ich habe den Punkt nun deaktiviert und siehe da: Es ist schon ne Ecke schneller!
Danke
Mike
http://thepiratebay.org/ Applications
Alle Versionen
es gibt was besseres: Intellij IDEA!!! Dauer-Testlizenz gibt's hier!
- Jens
(sorry - fand die Seite was unübersichtlich um ordentlich Features vergleichen zu können - aber vielleicht kennst du sie ja?)
thx & cya
Mr.Chauv
Gruss
Steffen
auf Version 3.1. Die habe ich jetzt grade laufen.
Gruß
Mike
Der IMHO beste Ratschlag (falls machbar): Einen schnelleren PC nehmen, so ab 2,5 GHz. Mit weniger als 2 GHz macht Eclipse keinen Spaß.
Hypocrisy - Total Eclipse
8-D
Pink Floyd: "Eclipse" (from "The Dark Side Of The Moon")
http://www.hugi.is/hahradi/bigboxes.php?box_id=51208&f_id=1269
Waer echt hilfreich denn ich komm garnicht drauf
http://www.yoxos.com/yoxos/doc/bs37/
oder direkt
http://yoxos-update.com/eclipse/eclipse-SDK-3.1-win32.zip
weiß jemand von Euch wo man das Language Pack für Deutsch runterladen kann? Die haben ja immer noch nicht gelernt als Basissprache auf Deutsch umzustellen... :(
Und überhaupt: Gibt es mitterlerweile Bestrebungen die IDE auf eine vernünftige Basis wie SWING umzustellen? Gibt es da irgendwo ein Projekt?
Danke
> die IDE auf eine vernünftige Basis wie SWING
> umzustellen? Gibt es da irgendwo ein Projekt?
Oh mein Gott, das wird hoffentlich nie passieren. SWT ist ja schon nicht so toll, aber Swing ist unterirdisch. (ich spreche aus der User-Perspektive, nicht über APIs) Die Widgets sind hässlich, die Usability ist schrecklich... Dann lieber SWT.
Wieso sollte Swing hässlich sein, SWT aber nicht?
Beide verwenden Gtk+, wenn sie es vorfinden.
Wer Motif wählt, braucht sich nicht zu wundern.
Falsch Swing verwendet eine GTK ähnliche Theme.. und SWT GTK direkt.. was ein großer Unterschied ist.
Swing wird nicht deine Theme komplett verwenden sondern bestenfalls eine kaputte Kopie davon, wohingegen SWT deine Desktoptheme annimmt, da es seine Widgets direkt von GTK zeichen lässt.
Mal davon abgesehen ist Swing träger und langsamer als SWT
Gruß
Waldgeist
Du willst doch nicht behaupten, dass Eclipse wirklich nach Gtk+ aussieht. Nautilus z.B. sieht komplett anders aus. Eclipse übernimmt also praktisch gar nichts.
Es wäre evtl. nützlich wenn du mir erzählen würdest was du unter "wie gtk aussieht" verstehst..
SWT verwendet GTK wo es geht und wo es nicht geht hat es eigene GTK Widgets entworfen, das ist aber auch ganz klar da SWT das kleinste Gemeinsame Vielfache von einer Handvoll Widgets APIs bedienen muss.
Trotzdem IST SWT unter Linux GTK/Motif nativ und Swing ist nur eine Theme, so wie eine Pixmap theme unter GTK.. einfach nur Grafiken.
Gruß
Waldgeist
PS: Jetzt kommt es drauf an ob du den Unterschied zwischen Aussehen und Technik kennst.. ich weiss ja nicht ob du Programmierer bist, oder ein Anwender der nach dem Aussehen urteilt.
Dass für die Schaltflächen etc. die jeweiligen Gtk+-Widgets genutzt werden. Dass der GtkFileChooser bzw. der GtkFileSelector genutzt wird. Dass die Symbolleiste sich genauso wie die von anderen Gtk+-Anwendungen verhält.
...
> SWT verwendet GTK wo es geht und wo es nicht geht hat es eigene GTK Widgets entworfen, das ist aber auch ganz klar da SWT das kleinste Gemeinsame Vielfache von einer Handvoll Widgets APIs bedienen muss.
Ja eben, Eclipse verwendet zum großen Teil eigene "Gtk-Widgets".
> ich weiss ja nicht ob du Programmierer bist, oder ein Anwender der nach dem Aussehen urteilt.
Programmierer, allerdings habe ich mir den Source von Swing noch nie angeschaut. Keine Lust, mich bei Sun zu registrieren.
Das dürfte schwer werden, da GTK und GNOME für fast jedes Problem 3-4 Lösungen haben :)
Auch Qt und KDE Anwendungen sind nicht identisch.
Soetwas gibt es nicht völlig, dennoch passt es so besser rein als jede Swing Anwendung.
Unter MacOSX sieht Eclipse auch nicht völlig richtig aus, da es einer anderen Designfamilie abstammt (eher Windows).
Zumindest in dem Punkt sind wir uns einig. :-)
Eigentlich sieht Eclipse nirgendwo richtig aus.
Swing sieht imho unter GTK sehr schlecht aus, wenn ich mir SWT dagegen ansehe.
Unter Windows gehts mit Swing einigermassen, aber die Performance ist schon nicht optimal. Wenn du ein Java-Programm entwickelst, das in andere VB oder C# Projekte (jaja ich weiss, aber hab das selber schon erfahren müssen) eingegliedert werden soll und niemand einen Unterschied von aussen merken soll, dann kommst du wohl kaum um SWT herum.
> Nautilus z.B. sieht komplett anders aus. Eclipse übernimmt also praktisch
> gar nichts
Das stimmt doch überhaupt nicht. Natürlich arbeitet Eclipse unter Linux mit
dem GTK, wenn Du die entsprechende Version (und nicht Motif) geladen hast.
Informiere Dich doch mal vorher genauer. Eclipse hat schlicht und ergreifend
noch einige eigene Widgets entworfen, was man als Nutzer des SWTs übrigens
auch tun kann.
Bitte bitte lies mal ein bißchen was über das SWT, bevor Du hier solche Sprüche
abziehst.
dem GTK, wenn Du die entsprechende Version (und nicht Motif) geladen hast.
Hab ich was anderes behauptet?
> Eclipse hat schlicht und ergreifend
noch einige eigene Widgets entworfen, was man als Nutzer des SWTs übrigens
auch tun kann.
Genau darauf will ich doch hinaus. Guck dir nur mal die Registerkarten an, die unter keinem OS nativ aussehen, weil Eclipse da eben was eigenes nutzt. Das hat natürlich den Vorteil, dass sich die Oberfläche beim Wechsel von Windows auf Linux kaum ändert.
http://actsofvolition.com/images/screenshots/clearlooks/clearlooks-scroll2.png
http://blog.fubar.dk/archives/100-percent-native-eclipse-2.png
In beiden Fällen wird das Gtk+-Theme "Clearlooks" genutzt.
Mit Swing sieht es natürlich wesentlich düsterer aus, weil es überhaupt nur mit 2 Gtk+-Engines umgehen kann, nämlich den beiden, die in der Java Runtime implementiert sind: pixmap und bluecurve.
SWT dagegen kann auf alle Engines zurückgreifen, da es die native Implementation der Gtk+-Bibliothek nutzt.
> vernünftige Basis wie SWING umzustellen? Gibt es da irgendwo ein Projekt?
Nein, da gibt es kein Projekt und das wird es auch nie geben. SWT wurde genau
wegen Eclipse entwickelt und das ist auch gut so, denn AWT bietet zu wenig
Möglichkeiten und Swing ist nicht nur langsamer, sondern bietet auch kein
natives Look & Feel des GUI.
SWT ist schon sehr genial und wie Du auf die Idee kommst es biete keine
vernünftige Basis bedarf wohl einer genaueren Erläuterung.
-> Alle Classen von Anwendungen sind bööössseeee ... nieder mit nicht-Java-VM teilen!
> und somit vollständig unbrauchbar. Mann sieht es ja schon bei der nötigen
> Installation. Ein SWING-basiertes Eclipse könnte aus einem jar-File auf allen
> Plattformen gestartet und genutzt werden.
Warum soll SWT unbrauchbar sein, nur weil es nicht in der Java-VM von Sun ist?
Du benötigst nur die entsprechende SWT-Bibliothek und fertig -- Eclipse läuft
hier auch ohne irgendeine Installationsorgie unter Windows, Linux und MacOS X
und ist mit SWT entwickelt.
> Aber Eurer "Verständis" sehe ich ja... Ihr labert hier nur Nonsens über Look
> & Feel das ohnehin niemanden interessiert.
Den Nonsens erzählst Du gerade hier. Natürlich ist den Leuten das Look & Feel
wichtig, sogar der großen Mehrheit der Benutzer und ganz besonders denjenigen,
die nicht häufig mit einem PC intensiv zu tun haben. Genau aus diesem Grund
entstand auch SWT, weil die Benutzer mit dem Aussehen von SWING nicht zufrieden
waren.
Das ist falsch. Swing verwendet unter Windows die Win32-API und unter Linux Gtk+.
Und von der Langsamkeit von Swing verglichen mit SWT hab ich auch noch nichts gemerkt. NetBeans 4.1 läuft hier jedenfalls sogar schneller als Eclipse 3.0.
> Das ist falsch. Swing verwendet unter Windows die Win32-API und unter Linux Gtk+.
Wie bitte? Du verwechselst in Deinem Posting gerade SWT und Swing. Eine Swing Applikation
sieht ungefähr so aus: http://pages.infinit.net/chanaan/images/nertec-SerView6Client.jpg
(hier wohl noch mit JRE < Java 5), während Du bei SWT unter Linux zwischen Motif und GTK2
wählen kannst und unter Windows und MacOS X die jeweiligen nativen Bibliotheken nutzt.
SWT muss speziell für das jeweilige Toolkit neu kompiliert werden. Deshalb gibts auch keine "Plattformunabhängigkeit" bei Eclipse.
Swing kann das native Look & Feel liefern. Das Gtk+ Look & Feel gibt es aber erst mit ner aktuellen Java VM.
SWT greift direkt auf die vorhandenen Libs zu und unterstützt Gtk+ also soweit möglich. Dafür sind Anwendungen, die SWT verwenden, überhaupt nicht "plattformunabhängig", was ja eigentlich der Vorteil von Java ist.
Swing kann ebenfalls Gtk+ verwenden, enthält allerdings noch keine vollwertige Implementierung, weshalb nicht alle Engines genutzt werden können, sondern derzeit nur pixmap und bluecurve.
Mein Vorposter hat behauptet, ich würde Swing mit SWT verwechseln, was nicht stimmt, da ich nie behauptet hab, SWT würde kein Gtk+ verwenden.
Hätte ich Swing und SWT verwechselt, hätte ich quasi behauptet, NetBeans würde auf SWT aufbauen.
Schoen waere es.
Im Prinzip ein riesiger Hack, um dem Verhalten von Gtk auf einigen Systemen möglichst nahe zu kommen. Gtk wirklich nutzen wie SWT es tut, tun die nicht, nur nachbilden. Und das macht es in meinen Augen unbrauchbar.
Eine Gtk Applikation auf meinem Rechner sieht deutlich anders aus als eine Swing-Anwendung im Gtk-Look. Da nehme ich gleich das Standard-Theme von Swing (das neue blaue, nicht das alte lila), das passt besser!
Gruß,
Bernhard
Schlieslich arbeiten sogar KDE und GTK auf solchen wegen zusammen. Das ist kein Wunderwerk. Dennoch nutzt KDE kein gtk
Java 1.5 dagegen wertet sie aus und beschwert sich sogar, dass die industrial-engine nicht unterstützt wird. Daher sieht die Swing-Anwendung in solchen Fällen auch bescheiden aus.
Da hast du deinen Link: http://ubuntuforums.org/archive/index.php/t-5197.html
Jein, es geht noch einiges mehr, wenn du kannst GTK mit einer qt pixmap engine laufen lassen. Und auch noch einige andere "Tricks" anwenden. Vieles davon wurde integriert, um Fremdanwendungen in KE besser zu integrieren.
"Java 1.5 dagegen wertet sie aus und beschwert sich sogar, dass die industrial-engine nicht unterstützt wird"
Es ist durchaus möglich das er das Theme unterstützt, aber dein Link sagt nichts darüber aus ob es auch GTK nutzt. Die engine oder sogar nur das stile das die Oberfläche zeichnet, macht noch lange nicht GTK aus.
Das GTK unter meinem Linux nutzt die "qt themes", deswegen ist es aber immernoch kein Qt selbst ;)
Theme != Lib
Mein StarOffice sieht auch wie mein Qt aus, aber eben auch nur durch den Trick der Zeichenengine.
Zu der Windows Control Api, Qt und GTK gehört aber WESENTLICH mehr als der Look. Schon beim "Feel" nützt es nicht viel. Nicht zu vergessen das es hier ja um speed ging, und da leidet Swing ja auch noch an ganz anderen stellen
(auch wenns wohl inzwischen wesentlich besser geworden ist)
Der ganze Code befindet sich in der rt.jar (/com/sun/java/swing/plaf/gtk). Das ganze hat *nichts* mit GTK zu tun ausser das es so aehnlich aussieht (es werden noch nicht mal die draw calls delegiert). Fuer Windows gilt dasselbe (/com/sun/java/swing/plaf/windows).
Im großen und ganzen sind sich ja alle bis auf fuffy einig
Du hast aber den Qt-Look.
Feel lass ich mal weg, da Java-Anwendungen z.B. nicht einmal das Pasten mit Mittelklick unterstützen und somit selbst zu xlib "inkompatibel" sind.
Das tut unter Windows jedes Programm ;)
Die Frage ist, ob auch die Windows Controls verwendet werden. Und das ist ja genau das, was Swing NICHT tut.
"Linux Gtk+"
Warum sollte es? Nö, SWT nutzt GTK unter Linux, Swing nutzt afaik nur die reinen X Kommandos zum zeichnen.
Gleiches unter Windows, auch mit diversen anderen Anwendungen, die mit Java 1.4 einfach grässlich aussehen.
Ansonsten bitte Quelle angeben, wo man nachlesen kann das Swing inzwischen die Windows Controls nutzt. Ein "es sieht so aus" reicht nicht
Unter Linux bekomme ich jedenfalls beim Start einer Java-Anwendung einige Gtk+-Fehlermeldungen, die darauf schließen lassen, dass die libgtk+ via JNI geladen wurde. lsof wird da sicher näher Auskunft geben.
mit Swing werden alle GUI Elemente in der VM selbst gezeichnet, d.h. es werden keine OS eigenen Widgets/Controls benutzt. Das ist ja auch der Vorteil von Swing gegenüber von SWT. Die einzigen Heavyweight Komponenten von Swing
sind JFrame, JDialog, JWindow, and JApplet, d.h. diese benutzen BS spezifische Aufrufe.
gruß
Eclipse läuft wesentlich langsamer, was aber höchstwahrscheinlich am Virenscanner liegt, der ständig die zig JAR-Archive entpacken muss.
Unter Linux spüre ich zwischen beiden keinen Unterschied.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-pi-carbon-3123 in java.library.path
Ich habe den Eindruck, das die Versionen vor M6 diese Konfiguration besser automatisiert haben. Wie ist denn nun die Vorgehensweise ?
Gruss,
Demo
Win32:
http://page.mi.fu-berlin.de/~stade/downloads/
eclipsesdk3.1win32.zip.torrent
sowie
MacOSX:
http://page.mi.fu-berlin.de/~stade/downloads/
eclipsesdk3.1macosxcarbon.tar.gz.torrent