Frage zur Verwendung des RCP

[hasenbrot]

Ab wann macht es Sinn, eine SWT-Anwendung auf dem RCP aufzubauen? Es kann ja im Prinzip für alle möglichen Anwendungen verwendet werden, allerdings frage ich mich, ob das RCP bei einer wirklich kleinen Anwendung überhaupt sinnvoll ist bzw. welchen Mehrwert es mir in dem Fall gegenüber einer reinen SWT-Anwendung bietet.

 

[Gast2]

Ab wann macht es Sinn, eine SWT-Anwendung auf dem RCP aufzubauen? Es kann ja im Prinzip für alle möglichen Anwendungen verwendet werden, allerdings frage ich mich, ob das RCP bei einer wirklich kleinen Anwendung überhaupt sinnvoll ist bzw. welchen Mehrwert es mir in dem Fall gegenüber einer reinen SWT-Anwendung bietet.

Ich würde fast sagen immer. Vor allem wenn du deine Anwendung auf verschiedene OS-Systeme ausliefern willst.

 

[Sonecc]

Ich halte es immer so:

Kann ich spezielle Funktionen von RCP für meine Anwendung gebrauchen, so nutze ich RCP
Brauche ich die Funktionalität die RCP mir bietet nicht, lasse ich RCP auch weg. (Eine Anwendung mit der ich Dateien von A - B kopiere benötigt kein RCP, z.B.)

Oft reicht es, wenn man JFace nutzt.


Edit: SirWaynes Aspekt ist natürlich auch ein Kriterium, für mich aber eher untergeordnet

 

[hasenbrot]

Um diese speziellen Funktionen, die die Anwendung ja beträchtlich vergrößern, geht es mir. Welche sind das im Einzelnen? Soweit ich weiß, geht es um bestimmte GUI-Komponenten, automatische Updates usw., aber das ist mir alles ein bißchen zu ungenau um entscheiden zu können, wann das RCP tatsächlich Sinn macht und wann es die Anwendung nur unnötig aufbläht.

 

[Sonecc]

Im Prinzip geht es nunmal um einzelne Konzepte.
Jedes einzelne davon zu erklären ist erstmal arg umfangreich und da die Eclipse RCP ja erweiterbar ist, wäre es auch sehr mühselig.

Das hängt zudem immer von der Anwendung ab (wie schon erwähnt)

 

[Gast2]

Wie oben schon erwähnt sind das ganz schön viele sowohl Runtime technisch wie auch UI technisch...
UI: Docking Framework, die ganzen Commands (speichern, exit) die es gibt, die ganzen Views und Editoren...
Runtime technisch: Core API, Equinox, Extension Point...

Außerdem musst du mit einem Eclipse RCP nicht unbedingt SWT/JFace verwenden geht ja auch mit Swing.

 

[Gonzo17]

Ich würde fast sagen immer. Vor allem wenn du deine Anwendung auf verschiedene OS-Systeme ausliefern willst.

???:L Das ist jetzt für mich garkein Argument. Eine normale .jar, die eine SWT- oder Swing-Anwendung öffnet, ist doch auch auf jedem Betriebssystem ausführbar. Oder was meinst du genau?

Außerdem musst du mit einem Eclipse RCP nicht unbedingt SWT/JFace verwenden geht ja auch mit Swing.

Meinst du mit einer SWT/AWT Bridge? Warum sollte man das wollen? Ich zumindest würde davon die Finger lassen. Kann zu mehr Problemen führen als es Vorteile bringt. Eclipse RCP ist nunmal auf SWT aufgebaut und sieht nicht vor, dass AWT- bzw- Swing-Komponenten verwendet werden, deswegen bräuchte man da eine Bridge.

Ansonsten generell folgende Aspekte beachten. Mit Eclipse RCP hast du das grundlegende Konzept von einem Workspace, einer Workbench mit Editoren, Views und Perspectives, den modularen Aufbau durch Plugins (macht das Produkt sehr gut erweiterbar) sowie die mitgebrachte Update-Funktion. Das sind für mich jetzt mal die Features, die im Vordergrund stehen. Wenn du davon fast nichts brauchst, dann würde ich von Eclipse RCP abraten, weil es natürlich schon von Haus aus ne Breite Masse mitbringt, die du ja dann nicht verwenden würdest. Wenn du aber eine Mehrzahl dieser Features sinnvoll nutzen könntest und willst, dann lohnt es sich meiner Meinung nach durchaus.

 

