Catégorie: GUI

En testant le dernier build du JDK7, j'ai découvert totalement par hasard que la classe JList était désormais paramétrée en JList<E>, comme on peut le voir dans sa javadoc temporaire. Son modèle de données ListModel a logiquement subit la même évolution.

A ma connaissance c'est la première classe de l'API Swing à intégrer les Generics en standard.

A noter toutefois qu'ils sont également déjà présent dans la nouvelle classe JLayer<V>, qui apparaitra également avec Java 7...

Je commence tout doucement à m'intéresser de plus près au développement sur Android, et même si je n'ai pas encore eu le temps de me plonger dans les spécificités de son API graphique, j'ai déjà pu remarquer qu'on y retrouve les mêmes concepts et les mêmes problèmes...

En effet, en parcourant le blog officiel des développeurs d'Android, je suis tombé sur un article de Romain Guy décrivant les problèmes de threading des applications Android.

Pour faire court : l'interface d'une application Android utilise un modèle mono-thread via l'UI-thread, et toute tâche un tant soit peu longue ne doit pas y être exécuter sous peine de bloquer l'interface utilisateur. Afin d'éviter cela on doit utiliser un nouveau thread, tout en continuant à mettre à jour l'affichage dans l'UI-thread afin de respecter le modèle mono-thread. On peut utiliser pour cela la classe AsynTask qui permet de simplifier toutes ces interactions entre threads...

Pour l'analogie : l'interface d'une application AWT/Swing utilise un modèle mono-thread via l'Event Dispatch Thread (EDT), et toute tâche un tant soit peu longue ne doit pas y être exécuter sous peine de bloquer l'interface utilisateur. Afin d'éviter cela on doit utiliser un nouveau thread, tout en continuant à mettre à jour l'affichage dans l'EDT afin de respecter le modèle mono-thread. On peut utiliser pour cela la classe SwingWorker qui permet de simplifier toutes ces interactions entre threads...

Et pour l'anedocte : on retrouve sur developpez.com un viel article de Romain concernant ce problème sur Swing : Threads et performance avec Swing

Bref pour le moment je ne suis pas trop perdu

Cette semaine aura été consacré à la classe SwingWorker de Java 6 : vous n'aurez sans doute pas manqué l'article de Romain Vimont concernant des interfaces graphiques plus performantes avec SwingWorker, mais peut-être que vous êtes passé à coté d'un sujet sur le forum qui a fini en mini-débat...

Pour info/rappel, SwingWorker permet d'exécuter un traitement dans une tâche de fond et ainsi de laisser l'EDT faire son travail, c'est à dire de gérer l'affichage des composants et les évènements graphiques.

» Lire la suite!

Je viens de tomber sur une petite astuce bien sympathique pour améliorer quelque peu l'aspect des JComboBox. En effet, ces dernières souffrent d'un petit problème assez ennuyeux : lorsqu'elle est déplié, la liste qui affiche tous les éléments conserve la même longueur que le composant parent quoi qu'il arrive. Ainsi, si les noms des différents items de la liste sont très grand mais que vous ne réserver qu'un espace restreint pour le composant, les différents éléments sont tronqués.

Et comme un bon dessin vaut mille discours, voici ce que cela donne :

Il serait bien entendu souhaitable que la longueur de la liste déroulante s'adapte à son contenu dans le cas où celui-ci est plus grand...

» Lire la suite!

JAXX est un framework Java opensource (sous licence BSD) permettant de réaliser des interfaces utilisateurs en XML. Il permet en effet d'écrire de simple fichier XML décrivant les différents composants de votre interface et leurs interactions, et d'utiliser des feuilles de styles CSS pour personnaliser l'apparence des composants plus simplement (en gérant l'état des composants avec des pseudo-classes).

