SWT Fragen

[xoom4]

Ich habe mit SWT noch nie gearbeitet sondern mit Swing. Doch habe ich in den letzten Tagen etwas über OSGi und Eclipse RCP gelernt. Eine erste Applikation war auch erfolgreich. Auch mit NetBeans Plattform hab ich ein wenig gespielt. Jetzt kahmen mir ein paar Fragen zur SWT API.

• Ich hab gelesen das eine SWT Applikation auf möglichst viele Betriebsysteme getestet werden muss weil sich die native GUI oft unterschiedlich verhält. Ist das heute auch noch so? Oder verhalten sich SWT Applikationen heute wie Swing Applikationen und können nahtlos ohne vorherige Tests auf unterschiedlichen Betriebsysteme eingesetzt werden?
• Müssen SWT Widgets wirklich alle manuell gelöscht bzw. disposed werden? Weil das erinnert mich ein wenig an C/C++ wo man new und delete einsetzen musste. Oder gibts dafür wie oft in der Informationstechnologie eine elegante Lösungen? Bei Swing hat man das Problem nicht durch den GC.
• Für einige Betriebsysteme gibt es kein direktes SWT, bspw. für FreeBSD. Ich musste extra den Eclipse Port installieren nur um an die native SWT Jar Datei ran zu kommen. Deshalb stellt sich mir die Frage ob die compilierung der SWT nativen Lib einfach machbar ist, ohne extra ein ganzes Eclipse zu installieren. Bspw. direkt aus dem Quellcode.

Im grunde spricht besonders die Performancevorteile für SWT. Auch wenn in einigen Quellen wie bspw. Wikipedia behauptet wird, dass Swing diesbezüglich aufgeholt haben soll. Stelle ich auch heute mit Java 7 noch fest, dass Swing um einiges langsamer ist als SWT. Dafür lassen sich aber Swing Applikationen problemlos als JNLP aushändigen wohingegen für SWT dafür extra noch abhängige SWT Dateien in der JNLP berücksichtigt werden müssen. Wurde ein Betriebsystem nicht berücksichtig darauf aber eine JVM existiert, hat man schon wieder das Problem das extra dafür ein SWT compiliert werden muss und in der JNLP eingetragen. Oder wie bei RSSOwl wo auf der Download Seite unzählige ZIP Dateien für das jeweilige OS lagern nur damit eine SWT Datei zum OS kompatibel ist. Die SWT Jar Datei ist gerade mal 2.2 MB gross, dafür extra mehrere 25 MB grosse Packet für das jeweilge OS zu verfügung stellen scheint mir etwas übertrieben. :reflect:

Ich hab mir auch überlegt ob ich nicht die NetBeans GUI innerhalb eines Equinox OSGi einsetzen soll. Mir fehlt dazu einfach noch ein guter einstieg wie man das NetBeans UI System problemlos ausserhalb von NetBeans implementiert. Als NetBeans Module hatte ich schon erfolg, musste aber die ganze NetBeans Plattform mitschleppen. Beim Eclipse RCP bin ich da schon weiter, so das ich ohne Eclipse das ganze RCP ausschliesslich via xsbt verwalten kann. Also mit den üblichen Dateien

• Application.scala
• ApplicationActionBarAdvisor.scala
• ApplicationWorkbenchAdvisor.scala
• ApplicationWorkbenchWindowAdvisor.scala
• plugin.xml

wird dann ein einfaches GUI mittels java -jar org.eclipse.osgi gestartet inkl. Fensterverwaltung. Wie man sieht bin ich halt noch etwas unentschlossen was die Wahl der GUI API angeht. Vieleicht helfen mir einige Antworten auf die oben gestellten Fragen zur entscheidungsfindung

 

[Wildcard]

Ich hab gelesen das eine SWT Applikation auf möglichst viele Betriebsysteme getestet werden muss weil sich die native GUI oft unterschiedlich verhält. Ist das heute auch noch so? Oder verhalten sich SWT Applikationen heute wie Swing Applikationen und können nahtlos ohne vorherige Tests auf unterschiedlichen Betriebsysteme eingesetzt werden?

Ist wie bei Swing, auch dort verhalten sich bestimmte Dinge je nach Platform etwas anders. Wie zum Beispiel Double Click Action und die Menu Bar unter MacOS und Unity.

üssen SWT Widgets wirklich alle manuell gelöscht bzw. disposed werden? Weil das erinnert mich ein wenig an C/C++ wo man new und delete einsetzen musste. Oder gibts dafür wie oft in der Informationstechnologie eine elegante Lösungen? Bei Swing hat man das Problem nicht durch den GC.

