Hi,
ich möchte während mein Programm läuft das Look & Feel ändern. Mit:

Code :

1 2	UIManager.setLookAndFeel(Look and Feel Class Name Here); SwingUtilities.updateComponentTreeUI(JFrame goes here);

klappts soweit ganz gut, nur leider wird der Inhalt der Textarea nicht angepasst und ein Label wird auch nicht angepasst. Die anderen Komponenten wie Menüleiste, Labels und Buttons werden angepasst.
Ich hoffe mir kann jemand helfen.

Gruß
ICHE9

Ich hab das selbe Problem. In meiner Applikation habe ich ein Menü integriert bei dem mehrere Look and Feels zur Auswahl stehen. Nun möchte ich das beim klicken auf eines der Look and Feels sich die GUI auch ändert, doch das funktioniert nicht sauber. Oft bleiben einige Komponente dem alten Look and Feel verfallen oder ändern sich zwar, doch die Konturen oder Farben bleiben die des alten Look and Feel.

Ich frag mich jetzt, ob es neben SwingUtilities.updateComponentTreeUI eine weitere möglichkeit gibt. Vieleicht irgend ein Reset oder so, damit sich die gesammte GUI wie beim neustart aufbaut?

Zurzeit hab ich die Notlösung die dem Anwender sagt, er solle die Applikation neustarten um die Änderungen wirtksam zu machen. Doch fällt es mir schwer zu glauben das bei dieser ausgezeichneten Swing API es doch nicht eine alternative, on-the-fly Lösung gibt

Es gibt noch irgendwas mit revalidate oder validate... probier das mal

Die Frage ist hier viel mehr auf welchen Container du updateComponentTreeUI anwendest. Im FileChooserDemo wird dies auf das JFrame angewendet. Versuche das mal.

Ich wende die SwingUtilities.updateComponentTreeUI auf einen JFrame. Bei den default Look and Feels sehe ich keine Schwierigkeiten, eher wenn ich externe Look and Feels einsetze. Weil aber beim neustart auch alles wunderbar funktioniert müsste es doch möglich sein das irgendwie zu reseten.

Die FileChooserDemo auf Oracle (FileChooserDemo.java) hilft nicht wirklich weiter weil die Demo nicht einmal SwingUtilities.updateComponentTreeUI einsetzt geschweige irgendwo das setLookAndFeel. Kann es sein das du dich auf ein anderes Projekt bezogen hast?

Validate hat beim JFrame auch nicht zum gewünschten effekt geführt.

Ein Problem hatte ich letztes mit dem Tonic Look and Feel das beim JToolBar den zwischenraum mit add(Box.createHorizontalGlue) ignoriert. Dieses Verhalten bleibt auch bestehen wenn wieder zum Metal Look and Feel gewechselt wird (deshalb die Idee mit dem reseten). Provisorisch hab ich jetzt aber mal das Tonic Look and Feel rausgeschmissen.

Probleme macht auch das Napkin Look and Feel weil beim zurückschalten auf das Metal Look and Feel bleiben die Konturen der Buttons dem alten Napkin Look and Feel treu. Ich glaube ich werde um einen Reset nicht herum kommen, fragt sich nur wie das funktioniert. Technisch müsste das eigentlich möglich sein, weil beim neustart alle Look and Feels sauber funktionieren.

Und ich hab da noch eine Frage, gibt es eine Methode die alle Root Komponente auflistet? Oder muss ich wie beim dynamischen i18n Ansatz (hier beschrieben) mit Listener arbeiten die beim wechseln der LAFs allen Root Komponenten informieren sie sollen sich selbst mit SwingUtilities.updateComponentTreeUI updaten?

Zitat von xoom4

Die FileChooserDemo auf Oracle http://download.oracle.com/javase/tu...ooserDemo.java hilft nicht wirklich weiter weil die Demo nicht einmal SwingUtilities.updateComponentTreeUI einsetzt geschweige irgendwo das setLookAndFeel. Kann es sein das du dich auf ein anderes Projekt bezogen hast?

JA -.-' *Kopf @ Tastatur* ...
... nämlich auf das hier : %JDK_HOME%/demo/jfc/FileChooserDemo/
Falls du es jemals für nötig gehalten hast dir diesen Ordner überhaupt anzusehen -.-'

Und wie sieht es aus wenn du folgendes machst :
1) JFrame.updateComponentTreeUI()
2) JFrame.validate()
3) JFrame.update(JFrame.getGraphics())

sollte EIGENTLICH funktionieren.