[hasenbrot]

Danke für die ausführliche Antwort.

Java wird allerdings immer noch recht selten für Desktop-Anwendungen verwendet, denn die meisten werden in C++ geschrieben. Ich habe allerdings mal gelesen, dass Java nicht zwingend langsamer ist als eine native Anwendung, da die JVM den Bytecode nach und nach optimiert, außerdem besteht die Möglichkeit, für besonders teure Operationen über das JNI auf nativen Code zugreifen zu können. Wie sieht es aber hinsichtlich der Entwicklungszeit und letztlich der damit verbundenen Kosten aus? Wäre die Programmierung einer bekannten Java-Anwendung, wie z.B. JDownloader, in C++ (Qt, WxWidgets...) mit sehr viel mehr Aufwand verbunden? Vielleicht hat hier ja jemand genügend Erfahrung in beiden Welten sammeln können.

 

[krazun]

Meinst du mit einer SWT/AWT Bridge? Warum sollte man das wollen? Ich zumindest würde davon die Finger lassen.

Wenn man jetzt mit EclipseRCP anfängt würde ich auf jedenfall zur Eclipse RCP 4 Platform raten. Da ist der GUI Renderer komplett unabhängig vom Framework und man kann ohne Probleme eine Eclipse RCP Anwendung mit JavaFX 2.1 GUI oder Swing schreiben anstatt SWT

grüße,
krazun

 

[Gonzo17]

Ah ok, das wusste ich nicht, klingt interessant. Kannst du mir einen Artikel oder eine Erklärung zu genau diesem Thema geben? Mich würde interessieren, wie das dann funktioniert.

 

[Gast2]

???:L Das ist jetzt für mich garkein Argument. Eine normale .jar, die eine SWT- oder Swing-Anwendung öffnet, ist doch auch auf jedem Betriebssystem ausführbar. Oder was meinst du genau?

Jo viel Spaß bei deployen immer richtige swt jar dazu legen usw. gilt für alle nativen sachen die du dann verwendest... RCP bringt das halt schon alles mit bekommst z.B. kommt ne .exe oder .sh raus usw.
Für jedes OS das richtige swt jar dabei usw.

Meinst du mit einer SWT/AWT Bridge? Warum sollte man das wollen? Ich zumindest würde davon die Finger lassen. Kann zu mehr Problemen führen als es Vorteile bringt. Eclipse RCP ist nunmal auf SWT aufgebaut und sieht nicht vor, dass AWT- bzw- Swing-Komponenten verwendet werden, deswegen bräuchte man da eine Bridge.

Nee geht auch ohne... Habs mit Eclipse 3.x noch nie versucht, aber jemand hier im Forum hat gesagt Sie haben nur Eclipse RCP mit Swing, fallen halt wieder nette Feature wie das Databinding weg usw.

Mit Eclipse 4.x ist man noch freier in der Auswahl...

 

[Gast2]

Java wird allerdings immer noch recht selten für Desktop-Anwendungen verwendet, denn die meisten werden in C++ geschrieben.

Das sagst du aus deiner reichhaltigen Erfahrung ?
Das Thema hatten wir schon sooooooooooooooooooooooooooooo oft, erst dem letzt wieder einfach mal Suchfunktion benutzen, dann siehst was es alles für Desktop-Anwendungen

 

[Gonzo17]

Jo viel Spaß bei deployen immer richtige swt jar dazu legen usw. gilt für alle nativen sachen die du dann verwendest... RCP bringt das halt schon alles mit bekommst z.B. kommt ne .exe oder .sh raus usw.
Für jedes OS das richtige swt jar dabei usw.

