Java Swing: Bei L&F Änderung verschwindet Rahmen ums Programm?

[Teelicht]

Hallo, ich lass mich auch mal wieder sehen ^^

Ich hab da ein Java Programm, in dem ich dem Benutzer ermögliche, zur Laufzeit den L&F zu verändern. Wenn ich das aber tue, verschwindet beim Nativen und beim Motif L&F plötzlich der Rahmen und die Titelleiste des Programms. -.-

Wie kann ich das verhindern?

Anmerkung: Der komplette Quellcode und das Programm kann, wenn nötig, unter http://193.22.164.98/real/reader/ gedownloadet werden. Der Quellcode ist etwas umfangreich, auch weil ich noch nicht so gut bin. Ich werd ihn irgendwann am Ende nochmal optimieren.


// Schritt 3: Das Interface mit Reaktionen verknüpfen
/** <p> Die Funktion actionPerformed(ActionEvent):void verknüpft die Benutzereingaben
* mit bestimmten Reaktionen des Programms. </p>
*/


public void actionPerformed(ActionEvent e) {
if (e.getActionCommand().equals("MNQuit")) {
cQuitApp();
}
else if (e.getActionCommand().equals("MNInfo")) {
cInfo();
}
else if (e.getActionCommand().equals("MNLFJava")) {
cLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");
}
else if (e.getActionCommand().equals("MNLFMetal")) {
cLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");
}
else if (e.getActionCommand().equals("MNLFMotif")) {
cLookAndFeel("com.sun.java.swing.plaf.motif.MotifLookAndFeel");
}
else if (e.getActionCommand().equals("MNLFNative")) {
cLookAndFeel("Native");
}
else if (e.getActionCommand().equals("MNOpen")) {
cOpen();
}
}

// Schritt 4: Die Reaktionen
/* Die c-Methoden sind verantwortlich für die Reaktionen des Programms auf
* bestimmte Benutzeraktivitäten und ~eingaben.
*/
/** <p> cLookAndFeel ermöglicht dem Benutzer, das LookAndFeel der Anwendung
* zur Laufzeit auszuwählen. </p>
*/
private void cLookAndFeel(String LookAndFeel) {
if (LookAndFeel.equals("Native")) {
JFrame.setDefaultLookAndFeelDecorated(false);
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
SwingUtilities.updateComponentTreeUI(thereader);
thereader.pack();
thereader.setSize(640, 480);
Dimension d = thereader.getToolkit().getDefaultToolkit().getScreenSize();
thereader.setLocation(d.width / 2 - 320, d.height / 2 - 240);
thereader.setVisible(true);
}
catch(Exception e) {};
}
else {
try {
JFrame.setDefaultLookAndFeelDecorated(false);
UIManager.setLookAndFeel(LookAndFeel);
SwingUtilities.updateComponentTreeUI(thereader);
thereader.pack();
thereader.setSize(640, 480);
Dimension d = thereader.getToolkit().getDefaultToolkit().getScreenSize();
thereader.setLocation(d.width / 2 - 320, d.height / 2 - 240);
thereader.setVisible(true);
}
catch(Exception e) {};
}
}

[Gekiganger]

Hi,

diese 3 Zeilen:

JFrame.setDefaultLookAndFeelDecorated(false);
sorgen dafür, dass Rahmen und Titelleiste verschwinden. Das benutzt man häufig dafür, eigene Titelleisten einzubinden.

[Teelicht]

Danke an dich, dass du dich durch den Quelltext gewühlt hast :)

Also ich hab jetzt alles, wo setDefaultLookAndFeelDecorated stand, rausgenommen. Wenn ich das auf true gestellt hatte, hat er nämlich den selben Fehler gemacht.

Also meine Titelleiste hab ich jetzt überall, so weit, so gut, aber eigentlich wollte ich beim Metal L&F auch die Metal L&F Titelleiste. Jetzt macht er mir den Inhalt des Fensters im Metal L&F und den Rest im Nativen Betriebssystem L&F.

Ich hab schon verschiedene Fallunterscheidungen versucht, bei denen ich z.B. das JFrame.setDefaultLookAndFeelDecorated(true); gesetzt habe, wenn der L&F Metal war, oder ich habe in der creator-Funktion das DefaultLookAndFeel true gesetzt, wenn eine Boolean true ist, wobei ich diese Boolean je nach L&F true oder false gesetzt hab. Bisher hat nichts davon so funktioniert wie ich es haben will.

Also, gibts da ne Möglichkeit, die Titelleiste bei Metal L&F auch im Metal L&F erscheinen zu lassen, bei anderen L&F's aber halt im entsprechenden L&F? Wenn nicht, ist es nicht schlimm, ich hab ja immerhin überall eine Titelleiste, das macht mich ja schon froh ^^ ;)

