Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
L'état de l'art est qu'on a pas besoin de fournir la JVM en bundle avec l'application. SWT, si. Et on ne peut pas juste mettre les jars pour tous les OS, ça ne marche pas. Ça oblige à faire de la gestion d'installation dont on se passe en général très bien en Java.
Le parallèle avec la JVM est osé, ce serait un peu comme si tu développais une application windows et tu demandais au client d'installer l'OSEnvoyé par Mickael_Istria
Un peu comme la JVM en faitL'implem de la VM est differente selon les OS, c'est pareil pour SWT. Ca ne le rend pas moins portable.
Quand on développe un soft, on ne fournit pas la jvm, on demande une version minimum tout au plus
Je crois que le fait de penser que c'est principalement ça qui pousserait un développeur à migrer de Swing ou Swt vers JavaFX serait une erreur, ce n'est pas juste une question d'animation, d'effets et de 3D.
JavaFX est une api construit à partir de zéro et une architecture bien pensée, et j'aurais aimé souligner qu'en JavaFX on retrouve:
- Une très bonne api de gestion des beans et simple à utiliser, qui permet la gestion facile de l'aspect dynamique des interfaces et la mise à jour des données avec le concept du binding, Tout contrôle qui s'affiche devant vous, c'est que derrière il y a un ensemble de propriétés(beans) qui définissent son comportement, chaque propriété peut être bindé avec un autre pour synchroniser ou non les modifications, comme il peut être la cible d'un événement et on peut écouter son changement de façon synchrone ou asynchrone selon notre choix. Sans pour autant nier la faisabilité de cela en Awt/Swing et Java2D, ou SWT mais je parle d'une architecture bien pensée à l'avance et simple à manier. Et pourquoi réinventer difficilement la roue alors qu'il y a ce qui est déjà servi et bien conçu.
- JavaFX est la meilleur API Java en matière de simplification à la conception d'applications suivant le pattern MVC, certains voient que le support de MVC en Swing pour manque de cohérence dans certains cas.
- Comment faites-vous pour personnaliser le Look&Feel de vos interfaces en SWT et en Swing? et avec quel coût? et pour quel résultat? Alors qu'en JavaFX vous programmer vos interfaces en toute tranquillité et après avec les feuilles de styles CSS vous faites tout ce que vous voulez en matière de style.
- Le langage FXML que vous pouvez adopter si vous voulez, et l'outils Scene Builder qui permet de concevoir rapidement l'UI en FXML et personnaliser après avec les CSS. Et tout est conçu à l'avance pour aller avec le pattern MVC.
- Alors les fan de gestion de contenu multimédia, ils vont trouvent ce qu'ils veulent, de même que les développeur de Jeux 3D, mais surtout le fait que JavaFX soit écrit à partir de zéro, de la base profonde, ça lui permet d'exploiter des nouvelles technologies graphiques des puissantes cartes graphiques modernes qui embarquent le GPU avec, ainsi ça offre une nouvelle expérience.
- Interopérabilité avec Swing et SWT, après la sortie de JavaFX 2.0, l'équipe JavaFX avait développé JFXPanel et FXCanvas pour permettre d'intégration de JavaFX respectivement dans Swing et SWT, ceci afin de permettre l’extension des interfaces existantes ou cas où on veut ajouter, des composants avec des effets ou des transitions à des interfaces existantes vu que cela n'était pas possible, après maintenant ils ont développé SwingNode pour intégrer Swing dans une application JavaFX existence, et récemment j'ai vu un article quelqu'un qui expliquait comment intégrer Swing,SWT,et JavaFX ensemble et les forcer à s’exécuter dans le thread JavaFX.
- .......
Personne ne nie que un API comme Swing est très riche et il y a quelques composants en Swing qui ne sont pas encore développés en JavaFX, mais tout reste que JavaFX possède aussi des contrôles qui n'existent pas en Swing comme les Chart par défaut, ou recensement plusieurs contrôles, il y a même le contrôle qui ressemble carrément à une feuille de calcul comme Excel et beaucoup d'autres. Et l'interopérabilité permet de combler tout vide quel qu'il soit.
Nous sommes devant HTML5 et on ne peut rester les mains croisés si un besoin de performance ou autre se pressentent, et qu'on se trouve qu'on ne peut pas faire exactement en natif ce que HTML5 fait dans le web, pour la pure et simple raison qu'on n'arriverait pas à réaliser cela avec Swing ou SWT. Bienvenue JavaFX!!
J'ai bien aimé le fait de voir que depuis la sortie de Windows 8, un développeur a pu reproduire le style Moderne UI en JavaFX rien qu'avec les css comme vous voyez dans ces images:
C'est du JavaFX personnalisé avec css en Fait.
Pièce jointe 138533
J'aurais une question à poser sur Java FX.
Existe-il un designer comme Microsoft blend en .net qui gère les styles , les storyboards ( GPU accéléré) etc...
sans pondre du code et en permettant une prévisualisation des animations sans compilation.
En Xaml on a la notion de template (en plus des styles) pour changer notamment la structure d'un contrôle simplement
( exemple remplacer une progressBar par un thermométre dont la température progresse de manière animée)
Le css +fxml permet-t-il de gérer simplement ça ?
Pour ce qui est de la génération de styles css et de code pour les animations on utilise FX Experience Tools et on visualise ce qui ça donner sans être obliger de pondre du code.
De même, avec certaines limite, pour ce qui est de la modification de l'apparence et l'ajout des effets(reflexion, trensparence, ombre..) et la prévisualisation des styles en Css on utilise JavaFX Scene Builder, mais Scene Builder ne génère pas de code css à votre place mais il applique ces modifications sur le fxml, mais il permet aussi avec autocompletion(v2.0) de choisir vous même les styles css que vous voulez appliquez, ou intégrer un fichier existant et visualiser le comportement sans être obligé de faire de la compilation.
Alors je vais essayer de vous expliquer une chose très importante existante en JavaFX et l'approche qui permet de réaliser facilement ce que vous dites. D'abord en JavaFX on a la notion de Skin qui est une classe qui communique avec un Behaveor et le Control, pour former le controle en sa totalité. Ainsi, il faut comprendre qu'en JavaFX chaque contrôle obéit au modèle MVC : le M:Model est représenté par le Control en soi, la classe qui s'en charge de garder l'état du control en détenant l'ensemble des propriétés du control, les propriétés sont des beans comme j'ai expliqué au premier message, et le V:view : c'est le Skin, la classe qui gère la partie Look&Feel du control, ainsi on sépare la partie look&Feel du Control avec les interaction de l'utilisateur. Et enfin le Behaveor qui n'est autre que le C: controlleur, c'est celle qui encapsule l'ensemble des interactions de l'utilisateur(clique de la souris, taper sur clavier, bouger le molette de la souris....)
Ainsi, l'habillage du control peut facilement être modifié en modifiant la variable skin sans que qu'on modifie ni son comportement ni son état, déjà les css s'applique à la classe SkinBase.
Ainsi, la logique fonctionnel d'un control est totalement séparée à son apparence, alors selon moi je ne vois pas encore le besoin de définir spécialement de Template dans le moment où chaque control tout son habillage est paramétrable et les propriétés(modèle) (sont des beans) qui peuvent êtres modifiés, écouter des événements et toutes les modifications se synchronisent entre tout, et on peut faire du binding partout et faire des animations personnalisé(pas les transitions par défaut) qui vont modifier les propriétés et le control agit en "temps réel". Et les CSS supportent les contrôles personnalisés et on peut créer des StealableProperties afin de permettre de styler les propriétés via CSS.
Alors pour l'exemple que tu as donné d'un progresse bar transformé en en thérmomètre cela est facilement faisable en JavaFX comme j'a dis l’apparence peut facilement changer et la logique fonctionnel du control reste le même et on peut ajouter des animations. Je vais te montrer un exemple d'application où on voit des contrôles par défaut, et vu que que tous les controles sont skinnables, alors dans la démo les controles sont skinné pour donner une apparence voulu mais derrière on a des controles connus et existant dans l'api JavaFX, regarde la vidéo suivante et tu peux retrouver le code source ici
Tout reste qu'avec JavaFX8 la notion de Skin à un peu évolué, bien développé et a subit quelques modifications, (on attend la version finale en Mars), déjà l'API SkinBase était privé c'est récemment qu'il est rendu publique pour permettre de créer des contrôles customisés et le BehavorBase reste encore privé. Mais la nouveauté avec JavaFX8 c'est qu'il est désormais possible de créer toute une classe à part avec nouveau Look&Feel qui implémente l'interface Skin et le spécifier dans le fichier css comme suit:
A noter que les attribuits css de JavaFX ne sont pas forcement ceux de html5.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4.custom-control { -fx-skin: com.javafx.customControl.skin.CustomControlSkin; }
EDIT: Je n'ai aucune expérience en Xaml mais je me suis basé sur ce que tu as dis et l'exemple que tu as donné
très belle réponse , je vais essayer de voir ce que ça donne, j'avais déja essayer java fx , mais au tout début de sa création. D'après ce que tu me montre , ça a évolué, j'ai donc besoin d'en apprendre plus par la pratique pour pouvoir émettre un jugement face à XAML.
En fait tu te méprends sur les templates dont il parlait.
En WPF l'apparence et la logique d'un contrôle sont également séparés. Ainsi un bouton a une propriété "Template" qui définit son apparence (et une propriété ContentTemplate si l'on veut seulement personnaliser l'aspect du contenu du bouton) et en-dehors de cela un bouton n'est qu'une logique et n'a aucune apparence propre. Template WPF et Skin Java FX me semblent donc fonctionnellement équivalents. De même que pour de simples changements de couleur WPF a des styles équivalents à ceux de CSS (mais moins puissants et plus lourds à vrai dire).
La grosse différence il me semble c'est que côté WPF le template est défini en XAML (le langage UI) plutôt qu'en C#/VB, tandis qu'en JavaFX une skin est codée en Java plutôt qu'en FXScript. Et du coup c'est plus facile en WPF : on spécifie directement un arbre visuel avec ses animations et tout le reste (plutôt que d'avoir à le rebâtir à la main en Java), et surtout le lien avec les propriétés du contrôle "skinné" est fait très simplement via des déclarations comme <TextBlock Text="{TemplateBinding Content}"/>, là où en Java il faudra souscrire aux abonnements du "skinné" pour détecter les changements de propriétés.
Du coup il me semble qu'une skin en java contient pas mal de plomberie là où un template en WPF se résume presque uniquement à la spécification de l'arbre visuel désiré.
Un simple exemple.
Répondre avec citation
Partager