Nous utilisons Java Swing pour notre développement Interface Graphique Utilisateur (GUI). Il est beaucoup plus puissant que l'AWT d'origine, et le prix est juste. En particulier, nous essayons d'utiliser le "format Bean" de la définition et l'obtention des membres, des rappels pour informer des changements, etc, pour le rendre plus facile pour construire des applications à partir de composants JMRI.
Nous avons évolué vers un schéma particulier pour l'utilisation de Swing, décrit ici. Le code source JMRI contient plusieurs générations de réalisations, aussi tout ne ressemble pas à ceci, mais nous avançons les classes dans ce sens tant que le temps le permet.
La structure de base est pour mettre en oeuvre des outils graphiques comme des objets JmriPanel. Ce sont JPanels avec assez de structure d'appoint pour que les applications JMRI puissent directement travailler avec eux. Par exemple, une sous-classe JmriPanel peut être "instanciée" et placé dans une fenêtre bien prévue par la création d'un Action JmriNamedPanel avec juste le nom de la classe JmriPanel, qui à son tour peut être fait avec différents outils automatisés.
Ce modèle nous permet d'écrire un panneau d'outils juste une fois, et de l'utiliser dans plein de lieux différents, intégrés dans des fenêtres de plusieurs façons. Il a également réduit considérablement le nombre de classes qui doivent être chargées au démarrage, car il n'y a pas de classes * d'Action et * de Frame distinctes, et les sous-classes JmriPanel n'ont pas à être chargées simplement parce qu'elles sont énumérées dans un menu.
Le paquet jmri.util.swing contient le code.
D'abord le 'ctor' s'exécute, puis initComponents. Cette deuxième partie devrait être le lieu pour les connexions à d'autres composants, où tous les objets de niveau inférieur ont été créés. (sous-classes pour des systèmes particuliers peuvent avoir par exemple des méthodes plus initComponents, appelé plus tard)
Dispose est appelée à la fin. (Notez que JPanels n'ont pas dispose (), c'est normalement une partie seulement de JFrames, mais nous la fournissons ici pour le nettoyage)
Les JmriPanels sont mieux créés par un nom avec JmriNamedPaneAction, qui a l'avantage de réduire fortement le nombre de classes qui ont besoin d'être chargées pour remplir un menu.
Si elle ne peut se faire par nom, alors JmriAbstractAction est la base.
Utilisation de WindowInterface pour créer des sous - fenêtres, de manière à les mettre au bon endroit.
(Voir les Javadocs dans ce paquet, qui sont très bons)
JmriJFrame est dans le mauvais endroit pour l'instant.
Des classes plus anciennes, d'autres encore devant être déplacées de jmri.util.swing, certaines sont des adaptateurs 1.1.8 qui devraient tout simplement disparaître.