gutes GUI-System

[shadow]

hallo,

ich bin schon seit wochen immer mal wieder ein paar stunden im internet unterwegs, so auch wieder heute, um etwas zu finden, was es offensichtlich nicht zu geben scheint:

ein cooles GUI-system für java.

ich hab schon so viel gelesen, angeschaut, ausprobiert... unglaublich, was und wie viel es da alles gibt, aber es ist nicht das dabei, was meinen vorstellungen entspricht. ich bin schon richtig frustriert.

vorgeschichte: ich komme aus der borland-ecke, delphi um genau zu sein, und bin so in die java-welt gestolpert. ich bin begeistert von der sprache an sich und wie viele äußerst professionelle produkte es gibt, alles open source. aber ich bin eben von delphi verwöhnt und suche nun ein open source-produkt ("CooleGUI"), das folgendes leistet:

* am liebsten ein plugin für eclipse
* ich wähle "neu->Cooles GUI-formular", es wird eine neue klasse erzeugt, die einem formular (fenster) entspricht. dazu eine xml-datei, in der die grafischen daten abgelegt sind, also wo buttons, edit-felder usw. auf dem formular plaziert sind
* mit einem gui-editor wird die xml-datei grafisch (klicki-bunti) bearbeitet. ich will weder "new JButton" oder sonst irgendetwas schreiben müssen, noch will ich, dass mir der gui-editor diesen code-schreibt, denn man sieht ja an vielen solchen produkten (z. b. VE), dass das nur probleme macht. nein, das formular soll mit allen dazugehörigen gui-infos in der xml-datei abgespeichert werden.
* im constructor der fenster-klasse steht dann irgendsowas wie "CoolesGUIFormular form = new CoolesGUIFormular("test.xml");". darüber werden klasse und xml sozusagen miteinander verbunden. die klasse "CoolesGUIFormular" übernimmt das auslesen der xml-datei und das erstellen des tatsächlichen fensters (s. u.)
* wenn ich im gui-editor das onClick-event vom button auswähle, dann kann mir der editor meinetwegen einen methoden-rumpf dafür erzeugen
* es kann auch gern swing verwendet werden, man würde davon (außer am aussehen der fertigen anwendung) ja eh nichts mitbekommen, da man nur die paar wenigen klassen von "CooleGUI" zu sehen bekommt, alles andere passiert im inneren von "CooleGUI". sehr geschickt wäre es dann natürlcih von den "CooleGUI"-entwicklern, wenn sie das plugin-mäßig so hinbekommen würden, dass man später (wenn z. B. das swing-plugin fertig ist) auch wxWidgets, Qt, GTK+ usw. programmieren kann. man müsste am code der anwendung, die "CooleGUI" verwendet, nichts ändern, sondern einfach nur das plugin austauschen...


ich bin mir sicher, dass all meine wünsche rein technisch machbar sind. warum ich mir sicher bin? weil ich schon sehr viele produkte gesehen habe, die gewisse teile meiner wünsche erfüllen. jetzt müsste ich nur doch die gewollten teile aus verschiedenen libs herausnehmen und neu zusammen setzten können.
deshalb die frage: warum gibt es soetwas noch nicht? einzig mir vorstellbare antwort: ich bin der einzige, der sich soetwas wünscht, alle anderen sind mit der umständlichen gui-bauerei zufrieden.

und jetzt die konkreten fragen an euch:

* gibt es vielleicht tatsächlich schon soetwas, und ich hab es die ganze zeit übersehn?
* würdet ihr euch auch soetwas wünschen, oder verwendet ihr andere produkte, mit denen ihr so zufrieden seid, dass euch nie der wunsch noch so etwas gekommen ist?


danke fürs lesen, und bitte baut mich ein bisschen auf. danke.

stefan.

 

[Bleiglanz]

...noch will ich, dass mir der gui-editor diesen code-schreibt, denn man sieht ja an vielen solchen produkten (z. b. VE), dass das nur probleme macht. nein, das formular soll mit allen dazugehörigen gui-infos in der xml-datei abgespeichert werden.

...im constructor der fenster-klasse steht dann irgendsowas wie

na was jetzt? wenn keine Klassendatei erzeugt wird gibts auch keinen Konstruktor

