GUI-Builder shootout
Stefan Matthias Aust
Teilnehmer in dieser Runde: Eclipse Visual Editor (für Java) und
VisualStudio Express 2005 beta2 für C# sowie Matisse von NetBeans.
Aufgabe: Größenveränderbares GUI mit zwei Listeboxen und einem
Texteingabefeld in folgender Anordnung:
+--+--+
|L1|L2|
+-----+
| T |
+-----+
Erste Listbox zeigt die Klassen Object, String und Integer an, wählt man
dort etwas aus, zeigt die zweite Listbox die Methoden dieser Klasse und
wählt man eine Methode, sieht man die Signatur (in Ermangelung von
Quelltext) im Eingabefeld.
Visual Editor
-------------
In Eclipse 3.2M2 gibt es einen Fehler, wenn ich versuche, den VE 1.1
über die Update-Funktion zu laden. Also muss ich EMF 2.1.0 und GEF 3.1
sowie VE 1.1.0.1 einzelnd als ZIPs laden, in mein Eclipse kopieren und
dieses neu starten.
Unter File|New|Other... werde ich nicht nur mit dem neuen Punkt "Visual
Class" beschenkt, sondern ungewollt erhalte ich noch 3 EMF-Einträge, 4
EMF-Beispiele, ein JET-Konverter und 8 AWT, Swing und SWT-Beispiele.
Weiterhin gibt es 8 Punkte zum Anlegen von AWT bzw. Swing Applets,
Dialogen, Frames und Panels. Dieser "Bloat" missfällt mir.
Beginnen wir mit SWT, danach das selbe mit Swing.
Ich lege eine neue Visual Class für eine "Shell" mit main-Methode an. Es
dauert ca. 8 Sekunden, bis das Fenster öffnet (Im Hintergrund wird eine
zweite VM gestartet, die das echte Shellfenster anzeigt, was dann von
dem UI-Builder beobachtet wird - man sieht in der Windows-Taskbar ein
"Shell" genanntes Fenster, was man nicht öffnen kann). Die Split-Screen
Darstellung erfordert einen großen Bildschirm (oder nur kleine UIs). Auf
den ersten Blick vermisse ich eine Palette mit Steuerelementen, finde
sie jedoch nach verblüftem Suchen zusammengeklappt am rechten
Fensterrand - dummer default.
Ich plaziere meine Steuerelemente, erkenne dann das ich keinen Layout
Manager benutze. Mich stört, dass ich jedes Mal einen Namen für die
Komponenten angeben muss und daher von der Maus zur Tastatur und zurück
wechseln muss. Anderseits hat das den Vorteil, dass ich gleich
sinnvolle Namen vergeben kann.
Ich hätte erwartet, dass ich ein Layout ebenso aus der Palette auswähle,
wie andere Komponenten, doch dann suche ich in den Properties. Diese
sind standardmäßig versteckt, da sich darüber in dem Bottom-View ein
Java-Beans-View befindet. Ich schiebe diesen nach links, dort hin wo
der Outline-View ist und bin erneut verärgert über die schlechten Defaults.
Mein Vorteil ist, dass ich weiss, was die Layout Manager machen und dass
ich am besten ein GridLayout nehme. Ein Anfänger hätte hier IMHO ohne
Kenntnisse der Layout Manager keine Chance.
Wie geht's weiter? Nach etwas suchen sehe ich einen Kontextmenü-Eintrag
"Customize Layout..." der ein nicht-modales Fenster (warum keinen View
oder besser noch keine weitere Palette?) öffnet, in dem ich dem
GridLayout zwei Spalten geben kann.
Das Customize-Fenster nutze ich, um allen Steuerelementen Fill und Grab
Excess zu setzen. Direkt im Editor scheint es nicht möglich zu sein,
irgendwelche Layout-Einstellungen vorzunehmen.
Ich wähle "Run|As SWT-Application" aus dem Kontextmenü meiner neuen
Klasse und kann mein layout das erste Mal bewundern.
Lästig, dass die Steuerelemente alle keinen Rahmen haben. Wenn ich alle
drei selektiere, kann ich jedoch nicht das Border-Property setzen. Ich
kann beide Listenboxen und das Texteingabefeld selektieren. Dann kann
ich den Border in zwei Schritten einschalten. Ich setze auch gleich
noch den vertikalen Rollbalken bei den Listboxen, aber der erscheint
nicht - muss ein Windows-Problem sein.
Ich sehe keine Möglichkeit, der Liste ein Modell zu geben. SWT hat zudem
das Problem, dass ich nur mir Strings statt mit meinen gewünschten
Objekten arbeiten kann. Ich füge die folgenden Zeilen ans Ende der
Methode "createSShell" (warum wohl doppel-S?):
list1.add("java.lang.Object");
list1.add("java.lang.String");
list1.add("java.lang.Integer");
was wie gewünscht funktioniert. Danach wähle ich "Events|widgetSelected"
aus dem Kontextmenü der Liste und implementiere:
list2.removeAll();
for (Method m : methods = Class.forName(list1.getSelection()[0])
.getDeclaredMethods()) {
list2.add(m.getName());
}
sowie für die andere Liste:
textArea.setText(methods[list2.getSelectionIndex()].toGenericString());
was eine ganz krude Implementierung ist, aber für meinen Zweck
ausreichen soll. Als ich nochmal zurück zum ersten Eventhandler wollte,
wählte ich erneut "Events|widgetSelected" er bekam einen zweiten Handler
- nicht das was ich erwartet hätte.
Dummerweise bricht mein GridLayout zusammen und macht beim Resize die
gefüllte Listbox so groß, dass das Textfeld verschwindet. Ich hätte
gerne gesagt, dass beide Zeilen je 50% verbrauchen sollen, aber das
überfordert wohl den LayoutManager und ich breche ab.
Für Swing erzeuge ich einen JFrame mit main-Methode. Der UI-Builer hält
es diesmal aber nicht für nötig, hier den Code zum Öffnen des Fensters
einzutragen. Ich muss manuell
UI2 ui = new UI2();
ui.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
ui.setVisible(true);
nachtragen und bin schon mal schlecht auf diesen UI-Builder-Modus zu
sprechen. Es hilft auch nicht wirklich, dass mir die Palette immer noch
SWT-Widgets anbietet. Zumindest weigert er sich, diese zu plazieren.
Ich greife mir eine JList und erkenne, dass ich so aus zwei Gründen
nichts werde. Erstens fehlt der Rollbalken - ich muss das manuell in
JScrollPanes wrappen und zweitens ist das BorderLayout nicht, was ich
will. Komponente löschen, GridBagLayout einstellen, Customize Layout
aufrufen... wundern, dass ich diesmal dort nichts einstellen kann und
beginnen, JScrollPanes zu plazieren.
Oh, das geht nicht, wenn er bietet mir nicht an, das zweite neben dem
ersten zu plazieren sondern denkt, ich will jetzt die Komponente in dem
ScrollPane plazieren. Scheiße! Ich kann den JavaBeans-View nutzen, um
mein zweites Pane auf die selbe Ebene zu ziehen, wie das erste und dann
defaultet das Gridbag so, dass sie nebeneinander stehen. Das dritte
"Pain" landet aus versehen neben dem fenster - komisch dass das auch geht.
Ich korrigiere das im Java Beans View und zirkel eine ganze weile mit
der Maus, bis tatsächlich mal so ein gelber Einfügebalken entsteht, und
ich schaffe es, das dritte ScrollPane in eine zweite Zeile zu schieben.
Danach kann ich dann mit der Maus die Position korrigieren und das den
CellSpan des zukünfigen TextFelds auf 2 setzen.
Als nächstes muss ich - scheiß GridBagLayout - die Ränder manuell
anpassen, damit ein Rand von 10 Pixeln zum Fenster und von 5 Pixeln
untereinander entsteht. Das SWT GridLayout konnte dies direkt. Ich
werde allerdings lieber 6 Pixel benutzen, da ich sonst niemals die
beiden Listboxen gleich breit bekomme. Zumindest scheint der Default
auf "Fill-Both" zu stehen, sodass ich nicht auch noch dies ändern muss.
Jetzt kann ich die JLists und JTextArea plazieren. Wie es der Zufall
will, plaziere ich zu erste die JTextArea. Dummerweise drückt die erste
JList das zweite Feld zu null zusammen und ich kann die zweite JList
nicht mehr plazieren. Außerdem entsteht das selbe Problem wie bei SWT -
die Listen drücken mir mein textfeld zusammen und die Weight-Angaben
scheinen egal zu sein. Der LayoutManager ist IMHO ungeeignet für
grafisches Design!
Ach ja, durch die Schachtelung von ScrollPane und List kann ich
natürlich durch einen Klick auf die Liste nicht mehr auf die
Layout-Daten zugreifen, da diese zur ScrollPane gehören, die ich aber
nicht anklicken kann. Einzig die Java Beans View funktioniert noch.
Ich gebe den drei ScrollPanes einen vertikalen Rollbalken der im
Gegensatz zu SWT auch erscheint. Dann wähle ich "Run|As Java
Application" und teste mein Design.
Wie setze ich das Model - wenn ich in meinem Projekt eine
ListModel-Implementierung habe - allerdings muss es eine Toplevel-Klasse
seine, eine statische Klasse innerhalb meiner UI-Klasse geht nicht, was
ich erst lernen musste - dann kann ich die hier anbinden.
Viel hilft mir das allerdings nicht, denn mal eben
public class ClassListModel implements ListModel {
public int getSize() {
return 3;
}
public Object getElementAt(int index) {
if (index == 0) return Object.class;
if (index == 1) return String.class;
if (index == 2) return Integer.class;
throw new Error();
}
public void addListDataListener(ListDataListener l) {
}
public void removeListDataListener(ListDataListener l) {
}
}
zu implementieren, ist nichts, was ich einfach bezeichnen würde.
Ansonsten kann ich ein DefaultListModel zuweisen und in der passenden
getListModel()-Methode einfach meine Initialisierung ergänzen:
classesListModel = new DefaultListModel();
classesListModel.addElement(Object.class);
classesListModel.addElement(String.class);
classesListModel.addElement(Integer.class);
Auch nicht der Bringer, aber einfacher. Für die zweite JList - die ich
aus einem mir unbegreiflichen Grund nicht direkt im Editor anklicken
kann, ich erreiche immer nur die ScrollPane während es in der ersten
JList genau anders herum ist - definiere ich ein zweites - vorerst
leeres - Model.
Ich füge einen valueChanged-Event zur Liste hinzu und implementiere:
getMethodsListModel().removeAllElements();
for (Method m : ((Class) getJList1().getSelectedValue())
.getDeclaredMethods()) {
getMethodsListModel().addElement(m);
}
Das ist nicht so 100% MVC, aber funktioniert ausreichend gut. Besser
wäre, wenn man sich einmal etwas besseres als das DefaultListModel
schreibt, was irgendwie immer noch bei Java 1.2 und dem normalen
Collection-API angekommen ist und was auch offenbar nicht damit rechnet,
das man mal alle Elemente auf einmal austauschen möchte.
Der zweite Event-Listener ist trivial:
getJTextArea().setText(getJList2().getSelectedValue().toString());
und die Swing-Variante ist fertig. Naja, fast, ich sehe, dass die
Listbox standardmäßig im Multiselection-Mode ist - dummer default, muss
ich ändern.
Zusammenfassung: Bei SWT suckt, dass Modelle komplett fehlen - bei
Swing, dass die Modelle nicht direkt ohne weiteres Zutun benutzbar sind.
In beiden Fällen sind die LayoutManager ungenügend für mein IMHO
trivales Layout.
Man braucht intime Swing bzw. SWT-Kenntnisse, um etwas zu reißen.
Visual Studio
-------------
Mit C# 2.0 und VSE 2005 eine Window Forms-Anwendung zu bauen, bedeutet,
sofort mit dem UI zu beginnen. Es ist standardmäßig kein Quelltext zu
sehen. Wie beim guten alten VB öffnet ein "Form1", in das ich aus der
angezeigten Palette Steuerelemente draggen kann.
LayoutManager sind etwas, das neu in .NET 2.0 ist. Ich dachte bei
meinem letzten Rant über dieses Tool noch, es gäbe gar keine.
Ich plaziere ein "TableLayoutPanel" in meinem Fenster. Es popt sofort
ein Kontextpanel hoch, das mir anbietet, die Vorgabe von 2x2 Zellen zu
ändern. Ich finde die jedoch gut und frage mich eher, wie ich das Panel
fensterfüllend hinbekomme. Das Panel hat einen kleinen Knopf
("Handle"), der einen Verschiebepfeil anzeigt. Über diesen Handle kann
ich das Ding so plazieren, dass es die Standardabstände zum Fenster
einhält. Das Ding rastet da automatisch ein und zeigt so kleine
abstandhalter an. Es funktioniert ausgesprochen bequem.
Nicht so bequem ist, dass ich danach das Panel manuell über die
Properties an allen vier Rändern verankern muss, damit es bei einem
Resize seine Größe ändert.
Ich plaziere die ListBoxen und das Textfeld (es gibt nur eines und es
bietet in einem Kontextpanel an, mehrzeilig zu sein).
Genau wie das Panel muss ich jetzt diese Steuerelemente mit Hilfe der
Abstandhalter und über die Anchor-Property in dem Gitter verankern.
Alternativ könnte ich auch "Docken", doch dann habe ich keine Abstände
zwischen den Komponenten. Auch den "ColSpan" des Eingabefelds muss ich
über das Properties-Feld einstellen. Im Gegensatz zu VE, wo die
Properties einfach nur alphabetisch sortiert sind, sind diese bei VS
nach Aufgaben gruppiert und dann erst sortiert (eine einfache Sortierung
ist optional möglich).
Das die Beta-Version ab und zu mal die Anchors vergisst, macht mich ganz
kirre. Nachdem ich bei beiden ListBoxen "integral height" ausgeschaltet
habe, weil das IMHO besser aussieht, startet mein Programm nach einem
Klick auf den grünen Pfeil.
(Total lästig, VS.NET muss explizit kompilieren)
Ich habe keinerlei Programmiererfahrung mit Window Forms 2.0 und war
deswegen etwas am Suchen, wie ich jetzt Daten binde. Über das UI ist es
sehr einfach, eine Datenbank anzusprechen, aber ich will ja eine
Collection benutzen.
Schließlich finde ich nach einem Beispiel in der recht guten Doku. Ich
doppelklicke meine Form und VS.NET generiert mir:
namespace WindowsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
}
}
}
Man beachte das "partial". Der eigentliche Code, der das UI erzeugt,
liegt in einer zweiten "Form1" genannten Klasse. Auch das Binden des
Events wird dort erledigt. Ich sehe hier nur meinen Anwendungscode ohne
den ganze Boiler-Plate-Mist.
Die folgende Zeile in dem Event-Handler tut was ich möchte:
listBox1.DataSource = new Type[] {
typeof(object), typeof(string), typeof(int) };
(Und wäre es schon C# 3.0, könnte ich sogar das "Type[]" weglassen, weil
er das dann selbst inferrieren würde.)
Zurück zum UI, und ein Doppelklick auf die Liste. Ein neuer
Event-handler wird für mich generiert und ich trage dort ein
listBox2.DataSource = ((Type)listBox1.SelectedItem).GetMembers();
ein. Ehrlich, dies ist das erste Mal, dass es Spass macht, das UI zu
bauen, weil es auf diese Weise in Riesenschritten voran geht. Außerdem
frist .NET einfach, was ich ihm als Array vorgebe und ich muss nicht
erst komplizierte Modelle bauen (ich könnte jedoch, wenn ich ein
automatisches Dependency-Tracking benötigen würde).
Einen kleinen Dämper bekomme ich, als ich ganz naiv:
textBox1.Text = listBox2.SelectedItem;
für den zweiten EventHandler hinschreibe. Erst beim Starten und
Kompilieren findet er meinen Flüchtigkeitsfehler. Ich ergänze noch ein
"ToString", vergesse dort die "()", weil ich mich nicht daran gewöhnen
kann, wann ich "()" setzen muss, und wann ich das weglassen darf und
haben im dritten Anlauf endlich mein fertiges Programm.
Wäre das verankern einfacher gegangen, wäre dies der ganz klare Sieger.
Übrigens, .NETs LayoutManager ist der einzige, der mir die Spalten und
Zeilen gleich hoch hält. Es wäre auch der einzige, der Erlauben, würde,
dass ich das Zeilenverhältnis von 50:50 zu 66:34 ändere.
Nachtrag: Matisse
------------------
Das Layout geht dort sehr gut - ich schrieb bereits darüber - allerdings
hilft Matisse genau wie die andere Builder für Java nicht wirklich, mir
den Rest des Codens zu vereinfachen.
--
Stefan Matthias Aust // Ergo bibamus, ne sitiamus, vas repleamus!
Daniel Völkerts
... Interessanter Teil gesnippt.
> Nachtrag: Matisse
> ------------------
>
> Das Layout geht dort sehr gut - ich schrieb bereits darüber - allerdings
> hilft Matisse genau wie die andere Builder für Java nicht wirklich, mir
> den Rest des Codens zu vereinfachen.
Haben für die Uni ein komplexeres UI mit Matisse gemacht, nachdem wir
die Assertions abgeschaltet hatten, konnte man damit auch arbeiten. Mein
Eindruck war: Layout super gut, aber wie du schon sagtest die Anbindung
an den Code.
Mir ist negativ aufgefallen, dass ich zwar über das Propertiespanel auf
den generierten Code zugreifen und bei Bedarf 'User Code' einfügen kann,
allerdings war ich immer ziemlich verwirrt und musste erst im Original
nachsehen, wo genau er es einfügt, damit ich wusste was er von mir
erwartet. Mal eine eher OT Nachfrage: Hast du schonmal den QT Designer
probiert? Wollte den immer mal in Verbindung mit Ruby testen, dass
könnte noch eine nette Kombination werden (trotz teilweise kommerzieller
Lizenz).
Gruß,
Daniel
Stefan Matthias Aust
> erwartet. Mal eine eher OT Nachfrage: Hast du schonmal den QT Designer
> probiert? Wollte den immer mal in Verbindung mit Ruby testen, dass
> könnte noch eine nette Kombination werden (trotz teilweise kommerzieller
> Lizenz).
Habe Qt4 inklusive Designer für Windows hier installiert, aber mehr als
ein bisschen darauf herumgeklickt habe ich nicht. Wenn du GUIs für Ruby
machen willst würde ich Glade empfehlen - ist zwar GTK/Gnome, aber dafür
ist dieser Designer einfach und gut zu bedienen.
Daniel Völkerts
> Habe Qt4 inklusive Designer für Windows hier installiert, aber mehr als
> ein bisschen darauf herumgeklickt habe ich nicht. Wenn du GUIs für Ruby
> machen willst würde ich Glade empfehlen - ist zwar GTK/Gnome, aber dafür
> ist dieser Designer einfach und gut zu bedienen.
Jepp, werde ich machen. Hab hier zum Testen mal ein Ubuntu 5.10
aufgesetzt und werde mal versuchen a) das Qt Binding nach Win zu
portieren und b) Glade unter Linux testen. Hatten heute an der FH ne
Präsentation und eine Gruppe hatte die Sachen auch mit Glade gemacht.
Sehr nett, Hauptvorteil von Qt wäre für mich, dass das Windows LAF sehr
gut unterstützt wird.
Gruß,
Daniel
Stefan Matthias Aust
> Präsentation und eine Gruppe hatte die Sachen auch mit Glade gemacht.
> Sehr nett, Hauptvorteil von Qt wäre für mich, dass das Windows LAF sehr
> gut unterstützt wird.
Siehe http://gtk-wimp.sourceforge.net/screenshots/. Ich habe hier bei
mir Mono installiert und da ist auch GTK dabei und das wiederum kommt
mit "gtk-wimp" und das hat IMHO so etwa die Qualität des Windows-LAF von
Java 1.4 :) Auf den ersten Blick gut genug.
Daniel Völkerts
> Siehe http://gtk-wimp.sourceforge.net/screenshots/. Ich habe hier bei
> mir Mono installiert und da ist auch GTK dabei und das wiederum kommt
> mit "gtk-wimp" und das hat IMHO so etwa die Qualität des Windows-LAF von
> Java 1.4 :) Auf den ersten Blick gut genug.
Nett, danke für den Link. Dann relativiert sich meine Aussage ;) Mal
sehen wie flott man damit was machen kann. Träume immer noch von einem
Rails für Desktop ;) (in einer Java-VM?)
Gruß,
Daniel
Stefan Matthias Aust
der Implementierung her - jedenfalls nicht der, die in dem Buch
beschrieben ist. Aber grundsätzlich finde ich diesen Ansatz sehr
interessant, um schnell etwas lauffähiges zu haben.
Erinnert übrigens total an das UI von Self und den dort verfolgten
explorativen Programmierstil.
Daniel Völkerts
> Dann schau dir mal vom Konzept "nakedObjects" an - nicht unbedingt von
> der Implementierung her - jedenfalls nicht der, die in dem Buch
> beschrieben ist. Aber grundsätzlich finde ich diesen Ansatz sehr
> interessant, um schnell etwas lauffähiges zu haben.
Mmm, waren das nicht Persitenzklassen? Momentan bin ich erstaunt, wie
schnell ich mit Eclipse, Omondo und Db4o sein 'könnte'.
Mal sehen, auf jeden sehr spannend die Produkitivität zu steigern ;)
Gruß,
Daniel
Stefan Matthias Aust
> Stefan Matthias Aust schrieb:
>> Dann schau dir mal vom Konzept "nakedObjects" an - nicht unbedingt von
> Mmm, waren das nicht Persitenzklassen?
NO hat zwar auch automatisch Persistenz, aber der Schwerpunkt hier liegt
auf dem automatischen Erzeugen von UIs für Objekte basierend auf
Konventionen und Annotationen sowie - und das ist das wichtigste - dem
automatischen zur Verfügung stellen von Operationen auf den Objekten.
Alfred
> Willkommen zu meinem subjektiven GUI-Builder shootout.
>
> Teilnehmer in dieser Runde: Eclipse Visual Editor (für Java) und
> VisualStudio Express 2005 beta2 für C# sowie Matisse von NetBeans.
GUI-Builder braucht kein Menschl.
Alfred
Kroll, Michael
> GUI-Builder braucht kein Menschl.
nette Aussage, aber warum ?
Es kann manchmal einfacher sein sich eine Oberfläche schnell zusammen zu
klicken, wenns auch nur als Test dient.
Gruss
Michael
Alfred
> Hallo,
>
>> GUI-Builder braucht kein Menschl.
>
> nette Aussage, aber warum ?
> Es kann manchmal einfacher sein sich eine Oberfläche schnell zusammen zu
> klicken, wenns auch nur als Test dient.
1. Es genügt sich den produzierten Source anzusehen.
(bitte nicht ohne Schutzbrille)
2. Das merkst du spätestens, wenn dein Click-Dummy nicht
das tut was du erwartest. (viel Spaß beim Debuggen)
3. Bei "handgeschreibenen" GUI's versteht man auch bis in's
Detail, wie sie funktionieren.
4. Es ist z.B. mit dem FormLayout sowas von banal auch komplexere
Eingabemasken etc. zu erstellen, daß man den Buildern klar überlegen
ist.
Alfred
Bernd 'Nexos' Dutkowski
Steffen Ramlow
> Schonmal http://www.jformdesigner.com/ angeschaut?
> Deiner Argumentation nach sicher nicht.
Bernd, du weißt doch, Alfred ist hier der Gruppenkasper und als solcher darf
er nichts von Tools wissen, die einem gewisse Arbeiten erleichtern können.
Man sollte gar davon ausgehen, dass er seine Postings in 'ner Telnet-Console
schreibt >:)
--
Sport frei!
http://www.fightclub-berlin.de
Alfred
> Schonmal http://www.jformdesigner.com/ angeschaut?
> Deiner Argumentation nach sicher nicht.
Ich hab eben einen eigenen Erfahrungsschatz und einen
Kopf zum Denken. Wozu braucht es da irgendwelcher Zitate?
Von denen kursieren hier doch mehr als genug.
Alfred
Alfred
> Man sollte gar davon ausgehen, dass er seine Postings in 'ner Telnet-Console
> schreibt >:)
Das kannst du wohl nicht? Oder brauchts für deine Postings
etwa auch eines Maus-Klick-Und-Drops Programmes?
Alfred