Widgets sind in der Praxis kein Problem, weil ein Parent immer alle Kinder disposed. Das heißt wenn du zB einen Dialog verwendest, dann disposed der Dialog beim schließen alle Widgets. Du hast also nicht mehr Arbeit als bei Swing. Einziger unterschied sind Resourcen wie Bilder, Schriften und Farben. Die müssen disposed werden wenn du sie explizit anlegst. In der Praxis verwendet man dafür dann eine ImageRegistry, FontRegistry usw. die Instanzen cached damit sie nicht n-fach erzeugt werden.

Im grunde spricht besonders die Performancevorteile für SWT. Auch wenn in einigen Quellen wie bspw. Wikipedia behauptet wird, dass Swing diesbezüglich aufgeholt haben soll. Stelle ich auch heute mit Java 7 noch fest, dass Swing um einiges langsamer ist als SWT. Dafür lassen sich aber Swing Applikationen problemlos als JNLP aushändigen wohingegen für SWT dafür extra noch abhängige SWT Dateien in der JNLP berücksichtigt werden müssen.

SWT Anwendungen und auch Eclipse RCP Anwendungen lassen sich recht einfach per Webstart deployen. Man verwendet dazu ein Wrapper Feature und aus diesem Feature kann man automatisiert eine JNLP erzeugen, die die Platformfilter für Webstart korrekt umsetzt.

Ich hab mir auch überlegt ob ich nicht die NetBeans GUI innerhalb eines Equinox OSGi einsetzen soll.

Halte ich für eine schlechte Idee. Ich glaube du machst dir das Leben schwerer als nötig. Für alle relevanten Platformen liegt SWT vorkompiliert vor. Sollte wirklich etwas fehlen, kannst du das ja nachliefern.
Du kannst mit p2 auch einen Webstart basierten Installer bauen, der deine Anwendung passend für das jeweilige System installiert. Alles was du dazu brauchst ist eine Update Site die deine Bundles enthält. Wie das funktioniert habe ich vor einer Weile zusammengefasst:
Creating a Webstart Eclipse Installer Johannes' Blog

 

[xoom4]

Danke für die kompetenten Antworten

st wie bei Swing, auch dort verhalten sich bestimmte Dinge je nach Platform etwas anders. Wie zum Beispiel Double Click Action und die Menu Bar unter MacOS und Unity.

Das habe ich schon erwartet, vieleicht habe ich mit dem Wort "nahtlos" meine Frage etwas schlecht formuliert. Das kleinigkeiten nicht 100% überall gleich funktionieren ist nachvollziehbar. Mir ging es eher um einige Horror Berichte wo einige Entwickler schrieben, dass sie mit SWT nur Probleme hatten. Viele Posts waren aber relativ sehr alt. Deshalb würde ich gerne wissen ob man heute von SWT erwarten kann, dass allgemein mit nicht viel flickerei oder fine tuning zu rechnen ist. Weil mir klebt da noch so die Vorstellung, dass wenn jetzt bspw. meine Applikation auf FreeBSD geschrieben wurde (GTK). Bei der installation auf bspw. Windows die ganze GUI komplett verrutscht oder nicht das tut, was sie eigentlich soll. Sowas kann man heute wenn die Layout Manager richtig eingesetzt wurden nicht mehr erwarten?

Ich hab mir auch überlegt ob ich nicht die NetBeans GUI innerhalb eines Equinox OSGi einsetzen soll.

Halte ich für eine schlechte Idee. Ich glaube du machst dir das Leben schwerer als nötig.

Hast du recht, dass ist eine sehr schlechte Idee. Ich hab das heute versucht, habe den Quellcode von NetBeans durchforstet und musste feststellen. Das das überhaubt nicht machbar ist ohne gleich das ganze NetBeans Modulsystem noch zusätzlich einzubauen. Weil das Fenstersystem von NetBeans wie bspw. org.netbeans.core.windows.view.ui.MainWindow dauernd meckert wenn die abhängigen Module nicht mit dem Modulsystem initialisiert wurden. Es fehlt also sehr vieles und das alles selber initialisieren würde in sehr viel Arbeit enden. Ausserdem würde bei einer Quellcode änderung mit hoher Wahrscheinlichkeit das spiel von vorne beginnen. Weil man muss auf sehr tiefer Ebene coden bis man das ganze Modulsystem und alles was dazu gehört überhaubt zum laufen kriegt. Alternative währe der Einsatz von einzelnen GUI Bestandteilen, aber dann muss auf den ganzen automatismus verzichtet werden.

Ich werde nun mit SWT anfangen, ich hoffe das die einarbeitung von Swing zu SWT nathlos übergeht

Noch eine Frage hab ich bezüglich Chart Widgets. Ich habe die JFreeChart so modifiziert das SVG Bilder in Scatter Diagrammen möglich sind. Heute entdeckte ich aber die Eclipse BIRT Chart Engine (komisch das die mir nie aufgefallen ist als ich damals unterschiedliche APIs durchforstete). Hat jemand vieleicht mit beiden APIs Erfahrungen und kann was über die Performance unterschiede erzählen?

 