so ein tool wie du dir wünscht wirds wohl nie geben

Grund:

du zeichnest einen neuen Button in deinem visuellen Editor

IDE ändert XML-Datei

XML-Datei wird zu .java umgesetzt

.java wird zu .class kompiliert

IDE lädt die .class über reflection, erzeugt eine Instanz und aktualisiert die Zeichnung am Bildschirm

(das dauert VIEEEL zu lange, weshalb alle heutigen IDEs "direkt" mit Java-Klassen arbeiten)

weil ich schon sehr viele produkte gesehen habe,

Welche denn? XUL? oder XAML?

Tss

 

[L-ectron-X]

Wenn du von Delphi kommst, solltest du dich im JBuilder wie zuhause fühlen.

 

[shadow]

na was jetzt? wenn keine Klassendatei erzeugt wird gibts auch keinen Konstruktor

* ich wähle "neu->Cooles GUI-formular", es wird eine neue klasse erzeugt, die einem formular (fenster) entspricht.

doch, es soll eine klasse geben, die soll aber (fast) frei von gui-infos sein, sondern nur logik enthalten.

so ein tool wie du dir wünscht wirds wohl nie geben

Grund:

du zeichnest einen neuen Button in deinem visuellen Editor

IDE ändert XML-Datei

XML-Datei wird zu .java umgesetzt

.java wird zu .class kompiliert

IDE lädt die .class über reflection, erzeugt eine Instanz und aktualisiert die Zeichnung am Bildschirm

(das dauert VIEEEL zu lange, weshalb alle heutigen IDEs "direkt" mit Java-Klassen arbeiten)

so hab ich das nicht gemeint, eher so:

* IDE ändert XML-Datei
* bereits vorhandene klasse wird gestartet, läd im konstruktor die xml-datei und erzeugt ein fenster
* bei einem event wird von eine methode in meiner klasse von "CoolesGUIFormular" aufgerufen, oder von wem auch immer, ist ja auch egal, hauptsache die methode wird aufgerufen...

weil ich schon sehr viele produkte gesehen habe,

Welche denn? XUL? oder XAML?

unter anderem.

Tss

wie darf ich das interpretieren?

Grüße.
Stefan.

 

[AlArenal]

www.jformdesigner.com

Derzeit ist es noch kein Eclipse-Plugin, aber Karl schruabt und bastelt fleißig daran (auch in eigener Sache). Ich habe mittlerweile alle meine Projekte auf der Arbeit umgestellt.

Was nicht klar ist ist, was du unter einem "coolen GUI" verstehst.

Für wxWidgets, QT, GTK, .. wirst du nichts finden, da es keinen nennenswerten Markt für Java-Applikationen mit entsprechendem GUI gibt. Wenn es nur ums Ausshene geht - es gibt Unmengen an Look&Feels...

 

[Bleiglanz]

IMHO ist es ja genau anders herum

die "zweite" Datei (nämlich die xml) muss von der IDE immer up to Date gehalten werden, und mit dem übrigen Projekt übereinstimmen, eine Desasterquelle

und man braucht sowas wie einen Übersetzer (damit man auch ohne IDE einen vollständigen Build durchführen kann)

Wer die bescheuerten versteckten .resx Dateien im M$ Visual Studio kennt weiss vielleicht was ich meine...

 

[AlArenal]

Manchmal habe ich den Eindruck, da wollen Leute programmieren, die gar nicht mehr programmieren wollen..

 

[The_S]

Manchmal habe ich den Eindruck, da wollen Leute programmieren, die gar nicht mehr programmieren wollen..

lol! Full Ack!

 

[shadow]

Wenn du von Delphi kommst, solltest du dich im JBuilder wie zuhause fühlen.

jbuilder erzeugt java-code. JBuilderX hab ich ausprobiert, gefällt mir nicht so. ich möchte nicht wieder ein flagschiff wie delphi haben, sondern bin auf der suche nach etwas open source. wie gesagt, am liebsten ein plug-in für eclipse. wenn ich mir das alles so durchlese, scheint es so, als hätte ich wahnsinnige ansprüche, ich finde aber trotzdem nicht, das dem so ist. man muss sich nur mal eclipse(swt, rcp) anschauen, oder ve, oder xul. alles wahnsinns produkte...

 

