Wie erstellt ihr die Java-GUI?

Java-Forum Allgemeine Themen
1

Ich bin ja immer am überlegen, ob ich den GUI-Designer von einer IDE (Eclipse, Netbeans, IntelliJ, XDev, etc.) nutzen sollte oder nicht.

Der Vorteil ist natürlich, daß es mit dem GUI-Designer einfacher geht.
Auf der anderen Seite, kann man hinterher nicht mehr einfach die IDE wechseln, weil jeder GUI-Designer sein eigenes proprietäres Datenformat hat, mit dem die anderen IDEs nichts anfangen können.
Also bleibt dann nur, die IDE als Texteditor mit Syntax-Highlighting und Autocomplete zu sehen. Dann bleiben die Projekte auch schön IDE-unabhängig. Dummerweise ist das Erstellen der GUI dann wieder mühseliger.

Wie handhabt ihr das Erstellen der GUI?

2

Ich habe früher auch mit Designern gearbeitet, aber seit einigen Programmiersprachen erstelle ich Guis nur noch von Hand.

3

es schadet ja nix, mal zu schauen was mit Designer machbar ist, wie der Elemente anordnet,
falls nur billige absolute Positionierung oder sonstiger starrer Layout-Einsatz, dann ist nicht viel zu lernen, nur einmal Arbeit geleistet,
und GUI vielleicht schon unbrauchbar hinsichtlich Größenänderung

wichtig ist, den Code dazu auch zu kennen, gegebenenfalls zu verbessern,
wann immer Wechsel/ Einbau usw. nötig ist, dann keine Rücksicht auf den Designer nehmen
sondern genauso vorgehen als wäre es eigener Code, könnte ja theoretisch genau so aussehen

ab dem Zeitpunkt eigener Eingriffe kann man aber nicht mehr zurück zum Designer, das muss klar sein,
aber wenn begründet dann ok, schlimmer als eh alles von Hand zu schreiben kann es nicht sein,
außer man weiß dass man mit eigenen strukturierten Aufbau (Schleife für 10 ComboBoxen…) gleich besser vorankommt

4

Per Hand. Da hab ich alles unter Kontrolle und bin unabhängig.

Dazu muss ich aber sagen, dass ich mich noch nicht näher mit Designern beschäftigt habe.

5

Noch per Hand ohne Designer.

Liegt aber auch immer an der eingesetzten Technologie, momentan Eclipse RCP auf SWT-Basis.
Bei Swing auch immer per Hand.

Was allerdings bei der nächsten GUI ansteht ist javaFX und der SceneBuilder in Kombination mit afterburner.fx.

SceneBuilder zum erstellen der FXML-Dateien mit GUI-BUILDER.
afterburner.fx zum verbinden der FXML-Komponenten mit dem Programmcode via Dependency-Injection.

Die Abhängigkeit zu proprietären GUI-Formaten sollte damit Geschichte sein. Eine Saubere Trennung der einzelnen Sachen also.

6

Immer von Hand (wenn ich das überhaupt noch mache).

Ist genau das gleiche wie beim Webdesign: am Anfang klickt und zieht man rum, später lernt jeder Entwickler, dass es schneller geht und viel Ärger erspart, wenn man das von Hand als “reinen Quelltext” erstellt.

Prototypen und Experimente - kann ich nicht ohne arbeiten, dann Code-Klau - immer mit Netbeans (kann ich am besten, bin am schnellsten damit).

7

Per Hand. Alles andere ist eine Krücke.

8

Ich nutze bisher immer noch das Eclipse-PlugIn “jigloo”… das Grundgerüst “klicke” ich mir damit zusammen und den Rest baue ich von Hand drum herum. Für Einsteiger finde ich das Tool klasse, da es wie gesagt schon mal die Grundstruktur anlegt (auch für Events von Buttons, Menues usw…).
Wird aber leider nicht mehr angeboten…

9

Moin,

der WindowBuilder von Eclipse erzeugt ganz normalen Java Code und man kann diesen auch verändern ohne das es zu Problemen mit dem Designer kommt. Einen Vendor Lock In gibt es dort also nicht.

Lediglich wenn man das Automatic Databinding nutzt (erstellt GUI und data binding automatisch aus einem bean heraus), handelt man sich eine Abhängigkeit zu org.jdesktop.beansbinding ein, das ist aber eine normale dependency die sich mit Maven auflösen lässt.

Viele Grüße
Fancy

10