Le framework se compose d'un compilateur (jaxxc) qui se chargera de compiler vos fichiers XML en bytecode Java (fichier *.class), et d'une librairie (jaxx-runtime.jar) qui devra être chargé avec votre application (très légère toutefois puisqu'elle ne fait que 32 Ko).

Je ne l'ai pas encote testé, toutefois il semble que les fichiers XML doivent impérativement être compilés, et qu'il ne soit pas possible de générer l'interface à la volée pendant l'exécution...

Reste à savoir s'il pourra s'imposer parmi les multiples frameworks GUI/XML existant, que ce soit xmlgui, CUF, SwingML, Luxor-XUL, SwiX ml ou XUI...

Il serait intéressant de voir émerger un standard...

IBM a publié un article présentant les différents frameworks graphiques pour Java : SWT, Swing et AWT.

L'article semble assez "neutre" (SWT a été créé par IBM) et présente assez bien les différentes librairies, leurs points forts et leurs points faibles.

De plus il comporte une section sur la comparaison des fonctions des différentes librairies qui s'avère fort pratique et intéressante (en particulier si vous devez passer d'une librairie à l'autre) : Feature Comparaison.

Bonne lecture...

Les applications Java de type "desktop" souffre d'un gros défaut : elles ne s'intègrent pas facilement dans l'environnement du système d'exploitation. Je ne parle pas ici de l'apparence de l'application, puisqu'on peut très facilement utiliser le LookAndFeel du système d'exploitation, mais plutôt de son interaction avec le système et les autres applications...

Bien souvent, pour effectuer des opérations toutes simples avec des API systèmes spécifique, il faut soit passer par des librairies tierces, soit utiliser du code natif avec JNI. Avec toute la difficulté que cela peut engendrer...

La prochaine version de Java devrait corriger certains de ces problèmes...

» Lire la suite!

Le portail anglophone java.sun.com a publié il y a quelques jours un article qui présente quelques unes des petites améliorations de Java SE 6 (Mustang).

On peut y lire en particulier toute une section concernant la "nouvelle" classe SwingWorker... En effet même si elle n'a jamais fait partie de l'API standard, ce n'est pas vraiment une nouvelle classe puisqu'elle existe depuis pas mal de temps, et qu'elle disponible en téléchargement dans le tutoriel de Sun concernant les Threads et Swing...

Elle sera ainsi finalement intégré dans l'API de Mustang, mais pour cela elle a été totalement remanié afin de bénéficier des améliorations apportées au langage entre-temps (en particuliers avec Java 5.0).

Mais a quoi sert-elle ?

» Lire la suite!

Il y a deux semaines, je vous présentais une petite API permettant de gérer la configuration d'une application avec les Annotations, et il se trouve que Romain Guy a eu une idée similaire, puisqu'il présente Fuse, une petite librairie destinée à modifier les ressources des interfaces graphiques.

Le procédé est assez proche (les attributs d'une instance de classe sont automatiquement modifiés selon les valeurs d'un fichier de propriété), mais plus adapté aux interfaces graphiques (gestion des couleurs, images, etc...).

Je vous invites à y jeter un coup d'oeil si la langue de Shakespeare ne vous fais pas peur : Fuse, UI Oriented Resource Injection.

Gageons que ce type de procédé sera de plus en plus courant, en particulier avec Mustang qui permettra d'utiliser APT avec le compilateur standard...

Décidément les forums de developpez.com sont une source de connaissance inépuisable... Même dans un message qui peut sembler anodin à première vue, on peut apprendre des petits trucs bien sympathique voir très enrichissant...

En lisant les réponses d'une question concernant le fonctionnement de la méthode paint() des composants AWT/Swing, je suis tombé sur une réponse très instructive de Romain Guy alias Gfx :

On peut aussi faire un RepaintManager qui detecte si des operations ont lieu en dehors de l'EDT (cf http://www.clientjava.com/blog/2004/08/20/1093059428000.html)

En effet, comme chaque développeur Swing le sait (ou devrait le savoir), toutes modifications sur l'interface graphique doit être exécutées dans l'EDT afin d'éviter des problèmes de synchronisation et d'accès simultanée (voir l'article Threads and Swing pour plus de détail)...

» Lire la suite!

Sun prépare le retour de Java pour les applications 'Desktop', et Mustang, la prochaine version de Java, apportera son lot de nouveautés pour Swing.

Un article sur java.sun.com présente en détail une des ces petites nouveautés qui peut sembler mineure à première vue : les Splash-Screen. Ce type d'écran est très répandu dans tout type de logiciels pour faire patienter l'utilisateur pendant le chargement de l'application, tout en affichant des informations utiles (logo, version du logiciel, licence, etc...).

Même si ce 'composant' ne faisait pas partie intégrante de l'API Java, il est très simple d'en créer soi-même... D'ailleurs les pages sources Java proposent deux implémentations : JWindow : SplashScreen et SplashScreen.

Pourtant ce procédé est assez peu utilisé dans les applications Java car il ne remplit son rôle qu'à moitié. En effet, pour afficher un Splah-Screen, il faut que la machine virtuelle et les composants graphiques (Swing et/ou AWT) soient chargés et initialisés. Donc le Splah-Screen ne s'affiche qu'après un certain temps de chargement, ce qui semble retarder encore un peu plus le temps de démarrage de l'application...

Mustang propose une solution toute simple pour pallier à cela. Il suffit de spécifier le fichier image (GIF, JPEG ou PNG) à afficher en tant que Splah-Screen, soit en utilisant un paramètre de java :

java -splash:filename.gif monpackage.MonAppli

Soit en utilisant le fichier Manifest de l'archive jar :

	Manifest-Version: 1.0
	Main-Class: monpackage.MonAppli
	SplashScreen-Image: filename.gif

Cette image sera affichée avant le chargement de la machine virtuelle, et elle sera automatiquement fermée dès que la première fenêtre Swing ou AWT sera affichée. Il est toutefois possible de modifier dynamiquement cette Splah-Screen une fois la JVM chargé en utilisant le singleton java.awt.SplashScreen.

Il y a donc de fortes chances que les Splash-Screen soit monnaie courante avec Mustang...