¿Cómo forzo/uso GTKLookAndFeel en Java en KDE?

swing look-and-feel

Question

En primer lugar, usar gnome no es una opción (pero es posible instalar sus bibliotecas).

Necesito saber qué es necesario para mostrar una aplicación de escritorio Java Swing utilizando el aspecto y la apariencia de KDE instalada actualmente en KDE. Idealmente, la solución debería permitirme aplicar una apariencia que se parezca al sistema de ventanas subyacente (es decir: Windows LNF para Windows, GTK LNF para Gnome (GTK), QT LNF para KDE (QT), el predeterminado para otras plataformas )

En KDE, también puede configurarlo para usar el tema actual de KDE para aplicaciones GTK. Entonces, si la solución funciona con GTK, está bien.

Cuando ejecuto la siguiente pieza de código bajo Gnome (Ubuntu 8.04), la aplicación Java se ve hermosa. Se integra muy bien con el resto de aplicaciones:

try {
// Set System L&F
UIManager.setLookAndFeel(
UIManager.getSystemLookAndFeelClassName());
} catch(Exception e) { //Handle it }

Sin embargo, si ejecuto lo mismo en Debian (Lenny) con KDE, la llamada UIManager.getSystemLookAndFeelClassName () devuelve el valor predeterminado de Java. Si continúo y le obligo a usar GTK LNF, la aplicación no funciona. Algunos campos son invisibles, otros se vuelven fuera de lugar, todo es inutilizable:

try {
//Force the GTK LNF on top of KDE, but **it doesn''t work**
UIManager.setLookAndFeel("com.sun.java.swing.plaf.gtk.GTKLookAndFeel");
} catch (Exception e) { /*Handle it*/ }

También intenté poner el siguiente código. Permite al usuario elegir cualquiera de los LNF disponibles y luego intenta configurarlo. Metal y Motif funcionan bien. GTK no. El control deslizante está realmente en mal estado. El cuadro de lista se ve feo y desaparece, pero parece funcionar. Los botones y el menú parecen estar bien. El código relevante se muestra aquí:

(...)
/** Creates new form SwingFrame */
public SwingFrame() {
initComponents();
//Save all available lafs in a combobox
cbLafs.removeAllItems();
UIManager.LookAndFeelInfo[] lafs=UIManager.getInstalledLookAndFeels();
for (int i=0,t=lafs.length;i<t;i++)
{
cbLafs.addItem(lafs[i]);
System.out.println(lafs[i].getName());
}
}
public void changeLookAndFeel(String laf)
{
//If not specified, get the default one
if (laf==null) {
laf=UIManager.getSystemLookAndFeelClassName();
}
try {
// Set System L&F
UIManager.setLookAndFeel(laf);
}
catch (Exception e) {
// handle exception
e.printStackTrace();
}
SwingUtilities.updateComponentTreeUI(this);
}
private void cbLafsActionPerformed(java.awt.event.ActionEvent evt) {
// TODO add your handling code here:
UIManager.LookAndFeelInfo laf=(UIManager.LookAndFeelInfo)cbLafs.getSelectedItem();
if (laf==null)
changeLookAndFeel(null);
else
changeLookAndFeel(laf.getClassName());
} 

Este mismo sistema tiene todas las aplicaciones GTK funcionando (por ejemplo: Firefox) como se esperaba. Asi que:

1) ¿Qué le falta al entorno para que una aplicación Java GTK LNF funcione bajo KDE?

2) ¿Qué comprueba la JVM para devolver a GTK como el tema del sistema predeterminado?

Gracias por tu ayuda Luis Fernando

PD-> He intentado con otras soluciones, como JGoodies, AWT y SWT. Sin embargo, Swing con GTK LNF sería la mejor solución para evitar las molestias de las bibliotecas nativas de SWT y las jarras adicionales JGoodies (también, JGoodies LNF no parece tan integrado como Swing GTK bajo Gnome). AWT se ve horrible (como un motivo) y echa de menos muchas características.

Answer 1

tal vez esto funcione:

try {
// sure look and feel
UIManager.setLookAndFeel("com.sun.java.swing.plaf.gtk.GTKLookAndFeel");
// not-so-sure look and feel
System.setProperty("os.name", "Windows");
System.setProperty("os.version", "5.1");
UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
}
catch (Exception ex) {
ex.printStackTrace();
}

Answer 2

Citando la documentación:

1. Si la propiedad del sistema swing.defaultlaf no es nula, use su valor como el nombre predeterminado de la clase de apariencia y comportamiento.

2. Si el archivo Properties swing.properties existe y contiene la clave swing.defaultlaf , use su valor como el nombre de la clase look and feel por defecto. La ubicación que se comprueba para las swing.properties variar según la implementación de la plataforma Java. En la implementación de Sun, la ubicación es ${java.home}/lib/swing.properties

Consulte las notas de la versión de la implementación que se utiliza para obtener más detalles.

Pero estoy 99% seguro de que su problema es este (citando los documentos):

Una vez que se ha cambiado la apariencia, es imprescindible invocar updateUI en todos los JComponents . El método SwingUtilities.updateComponentTreeUI(java.awt.Component) hace que sea fácil aplicar updateUI a una jerarquía de contención. Consulte para obtener más detalles. El comportamiento exacto de no invocar updateUI después de cambiar el aspecto no está especificado. Es muy posible recibir excepciones inesperadas, problemas de pintura o cosas peores.

Si no desea invocar updateUI en todos los JComponents , asegúrese de invocar UIManager.setLookAndFeel antes que cualquier otro código de swing.

Answer 3

Puede establecer la apariencia desde la línea de comando:

java -Dswing.defaultlaf = com.sun.java.swing.plaf.gtk.GTKLookAndFeel MyApp

Además, SwingSet2.jnlp ofrece una demostración de muestra de todas las cosas diferentes que se pueden cambiar. La fuente y otra información se pueden encontrar aquí: enlace de texto

Answer 4

El GTK Laf es, en mi humilde opinión, un período roto. No respeta algunas configuraciones aleatorias. Creo que se supone que no debe respetar ningún setBackground (), setForeground () o setFont () en la mayoría de los componentes.

Si está utilizando java> 1.4.2 sugiero usar MetalLookAndFeel [debería ser UIManager.getCrossPlatformLookAndFeelClassName ()]. Si está utilizando> 1.6.0_u10, puede probar NautilusLookAndFeel. Personalmente, me parece que el Metal es más bonito.