Discussion :

[dingoth]

Malheureusement, avec juste Swing, il faut un peu de réflexion et de méthode pour créer des animations intéressantes.

Si tu veux vraiment te lancer dedans, je crois que l'achat de Filthy Rich Clients est indispensable ; ou du moins avoir les connaissances présentes dedans, et franchement, ce n'est pas rien (voir la table des matières).

[bouye]

toujours sur le sujet des ihm, les animations à la aerith sont elles à la portée du 1er codeur venu ?

Non

faut il à tout prix le bouquin "filthy rich clients" ?

Oui car Swing ne supportant pas ce genre de choses de base, il faudra se taper tout les concepts de Swing et de Java2D pour apprendre les regles de bonne conduite, connaitre les classes de base pour faire des effets et savoir le minimum de trucs et astuces vitaux pour arriver a des trucs sympa ET reactifs. Tu peux ajouter un second livre sur Java2D d'ailleurs si tu veux aller voir des trucs plus avances.

Tant qu'on reste avec du Swing pur qui ignore totalement ce genre de choses on a que deux choix :

• Tout construire soit meme ce qui peut etre 'achement long. Substance meme ne s'est pas faite en un jour, ca fait plusieurs annees que Kiril bosse dessus.
• Se reposer sur les quelques libs externes qui permettent de faire des trucs plus chiades comme Substance, SwingX, etc.
  Et en fait, si on sort des lib-pur LnF additionnels on se rend compte qu'elles ne sont pas legions en fait.

Pour lier ceci a l'autre discussion, je n'ai pas dit que l'API Swing est mal fichue ce qui la rendrait caduque par rapport aux API plus recentes, je dis juste que :

• L'API a besoin d'etre nettoyee et modernisee : passage en collections non-synchronisees + generics + forcage de l'EDT. Certaines des interfaces des modeles, editors et renderer ont besoin d'etre revue et surtout unifiees (on se demande pourquoi certains des interfaces sont differentes d'autres mise a part que ce n'est pas le meme mec qui les a crees...).
• Ajouter ce qu'on trouve en standard dans les API plus recentes : support des Paint au lieu de simple Color, retructuration de la pile de rendu pour supporter la transparence/non-opacite de base sans devoir faire de bidouilles, acces aux feuilles de style des LnF/composant, support natif des animations/transitions, support du son et de la video en lecture directe ET en streaming, aide en ligne (et pour ces derniers non juste coller JAI+JMF+JavaHelp+JavaMail dans une install/distrib ne resout pas tous les problemes, il manque toujours le code d'integration que le programmeur tout se taper tout seul comme un grand... et qui grosso-modo est le meme a chaque fois).
  
  Or une bonne partie de cela se trouve desormais en JavaFX (soit deja dispo soit dans les futurs plans) mais il n'est apparement pas prevu de back-porter cela en Java pur. Pourtant des trucs comme Timeline, Transition, Interpolator, MediaPlayer, le support des flux RSS, les nouvelles couleurs "web", le support etendu des polices (qui est dans l'API mais pas encore actif) et les nouvelles composites utilisees pour la supperposition des groupes (en gros l'equivalent des composites supportees par SwingX) auraient bien leur place en Swing.
  
  Avoir le support JavaFX dans Swing (pour lequel je milite depuis le debut) pourrait pallier a ce genre de problemes d'ailleurs puisqu'un composant "fancy" pourait directement etre code/designer en JavaFX plutot qu'en bricolant du Java2D (justement Eclesia je pense ici au composant d'orientation que tu as dans PuzzleGIS par exemple).
• Et le principal defaut de Swing : il manque enormement de composants de base.
• Et il y a egalement beaucoup de code "boilerplate" sur les types de base qu'on est amene a manipuler dans des GUI (Icon, Image, Date, etc.) nottament au niveau des renderers et des editeurs qui revient souvent en fait et donc avoir des convertisseurs/formatter de base fournis par defaut ne seraient pas du luxe.