[Bleiglanz]

man muss sich nur mal eclipse(swt, rcp) anschauen, oder ve, oder xul. alles wahnsinns produkte...

Ja schon, dann verwende doch die?

http://java-source.net/open-source/xml-user-interface-toolkits

http://www.eclipseplugincentral.com/Web_Links+index-req-viewlink-cid-18.html

http://eclipse-plugins.2y.net/eclipse/plugins.jsp?category=UI

http://www.eclipse.org/community/osplugins.html

 

[shadow]

www.jformdesigner.com

Derzeit ist es noch kein Eclipse-Plugin, aber Karl schruabt und bastelt fleißig daran (auch in eigener Sache). Ich habe mittlerweile alle meine Projekte auf der Arbeit umgestellt.

auf der seite war ich auch schon mal, werd mich mir jetzt gleich nochmal genauer ansehn.

Was nicht klar ist ist, was du unter einem "coolen GUI" verstehst.

ist blöd ausgedrückt. damit meine ich einfach einen guten designer, vergleichbar mit dem von vb oder delphi.

Für wxWidgets, QT, GTK, .. wirst du nichts finden, da es keinen nennenswerten Markt für Java-Applikationen mit entsprechendem GUI gibt. Wenn es nur ums Ausshene geht - es gibt Unmengen an Look&Feels...

klar, ich mein ja nur. wenn ich mein wunsch-produkt ("CooleGUI") selbst implementieren würde, dann würde ich mich beispielsweise nicht auf swing festlegen, sondern alles dynamisch halten. wahrscheinlich würde ich mit swing anfangen, und dann weitere plug-ins dafür erstellen...

IMHO ist es ja genau anders herum

die "zweite" Datei (nämlich die xml) muss von der IDE immer up to Date gehalten werden, und mit dem übrigen Projekt übereinstimmen, eine Desasterquelle

bei dephi heißen "meine" xml-dateien dfm-dateien, bei vb gibts die auch, keine ahnung, wie die da heißen. klar, die ide muss diese dateien lesen und schreiben können. desasterquelle? wo denn? vielleich versteh ich dich auch einfach nicht richtig.

und man braucht sowas wie einen Übersetzer (damit man auch ohne IDE einen vollständigen Build durchführen kann)

ohne IDE einen build durchführen? du meinst kompilieren, ohne IDE? klar, das geht schon, aber warum sollte ich das machen wollen?

ich glaube es gibt an dieser stelle zwei ansätze: entweder man muss die xml-datei mit gui-infos mitliefern, damit sie von der klasse quasi on-the-fly gelesen werden kann. nachteil: der user kann die xml-datei öffnen und verändern, was die gui des programms verändern würde. variante nummer zwei: man vereint die klasse und die xml-datei zu einer weitern klasse: vorteil: geschwindigkeit, keine xml-datei mehr zum ausliefern. nachteil: zwischenschritt erforderlich.

Manchmal habe ich den Eindruck, da wollen Leute programmieren, die gar nicht mehr programmieren wollen..

ähm, meinst du damit mich?
imo eine sehr rückständige einstellung, möchte ja auch nicht mein os oder meine ide nochmal programmieren müssen. bei mir gehts primär um ergebnisse, und die sollen so schnell wie möglich (eben wie in delphi oder vb) fertig sein. ich möchte mich aber nicht mit vb oder delphi in irgendeine sackgasse begeben, sondern zukunftsorientiert (java) programmieren und das bequem.


grüße.
stefan.

 

[AlArenal]

Ich sehe nicht viel Zukunftsorientierung ein Eclipse-Plugin zu basteln, dass Java-Anwendungen mit einer wxWidgets/QT/GTK-Oberfläche ausstattet. Wer sollte das nutzen wollen?

Wenn ich einen GUI-Builder baue, dann ja nicht am Marlt vorbei und der Marlt verlangt eben manches aus deiner Wunschliste nicht. U.U. ist es auch nicht umsetzbar (oder nur sehr krude und mit Heidenaufwand), da die UIs unterschiedlichen Konzepten zugrunde liegen. Swing arbeitet mit Layout Managern. Wie will man ein solches Design auf eine GUI-Lib umsetzen, dass dieses Konzept nicht oder ganz anders umsetzt?