ich meine einen Designer mit Code wie

        gridBagConstraints21.gridx = 0;
        gridBagConstraints21.fill = GridBagConstraints.BOTH;
        gridBagConstraints21.weightx = 1.0;
        gridBagConstraints21.weighty = 1.0;
        gridBagConstraints21.gridy = 0;
        GridBagConstraints gridBagConstraints11 = new GridBagConstraints();
        gridBagConstraints11.gridy = 1;
        gridBagConstraints11.weightx = 1.0;
        gridBagConstraints11.weighty = 1.0;
        gridBagConstraints11.insets = new Insets(5, 0, 0, 0);
        gridBagConstraints11.fill = GridBagConstraints.BOTH;
        GridBagConstraints gridBagConstraints5 = new GridBagConstraints();
        gridBagConstraints5.gridx = 0;
        gridBagConstraints5.fill = GridBagConstraints.BOTH;
        gridBagConstraints5.weightx = 1.0;
        gridBagConstraints5.insets = new Insets(5, 0, 0, 0);
        gridBagConstraints5.gridy = 2;
        setLayout(new GridBagLayout());
        setSize(617, 477);
        add(getJX(), gridBagConstraints11);
        add(getJY(), gridBagConstraints5);
        add(getJZ(), gridBagConstraints21);

wenn man es dort wagen sollte, Komponenten auf eine Liste umzustellen oder mal eben das Layout zu wechseln,
vielleicht Untermethoden/ Klassenhierarchien,
dann möchte ich den Designer sehen der daraus wieder herauskommt

dass man in am Layout unbeteiligten Listenern beliebigen Code eintragen kann + sonstige beliebige Methoden in den Klassen ist klar,

und wenn man die obige Struktur gleich beläßt, nur Insets auf 20 statt 5 setzt ist das natürlich auch kein Problem,
für den Designer gar nicht von eigener Eintragung zu unterscheiden, wird keine geheime Gegenkontrolle aller Werte haben

11

Okay, diesbezüglich gibt es leider Einschränkungen:

Viele Grüße
Fancy

12

Die Hoffnung auf ein perfektes Round-Trip Werkzeug zwischen Visueller-GUI-Gestaltung und Java-Source-Code habe ich schon lange aufgegeben.

13

Da ich Java mehr als Hobby mache und mir auch immer nur hin und wieder kleiner CLI-Tools baue mache ich das was ich dann mal GUI-mäßig mache alles per Hand direkt im Source. Ich habe mich dabei mitlerweile stark auf das GridBagLayout eingespielt (ich weis, es gibt für vieles auch einfacherere Layouts) und bin so deutlich schneller als wenn ich mir jetzt einen GUI-Builder installiere in den ich mich auch erst wieder einlernen müsste und der mir dann am Ende ziemlich schlechte Code erzeugt. Auch kann ich vieles durch meine eh recht modulare Weis wiederverwenden, habe also viele GUI-Teile “so auf Lager” und muss diese dann nur einbinden und anpassen, was mir natürlich sehr viel mehr Arbeit erspaart als jedes mal eine komplett neue GUI zu bauen.

14

Seltsam, dass bei so einer Frage bisher noch nicht die Antwort kam, die bei so einer Frage immer komm…(t? en sollte? en müßte?)…

Das kommt drauf an

Tatsächlich baue ich meine GUIs komplett per Hand. Aber ich könnte mir vorstellen, dass wenn man jeden Tag 20 Standarddialoge für irgendwelche Datenbankeingaben in “Wegwerf-GUIs” bauen muss, zu denen es schon Beans und DAOs gibt, man irgendwann sagt: “Sch drauf”, und es eben mit einem GUI-Builder macht.

Auch wenn ich solche GUI-Builder selbst noch nicht aktiv verwendet habe, habe ich schon oft genug den Quälkot gesehen, den die teilweise generieren. Und das deutet darauf hin, dass es dort wie auch an vielen anderen Stellen so ist, dass wenn man “nur den Standardkram” machen will, das recht leicht geht und seinen Zweck erfüllt. Aber spätestens, wenn man irgendwas machen will, was eben nicht direkt durch einen Buttonklick im GUI-Builder abbildbar ist (z.B. wenn man einen Filechooser komplett Grün-Schwarz machen will) ist man leicht gescrewt.

Der Gedanke, dass man bestimmte Dinge leicht automatisieren könnte, manifestiert sich auch in sowas wie https://github.com/aeremenok/swing-formbuilder , was ich schon ziemlich cool fand (trotzdem habe ich ~“sowas ähnliches” auch mal selbst angefangen…) aber das hat eben auch nur sehr spezielle Einsatzbereiche.

15

Es kommt auch letztendlich auf das Projekt an.

Wenn es tatsächlich Standardkram ist und die Umgebung passt, dann habe ich mir auch schon viele GUI’s generieren lassen. Sind allerdings Webprojekte.

Ruby on Rails ist da z.B. ein Klassiker. Damit kann man sich nahezu alles generieren lassen. Datenbank/Model, Controller sowie Views. Einfach angeben wie die Entitäten aussehen. Dort nennt sich das Scaffolding und generiert die nötigen Views entweder on the fly oder ein Grundgerüst auf dem sich aufbauen lässt.

Das Gegenstück für die JVM ist hier Groovy on Grails.