Ansonsten auch die Frage : passiert dir das auch wenn du zwischen den bereits vorinstallierten L&F umschaltest oder nur wenn du ein CUSTOM-L&F verwendest ? Falls ja : fehlerhafte implementierung der CUSTOM-L&F

Hab die Demo gefunden, wusste halt nich das beim Diablo JDK (JDK für FreeBSD) auch Demos mit geliefert werden. Aber es wird wohl an der implementierung an den Custom L&Fs liegen weil auch mit JFrame.updateComponentTreeUI, JFrame.validate und JFrame.update(JFrame.getGraphics) bleibt das Problem bei den Custom L&Fs bestehen. Bei den integrierten L&Fs scheint alles zu funktionieren, zumindest soviel ich testen konnte.

Werde nun halt eine on the fly änderung implementieren für Look and Feels die das unterstützen und diejenigen die einen neustart benötigen den Anwender mit einer MessageBox informieren das ein neustart nötig sei um das Look and Feel einzusetzen.

Ähm ... warum verwendest du kein Sun Java ?
Falls du das RPM nicht installiert bekommst nimm das extract-Binary ... dieses entpackst du dann mit root in /opt/sun-jdk-1.6_xx und setzt mit (update-)alternatives java , javac , jar und das Java-Plugin ...
Falls du da genauere Infos brauchst kann ich dir da gerne helfen.
Da ich jetzt so keine Links zu den Custom-L&F hab kann ich natürlich nicht prüfen ob es daran liegt. *Das hättest du auch gleich in den ersten Post schreiben können.* Falls es mit dem Sun-JDK läuft solltest du dein Programm so schreiben das du darauf prüfst und bei einem Fehler eine Warnmeldung ausgibst das ein Sun-JDK verlangt wird *sehr einfach : einfach eine Klasse aus sun.* oder com.sun.* laden > bei Fehlschlag : KEIN Sun*.
Falls selbst das Sun-JDK nicht liegt es tatsächlich an den implementierungen.

Bei FreeBSD (ist kein Linux) gibts zwei Ports für SUN, zum einen das linux-sun-jdk16 und das diablo-jdk. Das erste ist die offizielle JDK von SUN und läuft auf einer Application Binary Interface (ABI), also einem Linux Emulator auf FreeBSD. Das zweite ist die native Java unstertützung für FreeBSD die auf den gleichen Quellcodes wie SUN ausgelieferte Linux basiert (die haben dafür eine Sonderlizenz mit SUN verhandelt, siehe Link). Deshalb sollte es geientlich kaum unterschiede zwischen Diablo JDK und dem SUN JDK für Linux geben. Diablo JDK bestand auch den "Sun's Compatibility Test Suite".

Aber ich werden jetzt doch noch das linux-sun-jdk16 installieren und dann wissen wir es genauer

Das sind die externen Look and Feels die ich zurzeit einsetze:
com.easynth.lookandfeel.EaSynthLookAndFeel
net.sourceforge.napkinlaf.NapkinLookAndFeel
com.nilo.plaf.nimrod.NimRODLookAndFeel
com.pagosoft.plaf.PgsLookAndFeel
ch.randelshofer.quaqua.QuaquaLookAndFeel
de.muntjak.tinylookandfeel.TinyLookAndFeel

Also ich habe ALLE L&F ausprobiert. Einige sehen sogar ganz gut aus. Aber ich bleibe dann doch stilbewusst beim Sun-Standard "Metal-L&F".
Ich habe alle L&F ins 2D-Demo geladen in dem man ja das L&F dynamisch ändern kann. Beim dynamischen Umschalten traten keine Darstellungsfehler auf. Es kann aber auch daran liegen das ich mit -Dsun.java2d.d3d=false das 3D-Rendering deaktiviert habe weil mein ATI-Triber v11 mit CCC2 extreme Probleme verursacht. Beim danymischen Laden hat das ändern gedauert ... aber falls das L&F zum Boot bekannt ist gehts sehr schnell.

Hast du beim Napkin Look and Feel mal zurück auf das Metal Look and Feel geschaltet? Dort ändern sich bei mir die Konturen der JButton's nicht wie gewünscht zum Metal zurück (also es bleiben die ungerade Konturlinien statt gerade Konturlinien).