Im Übrigen ist es doch so, dass man sich in der Entwicklung festlegt. Wir machen hier z.B. Swing only, nix SWT, also zahle ich nicht für SWT-Features, die ich nicht brauche.

Im JFormDesigner kannst du übrigens wählen ob er dir direkt Code erzeugt, oder ob du lieber die XML-Dateien aus der Anwendung heraus verwendest. Ich arbeite derzeit über letzteren Ansatz, weil er flexibler ist. Wenn Karl mal die Integration in Eclipse erledigt hat, schaue ich mir die Code-Generierung nochmal an...
Und bei uns ändert auch kein User irgendwelche XML-Dateien. Die Benutzen das Programm und fertig. An den JAR-Dateien einer Webstart-Anwendung frickelt keiner ruml, denn dann laufen sie nicht mehr (wegen der Signierung), abgesehen von rechtlichen Konsequenzen (Verlust der Gewährleistung, etc.).

Im Übrigen ist die Entscheidung für ein gewisses Tool auch eine Preisfrage und wenn ich sehe was mich ein JBuilder kostet (zunächst reichlich Geld, später noch reichlich Nerven wenn das Teil ums Verrecken nur noch Grütze im GUI-Builder anzeigt) und was mich Eclipse + JFormDesigner kostet, muss ich nicht lange überlegen.

Derzeit halte ich den JFD in Sachen Preis-/Leistung für ungeschlagen. Das er noch nicht direkt in die diversen IDEs integriert ist, macht sich nicht negativ bemerkbar. Gerade die Trennung zwischen UI und Code hält einen von vielen Dummheiten ab. Wer sich den autamtisch generierten Code im JBuilder mal ansieht, weiß, was ich meine...

 

[bygones]

www.jformdesigner.com

*träum* cooles Teil - scheint endlich mal ein Editor zu sein den man benutzen kann... natürlich dann nicht kostenlos

 

[AlArenal]

www.jformdesigner.com

*träum* cooles Teil - scheint endlich mal ein Editor zu sein den man benutzen kann... natürlich dann nicht kostenlos

Richtig, ist aber ein schwer guter Preis, wie ich finde.

 

[shadow]

Ich sehe nicht viel Zukunftsorientierung ein Eclipse-Plugin zu basteln, dass Java-Anwendungen mit einer wxWidgets/QT/GTK-Oberfläche ausstattet. Wer sollte das nutzen wollen?

moment. das plugin würde nur einen gui designer zur verfügung stellen, der die xml-gui-files editieren kann. die lib würde diese xml dann zur laufzeit auslesen und als fenster darstellen, je nachdem welches plugin verwendet wurde. es könnte dann plugins für alle gui-systeme geben. bitte jetzt nicht an wxWidgets usw. festbeißen, mirwegen auch awt, swt ...

Wenn ich einen GUI-Builder baue, dann ja nicht am Marlt vorbei und der Marlt verlangt eben manches aus deiner Wunschliste nicht. U.U. ist es auch nicht umsetzbar (oder nur sehr krude und mit Heidenaufwand), da die UIs unterschiedlichen Konzepten zugrunde liegen. Swing arbeitet mit Layout Managern. Wie will man ein solches Design auf eine GUI-Lib umsetzen, dass dieses Konzept nicht oder ganz anders umsetzt?

wie einfach oder schwierig das ist, wäre die sache des plugins.

Im Übrigen ist es doch so, dass man sich in der Entwicklung festlegt. Wir machen hier z.B. Swing only, nix SWT, also zahle ich nicht für SWT-Features, die ich nicht brauche.

hier würde man sich natürlich auf "CooleGUI" festlegen. aber mit welcher lib das fenster tatsächlich angezeigt werden würde, ist dynamisch.

