GUI Entwicklung: GUI Builder oder doch lieber händisch?

[Sinus]

Hallo zusammen,

seit geraumer Zeit entwerfe ich meine GUIs meist per hand.
Gestern habe ich jedoch im Forum gelesen, dass es eigentlich nicht mehr üblich sei, die GUIs
über die konventionelle Methode zu entwickeln.
Besser wären da die eingebauten GUI Builder von Netbeans oder GUI Builder Plugins von eclipse.

Wie sieht ihr das? Sollte man tatsächlich GUI Builder verwenden?

 

[Tobse]

Der selbst geschrieben Code ist meist immer schlanker und stabiler als der, den die GUI-Bilder produzieren. Allerdings machen meine GUIs aus dem GUI-Bilder von NetBeans auf keinem PC Probleme; und bevor ich mir aneigne von Hand 100% System-Kompatible GUIs programmieren zu können verlasse ich mich lieber auf den Builder; Die Zeit, welche fürs Testen der GUI draufgeht investiere ich lieber ins Bugfixen.

 

[Joose]

Ich persönlich halte nicht viel von GUI Buildern und rate auch anderen von deren Verwendung ab (solange man diesen nicht richtig bedienen kann).

Es wird viel überflüssiger Code generiert, meist nicht wirklich sauber formatiert und ist unübersichtlich. Per Hand kann ich genauso schöne GUIs schreiben, und da bin ich nicht viel langsamer (wobei je öfter man bestimmte Sachen schreibt umso schneller, und vieles kann man auch wiederverwenden) . Ich kenne mich dann im dem Code auch aus.

Auch weiß ich nicht wie weit GUI Builder in der Zwischenzeit sind. Aber wenn ich bestimmte Größen/Weiten von Componenten zentral festlegen will, konnte das bis jetzt noch kein GUI Builder.
Und hier und da bau ich mir eine GUI auch dynamisch zusammen. In diesem Fall bringt mir so ein Builder auch nichts.

Und wenn ich mir anschaue was viele Anfänger für ach so tollen generierten GUI Code vom Builder posten ..... :autsch:. Wenn man dann mal was nachfragt bezüglich ein paar Zeilen, wissen dann viele nicht einmal warum diese drinnen ist.

 

[dzim]

Im Moment mache ich es auch wieder ohne GUI-Builder (FXGraph für die Erstellunge von FXML in Eclipse, unter Verwendung des Plugins "e(fx)clipse"). Der SceneBuilder ist sicher super toll, aber ich habe mich noch nicht mit ihm angefreundet

Aber für SWT nehme ich den WindowBuilder von Eclipse. Jedenfalls um den Rumpf einer UI zu erstellen. Das ich danach viel von Hand wieder ändere, steht auf einem anderen Blatt, aber für Rapit Prototyping ist es sehr gut geeignet!
Ich denke, das man von Hand eher einige Sachen übersehen kann und man den Code dann X-Mal testen muss, bevor man ihn einmal verwenden kann. Das geht beim GUI-builder einfach flotter von der Hand.

Swing (und erst recht AWT) fasse ich nicht mal mit Zange und Lötkolben an!

 

[Tobse]

Es wird viel überflüssiger Code generiert, meist nicht wirklich sauber formatiert und ist unübersichtlich.

Ob der bzgl. der Platform-Kompatibilität überflüssig ist weiss ich nicht, aber sauber formatiert ist der von NetBeans:

        newAccountBT = new javax.swing.JButton();
        // [...]

        newAccountBT.setFont(newAccountBT.getFont()); // überflüssig
        newAccountBT.setIcon(new javax.swing.ImageIcon(getClass().getResource("/com/wisper/desktop/resources/add.png"))); // NOI18N
        newAccountBT.setText("Create a new Account");
        newAccountBT.setFocusable(false);
        newAccountBT.addActionListener(new java.awt.event.ActionListener() {
            public void actionPerformed(java.awt.event.ActionEvent evt) {
                newAccountBTActionPerformed(evt);
            }
        });
        javax.swing.GroupLayout layout = new javax.swing.GroupLayout(this);
        this.setLayout(layout);
        layout.setHorizontalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGroup(layout.createSequentialGroup()
                .addContainerGap()
                .addGroup(layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
                    .addComponent(jLabel1, javax.swing.GroupLayout.DEFAULT_SIZE,     javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)
                    .addGroup(layout.createSequentialGroup()
                        .addComponent(newAccountBT)
                        .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)
                        .addComponent(connectBT)
                        .addGap(0, 0, Short.MAX_VALUE)))
                .addContainerGap())
        );
        layout.setVerticalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGroup(layout.createSequentialGroup()
                .addContainerGap()
                .addComponent(jLabel1)
                .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)
                .addGroup(layout.createParallelGroup(javax.swing.GroupLayout.Alignment.BASELINE)
                    .addComponent(newAccountBT)
                    .addComponent(connectBT))
                .addContainerGap(javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE))
        );