[Jesus_666]

Ich würd's lassen. Mich persönlich nervt es, wenn meine Fensterdekoration mit irgendwas anderem ersetzt wird, wo am besten auch noch die ganzen Knöpfe woanders sind (bei mir sind sie links, das hab' ich vom Mac übernommen).

[Teelicht]

na gut :)

aber eine frage hab ich dann noch: was meinst du mit "wo am besten auch noch die ganzen Knöpfe woanders sind" ? Wo die Buttons etc. einer Anwendung sind, ist doch Sache der Anwendung, nicht des Betriebssystems... klar gibt es da quasi-Standarts, aber der Ort dieser Elemente ist doch unabhängig vom Look&Feel und Betriebssystem? Welche "Knöpfe" sind bei dir denn links?

[Lukas]

OS X (und fast jeder Window Manager für Linux, wenn man ihn entsprechend konfiguriert), lagern die Knöpfe für das Schließen, Minimieren und Maximieren von Fenstern links in der Dekoration. Da Windows sie aber rechts lagert, wird rechts von vielen Leuten, die eigene Fensterdekos bauen, als Standard angesehen. Das nervt dann, wenn man die im Normalfall links liegen hat. Aus diesem und ähnlichen Gründen sind eigene Fensterdekos fast immer eine schlechte Idee.

[Dingsi]

na gut :)

aber eine frage hab ich dann noch: was meinst du mit "wo am besten auch noch die ganzen Knöpfe woanders sind" ? Wo die Buttons etc. einer Anwendung sind, ist doch Sache der Anwendung, nicht des Betriebssystems... klar gibt es da quasi-Standarts, aber der Ort dieser Elemente ist doch unabhängig vom Look&Feel und Betriebssystem? Welche "Knöpfe" sind bei dir denn links?Du willst also, dass jede Anwendung auf deinem Rechner vollkommen selbst entscheidet wo sie was hintut und du jedes mal erstmal das Handbuch komplett durchlesen musst, bevor du mit einem Programm klar kommst?
Okay.
Wer braucht schon Benutzerfreundlichkeit?

[Gekiganger]

@ Jesus
Finde deinen Post nicht so toll.
Entweder man gibt eine Antwort auf die Frage oder man lässt es sein. Aber zu sagen, dass man es nicht machen sollte ist das unnötigste was man tun kann.
Ich muss das auch leider oft hier im Forum lesen, dass wenn bestimmte Leute etwas nicht wissen, sie den Fragesteller lieber zum aufgeben bewegen wollen, anstatt eine Lösung zu finden... -_-'


@ .Mi
Die Decoration wird beim instanzieren eines neuen Frames/Windows übernommen, soviel ich weiß kann sie danach aber nicht mehr für den erstellten Frame geändert werden.
Dazu müsstest du einen neuen laden und den alten dafür zerstören.
(kennt man ja von anderen Applikationen, die sich erst schließen und danach selbst neu starten, wenn man das Design geändert hat)
Ich frag morgen im Betrieb aber nochmal nen Java Guru was er dazu meint, eventuell kennt er ja ne elegantere Lösung. Falls es was zu berichten gibt, lasse ich es dich wissen.

[Jesus_666]

@ Jesus
Finde deinen Post nicht so toll.
Entweder man gibt eine Antwort auf die Frage oder man lässt es sein. Aber zu sagen, dass man es nicht machen sollte ist das unnötigste was man tun kann.
Ich muss das auch leider oft hier im Forum lesen, dass wenn bestimmte Leute etwas nicht wissen, sie den Fragesteller lieber zum aufgeben bewegen wollen, anstatt eine Lösung zu finden... -_-'
Du übersiehst den Unterschied zwischen "Ich weiß nicht, wie das geht. Laß' es lieber" und "Das würde einigen Benutzern sauer aufstoßen. Laß' es lieber". Meine Kritik (die übrigens von masterquest sehr gut vervollständigt wurde) bezog sich eben darauf, daß eigene Fensterdekos dazu neigen, den Einstellungen des Users zuwiderzulaufen - was einem geringen aber spürbaren Ergonomieverlust gleichkommt.

Es wäre natürlich eine Lösung einfach eine Checkbox dazuzutun, die abfragt, ob die normale Fensterdeko oder die vom LnF benutzt werden soll.

[Gekiganger]

Überleg doch bitte nochmal, wieso man eigentlich zwischen unterschiedlichen LaFs auswählen kann.
- Damit sich der User das Fensterdesign nach seinen Wünschen anpassen kann. Wenn er seine widgets eben links angeordnet haben will, so stellt er sich ein natives LaF ein, wenn er sie rechts haben will und eventuell noch ein schöneres Decoration-Design haben will, ein anderes.

