Discussion :

[_skip]

Bonjour,

On peut voir que JavaFx, techno autrefois stupide et honteuse subit un gros lifting et se rapproche petit à petit de quelque chose d'utilisable, ce qui n'est pas malvenu après presque 4 ans d'existence (et de doutes sur son avenir).

Toutefois, je n'arrive pas bien à y voir clair dans le rôle que javaFX va jouer. Est-ce que c'est destiné à devenir la nouvelle façon de faire des applications desktop en java au détriment de swing / swt etc... Ou est-ce que c'est juste réservé aux petites applications *kitenfoutepleinlavu* avec leurs petits boutons animés?

En gros si je veux programmer une application de gestion avec une ergonomie moderne mais néanmoins classique est-ce que javaFx sera le choix mis en avant ou est-ce qu'il faudra encore rester sur du swing?

[la.lune]

Cette question est bien frenquente ,je rapporte ce que dit la FAQ de JavaFX sur le site officiele javafx.com

"6. Est se que JavaFX est entrain de remplacer Swing comme comme la nouvelle librerie d'UI client pour le Java SE?"

"Oui et non. Swing restera une partie de la spécification Java SE pour l'avenir prévisible, et est inclus dans le JRE. D'une part, Swing est largement utilisé dans les applications existantes de Java Desktop, mais s'appuie sur une architecture ancienne, qui nécessite un certain niveau d'expertise et de spécialisation. D'autre part, JavaFX comprend un ensemble de contrôles d'interface utilisateur moderne, qui peut être dépouillés selon des techniques standard CSS. Bien que nous recommandons aux développeurs d'exploiter les API JavaFX autant que possible lors de la construction de nouvelles applications, il est possible d'utiliser Swing et JavaFX dans la même application, permettant aux développeurs d'étendre les applications Swing existants.

Mais selon un expert sur ce forum il dit:

il reste encore des tas de trucs qui font que ni AWT/Swing ni Java2D ne peuvent être abandonnés pour le moment :

• Pas de gestion du texte bidir (en saisie)
• Pas de gestion de l'accessibilité
• Pas de gestion de l'I18N (y compris l'orientation des composants et layouts en R2L ou dans les autres directions).
• Pas de composant de texte à filtrage
• Choicebox à virer et à rapidement remplacer par une ComboBox reposant sur Cell
• Pas d'API bitmap 2D (et le langage de shaders permettant de faire des effets est pour le moment privé)
• La gestion des Path est catastrophique au niveau occupation mémoire par rapport à PathIterator/Path2D de Java2D (composer trop de chemins entre eux et c'est la catastrophe)
• Gestion du stroke trop simpliste
• Les charts bouffent une quantité de mémoire hallucinante (par rapport à des libs équivalentes Swing)
• ...

Pour conclure, je peut personnellement dire qu'on peut se passer de Swing AWT pour nos applications en java et au cas où on on trouve une necessité sur une fonctionalité qui n'existe pas dans JavaFX on peut opter pour l'hybride,vu qu'on peut porter JavaFX sur Swing et non pas le contraire, ou retourner en Swing,mais a vrai dire ça ne tardera pas que JavaFX supporte tout. Il ne faut pas oublier que beaucoup de fonctionalités existent et bien évolué dans JavaFX. JavaFX est bien très avant et surtout sur l'aspet dynamique. C'est aussi simple de créer une application MVC avec. J'étais parfaitement étonné de voir comment on peut exploiter facilement des services web avec, integrer n'importe quel Map Bing, Google Map,Yahoo sans avoir besoin d'une API intermédiaire comme fait Flash ou Silverlight. Avec le conteneur WebView c'est une révolution, est possible en une simple méthode, envoyer Script JavaScript pour que ce conteneur l'execute dans le contenu existant. J'ai vu des gens utiliser certains contrôles JQuery UI dedant et les manipuler avec ce que ça retourne en Java.

Je peut dire que on va vers une nouvelle génération pour les RIA.

[_skip]

Salut et merci de ta réponse.
Je n'ai aucun doute que tous les widgets super cool puissent être utilisés mais dans une application de gestion, on a surtout besoin de fonctionnalité comme par exemple les impressions, l'accès aux périphériques etc...
Typiquement ce qui tourne autour de l'impression en java (printdialog et autres vieilleries awt) aurait un équivalent sur javafx ?

[sinok]

Pour tout ce qui est printing, faut continuer de passer par tout ce qui est PrintService, en générant des documents dont le type est supporté nativement par les imprimantes (PDF, images,...) et en l'envoyant à l'imprimante...
Ce qui évite d'avoir à se fader de dessiner directement sur les graphics de l'imprimante...

[bouye]

Actuellement :

• Pour le moment, pas de dialogue d'impression en FX. Il faut en construire un soi-même en fonction des infos retournées par le PrintService et le mécanisme d'impression AWT.
• Toujours pas d'export de scène ou de nœud en bitmap donc pas possible d'imprimer ou d'exporter en bitmap ou en PDF rapidement sans se prendre la tête. Officieusement, il y a cette méthode mais je n'ai pas testé son efficacité (et sa disponibilité dans la 2.1 bêta).
  Une méthode alternative est de passer par un JFXPanel (inclusion FX dans Swing) ou un FXCanvas (inclusion FX dans SWT) et de faire l'export bitmap via ces framework/toolkit mais c'est plus lourd.
• Pas de scène alternative/device independant dont la sortie serait autre chose que l’écran genre PrinterScene (un peu comme le fait qu'un Graphics peut cibler autre chose qu'un écran).

Cependant :

• Export PDF, SVG, HTML ou tooklit vectoriel similaire possible en explorant le SceneGraphe et en traduisant a mano les nœuds rencontrés vers leurs équivalents du toolkit en question.

EDIT - ca marche aussi en 2.1.

• Le code de la classe ImageConverter est disponible ici.
• Il faut bien sur que le nœud et sa scène aient été visibles a l’écran auparavant pour qu'ils soient realized sinon l'image résultat sera vierge.
• Bizarrement, l'image de sortie est opaque (couleur de fond = couleur de la scène). Penser a mettre une couleur de scène transparente pour avoir une image non-opaque.