Ja, einige LAFs sehen gut aus, mir gefällt besonders das Quaqua oder das TinyLaF mit dem integrierten Theme Editor (siehe Anhang). Und weil eben die Geschmäcker so verschieden sind will ich dem Anwender die Qual der Wahl lassen welches LAF er möchte
Ich bin aber überascht das es so wenige davon gibt. Vergleicht man es mit Desktop Themes wie KDE oder der Gtk API gibt es dort viel mehr sogenannte "LAFs".

Bezüglich der Installation von linux-sun-jdk16 muss ich eine weile warten, die Makefiles des linux-sun-jdk16 Ports scheinen beschädigt zu sein. Mal hoffen der Maintainer hat das demnächst fixed, dann kann ich endlich mal Nimbus ausprobieren weil diablo-jdk16 noch Update 7 ist

Maintainer ? .. öhm WHAT ?
Willst du mir jetzt verraten das du da nicht mal an deinem Rechner sitzt und dem zufolge natürlich auch keine Admin-Zugriffe hast oder verstehe ich da grad etwas falsch ?

Hihihi, nein, ich bin schon mein eigener Admin

Maintainer bzw. Ports-Maintainer werden im FreeBSD-Universum diejenigen genannt die die Ports betreuen (siehe Artikel). Und bei Ports handelt es sich nicht um die Netzwerk-Ports sondern um die FreeBSD Ports Collection was eine Sammlung von Makefiles ist die die compilierung und Installation von Drittsoftware managen (auch das automatische downloaden der Quellcodes oder Deinstallation). Diese Makefiles sind nötig damit für FreeBSD die Drittsoftware nach den Normen des Betriebsystem installiert werden. Also Bsp. das alle Software nach /usr/local installiert werden und nicht einfach wild im Verzeichnisbaum (Ordnung muss sein ). Neben den Ports gibts aber natürlich auch vor compilierte Binärpackete, doch eben nicht zu allen Drittsoftware weshalb man oft über die Ports Collection die Drittsoftware installiert.

Gut ... und warum nutzt du dann BSD wenn du um seine Mängel weist ?
Du brauchst dich nicht wundern wenn irgendwelche Java-Module die EIGENTLICHT für eine aktuelle Sun-JRE geschrieben sind unter einem selbstgestricktem und veraltetem Hobby-Bastler-System nicht einwandfrei laufen.

Ich würde mich aber bei solch gravierenden Mängeln GANZ SCHNELL nach nem anderen OS umsehen. Ein OS für das dierekt keine Software entwickelt wird und auf dem man aber auch keine Software seines Vorfahren Unix und seines Verwandeten Linux ausführen kann ... so etwas ist für einfach nur MINDERWERTIG.

Das ist doch quatsch, wenn FreeBSD ein sogennanten Hobby-Bastler-System sein soll fragt sich nur warum Yahoo für seine Webserver und Microsoft für seinen Hotmail Dienst genau dieses Betriebsystem einsetzt und nicht ihre eigene wie Window Server Edition

Die Linux ABI von FreeBSD ist ausgezeichnet und das linux-sun-jdk16 (jdk-6u26-linux-i586.bin) läuft einwandfrei auf dieser ABI. Nicht vor all zu langer Zeit hatte ich mal NetBeans drauf laufen. Das es jetzt nicht funktioniert liegt überhaubt nicht am Betriebsystem sondern an einem Fehler der geschriebenen Makefile für den Port. Ich schätze das der Port-Maintainer ein Tippfehler gemacht hat, weil bei der Installation er nach der jdk-6u26-linux-i586.bin sucht und obwohl die Datei unter /usr/ports/distfiles/ liegt findet er sie nicht und meldet das die Datei vermisst wird. Deshalb kann der Installationsprozess nicht fortgesetzt werden.
Das hat also überhaubt nichts mit der SUN JRE/JDK zu tun, sondern ist ein menschlicher Fehler der halt mal bei 22'462 verwalteten Ports passieren kann. Jetzt das gesammte Betriebsystem deswegen als Mangelware abzuwstempfeln ist nicht fair nur weil es nicht soviele Mitwirkende wie bei den Linux Distributionen hat die innerhalb Sekunden alles reparieren . Das FreeBSD jetzt vieleicht nicht die beste wahl für die Java Entwicklung ist weil SUN bzw. jetzt Oracle primär Mainstream Betriebsysteme mit ihrer JRE/JDK unterhält mag sein. Aber deswegen ein ausgezeichnetes Betriebsystem mit dem ich sehr zufrieden bin und in vielen belangen einen sehr guten Dienst erfüllt auszutauschen kommt bestimmt nicht in Frage. Ok, nicht ganz, ich will demnächst zu NetBSD wechseln