Und hier und da bau ich mir eine GUI auch dynamisch zusammen. In diesem Fall bringt mir so ein Builder auch nichts.

Aber natürlich. Ich kann nach wie vor Komponenten über die [c]add[/c] Methoden einfügen und über die definierten Klassenvariablen ansprechen.

Und wenn ich mir anschaue was viele Anfänger für ach so tollen generierten GUI Code vom Builder posten ..... :autsch:. Wenn man dann mal was nachfragt bezüglich ein paar Zeilen, wissen dann viele nicht einmal warum diese drinnen ist.

Das sehe ich änlich. Der GUI-Builder ist etwas für diejenigen, die wissen wie die GUI im Prinzip funktioniert. Wer das nicht verstanden hat wird mit einem GUI Builder nicht weit kommen. Aber gerade was kompatibilität angeht fühle ich mit dem GUI Builder immer auf der sichereren Seiten.

 

[Sinus]

ich teile Jooses Meinung. Auch für mich steht die Stabilität und die Übersichtlichkeit des Codes
im Vordergrund. Von daher bevorzuge ich das Erstellen von GUIs per Hand.
Insbesondere als Anfänger sollte man die GUIs selbst schreiben können, um einfach ein "Gefühl" dafür zu
bekommen.

Nichtsdestotrotz habe ich das Gefühl, dass der Trend eher in Richtung GUI Buildern geht:
man erreicht zwar dadurch mehr Arbeit bei kurzer Zeit, andererseits vermute ich, dass man
schnell den Überblick verliert und man später nichts mehr versteht, weil alles vom Builder selbst
generiert wird.

 

[Kiri]

Ich bin von Gui-Buildern weg, weil ich schier wahnsinnig wurde, wenn ich später etwas ändern wollte. Um mal schnell eine Vorlage zu haben, wie etwas aussehen könnte, da ist so ein Builder praktisch. Einfach als visuelle Entscheidungshilfe. Aber um später wirklich eine vernünftige Gui zu haben - mit Übersichtlichen Code - mache ich es lieber händisch! Bei Anfängern ist so ein Gui-Builder meistens eher angesagt, weil das Verständnis fehlt. Wenn du aber deine Guis selber codieren kannst, bleib dabei! Mit der Zeit geht das sogar schneller!

 

[Joose]

Ob der bzgl. der Platform-Kompatibilität überflüssig ist weiss ich nicht,
......
Aber gerade was kompatibilität angeht fühle ich mit dem GUI Builder immer auf der sichereren Seiten.

Java Code bleibt Java Code und sollte somit überall ausführbar sein wo das Java FX installiert ist.
Oder von welcher Kompatibiltät sprichst du?

aber sauber formatiert ist der von NetBeans:

        javax.swing.GroupLayout layout = new javax.swing.GroupLayout(this);
        this.setLayout(layout);
        layout.setHorizontalGroup(
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
            .addGroup(layout.createSequentialGroup()
                .addContainerGap()
                .addGroup(layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
                    .addComponent(jLabel1, javax.swing.GroupLayout.DEFAULT_SIZE,     javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)
                    .addGroup(layout.createSequentialGroup()
                        .addComponent(newAccountBT)
                        .addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.RELATED)
                        .addComponent(connectBT)
                        .addGap(0, 0, Short.MAX_VALUE)))
                .addContainerGap())
        );

Naja darüber lässt sich streiten, klar er ist übersichtlicher und besser formatiert als manch anderer Code.
Aber wenn man es genau nimmt, ist das eine(!) Zeile Code die einfach nur entsprechend formatiert wurde.
Bei sauberer Programmierung sollte es nur 1 Anweisung pro Zeile geben.
Wenn ich bei diesem Code mal etwas auskommentieren will muss ich auf die folgenden Zeilen auskommentieren, da es sonst zu Syntaxfehler kommt.

Außerdem mag ich an diesem Code nicht das alle Typen anscheinend voll qualifiziert angeführt sind. Das macht es wieder unübersichtlicher.

