Grundwissen zum GUI Aufbau

[huNt]

Hallo liebe Mitglieder des Java-Forums.

Ich habe vor mir einen grafischen Editor zu bauen. Im Kopf habe ich etwas wie eine Oberfläche, ähnlich wie ein UML Editor. Ich möchte Icons aus einer Leiste auswählen, per Drag and Drop auf eine Oberfläche setzten und verschieben und wenn möglich auch miteinander verbinden.

Meine Frage lautet eigentlich mit welcher Bibliothek ist sowas möglich?

Zur Auswahl stehen ja:
AWT
swing
SWT

Natürlich möchte ich dieses GUI grafisch zusammenbauen und nicht alles per Hand schreiben.
Für SWT habe ich den VE ( Visual Editor (VE) - Downloads ) in Eclipse und für swing weiss ich, das es einen Editor in NetBeans gibt.

Welche Bibliothek ist für soetwas geeignet?

Um vllt einen nicht so komplizierten Editor zu bauen, könnte ich ich mir auch einen Editor in der Art von dem Control Beispiel von SWT vorstellen ( http://j2s.sourceforge.net/screenshots/j2s-swt-control-example.png ). Also einfach verschiedene Pulldown Menüs oder sowas. Allerdings wären grafische Symbole mit einer Oberfläche auf denen sie bewegbar sind, interessanter.

Zur Zeit lese ich das Buch "Java Entwicklung mit Eclipse 3" und dort den SWT Teil. Bisher habe ich aber noch nicht allzu viel Wissen über SWT und wollte daher hier die Frage stellen, anstatt das ich mich in verschiedenen Dingen einlesen muss, welche ich dann nicht brauche.
Ich denke wenn hier mir jemand ein paar signifikante Eigenschaften der beiden Bibliotheken nennen oder Hinweise auf andere Frameworks zum GUI Bau geben könnte, wäre mir schon viel geholfen.

Gruß!

 

[miwoe]

Jigloo GUI Builder finde ich ganz nett.

 

[André Uhres]

Mit dem Standardangebot von GUI Buildern werden wir für diese Anwendung wohl nicht weit kommen. Hier ist ein möglicher Ansatz: Verschiebbare Elemente in einem Rollbaren Container - Byte-Welt Wiki. Allerdings fehlt dort noch die Verbindung der Elemente.

 

[sadfsfasfasdg34]

Du kannst dir für das Zeichnen auch mal die Visual Library ansehen, die ist in der Netbeans Platform dabei. NetBeans

 

[tuxedo]

Naja, Vorteile von SWT hin oder her: Es ist nativer Code (bzw. die binaries) der da laufen muss. Wenn man da nicht absolut fit drin ist, kann man sich da mit ner gewachsenen UI recht unschöne Nebeneffekte einbauen. Klar, das Problem hat man u.U. mit Swingm aber, aber mit SWT muss man sich um vieles beim Aufräumen selbst kümmern das einem der GC nicht abnehmen kann.

Ich bevorzuge wo's nur geht Swing. Aber im Endeffekt ist es Geschmacks-/Glaubenssache.

- Alex

 

[Wildcard]

Am schnellsten zum Ziel kommst du mit GMF, da dir ein voll funktionsfähiger Editor komplett generiert wird. Du musst dann nur noch customizen.
Graphical Modeling Framework

Naja, Vorteile von SWT hin oder her: Es ist nativer Code (bzw. die binaries) der da laufen muss. Wenn man da nicht absolut fit drin ist, kann man sich da mit ner gewachsenen UI recht unschöne Nebeneffekte einbauen. Klar, das Problem hat man u.U. mit Swingm aber, aber mit SWT muss man sich um vieles beim Aufräumen selbst kümmern das einem der GC nicht abnehmen kann.

Bei Swing ist es ganz genauso nativer Code. Das Aufräumen ist nicht das geringste Problem, da ein Container alle Children automatisch entsorgt. Der einzige Unterschied beim Aufräumen ist das man Images, Fonts und Colors explizit freigeben muss, das ist bei Swing aber auch nicht viel anders, ausser das man dort den Graphics Kontext freigeben muss.

 

[tuxedo]

Bei Swing ist es ganz genauso nativer Code.

Logo, aber ich bekomm davon nix mit.

Das Aufräumen ist nicht das geringste Problem, da ein Container alle Children automatisch entsorgt.

Was auch nur in der Standardkonstellation prima funktioniert. In komplexeren Hierarchien schwächelt das System IMHO etwas. Für die meisten Fälle wirds jedoch passen.

Der einzige Unterschied beim Aufräumen ist das man Images, Fonts und Colors explizit freigeben muss, das ist bei Swing aber auch nicht viel anders, ausser das man dort den Graphics Kontext freigeben muss.

Wie oft kommt man denn bei einer 0815 Standardanwendung mit dem GK in Berührung? Mit Fonts etc. schon eher.

Aber wie gesagt: Das ist alles Geschmacks-/Glaubenssache. Ich will ja niemanden von Swing überzeugen oder von SWT abhalten. Um Himmels willen ... Das soll jeder für sich entscheiden.

- Alex

 

[Wildcard]

Logo, aber ich bekomm davon nix mit.

Bei SWT bekommst du auch nichts davon mit ausser das du das richtige Binary mitlieferst, sehe ich also nicht wirklich als ein schlagendes Argument.

Was auch nur in der Standardkonstellation prima funktioniert. In komplexeren Hierarchien schwächelt das System IMHO etwas. Für die meisten Fälle wirds jedoch passen.

Beispiele? Quellen? Ich entwickle seit Jahren täglich mit SWT und habe trotz komplexer Hierarchien keine Probleme mit den Resource.

Wie oft kommt man denn bei einer 0815 Standardanwendung mit dem GK in Berührung? Mit Fonts etc. schon eher

Wohl öfter als mit Fonts. Bilder zeichnen ist absolut eine Standardaufgabe.

 

[tuxedo]

Beispiele? Quellen? Ich entwickle seit Jahren täglich mit SWT und habe trotz komplexer Hierarchien keine Probleme mit den Resource.

Ich glaube du verstehst mich falsch. Wirkliche Probleme hab ich mit SWT nicht. Man muss nur, wenn's komplexer wird höllisch aufpassen. Es gibt IMHO mehr Stellen wo man was "falsch" machen kann und sich damit die tollsten Lecks einbaut, als das das der Fall in Swing ist.

Quelle: Unsere aktuelle Produktentwicklung, basierend auf Eclipse RCP/SWT/ActiveX Integration für Audio und Video-Rendering via SWT's Ole-Brücke. Da ich hier wie bereits erwähnt von komplexen Umgebungen und Hierarchien spreche ist es mit einem einfachen Beispiel nicht getan. Und mein AG sieht es nicht gern wenn ich ganze Klassen poste :-(

Mit etwas Erfahrung (die haben unsere Inder leider nicht ganz so) ist aber auch das kein Problem. Man muss eben wissen was man tut. Und da liegt die gefühlte "Problemschwelle" bei Swing für mich niedriger als bei SWT. Nicht mehr oder weniger wollte ich zum Ausdruck bringen.

Wohl öfter als mit Fonts. Bilder zeichnen ist absolut eine Standardaufgabe.

Kommt auf den Anwendungsfall an. Gibt genug Anwendungen wo man keine Bilder "von Hand" zeichnen und danach ans aufräumen denken muss, sondern die Standard-API einem alles abnimmt.

Für mich bleibt jedenfalls Swing das Standardmittel für die GUI Entwicklung.

- Alex

 

[Wildcard]

OLE ist ein schlechtest Beispiel da hier nicht SWT dein Problem ist, sondern das du durch OLE einen separaten Prozess ins Spiel bringst. Für Widgets/Dialoge und so weiter ist das Resource Handling nicht komplizierter als mit Swing. Nachdem der Dialog geschlossen wurde sind alle Widgets freigegeben. Die Images kann man zB in einer Registry Cachen und wiederverwenden, das ist auch in Swing nicht die schlechteste Idee. Auch in diesem Fall musst du dich niemals ums disposen kümmern solange du das nicht explizit möchtest.

 

[tuxedo]

OLE ist ein schlechtest Beispiel da hier nicht SWT dein Problem ist, sondern das du durch OLE einen separaten Prozess ins Spiel bringst.

Oh man. Wie mans dreht und wendet wird's falsch aufgenommen.
Die (durchaus lösbare) Problematik ist auch ohne Ole gegeben.

Nebenbei: SWT+OLE != separater Prozess. Ist alles nach wie vor ein einzelner Prozess.