Or tout cela demande des ressources que Sun n'a pas... donc on continura a faire avec ce qu'on a actuellement.
La seule certitude du JDK7 c'est qu'ils ont un peu modernise le JColorChooser (http://java.dzone.com/articles/new-color-chooser-jdk-7) pour supporter l'alpha (waahhh j'ai envoye cette RFE dans la bugdata base de Sun en '99 ou en 2000 il me semble !!!) ce qui a declenche une grosse serie de "LOLOLOLOLOLOLOLO" de la part de pas mal de gens puisque le composant a toujours son apparence d'origine qui un peu a cote de la plaque par rapport a des composants plus recents. Qu'on aura enfin un date chooser en standard (pas trop tot !) et quant au JWebPane, il semble encore s'etre perdu dans la nature...

[sinok]

En ce qui concerne les animations en Swing il y a grosso modo deux frameworks...

Le timingframework écrit par Romain Guy et Chet Haase dont la base se retrouve dans Aerith. Toutefois je suis pas sur qu'il soit maintenu ou du moins appeler à évoluer par le futur, les deux auteurs ayant pris un peu de recul par rapport à Swing (Romain chez google et Chet chez Adobe).

Le framework Trident est lui bien plus récent (la 1.0 a été mise à disposition cette automne). Il découle du travail sur les animations effectuées dans Substance. De fait il constitue une des briques de base de la version 6 de substance et de fait sera maintenu et évoluera probablement. (voir le blog de Kirill pour plus d'infos as usual: http://www.pushing-pixels.org/?cat=16 )

[joseph_p]

pour les pbs d'évolutions de swing, est ce tant un manque de moyen qu'un manque de volonté ? Perso j'aurai plutôt tendance à pencher sur la 2eme option, vu qu'ils ont eu les moyens pour JavaFX... D'ailleurs je ne comprends pas pourquoi ils ne l'ont pas intégré dans swing, ça aurait bien aidé. M'enfin...

A propos, avez vous la moindre idée de ce que réserve Oracle dans ces domaines ?

Et heureusement qu'il y a krill

[bouye]

Ils ont les moyens pour FX car actuellement tous les oeufs sont dans le panier FX

Faut attendre la validation de l'achat et peut-être aussi les prochaines réunions des actionnaires d'Oracle et Sun pour savoir quels sont les plans pour 2010 (quand est-ce qu'ils terminent leur année fiscale et publient leurs bénefs ? en mars ?). Les intentions indiquées par le CEO d'Oracle lors de la dernière JavaOne étaient de se lancer sur le secteur ouvert par Android sur les mobiles et les notebooks et qu'il y avait des trucs faits en FX... par l'équipe d'OpenOffice.

[dingoth]

[...] Pourtant des trucs comme Timeline, Transition, Interpolator, MediaPlayer, le support des flux RSS, les nouvelles couleurs "web", le support etendu des polices (qui est dans l'API mais pas encore actif) et les nouvelles composites utilisees pour la supperposition des groupes (en gros l'equivalent des composites supportees par SwingX) auraient bien leur place en Swing.

Je crois que là, j'ai un gros souci : les flux RSS, c'est du network. En quoi cela devrait-il être nativement supporté par Swing, et surtout comment sans enfermer l'utilisateur dans un système unique ?

[bouye]

Là j'aurais du sans doute plutot dire : "l'intégrer dans l'API Java". Mais bon pour être encore plus précis pour la plupart de ces choses elles sont présentes dans les classes internes proprio de Sun vers lesquelles les classes de l'API publique FX délèguent (tout comme certaines des classes de l'API publique Java délèguent vers des classes proprio de Sun). Donc ils pourraient très bien décider d'exposer ces APIS en Java s'ils le voulaient ou en avaient les moyens (et qui sait, cela viendra peut-être dans le JDK7)

Si tu vas par là également, Timeline, KeyFrame et Interpolator n'ont absolument rien de graphique non-plus puisqu'il s'agit d'un timing framework. Et pourtant elles forment la base du système de transition et d'animation de SceneGraph.

[joseph_p]

Ils ont les moyens pour FX car actuellement tous les oeufs sont dans le panier FX

erf

une question encore, d'un mec curieux mais qui ne fait pas de client lourd/riche : javaFx peut il à terme remplacer Swing ? J'ai plutot l'impression que javaFx est un truc de niche, mais bon, je peux me tromper...

[bouye]

Qui sait ? Mais il reste encore pas mal de boulot. Et les controles FX ce n'est pas du MVC* mais du VC (y a pas de modèle !).

*Mais bon Swing plutot du M V+C que du MVC de toute manière.

Concernant l'utilisation de FX dans OpenFX... vu que toutes les dernières présentations de James Gosling depuis l'animation sur l'histoire de Java lors de la dernière JavaOne jusqu'à sa présentation à l'Oracle Openworld sont en 100% FX, peut-on en déduire que ça sera une refonte de Impress (l'équivalent de PowerPoint dans Open Office) ?

[ame="http://www.youtube.com/watch?v=LVGGeM4Ewk0&feature=related"]YouTube- The Gospel of Java According to James[/ame]

EDIT - ah mais le forum support YouTube désormais ?

[professeur shadoko]

héhé, c'est la ou je ne suis pas d'accord puisqu'on peut faire de belles IHM "genre à la MAC ou QT" même en client léger et que la capture d'écran est tout a fait faisable.

C'est justement ce que je souligne, d'abord se poser ses prérequis, ensuite choisir une techno et pas l'inverse.

tout à fait d'accord!
Ce que je constate trop souvent c'est que la démarche initiale est orientée vers le spectaculaire au lieu d'être orientée vers l'ergonomie.
Un exercice très interessant est de faire son IHM avec des composants très simples (qui peuvent être joliment décorés - faire des "peaux" en awt n'est pas si extraordinairement compliqué-) se focaliser sur la facilité de compréhension de l'utilisateur ... après on peut reprendre avec du plus compliqué (mais seulement après).

[bobuse]

J'ai pas tout lu, et donc je ne sais pas si ça a déjà été cité, mais Aerith est un exemple sympa d'interface originale :
https://aerith.dev.java.net/

Sinon, les look and feel, je trouve ça assez inutile. Le minimum est que le look and feel respecte le style du système du client. C'est au client de choisir le style graphiques de ses applications, et non à l'application d'imposer le sien.

[javan00b]

C'est certain qu'ils y seront ? Je ne les vois pas dans http://java.sun.com/javase/7/docs/api/ ...

http://openjdk.java.net/projects/jdk7/features/

tout au bas de la page: "Swing updates".

[Mister Nono]

J'essaie d'eviter l'utilisation de librairie externe la pluspart du temp.

C'est sur que c'est mieux.

[lvr]

Tant qu'on y est avec Substance (ou avec la belle programmation Swing), jusqu'où faut-il aller dans l'EDT ? Si je fais un monlabel.setText("Hello"), je dois mettre ça dans l'EDT aussi ?

[dingoth]

Dans un monde idéal, oui.

[sinok]

Tout à fait. C'est une modification d'un composant graphique, donc elle doit avoir lieu dans l'EDT.
Les seules méthode qui sont thread safe dans Swing sont les quivante: repaint(), revalidate(), and invalidate() qui ne font que poster une demande sur une file d'attente et non modifier le composant en lui même.

Par contre si tu te trouves déjà dans l'EDT (c'est à dire dans toute méthode de listener, dans une méthode ou un constructeur exécuté dans l'EDT) tu n'as pas besoin d'embedder ça dans un SwingUtilities.invokeLater.

[bouye]

Waaah qqun a decide d'implementer les Generics dans Swing.
Sa participation a ete postee dans l'OpenJDK.

http://puces-blog.blogspot.com/2009/...ist-patch.html

[Baptiste Wicht]

Waaah qqun a decide d'implementer les Generics dans Swing.
Sa participation a ete postee dans l'OpenJDK.

http://puces-blog.blogspot.com/2009/...ist-patch.html

Ce serait bien le moment que ce soit dans Swing ça

[lvr]

Ce serait bien le moment que ce soit dans Swing ça

Je m'emmêle les pinceaux: l'OpenJDK n'est pas le futur du JDK ? Et si c'est dans l'OpenJDK ce ne sera pas à termes dans le JDK officiel ?
Pcq en effet c'est plutôt intéressant un Swing avec Generics

[Baptiste Wicht]

Je m'emmêle les pinceaux: l'OpenJDK n'est pas le futur du JDK ? Et si c'est dans l'OpenJDK ce ne sera pas à termes dans le JDK officiel ?
Pcq en effet c'est plutôt intéressant un Swing avec Generics

C'est pour le moment juste une proposition à ce que j'ai compris.