Und wenn ich einen Bezeichner jLabel1 sehe kommt mir auch das Grausen :autsch: ;(

Aber natürlich. Ich kann nach wie vor Komponenten über die [c]add[/c] Methoden einfügen und über die definierten Klassenvariablen ansprechen.

Hm .... schön und gut ich meinte eigentlich das ich mir im Code anhand von meinen Daten eine bestimmte Oberfläche dynamisch erstelle. Das Problem, jemand der nie auch nur GUI Code gesehen hat wird nicht wissen, wie es funktioniert.

 

[dzim]

Na wie gesagt: Für Rapit Prototyping ist es sinnvoll - wenn man dem chef schnell was zeigen muss. Und auch für Neulinge (oder wenn man deklarative UIs warten möchte; das kann per Hand sonst, z.B. mit FXML, auch recht grausam werden) ist es auch noch ok.
Wie gesagt: Für JavaFX verwende ich eigentlich nur noch FXGraph - die JSON-ähnliche DSL - und schreibe mir so auch noch ziemlich schnell (dank JavaFX-Preview in e(fx)clipse) meine GUIs zusammen. Bei den Controllern (also der Logik) kann mir ein GUI-Builder eh kaum noch helfen. Und ich würde es auch nicht wollen.

 

[Tobse]

Java Code bleibt Java Code und sollte somit überall ausführbar sein wo das Java FX installiert ist.
Oder von welcher Kompatibiltät sprichst du?

Mir ging es mit dem seblst geschriebenen GUI-Code immer so, dass auf verschiedenen Betriebssystemen/LAFs die Padding und Border Werte variierten. Dann hat man z.B. ein JScrollPane so parametrisiert, dass die ScrollBar nur kommt, wenn wirklich nötig. Unter Linux waren dann 10 pixel padding mehr mit drin und es war eine Scroll-Leiste Da. Unter Mac wars dann gerade andersherum falsch. Mit GUIs aus dem Builder ist mir das bis jetzt nicht passiert.

Und wenn ich einen Bezeichner jLabel1 sehe kommt mir auch das Grausen :autsch: ;(

Da ich meine GUIs nur da bearbeite, wo es nötig ist bin ich aus Zeitgründen dazu übergegangen, die variablen-namen von GUI-Elementen welche zur Laufzeit unverändert bleiben nicht zu ändern; ich kann im GUI-Editor ohnehin einfach draufklicken und die Parameter bearbeiten

Hm .... schön und gut ich meinte eigentlich das ich mir im Code anhand von meinen Daten eine bestimmte Oberfläche dynamisch erstelle. Das Problem, jemand der nie auch nur GUI Code gesehen hat wird nicht wissen, wie es funktioniert.

Das habe ich ja auch geschrieben. Wer nicht weiss, wie eine GUI funktioniert kann auch den GUI-Editor nicht sinnvoll bedienen.

 

[Joose]

Mir ging es mit dem seblst geschriebenen GUI-Code immer so, dass auf verschiedenen Betriebssystemen/LAFs die Padding und Border Werte variierten. Dann hat man z.B. ein JScrollPane so parametrisiert, dass die ScrollBar nur kommt, wenn wirklich nötig. Unter Linux waren dann 10 pixel padding mehr mit drin und es war eine Scroll-Leiste Da. Unter Mac wars dann gerade andersherum falsch. Mit GUIs aus dem Builder ist mir das bis jetzt nicht passiert.

Also mir ist es noch nie passiert das Swing Anwendungen auf unterschiedlichen Betriebssystemen unterschiedlich dargestellt wird. Da ich noch nie eigene L&Fs verwendet habe, weiß ich nicht wie diese sich verhalten.

Da ich meine GUIs nur da bearbeite, wo es nötig ist bin ich aus Zeitgründen dazu übergegangen, die variablen-namen von GUI-Elementen welche zur Laufzeit unverändert bleiben nicht zu ändern; ich kann im GUI-Editor ohnehin einfach draufklicken und die Parameter bearbeiten

klar, teilweise verständlich. Aber eben wenn man den Code an andere Leute weitergibt (und sei es nur ein Ausschnitt) dann muss man immer erst schauen ... welches JLabel ist denn nun gemeint, ...
Einem selbst ist das natürlich fast immer klar und schnell ersichtlich

 

[Tobse]

Also mir ist es noch nie passiert das Swing Anwendungen auf unterschiedlichen Betriebssystemen unterschiedlich dargestellt wird. Da ich noch nie eigene L&Fs verwendet habe, weiß ich nicht wie diese sich verhalten.

Ich setzte relativ and en Afang aller meiner GUI-Anwendungen folgenden code:

try
{
    javax.swing.UIManager.setLookAndFeel(javax.swing.UIManager.getSystemLookAndFeelClassName());
}
catch (ClassNotFoundException ex) {}

Und das System-LAF von Ubuntu hat deutlich andere Ausmaße als das von Windows XP oder 7. Dadurch reicht dann z.B. ein Button um 20px über die Fensterbreite heraus, etc; ist einfach lästig.

klar, teilweise verständlich. Aber eben wenn man den Code an andere Leute weitergibt (und sei es nur ein Ausschnitt) dann muss man immer erst schauen ... welches JLabel ist denn nun gemeint, ...
Einem selbst ist das natürlich fast immer klar und schnell ersichtlich

Das stimmt, ja. Code aus dem GUI-Builder nachzuvolziehen ohne seblst den GUI-Editor zu verwenden ist auch totaler Wahnsinn. Ich habe teilweise Frames mit 20 JLabels drin, von denen ich dann vllt 3 oder 4 ansprechen muss. Die anderen heissen Dann [c]jLabel1[/c] bis [c]jLabel16[/c]; auch ich habe da keinen Überblick mehr. Aber wie gesagt, im GUI-Editor genügt ein Klick.

 

[kaoZ]

Im bleib ja dabei meine GUI's von Hand zu Programmieren, dauert zwar wenn die Komplexität steigt und treibt mich stellenweise in den Wahnsinn, allerdings freu ich mich auch immer wie ein Schneekönig wenn dann alles so aussieht wie es soll, und ohne Fehler läuft

Und ich weiß dann genau der Code ist so Formatiert wie ich jeden Code Formatiere, und falls ich Bugs fixen muss weiß ich direkt wo ich ansetzen muss.

 

[Phash]

Pffff. Wenn ich ne GUI mach schaut es immer s*****e aus... Egal ob mit Builder oder per Hand.

Ich probierte immer wieder Builder aus, fand es meist unpraktisch, und mach dann das meiste doch mit der Hand.
Aber mit dem neuen scene Builder für fx ist es anders, man macht das design im Builder, aber hat den code per Hand

 

[Ruzmanz]

Kommt doch meistens auf den Anwendungsfall an. Wenn man ein System entwickelt, dass mehrere Jahre laufen soll bietet sich ein GUI-Builder an. Der liefert einen "S*****" Quellcode, aber ehrlich gesagt habe ich da schon sehr lange nicht mehr reingeguckt. Warum sollte man da auch reinschauen? Bugs gibt es aktuell keine mehr, die UI-Komponenten für die Applikation sind einheitlich gestaltet und falls es dann doch noch eine spezifische Änderung braucht, geht das mit Vererbung. Diese halten sich aber im Rahmen. Alle Metadaten sind in einer Datenbank gespeichert, sodass ich mit SQL-Statements schnell Fragen beantworten kann. Welche Textfelder/Comboboxen/etc. laden/speichern in einem bestimmten Tabellenfeld. Durch eine einheitliche Namenskonvention kann man auch sehr gut Abhängigkeiten feststellen. Wenn es mal in Richtung JavaFX geht, muss man nur noch die einzelnen Komponenten des Builders anpassen und hat nicht einen ganz so großen Aufwand, wie bei individuell gestalteten Oberflächen. Für kleine Projekte mit sehr individuellen Oberflächen lohnt sich ein UI-Designer defintiv nicht. Wobei ich eher einen eigenen Builder für eine langlebige Applikation entwerfen würde, als auf Netbeans / Eclipse zurückzugreifen.

 

[Basti90]

Hallo zusammen,

Ich weiß natürlich nicht von welcher komplexität Ihr redet - aber ich verwende den Window Builder bei dem sieht der Code anständig aus - Variablen muss man natürlich selbst ändern aber wie soll der Builder des auch bitte schön hinbekommen :lol:-
man kann durch die Auswahl an Layouts durchaus ansehnliche Guis bauen(ich spreche von guis mit 15 labels+ 15 Buttons und 12 Textfeldern teilweise in reihe teilweise frei angeordnet- da war der Window Builder nützlich). Natürlich ist es von Vorteil wenn man weiß wie ein Layout Funktioniert

Wo ich allerdings händisch gearbeitet habe war wenns sehr komplex wurde und z.b. beim größer/kleiner machen die position gehalten werden musste da dort der Builder an seine grenzen gestoßen ist.

Zugegebenermaßen bin ich auch noch kein Programmierer mit Jahrelanger erfahrung in GUIs basteln

 

[turtle]

In Swing nehme ich auch immer den Window Builder.

Dieser unterstützt den besten Layout-Manager, den ich kenne: JGoodies FormLayout

Aber da ich nun immer mehr mit JavaFX mache, nutze ich dort ebenfalls einen Builder, nämlich JavaFX Scene Builder.

Händisches Erstellen von GUI finde ich etwas archaisch

 

[dzim]

@Turtle: Probier mal (wenn du Eclipse verwenden solltest) die FXGraph-Variante aus. Ich finde, damit kann man die GUIs auch gut mit der Hand programmieren. Irgendwie macht mich der SceneBuilder nicht so richtig an ;-)