Version imprimable
Bonjour,
Je commence a avoir une certaine experience dans le developpement de composant sur mesure. (de Java2D jusqu'a l'intégration dans les editeurs comme Matisse).
J'aimerai aller plus loin en intégrant d'avantage mes composants dans l'environnement en utilisant le Look&Feel natif (recuperer les teintes de couleur principales, les styles d'angles ...etc...).
Quelqu'un a t il deja exploré cette voie ?
Il existe le UIManager qui donne des infos plus ou moins pertinentes suivant le Look&Feel.
Sauf que pour les l&f natifs c'est un peu plus dur, l'UIManager n'est pas forcément super bien renseigné, car beaucoup de parties de composants sont crées à partir d'images au moyen d'API spécifiques et internes à Sun (pour le l&f Windows il s'agit de l'API UXTheme, pour le l&f GTK il s'agit d'un L&F Synth qui va piocher dans les ressources GTK)
Oui, à mon niveau bien sûr (je suis pas un graphiste), et, informatiquement parlant, je ne la trouve pas pratiquable.Citation:
Envoyé par eclesia
Le L&F est bon pour faire un environnement complet, et encore ; cela marche, mais reste difficile, en tous les cas c'est un gros boulot. Cela ne m'a pas paru adapté pour des demi-L&F, le concept manque de logique et de cohérence.
Par exemple, les couleurs peuvent se définir à la fois dans le L&F et directement dans le composant. Pourquoi ? Quelle est la plus-value, où est-ce le mieux, à quoi rime l'un ou l'autre ? Mystère. Si on veut faire un composant perso qui s'adapte au contexte, c'est pas gagné du tout. Et passe encore pour la couleur, mais pour la transparence, les bords, la taille du composant, le focus, la situation est pire.
Et, pour couronner le tout, les GUI Builder tels Matisse, pourtant conçus par Sun, ignorent complètement la notion de L&F : si tu dis de mettre un arrière plan de telle couleur, il sera de cette couleur quel que soit le L&F.
Même les L&F qui sont fait pour ça sont pas pratiques, et de toutes façons, rien ne dit qu'un utilisateur les choisirait.
Bref je ne trouve pas que le L&F soit la meilleure techno de swing et, pour moi, à moins d'être un génial, d'avoir 150 stagiaires à sa dispo, c'est pas jouable.
Et maintenant, lorsque j'ai un composant à définir au niveau graphique, je me passe complètement de la notion de L&F, cela fonctionne aussi bien, c'est tout autant adaptable, et je gagne 99% de mon temps !
Sinon pour faire propre et laisser la porte ouverte à des L&F tierces pour implémenter le look de tes composants, diriges toi vers les sources de Swingx.
Ils ont fait un gros travail avec Kirill Grouchnikov et les gens de Synthetica pour que les UI de leurs composants soient aisément implémentables pour un L&F tierce. Ce qui a permis à substance et synthetica de proposer des add ons pour Swingx. Quoi qu'il en soit tu peux oublier la redéfinition directe de la méthode paintComponent et tu dois proposer un système à base d'UIDelegates, comme Swing le fait de base.
Oui, excellente remarque de sinok, j'ai l'impression que swingx a mieux réfléchi a ces questions. Mais là, je n'ai aucune expérience pratique, je parle seulement d'après mes lectures et impressions !
Swingx possède également un deuxième mécanisme, en plus de leurs delegates spécifiques (qui étendent XComponentUI qui propose plus de mécanismes que le componentUI Swing de base). Pour suivre un peu le travail réalisé il faut fouiller dans le forum de Swingx ou un certain nombre de posts impliquent Kirill, Jeanette, Mnathan, kschaefe, rah003
Ce mécanisme est utilisé dans leurs UIDelegates par défaut et s'appelle LookAndFeelAddons. Il permet d'adapter une partie de l'UIDelegate à l'OS, le mécanisme est décrit ici. Il est issu à la base du travail réalisé par Frédéric Lavigne pour les l2fprod commons.
Sinon pour voir comment implémenter un composant custo de façon propre il existe cet excellent de Kirill Grouchnikov: http://today.java.net/pub/a/today/20...component.html
merci beaucoup, je vais jeter un oeil a tout ca.