Sowas würde ich dann aber schlicht im Build-Prozess konfigurieren, wenn ich es bräuchte. Ich weiß, dass das mit RCP ohne Mehraufwand schon getan wird, allerdings würde ich deshalb alleine sicherlich keine Anwendung auf Eclipse RCP aufbauen.
Wie gesagt, ich rede von kleinen Anwendungen, denn sobald ich eine Anwendung mit all diesen Features ohnehin entwerfen will, dann kann ich auch auf Eclipse RCP setzen.

Nee geht auch ohne... Habs mit Eclipse 3.x noch nie versucht, aber jemand hier im Forum hat gesagt Sie haben nur Eclipse RCP mit Swing, fallen halt wieder nette Feature wie das Databinding weg usw.

Mit Eclipse 4.x ist man noch freier in der Auswahl...

Das mit Eclipse 4.x hört sich tatsächlich gut an, aber bei Eclipse 3.x halte ich das weiterhin für problematisch. Hier ein zwar etwas älterer Artikel, aber nen neueren Stand kenne ich auch nicht: Eclipse Corner Article: Swing/SWT Integration

Eclipse RCP für Swing hatte ich mal gelesen, da hat ein Unternehmen etwas gebastelt. Aber dieses Unternehmen (TrioMii ?!) gibt es wohl auch nicht mehr. Ansonsten wäre mir da nichts bekannt.

 

[krazun]

Ah ok, das wusste ich nicht, klingt interessant. Kannst du mir einen Artikel oder eine Erklärung zu genau diesem Thema geben? Mich würde interessieren, wie das dann funktioniert.

Klar doch:

Die einfachste Möglichkeit eine Eclipse RCP 4 Anwendung mit JavaFX 2.1/Swing etc. GUI zu erststellen ist e(fx)clipse - JavaFX 2.0 Tooling and Runtime for Eclipse von Tom Schindl. JavaFX Runtime und Renderer für Eclipse 4 werden da bei einem Eclipse RCP 4 JavaFX Projekt automatisch hinzugefügt.

Im Prinzip muss man einfach nur einen Renderer schreiben für die GUI Technologie die man gerne für die Eclipse 4 Anwendung nutzen möchte.

Eclipse 4 Renderer Tutorial von Lars Vogel:
Eclipse 4 Renderer - Tutorial

Weitere Infos:
e4 – Use Eclipse 4.1 Application Platform but not SWT | Tomsondev Blog
Kai's Blog JavaFX 2.0, Swing & SWT Renderers for the Eclipse 4.x Application Platform (JavaFX 2.0, Swing & SWT Renderers for the Eclipse 4.x Application Platform)

Ausführlicher Artikel auf it-republik: JavaFX-2.0-Integration mit Eclipse 4.x

Schau dich mal im Git-Repo von Tom Schindl / efxclipse um. Da gibts schon fertige JavaFX Renderer.

grüße,
krazun

 

[Gast2]

Eclipse RCP für Swing hatte ich mal gelesen, da hat ein Unternehmen etwas gebastelt. Aber dieses Unternehmen (TrioMii ?!) gibt es wohl auch nicht mehr. Ansonsten wäre mir da nichts bekannt.

Wie gesagt such hier mal im Forum danach, irgendjemand macht nur Eclipse RCP auf Swing basis, kannst ihn ja mal fragen wies geht wenn es dich interessiert...

 

[Gast2]

So nachdem ich jetzt neue Informationen zu e4 habe, muss ich einige enttäuschen mit dem 4.2 release kann man die UI NICHT so einfach austauschen. Man hat zwar ein EMF Application Model aber die E4Application ist noch hart mit SWT verdrahtet.

Der Kai Toedter/Tom Schindl hat einen fork gemacht und einen eigenen Renderer für JavaFX und Swing geschrieben, der allerdings noch ein Prototyp ist. Da muss man die ganze e4 Framework bei ihn runterladen, bei den jetzigen Distributionen geht das wie gesagt noch nicht.

Außerdem ist das css Styling auch nicht so dolle bei SWT e4, man kann keine Scrollbar,Button, TableHeader usw. stylen, das ist natürlich bescheiden.

 

[javanewbie2]

Ich würde fast sagen immer. Vor allem wenn du deine Anwendung auf verschiedene OS-Systeme ausliefern willst.

Ja, das würde ich auch so sehen und sagen.

Liebe Grüße