Der Grosse Unterschied ist meist die Art wie GUIs beschrieben werden. JavaFX oder XAML für .net/WPF oder früher noch Flex/Flash sind absolut genial.
Android schlägt da mit seinen ressourcen und layouts in die selbe Kerbe.

Die GUI’s werden in XML definiert und haben eine Struktur. Deklarativ. GUI-Builder können damit sehr einfach umgesetzt werden.

Und der Code, den die GUI-Builder ausspucken ist absolut identisch mit dem, was man von Hand schreiben würde.

Swing ist eine ganz andere Geschichte. Swing ist IMHO so gut wie Tot. Oracle macht da so gut wie nichts mehr dran.

16

ouh … pls … just don’t …

Wie ein Bekannter von mir immer so schön zu sagen pflegt : Das halte ich jetzt aber für ein Gerücht.

Sicher, einige Builder erzeugen schon was recht brauchbares, aber es gibt auch welche, gerade „die größeren“ die absoluten Schrott erzeugen. Während man per Hand noch sauber ein Layout nutzt werfen die meisten Builder nur irgendwas mit Bounds und irgendwelchen Groups in den Raum. Das ist dann schon sehr weit von dem entfernt was man „als guten Stil“ lernt und funktioniert auch nur weils halt auch so über-umständlich geht Code der eigentlich in einem Layout-Manager stecken sollte direkt in die Positionsangabe reinzudrücken.
Ich hab zwar jetzt erlich gesagt spontan keinen Code griffbereit, aber ich erinner mich da an so einigen Blödsinn den ich hin und wieder mal bei Fragen wie „Wie häng ich da jetzt einen Listener ran?“ gesehen habe. Auch scheint es ja gebräuchlich zu sein (bzw war gebräuchlich) das Events erstmal auf gut Glück aus dem anonymen Listener wieder zurück in die eigentliche Klasse gelegt wurden statt erstmal sinnvoll ein Thread-Konstrukt einzubringen. Ich denke das liegt daran das man wohl vom Builder aus direkt wählen kann welche Methode gecallt werden soll.

17

[quote=Ken]Ich bin ja immer am überlegen, ob ich den GUI-Designer von einer IDE (Eclipse, Netbeans, IntelliJ, XDev, etc.) nutzen sollte oder nicht.

Der Vorteil ist natürlich, daß es mit dem GUI-Designer einfacher geht.
Auf der anderen Seite, kann man hinterher nicht mehr einfach die IDE wechseln, weil jeder GUI-Designer sein eigenes proprietäres Datenformat hat, mit dem die anderen IDEs nichts anfangen können.[/quote]

Den wichtigsten Nachteil hast du übrigens übersehen: bei vielen GUI-Designern legst du fest, was bei einem Button passieren soll durch einen Mausklick (oder rechte Maustaste …) fest und dann öffnet sich ein Source-File und der Cursor steht an einer Stelle, wo du gleich was reinschreiben kann. Sehr, sehr verlockend. Da können viele nicht widerstehen.

Wenn du das ein paar mal gemacht hast, kannst du gleich einen Topf Spaghetti auf den Herd stellen.

18

Also für Swing kann ich ganz klar den WindowBuilder von Eclipse empfehlen. Vielleicht kann der nicht mit GridBagLayout umgehen, aber das kann ich auch nicht. Da schlägt meine Abneigung gegen dieses Layout wieder durch. Mit jedem anderen Layout kommt der nämlich super klar und Änderungen per Hand sind jederzeit möglich. Der GUI-Builder ersetzt natürlich nicht das Wissen eine GUI per Hand zu bauen, er automatisiert nur gewisses Sachen und erleichtert vor allem das Erstellen von Prototypen.

19

Ich habe früher Prototypen mit Netbeans zusammengeklickt und dann von Hand geschrieben, weil der generierte Code entsetzlich war.
Heute mache ich alles gleich von Hand. Bisher schreibe ich nur Swing-Code aber irgendwann muss ich noch mal an JavaFX ran…

20

Android: ich schreibe meine XMLs meistens von Hand. Geht schneller und eine Layout-Datei ist selten wirklich komplex. Der mitgelieferte GUI-Builder dient dann eher zur visuellen Kontrolle (erspart mir das starten der App)

Swing: Da setze ich mittlerweile auf den Designer von Intellij IDEA. Das GUI ist schneller zusammengeschraubt und Code sehe ich da keinen (wird bei meinem aktuellen Projekt auch glaube erst zur Compilerzeit aus XML-Daten generiert). Damit bin ich auf jeden Fall produktiver unterwegs als ohne den Designer. Habs zumindest bisher noch nicht bereut, hier auf einen Designer zu setzen.

JavaFX: Unentschlossen. Werde hier wohl anfangen wie bei Android: mit dem Designer beginnen aber immer mal wieder in den XML-Code schauen. Dann wird sich zeigen, ob ich hier von Hand meinen Code schreibe oder via SceneBuilder