Comment forcer/utiliser GTKLookAndFeel en Java sur KDE?

Question

Tout d'abord, l'utilisation de gnome n'est pas une option (mais il est possible d'installer ses bibliothèques).

J'ai besoin de savoir ce qui est nécessaire pour afficher une application de bureau Java Swing en utilisant l'apparence et la convivialité KDE de KDE. Idéalement, la solution devrait me permettre d'appliquer un aspect qui ressemble au système de fenêtrage sous-jacent (Windows LNF pour Windows, GTK LNF pour Gnome (GTK), QT LNF pour KDE (QT), celui par défaut pour les autres plateformes). Sous KDE, vous pouvez le configurer pour qu'il utilise également le thème KDE actuel pour les applications GTK. Donc, si la solution fonctionne avec GTK, c'est bien.

Lorsque j'exécute le morceau de code suivant sous Gnome (Ubuntu 8.04), l'application Java est belle. Il intègre très bien avec le reste des applications:

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

Cependant, si je lance la même chose sous Debian (Lenny) avec KDE, l'appel UIManager.getSystemLookAndFeelClassName() retourne la valeur par défaut de Java un. Si je vais de l'avant et l'oblige à utiliser le GTK LNF, l'application ne fonctionne pas. Certains champs sont invisibles, d'autres deviennent hors de propos, tout est inutilisable:

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*/ } 

J'ai aussi essayé de mettre le code suivant. Il permet à l'utilisateur de choisir l'un des LNF disponibles, puis essaie de le définir. Le métal et le motif fonctionnent bien. GTK ne le fait pas. Le curseur est vraiment foiré. La zone de liste semble moche et disparaît, mais semble fonctionner. Les boutons et le menu semblent ok. Le code correspondant est indiqué ici:

(...) 
    /** 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()); 
    }          

Ce même système a toutes les applications GTK de travail (par exemple: Firefox) comme prévu. Donc:

1) Qu'est-ce qui manque à l'environnement pour qu'une application Java GTK LNF fonctionne sous KDE?

2) Que vérifie JVM pour retourner GTK comme thème système par défaut?

Merci pour vous aider à Luis Fernando

PS-> J'ai essayé d'autres solutions, aussi, comme JGoodies, AWT plaine et SWT. Cependant, Swing avec GTK LNF serait la meilleure solution pour éviter les tracasseries des bibliothèques natives SWT et des pots supplémentaires JGoodies (de plus, JGoodies LNF ne semble pas aussi intégré que Swing GTK sous Gnome). AWT semble hideux (ressemblant à un motif) et manque beaucoup de fonctionnalités.

Answer 1

peut-être ceci fonctionne:

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

Citant la documentation:

1. Si la propriété système swing.defaultlaf est non nul, utilisez sa valeur comme l'apparence par défaut et se sentir nom de classe .

2. Si le fichier de propriétés swing.properties existe et contient la clé swing.defaultlaf, utilisez sa valeur comme nom de classe par défaut. L'emplacement vérifié pour swing.properties peut varier en fonction de l'implémentation de la plate-forme Java.Dans la mise en œuvre de Sun l'emplacement est ${java.home}/lib/swing.properties

Veuillez vous référer aux notes de version de la mise en œuvre utilisées pour plus de détails.

Mais je suis sûr à 99% que votre problème est celui-ci (citant la documentation à nouveau):

Une fois que l'apparence a été modifiée, il est impératif d'invoquer updateUI sur tous JComponents. La méthode SwingUtilities.updateComponentTreeUI(java.awt.Component) facilite l'application de updateUI à une hiérarchie de confinement. Reportez-vous à cela pour plus de détails. Le comportement exact de ne pas appeler updateUI après avoir modifié l'apparence n'est pas spécifié. Il est très possible de recevoir des exceptions inattendues, des problèmes de peinture, ou pire.

Si vous ne voulez pas invoquer updateUI sur tous les JComponents, assurez-vous d'invoquer UIManager.setLookAndFeelavant tout autre code de swing.

Answer 3

Vous pouvez définir l'apparence de la ligne de commande:

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

, SwingSet2.jnlp fournit également un échantillon démo de toutes les différentes choses qui peuvent être changées. La source et d'autres informations peuvent être trouvées ici: link text

Answer 4

La GTK Laf est, à mon humble avis, période brisée. Il ne pas honorer certains paramètres aléatoires. Je crois qu'il n'est pas censé honorer setBackground(), setForeground(), ou setFont() sur la plupart des composants.

Si vous utilisez java> 1.4.2, je suggère d'utiliser MetalLookAndFeel [devrait être UIManager.getCrossPlatformLookAndFeelClassName()]. Si vous utilisez> 1.6.0_u10, vous pouvez essayer NautilusLookAndFeel. Personnellement, je trouve le métal plus agréable.