Darauf bist du aber erst garnicht eingegangen. Du hast gesagt "gefällt mir nicht, ist blöd, lass es sein" anstatt eine konkrete Antwort auf die Frage zu geben.
Deine Antwort war einfach fehl am Platz und eher destruktiv denn fördernd.

[Teelicht]

naja, ganz so negativ wie gekiganger sehe ich das nciht, aber jesus_666 hat einen wichtigen punkt übersehen: man sollte sich immer alle informationen durchlesen! dann hättest du (jesus_666) nämlich auch gesehen, dass man in meiner anwendung immer das native l&f auswählen kann, siehe quellcode: man kann Java l&f (also Metal), Motif Dingsda, und das Native F&L des Betriebssytems auswählen. letzteres sollte sich genauso verhalten, wie du es bei anderen programmen gewöhnt bist.

abgesehen davon würde ich rechtsorientierte schließbuttons nie zum standart erheben, eher wohl die linksorientierten, weil ich apple fan bin :P (leider hab ich aber keinen)


Du willst also, dass jede Anwendung auf deinem Rechner vollkommen selbst entscheidet wo sie was hintut und du jedes mal erstmal das Handbuch komplett durchlesen musst, bevor du mit einem Programm klar kommst?
Okay.
Wer braucht schon Benutzerfreundlichkeit?

hey, hey, mal langsam. es bestehen grundlegende unterschiede zwischen layout und design, ich verändere nur das design, nicht das layout. auch bei mir ist die menüleiste oben, die tastenkombination für schließen strg+q usw. was das design angeht: ich persönlich finde z.b. das von winamp, quicktime und itunes besser als mein luna design und finde es desshalb gut, dass sie nicht das native design verwenden! das design hat weniger mit der benutzerfreundlichkeit zu tun, als dein beitrag erahnen lässt.


Es wäre natürlich eine Lösung einfach eine Checkbox dazuzutun, die abfragt, ob die normale Fensterdeko oder die vom LnF benutzt werden soll.

habt ihr euch einmal, wenigstens einmal, meinen quellcode angesehen?! wenigstens das bisschen, was ich gepostet hab hättet ihr überfliegen können und dabei folgende zeile entdecken können:

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

na, na, was macht diese zeile? wow, was für eine erkenntnis! *ARG* sorry, aber genau DAS finde ich dann doch schon beschissen! ich finde es auf der einen seite gut, dass du so denkst, wie du denkst, jesus_666, aber eines kann ich doch als beitragsschreiber verlangen: das du den ganzen beitrag liest, oder? oder hab ich jetzt was falsch verstanden? so kompliziert war dein satz doch nicht?


Ich frag morgen im Betrieb aber nochmal nen Java Guru was er dazu meint, eventuell kennt er ja ne elegantere Lösung. Falls es was zu berichten gibt, lasse ich es dich wissen.

danke, find ich cool :)

[Jesus_666]

naja, ganz so negativ wie gekiganger sehe ich das nciht, aber jesus_666 hat einen wichtigen punkt übersehen: man sollte sich immer alle informationen durchlesen! dann hättest du (jesus_666) nämlich auch gesehen, dass man in meiner anwendung immer das native l&f auswählen kann, siehe quellcode: man kann Java l&f (also Metal), Motif Dingsda, und das Native F&L des Betriebssytems auswählen. letzteres sollte sich genauso verhalten, wie du es bei anderen programmen gewöhnt bist.
Nur unter Windows und OS X. Unter allen anderen Unixartigen (also auch unter Linux) sieht Sun als System-LnF Motif vor. Außerdem fummeln bei mir alle anständigen Java-Anwendungen nicht an der Fensterdeko rum - die ist bei mir nämlich die von meinem Fenstermanager und nicht die von Java. Also sollte zumindest die Möglichkeit gegeben sein, daß das Programm nicht versucht, zwingend die Fensterdeko zu überschreiben. "Nativ" bedeutet mit Swing unter Linux nämlich "pottenhäßlich und nicht annähernd mit dem Rest des Systems integriert". Und das wird sich frühestens mit Java 1.6 ändern.
Es gibt zwar ein LnF, das versucht, über GTK zu rendern, aber a) ist es nicht das "native" LnF für Linux und b) läuft es nicht mit allen GTK-Stilen.


