#91 L'implémentation des dialogues modaux est obsolète

[Vincent Belaïche]

L'implémentation utilise la reflexivité pour accéder à des méthodes privées de l'ancêtre. Cela ne sera probablement plus pris en charge dans les versions futures de java.
De plus sur MACOS il est impossible de fermer les dialogue modaux avec le clic sur le bouton rouge du bandeau, même si on a mis setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);

[Vincent Belaïche]

Alors pour être plus précis ça ne concerne que le cas où la MDI (Multi Document Interface) est configurée en « child-frames » et non le cas où elle est configurée en « Gimp-like », en effet seul dans le premier cas des JInternalFrame sont utilisées pour tous les cadres, et la modalité est implémentée à la main avec du code utilisant la réflexivité pour accéder à une méthode privée du Container. Cette implémentation est d'ailleurs pompé du code de JOptionPane. Avec les JVM récentes ça ne fonctionne plus.

[Vincent Belaïche]

@reynal ci-joint une tentative de correction basée sur l'utilisation d'un glassPane pour intercepter tous les évènements souris, et ne redistribuer que ceux qui sont destinés à un sous-composant du dialogue modal en cours. Ça ne fonctionne pas entièrement bien avec les JPopupMenu issus de JComboBox, il faut glisser la souris pour sélectionner l'item sinon le JPopupMenu disparaît avant qu'on ait pu faire la sélection, et de plus si jamais on faisait un dialogue avec deux niveaux de menus, ça ne fonctionnerait pas — mais ce cas n'existe pas dans les dialogues modaux de la GUI (Interface Utilisateur Graphique) actuelle de JPicEdt.

La pièce jointe contient un dépôt git, car le changement est si complexe que je l'ai fait en plusieurs commissions. Du coup je me demande ce que tu (@reynal) penses de cela : est-ce que ça n'est pas incroyablement complexe pour quelque-chose qui devrait exister de base dans la trousse de dév Java ? Est-ce qu'il existe quelque-part une bibliothèque java libre qui offre cette fonction déjà toute prête ? Et pourquoi au fait on se contraint à n'utiliser que des JInternalFrame pour la MDI «child-frames», c'est quoi l'historique de cette décision, est-ce qu'il y avait l'idée de faire une version Web de jPicEdt via une applette Java ?

[Syd (Sylvain) Reynal]

Salut Vincent,
Ouh la la il faut que je me remette dedans, d'autant que j'ai pas codé en Java depuis des lustres !!!
Tu veux pas supprimer l'un des deux modes ? et rester en Gimp-like uniquement ? La GUI mériterait d'être simplifiée je pense, à l'heure des écrans 34" !

Applet Java... je sais plus... je crois pas que j'avais ça en tête.
Syd

[Vincent Belaïche]

Salut Sylvain (@reynal),

En fait la solution que j'ai codée ÀMHA fonctionne suffisamment bien pour être publiée. Juste je voulais avoir ton avis à la fois par rapport à sa complexité, et par rapport aux raisons qui ont dirigé la conception du MDI « child-frames ».

J'avais pensé à une solution alternative basée sur des JDialog, ça aurait consisté à étendre les JDialog en rajoutant du code contraignant le panneau à ne pas sortir de la mainFrame — de sorte à mettre en œuvre le même rendu qu'actuellement avec le MDI « child-frames ».

Quand je parle de complexité de la solution jointe dans mon message précédent (qui conserve les JInternalFrame en utilisant un glassPane), je ne considère que le volume de code applicatif qu'il faut pour la mettre en œuvre, mais vu que les JInternalFrame sont supposées « légères » alors que les JDialog sont supposés « lourds » aussi bien, en termes de byte-code Java produit, la différence n'est pas significative.