Im JFormDesigner kannst du übrigens wählen ob er dir direkt Code erzeugt, oder ob du lieber die XML-Dateien aus der Anwendung heraus verwendest. Ich arbeite derzeit über letzteren Ansatz, weil er flexibler ist. Wenn Karl mal die Integration in Eclipse erledigt hat, schaue ich mir die Code-Generierung nochmal an...
Und bei uns ändert auch kein User irgendwelche XML-Dateien. Die Benutzen das Programm und fertig. An den JAR-Dateien einer Webstart-Anwendung frickelt keiner ruml, denn dann laufen sie nicht mehr (wegen der Signierung), abgesehen von rechtlichen Konsequenzen (Verlust der Gewährleistung, etc.).

ja, seh ich genau so.


ich würde ja zu XMLFace tendieren, wenn das nicht ein paar tausender kosten würde...

 

[AlArenal]

Hast du aber immernoch das Standardproblem aller Gleichmacher: Den kleinsten gemeinsamen Nenner.

Du kannst dann nur diejenigen Komponenten benutzen, die in allen zu unterstützenden Libs ebenfalls enthalten sind. Allein das ist schon ein Riesen-Pferdefuß. Hinzu kommt noch, dass du in der Praxis mit den Standard-Komponenten nicht weit kommst, sondern dir eigene schreibst, bzw. vorhandene erweiterst. Das alles kannst du dann nicht machen...

Im Grunde führt der Wunsch alle bedienen und unterstützen zu wollen dann nämlich in zwei Richtungen:
1. Zieht man es dogmatisch in der Entwicklung durch, unterstützt man alles mögliche, hat aber nur rudimentäre Möglichkeiten (KGN).
2. Man beschränkt sich am Ende auf eine einzige Lib (z.B. Swing) . Dann hat dein Tool aber keinen zusätzlichen Nährwert zu anderen Tools, sondern schleppt noch allerlei Overhead mit sich rum, was sich bei nem kommerziellen Tool auch im Preis niederschlägt.

Wenn man nicht gerade Produkte auf Basis der Eclipse-Plattform entwickelt, sehe ich auf Basis von Java im Desktop-Application-Bereich kein Vorbeikommen an Swing, alleine schon aufgrund vielerlei Gründe, wie Verbreitungsgrad (ist ein Faktor bei der Personalbeschaffung), Dokumentation, Tutorials, Bücher, freie und kommerzielle Libs, ...

 

[Guest]

Es gibt von IBM AlphaWorks Reflexive User Interface Builder einen Versuch in diese Richtung.

 

[Dukel]

Wie wärs mit http://www.swixml.org/
Evtl. noch ein Plugin für Eclipse welches das nutzt.

 

[shadow]

Hast du aber immernoch das Standardproblem aller Gleichmacher: Den kleinsten gemeinsamen Nenner.

Du kannst dann nur diejenigen Komponenten benutzen, die in allen zu unterstützenden Libs ebenfalls enthalten sind. Allein das ist schon ein Riesen-Pferdefuß. Hinzu kommt noch, dass du in der Praxis mit den Standard-Komponenten nicht weit kommst, sondern dir eigene schreibst, bzw. vorhandene erweiterst. Das alles kannst du dann nicht machen...

Im Grunde führt der Wunsch alle bedienen und unterstützen zu wollen dann nämlich in zwei Richtungen:
1. Zieht man es dogmatisch in der Entwicklung durch, unterstützt man alles mögliche, hat aber nur rudimentäre Möglichkeiten (KGN).
2. Man beschränkt sich am Ende auf eine einzige Lib (z.B. Swing) . Dann hat dein Tool aber keinen zusätzlichen Nährwert zu anderen Tools, sondern schleppt noch allerlei Overhead mit sich rum, was sich bei nem kommerziellen Tool auch im Preis niederschlägt.

stimmt. ans geld denke ich zwar im moment überhaupt nicht, das behindert immer so das freie denken... aber ansonsten geb ich dir natürlich vollkommen recht. ausschließlich den kgn anzubieten is nix, würde sich nie durchsetzen. die andere möglichkeit ist, dass man immer meldungen und hinweise bringt, wenn in einer bestimmten gui-lib was nicht unterstützt werden würde. aber dann würde auch jeder user zu der lib greifen, in der von anfang schon alles geht und niemand würde drauf warten, bis in seiner gewählten gui-lib die gewünschten features implementiert sind, und dann müssen die auch noch in "CooleGUI" eingebaut werden... macht keiner.

