Le blog de Julien H

Un article de morgoth_fr    5 Commentaires

Vous avez peut-être remarqué que dans le monde des applications professionnelles, Swing fait son come-back. Cependant, certaines choses rendent encore Swing vraiment rébarbatif. En vrac :

• API pas homogène (on sent bien que ça a de la bouteille et qu’il a fallut jouer avec la compatibilité ascendante
• Composants n’utilisant pas les generics (c’est en cours, mais est-ce que ça sortira un jour ?)
• Manque un bon éditeur graphique (je crois qu’on dit « RAD »)

C’est sur le dernier point que je vais essayer de faire un compte rendu de mes dernières recherches.

Tout d’abord, avant qu’on me pose la question, oui, je connais Matisse. Du moins je l’ai un peu manipulé à plusieurs reprises. Il a certes de nombreuses qualités, en partie du fait qu’il sert de vitrine à toutes les JSR qu’on espère voir un jour de base dans le JDK sans avoir à installer des JAR supplémentaires (appframework, beans binding, ..). Mais il a pour moi 2 inconvénients majeurs :

• C’est sous Netbeans, et dans ma société, l’outil recommandé est Eclipse.
• Le code est non éditable

Pour moi, le second point est vraiment gênant. En effet, en fonction de l’action à réaliser, j’aime bien faire les modifications à la main dans le code plutôt que de passer par l’éditeur.

Sous Eclipse, je connais deux outils open-source et gratuits répondant à priori à mes besoins :

• Visual Editor
• Visual Swing 4 Eclipse

Visual Editor

Visual Editor est un projet assez ancien. Tellement ancien qu’il semble abandonné. Sur le site officiel, la dernière version est pour Eclipse 3.2. Cependant, il semble que la société Soyatec ait repris les choses en main (merci à eux). Les instructions d’installation sont sur le wiki.

J’ai testé VE sous Windows et Linux. Son principal défaut est de forker un process Java pour chaque composant graphique affiché dans Eclipse (chaque onglet). Et vu que je n’ai pas l’impression qu’il y ait un mécanisme de libération (à moins de fermer Eclipse), on se retrouve vite avec des dizaines de process java dans le gestionnaire de tâches, chacun prenant environ 40 Mo de RAM. Mon astuce à 2 centimes : dès que j’ai plus de RAM, je kill manuellement tous les process java (sauf Eclipse bien sûr), et je peux continuer à travailler.
De plus, sous Windows, on a toujours dans la barre des tâches un élément supplémentaire qui correspond au composant qu’on est en train d’éditer dans Eclipse. Sous Linux, c’est encore pire, vu qu’on a également une fenêtre flottante contenant la même chose que ce qu’on a dans l’onglet d’Eclipse. Assez pénible à la longue.

Ses avantages :

• gère tous les layouts de base, dont les GridBagLayout. Il manque cependant la possibilité de pouvoir modifier en masse les GridBagConstraints de plusieurs composants, comme on peut le faire pour les propriétés « classiques »
• il est possible d’exécuter/prévisualiser de nombreux composants, et pas seulement les frames (par exemple les panels), en faisant Run As->Java Bean
• s’en sort très bien avec du code modifié à la main (sauf qu’il semble y avoir parfois des problèmes de cache, il faut fermet et ré-ouvrir l’éditeur)

Visual Swing 4 Eclipse

Je l’ai découvert très récemment. Il semble développé par une seule personne, William Chen. A la première ouverture, c’est une réelle surprise par rapport à VE : pas de process forké, donc pas de fenêtre flottante ni d’élément dans la barre des tâches. Seule la première ouverture d’un composant est un peu longue (j’imagine qu’il initialise pleins de trucs). A l’utilisation, je l’ai trouvé très stable.

A noter que VS4E fourni un GroupLayout custo qui n’est pas celui du JDK 1.6. Cela est est gênant car requiert une dépendance supplémentaire dans le code. Une issue est ouverte à ce sujet.

Donc pour moi, ce serait le parfait remplaçant de VE, sauf qu’il manque encore les fonctionnalités suivantes :

• gestion graphique du GridBagLayout. Il est quand même possible de faire les modifs dans le code, et l’affichage dans l’éditeur est parfait. Cependant, j’ai assez souvent mes modifications (GridBagConstraints) qui sont écrasées quand je fais des modifs dans l’éditeur.
• quelques améliorations d’ergonomie. Par exemple si je sélectionne un composant et que je « sors » trop vite ma souris de la zone, mon composant n’a pas suivi. Je dois repasser ma souris sur l’onglet des composants (sans cliquer) pour « rattacher » le composant à mon curseur et pouvoir le poser dans la zone.