Gui-Builder

[Logaff]

hiho,

1.)ich wollte wissen ob es ehr zu empfehlen ist den Code für die Oberfläche selbst zu schreiben oder ob es oki ist den code vom gui-builder bei netbeans zu verwenden?

2.)gibst irg wo noch paar gute tuts für oberflächen ausser in "Java ist auch eine Insel"?

 

[noobadix]

Es ist sicherlich oki das zu googlen, weil die Fragen schon oft beantwortet worden sind. Ich habe ganz naiv "java obeflächen tutorial" gegooglet und brauchbare Ergebnisse erhalten.
Die Frage, wie viel Kontrolle ergo Wissen über GUI du brauchst musst du dir selbst beantworten.

Hier im Forum gibt es auch eine Kategorie "Tutorials/Quiz/FAQ", in der zunächst folgendes lesenswert ist:

http://www.java-forum.org/entwuerfe/94299-faq-swt-swing-grundlegende-informationen.html

 

[chalkbag]

Servus,

das wird sicherlich jetzt eine Grundsatzdiskussion.

ich persönlich klicke gerne im Windows Builder Pro (eclipse, kostenlos) erstmal die Oberfläche zusammen.
Danach strukturiere ich aber gerne den Code in einzelne Klassen um, auch kann man nicht alles in den Gui Buildern einstellen (z.B. SplitPlane hab ich über den Editor nicht hinbekommen). Danach war der Gui Builder oft nicht mehr zu verwenden, da er die ganzen Klassenbeziehungen nicht mehr auflössen konnte.

Für den Window Builder Pro gibts paar gute Beispiele, an sich ist er aber relativ selbsterklärend.
WindowBuilder User Guide - Google Web Toolkit - Google Code

 

[twseitex]

Hallo,
ich dreh den Spiess mal um.
Mangels irgend einem GUI-Konzept als Baustein in Java SE habe ich mir die GUI-Komponenten
selbst programmmiert, und zwar so, dass sie dynamisch fütterbar sind. Ich habe also Fensterelemente,
Buttons und Titels etc. als Klassen abgebildet und vereinigt, so dass per Konstruktur der Klassen
das Layout der GUI festgelegt werden kann. Also nichts anderes als ein GUI-Bilder, aber komplett
dynamisch. Die GUI ist in einem Applet gelandet.

Der Haken ist woanders.
Alle GUI-Komponenten müssen synchronisiert werden - von Fenster bis hin zum Button und allen
Events. Und dabei ist die GUI ja variabel. Also wurden eine Menge von Threads programmiert, die
parallel laufen.
Ergo GUI-Builder ohne synchronisierende Threads geht nicht.

Der nächste Haken: Wenn man die GUI mit der eigentlichen Aufgabe verbindet z.B. einem
Soundplayer, welche ebenfalls Threads nutzt UND mit den Threas der GUI synchronisert
werden muss. Bei Applet muss dieses auch noch periodisch in der GUI refresht werden.

Java AWT ist alles andere als perfomance. Und J-Element auch wenig.

Wer also eine GUI plant, die statisch ist, soll einen GUI-Bulder nehmen.
Wer also eine GUI plant, die komplett dynamisch ist, muss selbst Hand anlegen,
da Java SE so gut wie nichts von sich aus kombiniert.

Tutorials dazu gibt es nur grundlegende. Die Feinheiten muss man sich selbst
erarbeiten u.a. per Java-Doc zum Java-Release. Das kostet Zeit und Durchhaltewille.

Ich nutze Eclipse Helios und Java SE, also kein Java FX etc.

Damit die obige Erklärung auch beweisbar wird: Auf meiner Webseite
twseiten.com audio, flash and java findest Du den Beweis der dynamischen
GUI-Programmierung OHNE GUI-Builder. Der Java Player ist fast frei in der
GUI ausgestaltbar (siehe Beschreibungen). Und der Player frisst reichlich
Ressourcen.

Am besten das Applet downloaden und austesten. Das Applet ist free.
Die Konfiguration der GUI ist etwas kompliziert, da diese ja komplett
dynamisch programmiert wurde. Dafür sind GUI-Elemente ziemlich
frei ausgestaltbar.


Ciao !

P.S. mit Adobe Flash 5 kann man manche Sachen erheblich einfacher machen, wenn man es
im Zeitraum einer Trial schafft. Ansonsten kostet Flash ne Menge Geld.