[SWING] Aufruf an alle LaF-Programmierer
Bernd 'Nexos' Dutkowski
schwieriger diese auch in die eigenen Anwendungen einzubinden.
Ich benutze derzeit eine Methode, die einfach versucht alle mir
bekannten LaFs zu registrieren und dann in einem Dialog zur Auswahl zur
stellen. Schoener jedoch waere es, wenn man das einheitlich Regeln
wuerde. Anbieten wuerde sich dafuer die "JAR Service Provider API"
http://java.sun.com/j2se/1.4/docs/guide/jar/jar.html#Service%20Provider
mehr dazu unter news:3CC6CC8E...@dutkowski.net
Somit kann ein LaF als Service betrachtet werden, der durch eine kleine
Methode zur Laufzeit als LaF registriert wird:
***
Iterator iterator;
LookAndFeel laf;
iterator = Service.providers(LookAndFeel);
while(iterator.hasNext())
{
laf = (LookAndFeel) iterator.next();
UIManager.installLookAndFeel(laf.getName(), laf.getClass().getName());
}
***
Bei den einzelnen LaFs muessen dann nur noch je eine Datei
"META-INF/services/javax.swing.LookAndFeel" mit dem Namen der Klasse
darin in das Jar und gut ist :-)
Anregungen und Kritik sind wie immer wilkommen!
MFG
bernd
Karsten Lentzsch
Den Vorschlag finde ich gut, wir sollten ihn mit dem Swing-
Team diskutieren. Bernd, sende den Vorschlag doch bitte an
swing-f...@java.sun.com.
Der Ansatz hilft, vorhandene Looks zu entdecken, meistens
braucht man nur die unterstützten; das ist aber einfach gemacht.
Wesentlich wichtiger fände ich allerdings, die L&F-Anbieter
darauf zu trimmen, dass die Looks sich zur Laufzeit nicht
untereinander stören. Die populären L&Fs sind zumeist
auf Suns Java-L&F aufgebaut und teilen sich in der Regel
etliche statische Variablen. Dadurch kommt es zu Fehlern
wenn zwei solche Java-L&F-Kinder gewechselt werden.
Außerdem sollte ein Look bei der Instanziierung andere
Looks nicht beeinflussen.
Seit der 1.4.1 wird die Situation noch ein bisschen schwieriger,
weil die Initialisierung von Schriften mittels FontDelegate
bisher von kaum einem Look-Anbieter beachtet wird. Siehe
dazu die Kommentare in den Klassen MetalLookAndFeel
und MetalTheme.
Deshalb rate ich Entwicklern, die meinen Plastic-L&F oder
meinen Windows-L&F einsetzen, die Menge der installierten
Looks selber zu bestimmen - soweit es geht, z. B. wird der
native Mac OS X-Look in der Mac-Umgebung automatisch
installiert. Zweitens empfehle ich, eine Liste von L&F-Ersetzungen
zu verwenden, z. B. MetalLookAndFeel durch PlasticLookAndFeel,
WindowsLookAndFeel durch ExtWindowsLookAndFeel,
so dass aus jedem Strang von L&F-Implementierungen
nur einer vorhanden ist. Filtert man dann noch die nicht
unterstützten Looks raus, erhält meine eine Menge von Looks,
die man benutzen kann und die im laufenden Betrieb gewechselt
werden können - wenn man noch zahlreiche andere Swing-Fehler
umschifft.
Dieses Verfahren turne ich für meinen Plastic und Windows-
Look im jDiskReport vor - dort zu finden in den Präferenzen.
Gruß,
--
Karsten Lentzsch - User Interface Design - www.jGoodies.com
Christian Wederhake
> Es gibt immer mehr Swing LaFs und es wird als Anwendungsentwickler immer
> schwieriger diese auch in die eigenen Anwendungen einzubinden.
> Ich benutze derzeit eine Methode, die einfach versucht alle mir
> bekannten LaFs zu registrieren und dann in einem Dialog zur Auswahl zur
> stellen. Schoener jedoch waere es, wenn man das einheitlich Regeln
> wuerde. Anbieten wuerde sich dafuer die "JAR Service Provider API"
> http://java.sun.com/j2se/1.4/docs/guide/jar/jar.html#Service%20Provider
> mehr dazu unter news:3CC6CC8E...@dutkowski.net
> Somit kann ein LaF als Service betrachtet werden, der durch eine kleine
> Methode zur Laufzeit als LaF registriert wird:
[x] Dafuer.
RFE bei Sun einreichen zwecks globaler Spezifikation?
Ciao
Chris, dessen Schnittstellen schon seit laengerem auf dem SPI-Framework basieren...
--
"Jeder Mann wünscht sich eine Frau, klug genug, um ihn zu verstehen,
und dumm genug, um ihn zu bewundern." (Israel Zangwill)
Paul Ebermann
[...]
> Anbieten wuerde sich dafuer die "JAR Service Provider API"
> http://java.sun.com/j2se/1.4/docs/guide/jar/jar.html#Service%20Provider
> mehr dazu unter news:3CC6CC8E...@dutkowski.net
> Somit kann ein LaF als Service betrachtet werden, der durch eine kleine
> Methode zur Laufzeit als LaF registriert wird:
>
[...]
> Bei den einzelnen LaFs muessen dann nur noch je eine Datei
> "META-INF/services/javax.swing.LookAndFeel" mit dem Namen der Klasse
> darin in das Jar und gut ist :-)
Eine Frage:
Ist es mit dem Serivce Provider-Interface möglich, auch
mehrere Implementierungen des selben Interfaces in einem
Jar aufzubewahren?
In der oben genannten Seite (und auch in deinem Artikel)
ist nur eine Möglichkeit genannt, eine einzige Klasse
anzugeben.
Das ist IMHO eine unsinnige Beschränkung der Möglichkeiten.
Paul
Christian Wederhake
> "Bernd 'Nexos' Dutkowski" skribis:
> Ist es mit dem Serivce Provider-Interface möglich, auch
> mehrere Implementierungen des selben Interfaces in einem
> Jar aufzubewahren?
Ja.
Einfach die Klassennamen reihauf newline-separiert in
das service-descriptor-file schreiben...
Ciao
Chris
--
Appleby, Shiri 07.12.1978 -> 22 Heigl, Katherine Marie 24.11.1978 -> 22
"Die sehen dafür aber verdammt jung aus." --- "Deswegen wurden sie
gecastet. Ne 22jährige die aussieht wie 30 macht sich nicht so gut als
16jährige Teenagerin." (Nicolas Byl & Joerg Tewes [de.rec.tv.buffy])
Bernd 'Nexos' Dutkowski
> "Bernd 'Nexos' Dutkowski" <be...@dutkowski.net> schrieb:
>
> Den Vorschlag finde ich gut, wir sollten ihn mit dem Swing-
> Team diskutieren. Bernd, sende den Vorschlag doch bitte an
> swing-f...@java.sun.com.
Ui, gleich sowas :)
> Der Ansatz hilft, vorhandene Looks zu entdecken, meistens
> braucht man nur die unterstützten; das ist aber einfach gemacht.
>
> Wesentlich wichtiger fände ich allerdings, die L&F-Anbieter
> darauf zu trimmen, dass die Looks sich zur Laufzeit nicht
> untereinander stören. Die populären L&Fs sind zumeist
> auf Suns Java-L&F aufgebaut und teilen sich in der Regel
> etliche statische Variablen. Dadurch kommt es zu Fehlern
> wenn zwei solche Java-L&F-Kinder gewechselt werden.
> Außerdem sollte ein Look bei der Instanziierung andere
> Looks nicht beeinflussen.
Das ist n guter Punkt, leider kann ich da nix machen.
> Seit der 1.4.1 wird die Situation noch ein bisschen schwieriger,
> weil die Initialisierung von Schriften mittels FontDelegate
> bisher von kaum einem Look-Anbieter beachtet wird. Siehe
> dazu die Kommentare in den Klassen MetalLookAndFeel
> und MetalTheme.
Noch gar nicht angeschaut
> Deshalb rate ich Entwicklern, die meinen Plastic-L&F oder
> meinen Windows-L&F einsetzen, die Menge der installierten
> Looks selber zu bestimmen - soweit es geht, z. B. wird der
> native Mac OS X-Look in der Mac-Umgebung automatisch
> installiert. Zweitens empfehle ich, eine Liste von L&F-Ersetzungen
> zu verwenden, z. B. MetalLookAndFeel durch PlasticLookAndFeel,
> WindowsLookAndFeel durch ExtWindowsLookAndFeel,
> so dass aus jedem Strang von L&F-Implementierungen
> nur einer vorhanden ist. Filtert man dann noch die nicht
> unterstützten Looks raus, erhält meine eine Menge von Looks,
> die man benutzen kann und die im laufenden Betrieb gewechselt
> werden können - wenn man noch zahlreiche andere Swing-Fehler
> umschifft.
Das hoert sich nach nem heftigen Workaround an.
> Dieses Verfahren turne ich für meinen Plastic und Windows-
> Look im jDiskReport vor - dort zu finden in den Präferenzen.
Mir waere es halt am liebsten, dass der Anwender oder Sysadmin die
gewuenschten LaFs instaliert (sprich das Jar in ext kopieren) und meine
Anwendung findet die dann per SPI.
--
Bernd Dutkowski \|/ ______ \|/
http://www.g-ne.de/ "@' / , . \ `@"
/__| \____/ |__\
\___U__/
Karsten Lentzsch
> Mir waere es halt am liebsten, dass der Anwender oder
> Sysadmin die gewuenschten LaFs instaliert (sprich das Jar
> in ext kopieren) und meine Anwendung findet die dann per SPI.
Das fände ich auch schön; die Situation ist aber, dass man
die Looks nur einmalig vor dem Anwendungsstart wählen kann,
ein Wechsel im Betrieb ist nur mit ausgewählten Looks möglich
und auch dann nur eingeschränkt.
Typische Probleme sind:
1) ein Look installiert Resourcen in den Komponenten,
die nicht UIResource implementieren,
2) ein Look installiert Dinge in der User-Ebene der UIDefaults,
nicht in der Look-Ebene,
3) der application context wird nicht beachtet,
4) Seiteneffekte beim Instanziieren eines Looks,
5) aktive UIDefaults werden durch passive ersetzt, so dass
der Look Desktop-Einstellungen nicht mehr berücksichtigt,
6) ToolBar-Rollover-Rahmen werden falsch gesetzt,
oder nicht mehr zurück genommen,
7) Tabellen werden beim Look-Wechsel falsch konfiguriert,
siehe JTable.configureEnclosingScrollPane
Diese Fehler trifft man in den Looks unter www.javootoo.com,
6) und 7) auch in den Sun-Implementierungen; man bemerkt
sie allerdings erst, wenn man den Look wechselt, nachdem
die Swing-Komponenten 'realisiert' sind.
Der einzige Fehler, den ich mit meinen Looks nicht
umschiffen konnte, tritt auf, wenn man unter Windows
den Desktop umkonfiguriert. Dann wird nicht mein
korrigiertes Wechsel-Verfahren angestossen, sondern
das mangelhafte von Sun. Als Folge treten Artefakte zu
6) und 7) auf, die erst verschwinden, wenn man mein
Verfahren anstösst, z. B. durch erneuten Look-Wechsel.
Gruß aus'm Norden,
Bernd 'Nexos' Dutkowski
Was hier noch fehlt, ist die Pruefung ob ein LaF schon instaliert ist
und ueber die Namen der Klasse und Methode kann und sollte man auch noch
reden.
***
package de.dclj.swing;
import java.util.Iterator;
import javax.swing.LookAndFeel;
import javax.swing.UIManager;
import sun.misc.Service;
public class LookAndFeelRegistry
{
public static void register()
{
Iterator iterator;
LookAndFeel laf;
iterator = Service.providers(LookAndFeel.class);
while(iterator.hasNext())
{
laf = (LookAndFeel) iterator.next();
UIManager.installLookAndFeel(laf.getName(), laf.getClass().getName());
}
}
}
***
--