[Sonecc]

Im grunde spricht besonders die Performancevorteile für SWT. Auch wenn in einigen Quellen wie bspw. Wikipedia behauptet wird, dass Swing diesbezüglich aufgeholt haben soll. Stelle ich auch heute mit Java 7 noch fest, dass Swing um einiges langsamer ist als SWT.

Liefere Zahlen, sonst ist es nicht wahr.
Oder anders gesagt:
Die Eindrücke die du hast sind rein subjektiv. Selbst wenn Performanceunterschiede bestünden, so würdest du diese in 95% der Fälle nicht bemerken.
Es ist schon so, dass sich SWT und Swing in der Perfomance nur so gering unterscheiden, dass es gut und gerne vernachlässigt werden kann.

Die Performance ist jedenfalls ein schlechtes Argument für oder gegen ein UIToolkit.

 

[Gast2]

Sowas kann man heute wenn die Layout Manager richtig eingesetzt wurden nicht mehr erwarten?

Das bei Swing wie auch bei SWT so. Bei Swing kommt es auf dein L&F an wenn die Schriften in dem einem L&F größer als bei einem anderen ist, können die GUI's verschieden aussehen (z.B. verrutschen weil ein Label mehr Platz braucht).

Ich werde nun mit SWT anfangen, ich hoffe das die einarbeitung von Swing zu SWT nathlos übergeht

Glaube ich nicht SWT ist anders als Swing

 

[xoom4]

Liefere Zahlen, sonst ist es nicht wahr.
Oder anders gesagt:
Die Eindrücke die du hast sind rein subjektiv. Selbst wenn Performanceunterschiede bestünden, so würdest du diese in 95% der Fälle nicht bemerken.
Es ist schon so, dass sich SWT und Swing in der Perfomance nur so gering unterscheiden, dass es gut und gerne vernachlässigt werden kann.

Ich habe keine technischen Messungen gemacht, deshalb ist mein Urteil wie du richtig erkannt hast subjektiv. Ich arbeite hier mit einer längsameren Kiste und merke bei der Bedienung sehr wohl den unterschied zwischen Swing und SWT. Und wenn ich das bei mir merke, kann ich mir gut vorstellen das ein Anwender, der nicht einen neusten PC oder Laptop hat lieber die schnellere GUI bedient als die längsemere. Die Performanceunterschiede die ich bemerke sind gravierend, bspw. so 0.5 - 2 Sekunde bis das Menü bei NetBeans überhaubt öffnet. Während bei der Eclipse IDE das ruck zuck läuft. Auch bei einigen Anwendungen in Swing merke ich diese Performanceeinbussen.

Die Performance ist jedenfalls ein schlechtes Argument für oder gegen ein UIToolkit.

Das ist auch nicht mein Kriterium. Ich muss mich entscheiden zwischen Eclipse UI basierend auf SWT, NetBeans UI oder ich bau mir alles selbst. Die Einbindung der NetBeans UI ist fehlgeschlagen, wie oben beschrieben lohnt sich das kaum. Alles selber coden würde bedeuten das RAD neu zu erfinden. Man könnte auch MyDoggy oder ein anderes Framework benutzen, doch in diesem Fall werde ich es mit SWT bzw. Eclipse UI versuchen

 

[xoom4]

Ich werde nun mit SWT anfangen, ich hoffe das die einarbeitung von Swing zu SWT nathlos übergeht

Glaube ich nicht SWT ist anders als Swing

Ich könnte auch einfach das Fenstermanagement der Eclipse UI überlassen und mit einer Bridge dann Swing einbinden (hab dazu was im Netz gelesen). Oder wie sieht es eigentlich mit SWTSwing aus? Auf deren Homepage ist das Packet schon über 4 Jahre alt. Hat man die Weiterentwicklung aufgegeben? Gibt es vieleicht ein anderes Projekt das die native UI bei SWT via Swing implementiert? Somit müsste nur noch eine JAR Datei ausgeliefert werden, die org.eclipse.swt.swing

 

[maki]

Ich habe keine technischen Messungen gemacht, deshalb ist mein Urteil wie du richtig erkannt hast subjektiv. Ich arbeite hier mit einer längsameren Kiste und merke bei der Bedienung sehr wohl den unterschied zwischen Swing und SWT. Und wenn ich das bei mir merke, kann ich mir gut vorstellen das ein Anwender, der nicht einen neusten PC oder Laptop hat lieber die schnellere GUI bedient als die längsemere. Die Performanceunterschiede die ich bemerke sind gravierend, bspw. so 0.5 - 2 Sekunde bis das Menü bei NetBeans überhaubt öffnet. Während bei der Eclipse IDE das ruck zuck läuft. Auch bei einigen Anwendungen in Swing merke ich diese Performanceeinbussen.