was das design angeht: ich persönlich finde z.b. das von winamp, quicktime und itunes besser als mein luna design und finde es desshalb gut, dass sie nicht das native design verwenden! das design hat weniger mit der benutzerfreundlichkeit zu tun, als dein beitrag erahnen lässt.
Kommt drauf an. In der Windows-Welt interessiert sich niemand für Konsistenz, nicht mal Microsoft. Auf anderen Plattformen ist es hingegen anders: Ein OS X-User möchte, daß alle Anwendungen ein abgekoppeltes Menü haben (macht Swing glücklicherweise automagisch) und daß sie wie der Rest von OS X aussehen und sich auch entsprechend benehmen (macht Swingteilweise). Außerdem wäre es von großem Vorteil, wenn der Entwickler sich an die Apple Human Interface Guidelines halten würde - das sorgt für ein übersichtliches, einfach zu bedienendes Interface, das konsistent mit dem Rest des Systems ist.
Und ja, Konsistenz ist so wichtig. Ich benutze unter OS X nicht das normale OpenOffice sondern einen Fork, der komplett in Java geschrieben ist. Das Ding ist ziemlich langsam, aber das ist es mir wert - weil das normale OOo nicht wie eine Apple-Anwendung aussieht und kein abgekoppeltes Menü hat.

Für Linux- und OS X-Beutzer ist Konsistez mit ihrem System ein großer Faktor in der Entscheidung, ob ein Programm gut ist. Frag' mal einen Linux-User zu seiner Meinung bezüglich KDE und Gnome...


habt ihr euch einmal, wenigstens einmal, meinen quellcode angesehen?! wenigstens das bisschen, was ich gepostet hab hättet ihr überfliegen können und dabei folgende zeile entdecken können:

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

na, na, was macht diese zeile?
Unter Windows und OS X: Das Programm mit einem dem System ensprechenden LnF anzeigen.
Unter Linux, BSD und Solaris: Das Programm pottenhäßich machen.


wow, was für eine erkenntnis! *ARG* sorry, aber genau DAS finde ich dann doch schon beschissen! ich finde es auf der einen seite gut, dass du so denkst, wie du denkst, jesus_666, aber eines kann ich doch als beitragsschreiber verlangen: das du den ganzen beitrag liest, oder? oder hab ich jetzt was falsch verstanden? so kompliziert war dein satz doch nicht?
Man beachte, daß ich mich nicht gegen wählbare LnFs ausgesprochen habe. Ich habe mich dagegen ausgesprochen, dem User in der Fensterdeko herumzufummeln.

[Teelicht]

*lol* da sag ich dir, du sollst dir alle informationen durchlesen, und denke selbst nicht an alle informationen, die ich habe... ich hab das mal überflogen, dass Sun unter Unix/Linux einfach Motif als System-L&F benutzt, aber ich habs vergessen. Schuldigung, Jesus_666, danke für den Hinweis!

Was nun noch supercool wäre, wenn du mir jetzt den Java-Code dazu geben würdest, wie man das L&F von Java ausschaltet... eine andere Methode als es auf das Native System zu schalten kenne ich nämlich nicht.

Mal abgesehen davon finde ich Motif gar nicht so übel ^^ naja, aber auf Dauer wirds natürlich lästig *g* wobei man dann ja auf Metal umschalten kann, das ist nicht schlecht. Blllll egal, also - wie schaltet man das L&F wieder aus, damit auch die Linux/Unix Benutzer ihr eigenes wiederbekommen?


EDIT:

Augenblick! Was genau meinst du mit Fensterdeko? Na egal, will trotzdem wissen, wie man wirklich natives L&F bekommt. Wenn du mit Fensterdeko "nur" Titelleiste und Rahmen meinst, haben wir ja kein Problem - meine Anwendung benutzt unerklärbarerweise immer die nativen Rahmen... -.- na egal, mal sehen, was Gekiganger dazu erfährt.... und sowas nennt man dann Plugable Look And Feel. Das ich nicht lache! So einfach plugable ist es gar nicht! *ARG*

[Jesus_666]

Exakt das meine ich. Im KDE-Kontrollzentrum kann man den grafischen Stil, der für Anwendungen gebraucht wird und den Rahmen mit Titelleiste separat einstellen; der Rahmen etc. wird dort eben als Fensterdekoration bezeichnet. Bei Gnome sieht's wahrscheinlich ähnlich aus.
Schönerweise wird die Fensterdeko bei Swing nicht sofort vom LnF beeinflußt - damit haben wir nur häßliche Anwendungen und keine häßlichen Rahmen. ;)

Ich hätte bei meinem Anfangspost präziser schreiben sollen, was genau ich eigentlich für eine schlechte Idee halte.


Okay, ich habe ohnehin ein anderes (https://substance.dev.java.net) LnF installiert. Damit sieht Swing nicht mehr ganz so schlimm aus. Trotzdem bin ich auf Java 1.6 gespannt - wenn Swing-Anwendungen endlich richtig auf GTK zurückgreifen (und nicht so halbbacken und nicht mal standardmäßig wie jetzt) sehen sie bestimmt auch besser aus...