ok, ihr habt mich überzeugt ???:L ... dann vergess ich das mal mit der unterstützung für verschiedene guis.
in ordnung, dann suche ich das produkt, das alles beschriebene kann, nur speziell für eine gui-lib.

Wenn man nicht gerade Produkte auf Basis der Eclipse-Plattform entwickelt, sehe ich auf Basis von Java im Desktop-Application-Bereich kein Vorbeikommen an Swing, alleine schon aufgrund vielerlei Gründe, wie Verbreitungsgrad (ist ein Faktor bei der Personalbeschaffung), Dokumentation, Tutorials, Bücher, freie und kommerzielle Libs, ...

für solche aussagen kenn ich mich nicht genug aus, aber "kein vorbeikommen" hört sich für mich ein bisschen zuu festgelegt an. außerdem gefällt mir swing irgendwie nicht *duck*. werd mich auf jeden fall noch umsehen...

Wie wärs mit http://www.swixml.org/
Evtl. noch ein Plugin für Eclipse welches das nutzt.

ja, für swing ist das auf jeden fall ein gutes produkt, denke ich.

 

[shadow]

Ich wollte nur noch schnell ein paar abschließende Worte loswerden:

Ich hab mich jetzt, nach langer Überlegung, für ein Produkt entschieden. Es ist zwar nicht genau das, was ich anfangs wollte, aber ich bin damit jetzt auch recht zufrieden: GTK+ mit glade/libglade.

Mit dem glade-Designer kann man sein Formular in .xml-Dateien abspeichern und mit libglade das Formular laden, anzeigen, Events abgreifen usw., von der GTK+-Programmierung bekommt man gar nichts mit.

Nachteil: Der Designer ist kein Plugin für Eclipse -> man muss die Events selbst verknüpfen, und zwar über die richtige Benennung der EventHandler (buttonClick() ), es hätte mir besser gefallen, wenn es über Doppelklick gegangen wäre, so wie in Delphi oder VB. Aber was nicht ist, kann ja noch werden.

Ich habe noch nicht sonderlich viel damit gemacht, kann deshalb nicht von großen Erfahrungen berichten, bin jedoch guter Dinge. Danke für die aufschlussreiche Diskussion.

.shadow.

 

[AlArenal]

Vielleicht habe ich was verpasst, aber wo ist nun der Zusammenhang zwischen GTK+ / glade und Java?

 

[shadow]

der Zusammenhang? wie meinst du das?

 

[AlArenal]

Du warst auf der Suche nach einem "coolen GUI-System für Java". Nun schriebst du, du nutzt GTK+, glade und libglade.

Ich verstehe nicht, wie du das nun in Java nutzen willst.

 

[shadow]

http://java-gnome.sourceforge.net/cgi-bin/bin/view

 

[AlArenal]

Ok, nun ergibt es Sinn.. aber irgendwie bekomme ich Bauchschmerzen bei so einer Lösung. Bei allem was mit UI zu tun hat, musst du auf glade zurückgreifen. Mal eben ne eigene Komponenten in Java entwickeln iss nicht...

Da schüttelts mich..

 

[shadow]

kommt halt wie immer drauf an, was man machen will...

 

[AlArenal]

kommt halt wie immer drauf an, was man machen will...

Ne Menge nativen (plattformabhängigen) Code benutzen und dadurch viele Abhängigkeiten erzeugen, keine eigenen Komponenten in Java entwickeln und auch keine vorhandenen nutzen können.. Da kann ich ja gleich C++ nehmen und muss dem Kunden nicht zumuten auch noch ein passendes JRE zu installieren (neben all dem anderen benötigten Kram).

Klingt irgendwie gar nicht mehr nach einem "coolen GUI"

 

[shadow]

ok.

 

[Jörg]

was ist damit:
http://thinlet.sourceforge.net/
kommt glaub dem swixml Ansatz nahe ...

 

[Arno Nym]

Sorry dass ich den alten Thread wieder auskrame, aber eine Lösung, in diesem doch relativ Eclipse lastigen Forum wurde nicht angesprochen -> Netbeans Mattise (http://www.netbeans.org/kb/articles/matisse.html) (den gabs schon 2005)