Du vergleichst Netbeans mit Eclipse, nicht Swing mit SWT.
Swing läuft mittlerweile genausoschnell wie SWT, wenn nicht schneller, solange die "Kiste" OpenGL bietet.

Nebenbei, die Memoryeinstellungen bei Netbeans sind in der Defaulteinstellung ein Witz, einfach mal anheben, dann soltest du schon einen Unteschied merken

Das ist auch nicht mein Kriterium. Ich muss mich entscheiden zwischen Eclipse UI basierend auf SWT, NetBeans UI oder ich bau mir alles selbst. Die Einbindung der NetBeans UI ist fehlgeschlagen, wie oben beschrieben lohnt sich das kaum. Alles selber coden würde bedeuten das RAD neu zu erfinden. Man könnte auch MyDoggy oder ein anderes Framework benutzen, doch in diesem Fall werde ich es mit SWT bzw. Eclipse UI versuchen

SWT und Swing sind beides "nur" GUI Frameworks die einem vereinfacht gesagt helfen Buttons etc. zu erzeugen.
RCP Frameworks wie Netbeans RCP und Eclipse RCP sind Frameworks/Baukästen für Anwendungen(!), die gehen noch viel weiter als GUI Frameworks.

Persönlich finde ich Eclipse RCP sehr gut und es deckt fast alles ab, Netbeans habe ich mir nie wirklich angesehen (benutzt das eigentlich irgendwer wirklich??), jedenfalls ist Eclipse RCP viel weiter verbreitet als Netbeans RCP.

 

[Sonecc]

Du kannst Netbeans und Eclipse absolut nicht vergleichen. Vor allem was performance betrifft.
Dabei wundert mich btw. dass Eclipse bei dir schneller sein soll als Netbeans, hab da andere Erfahrungen gemacht.

SWT ist schon eine gute Entscheidung, wenns aber sogar darum geht, welches RCP-Framework du verwenden willst, dann war die Frage von anfang an obsolet. Da ist Eclipse-RCP das beste Mittel und diese basiert nunmal auf SWT.

 

[Gast2]

Du kannst auch einen Eclipse RCP mit Swing bauen, ob sich das aber lohnt weiß ich nicht.
Finde persönlich, dass SWT/JFace die besseren und mächtigeren widgets bietet.

 

[Sonecc]

Du kannst auch einen Eclipse RCP mit Swing bauen, ob sich das aber lohnt weiß ich nicht.

Ist aber mit SWT intuitiver nutzbar und ursprünglich auch für SWT gedacht und dementsprechend konzipiert

 

[Gast2]

Ist aber mit SWT intuitiver nutzbar und ursprünglich auch für SWT gedacht und dementsprechend konzipiert

Ich hab das soapUI plugin für eclipse gefunden, dass sieht auch stark nach swing aus und funktioniert ganz gut

 

[Sonecc]

Mensch... Ich sag ja nich, dass es nicht geht, sondern nur, dass du dir unnötig viel arbeit machst, wenn du RCP ohne SWT machst. :bae:

 

[Gast2]

Mensch... Ich sag ja nich, dass es nicht geht, sondern nur, dass du dir unnötig viel arbeit machst, wenn du RCP ohne SWT machst. :bae:

War doch gar nicht auf dich bezogen ... Hab doch gesagt ich würde es auch nicht mache, da es wenig Mehrwert hat.
Aber ich war verwundert dass ich wirklich mal ein Eclipse Plugin finde dass eine Swing GUI hat ^^.

Aber bin mir nicht mal sicher ob es wirklich Swing ist, aber sieht stark danach aus.

 

[maki]

Ab Eclipse 4 ist SWT nur eine von vielen Möglichkeiten für eine GUI

 

[xoom4]

Ich hab das soapUI plugin für eclipse gefunden, dass sieht auch stark nach swing aus und funktioniert ganz gut

Du meinst das SoapUI hier? Das sieht mir eher stark nach Test-Werkzeug aus :reflect:

Ab Eclipse 4 ist SWT nur eine von vielen Möglichkeiten für eine GUI

Eclipse 4? Erzähl mehr davon :hihi:

 

[Wildcard]

Eclipse 4? Erzähl mehr davon :hihi:

e4 Project

 

[xoom4]

Ich muss mein älteres native SWT 3.6.X für FreeBSD auf 3.7 updaten. Dafür nutzen wir beim FreeBSD das konventionelle swt-3.7-gtk-linux-x86.zip und patchen es. Doch, komischerweise fehlt beim 3.7 die build.xml Datei. Hat sich bei der compilierung was geändert? Ich kann auf der Homepage von SWT nichts finden :noe: