La version 1.2 de JavaFX est disponible et arrive sur Linux et OpenSolaris

Version imprimable

Voir 40 message(s) de cette discussion en une page

01/06/2009, 13h45
galien

La version 1.2 de JavaFX est disponible et arrive sur Linux et OpenSolaris

Après un petit jeu de piste j'ai réussi à télécharger la 1.2 (Windows, Mac, Solaris x86, Linux)

Les nouveautés

Citation:

Envoyé par kajava

JavaFX dans sa version 1.2 arrive enfin sur Linux :D

Plateforme de test (Fedora 10)

http://java-javafx-iipt.blogspot.com...-linux-12.html

Citation:

Envoyé par galien

Pour ceux que cela intéresse la première journée de javaone avec par le menu:

JavaFX sur une télé LG.
L'outil de création style flexbuilder.
L'app store en javaFX.
Les déclarations plus que rassurante du pdg d'Oracle sur le futur de javaFX (il voit bien OpenOffice version javaFX).
La vidéo:
http://java.sun.com/javaone/2009/general_sessions.jsp
Ce sont finalement plutôt des bonnes nouvelles pour tout ceux qui appartiennent à l'encore trop petite communauté javaFX.

Mise à jour du Plugin Eclipse

Comme d'habitude le blog de james weaver vous donnera quelques infos dessus.

http://learnjavafx.typepad.com/weblog/
01/06/2009, 18h50
Ricky81

Est ce qu'on peut s'attendre à une version plus mature qui va pouvoir faire face à la concurrence, ou faudra-t-il attendre une 2.0 ?
01/06/2009, 19h18
vbrabant

au fait, les nouveautés JavaFX 1.2 sont décrites là http://javafx.com/do...ticles/javafx1-2.jsp
Mais le plus important à savoir est que JavaFX 1.2 n'est pas compatible JavaFX 1.1 (qui n'était pas compatible JavaFX 1.0)

Et toujours pas de version annoncée pour Linux :aie:
01/06/2009, 21h32
*alexandre*

quel est l intérêt de java fx franchement ? les développeurs java ne sont pas censée faire du flash ...
01/06/2009, 22h16
galien

Y'a la version Linux et Solaris x86
Il semble de plus que le jdk update 14
01/06/2009, 23h15
entreprise38

Une chose me rébute énormément chez JavaFX : l'incompatiblité entre les versions (comme dit plus haut).
Etant dans un univers imprégné de Java, la moindre des choses aurait été de préserver cette compatiblité, non ? Ou celle-ci est-elle facilement franchissable ? Suffit-il seulement de recompiler avec le SDK visé ? (si ce n'est que ça... ça va, sinon je pleure)

Merci :ccool:
02/06/2009, 00h21
galien

Pour les changement et les incompatibilités:
http://www.javafx.com/docs/articles/javafx1-2.jsp
Sinon entreprise38 c'est en effet un peu embêtant mais étant donné la maturité de javaFX ce n'est pas si surprenant. Enfin l'API de composants graphique est définie, les problèmes viendront d'ailleurs principalement de ce coté. Sun l'avait cependant annoncé, ce n'est donc pas une surprise. Rassurons nous, les prochaines versions seront certainement rétro compatibles, comme java l'est aujourd'hui.
02/06/2009, 01h00
bouye

Bah mieux vaut qu'ils modifient puis finalisent ENFIN l'API plutot que de garder des trucs deprecated pendant des annees. Apres... apres la pilule serait probablement mieux passee si la version 1.0 et 1.1/1.1.1 avaient ete respectivement appellees beta 98 et beta 99. Reste plus qu'a esperer que la version 1.2 soit la VRAIE version finale et non-pas une etape intermediaire de plus. Pis pour le futur, faudra aussi voir ce qu'Oracle en fait et des infos qu'on pourrait glaner a la JavaOne.

Citation:

Envoyé par *alexandre*

les développeurs java ne sont pas censée faire du flash ...

Ahhh pourtant si mes souvenirs sont bons Java a commence en rajoutant des animations dans des pages web... Y a des trucs qui sont IMMENSEMENT plus compliques a faire en Java2D + JMF + JAI alors que c'est les doigts dans le nez en JavaFX.

Mais bon... *gosh* va me falloir repasser sur tous mes exemples de test... enfin une fois les telechargements effectues.
02/06/2009, 01h22
bouye

:calim2: Ben a la vue des changements c'est pas encore ca...

Mais ou est passe le language oriente pour les designers... :mouarf: ?

Mixins ? :aie:
02/06/2009, 09h54
Fr3nchK1ss

Un langage pour les designers? Hey ils vont pas quand même venir nous voler notre travail ;)
Bon, comme prévu on va souffrir, c'est pas rétro compatible et ça bouge pas mal. Mais je suis quand même content qu'ils aient amélioré la gestion des layouts et les perfs globales. Et puis une 1ère compatibilité linux officielle ça se fête non? :)
Ce début de semaine va être rude...
02/06/2009, 10h52
galien

Je vois pas vraiment pourquoi cette étiquette de langage pour les designers.
C'est plutôt un langage moderne avec une grosse api graphique, des fonctionnalité bien pratiques mais pas forcément réservé au designers.
L'outil du graphiste est la souris pas le clavier!
Pour rester sur le design il semble que pour le prochain plugin netbeans on aura le support natif du svg actuellement juste implémenté pour le plugin ME
http://wiki.netbeans.org/NewAndNoteW...MobileDesigner
Quand netbeans rencontre photoshop...
02/06/2009, 12h16
kajava

JavaFX 1.2 arrive sur Linux

JavaFX dans sa version 1.2 arrive enfin sur Linux :D

Plateforme de test (Fedora 10)

http://java-javafx-iipt.blogspot.com...-linux-12.html
02/06/2009, 14h11
Traroth2

En fait, quand on cherche à télécharger JavaFX, c'est bien la version 1.2 qu'on obtient, mais la homepage n'a pas été mise à jour.
02/06/2009, 14h13
Traroth2

Citation:

Envoyé par galien

Je vois pas vraiment pourquoi cette étiquette de langage pour les designers.
C'est plutôt un langage moderne avec une grosse api graphique, des fonctionnalité bien pratiques mais pas forcément réservé au designers.
L'outil du graphiste est la souris pas le clavier!
Pour rester sur le design il semble que pour le prochain plugin netbeans on aura le support natif du svg actuellement juste implémenté pour le plugin ME
http://wiki.netbeans.org/NewAndNoteW...MobileDesigner
Quand netbeans rencontre photoshop...

Ce n'est pas sensé être "réservé" aux designers, mais *accessible* au designer, contrairement à Java. Sauf que la rupture de compatibilité entre chaque version empêche tout travail sérieux. C'est de la beta-version, ça, et encore.
02/06/2009, 22h33
galien

Javaone 09 et le futur de javaFX

Pour ceux que cela intéresse la première journée de javaone avec par le menu:

JavaFX sur une télé LG.
L'outil de création style flexbuilder.
L'app store en javaFX.
Les déclarations plus que rassurante du pdg d'Oracle sur le futur de javaFX (il voit bien OpenOffice version javaFX).
La vidéo:
http://java.sun.com/javaone/2009/general_sessions.jsp
Ce sont finalement plutôt des bonnes nouvelles pour tout ceux qui appartiennent à l'encore trop petite communauté javaFX.
02/06/2009, 23h29
bouye

Comme cela l'a deja ete repete plusieurs fois officiellement c'est un language destine a faciliter le devellopement en utilisant une approche orientee design et non pas en utilisant l'approche classique en programmation. Il est positionne de maniere a concurrencer Flash et Silverlight et a accrocher tout le marche potentiel des designers (dans le language de Sun : des gens qui utilisent Illustrator et Photoshop. Dans leur propre mots -en parlant de la Production Suite- : "What do designers love? They love Photoshop & Illustrator! So we made Photoshop & Illustrator plugins instead of develloping our own designer's tool"). Bien sur Grosling a bien indique qu'on peut fait bien d'autres choses en JavaFX que des applications RIA (et je suis d'accord avec lui).

En attendant pour les programmeurs, ca va ils ont l'habitude de faire ca "a la dure" ; pour l'accroche des designers... on repassera... :mouarf:

Sympa JavaFX, z'ont reussis a se mettre a dos :
* Les utilisateurs Linux lors des sorties 1.0 puis 1.1.1/1.1.
* Les programmeurs Swing et Java2D (pas d'integration dans le sens inverse).
* Les gens a qui le language est principalement destine faute d'outils de design corrects et a cause des incompatibilite entre chaque version...

:zoubi:

Ahhh dans la serie Good news, suite aux changements dans l'heritage et le passage a la poubelle de l'heritage multiple (direct) on peut enfin appeler super.machin() quand on veut appeler la super methode d'une classe.

JListener.java

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
package test;
 
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;
 
/**
 *
 * @author fabriceb
 */
public class JListener extends MouseAdapter {
    /**
     * {@inheritDoc}
     */
    @Override
    public void mouseClicked(MouseEvent event) {
        System.out.println("JListener: mouseClicked()");
    }
}

FXListener.fx

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
package test;
 
import java.awt.event.MouseEvent;
import javax.swing.SwingUtilities;
 
/**
 * @author fabriceb
 */
 
public class FXListener extends JListener {
    /**
    * {@inheritDoc}
    */
    public override function mouseClicked(e:MouseEvent):Void {
        if (SwingUtilities.isRightMouseButton(e)) {
            println("FXListener: mouseClicked()");
        }
        else if (SwingUtilities.isLeftMouseButton(e)) {
            println("Trying to call super.mouseClicked(e)");
            super.mouseClicked(e);
        }
    }
}

Pour info precedement il fallait faire un truc pas vraiment documente (voir pas du tout) : JListener.mouseClicked(e) (a eviter desormais puisque la fonction boucle alors a l'infini).

03/06/2009, 00h38
bouye

Bonne nouvelle alors :D

Par contre j'vois pas la video (sans doute un blocage quelconque)... faudra que je regarde depuis chez moi.
03/06/2009, 01h45
bouye
Apparement la gestion des types est un peu moins evoluee qu'avant. Ou du moins se base uniquement sur l'usage interne de la classe et non pas egalement sur son usage externe comme avant.

Ainsi dans un test j'ai du specifier le type de deux membres que j'avais oublie de specifier lorsque j'avais code le test initialement..
Code:

1 2 3 public class ParameterEditorNode extends CustomNode { public var width; public var height;
Code:

1 2 3 def editor = ParameterEditorNode { width: bind mainPanel.width - 4 * 5.0 height: bind mainPanel.height - 4 * 5.0;
Sinon j'avais plein de ClassCastException (de ObjectVariaable en FloatVariable). Le probleme ici venait que le type de width etait bien trouve car la variable etait utilisee dans la classe meme alors que pour height, n'etant pas utilisee (elle positionnee dans la classe appellante mais pas utilisee dans la classe meme), elle prend le type Object dans la 1.2 alors qu'elle prenant le type Number dans les precedentes versions.

Bon en meme temps, la, c'etait une erreur de ma part. Mieux vaut toujours prendre l'habitude de specifier les types des membres.
Code:

1 2 3 public class ParameterEditorNode extends CustomNode { public var width:Number; public var height:Number;

Bon alors les mixins...

Ceci ne compile plus :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class Selectable {
    /**
    * Indicates whether this <code>Selectable</code> is selectable.
    * <br/>Default value is {@value}.
    */
    public var selectable:Boolean = true on replace {
        onSelectableChanged(selectable);
    }
 
    /**
    * Called whether the selectable status has changed.
    * @param selectable The current selectable status.
    */
    public var onSelectableChanged:function(selectable:Boolean);
 
    /**
    * Indicates whether this <code>Selectable</code> is selected.
    * <br/>Default value is {@value}.
    */
    public var selected:Boolean = false on replace {
        onSelectedChanged(selected);
    }
 
    /**
    * Called whether the selected status has changed.
    * @param selected The current selected status.
    */
    public var onSelectedChanged:function(selected:Boolean);
 
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
public class Enablable {
    /**
    * Indicates whether this enablabled is enabled.
    * <br/>Default value is {@value}.
    */
    public var enabled:Boolean = true on replace {
        onEnabledChanged(enabled);
    }
 
    /**
    * Called whether the enabled status has changed.
    * @param selected The current enabled status.
    */
    public var onEnabledChanged:function(enabled:Boolean);
}

Code:

public class MenuToggleButton extends CustomNode, Selectable, Enablable {

Il faut desormais ecrire :

Code:

1
2
public mixin class Selectable {
    [...]

Code:

1
2
public mixin class Enablable {
   [...]

Ce que je trouve un peu etrange. Pourquoi le declarer au niveau de la classe-mere ? Ca serait plutot au niveau de la class-fille de le declarer (du meme style que extends ... implements ... en Java)

03/06/2009, 12h22
Traroth2

Ils ont supprimé l'héritage multiple dans la version 1.2 ? C'est un peu plus qu'une petite modification de syntaxe. C'est extrêmement structurant. Pour ceux qui ont écrit du code qui l'utilisait, ça veut dire reprendre une bonne partie de leur travail, carrément au niveau conception. Ca va mal finir, cette histoire...
03/06/2009, 12h34
Traroth2

Euh... d'ici une quinzaine de jours, d'après Amazon, c'est 4 livres sur JavaFX qui doivent sortir, et ils sont prévus depuis un moment. En gros, grâce à la version 1.2, ils sont obsolètes avant même d'être en librairie, quoi...

http://www.amazon.com/Pro-JavaFX-tra...4025061&sr=8-2
http://www.amazon.com/JavaFX-Action-...4025061&sr=8-3
http://www.amazon.com/JavaFX-Develop...4025061&sr=8-5
http://www.amazon.com/Essential-Java...4025061&sr=8-7
03/06/2009, 12h35
bouye

Pour le moment le peu d'héritage multiple que j'avais (cause habitué à Java) s'est aisément résolu en mettant les mot-clé mixin là ou il fallait. Par contre comme ca se place sur la classe-mère... chai pas trop comment on peut décider qu'une classe mérite un mixin plus qu'une autre...
03/06/2009, 14h39
bouye

Effectivement tant le FXBuilder que le JavaStore ont l'air interressant. Etonant aussi qu'Oracle veuille se lancer dans le business des mobiles/appareils embarqués.

Par contre le coup de frayeur, c'est Intel qui veut dominer le monde... vivement que la CEE mette son nez dedans !!! :D
05/06/2009, 03h58
bouye

Quelques tests plus tard :

- les nouveaux layouts peuvent parfois se comporter un peu bizarrement : un Stack contenant un rectangle dont la largeur varie en fonction de la largeur de la scene sera de taille variable si mis dans une VBox mais de taille fixe si mis dans un Group (il faut alors binder le champs width du Stack avec le champs width de la scene).

- le positionnement relatif des objets dans les layout est malheureusement fait avec un int ou un float, donc parfois on a quelques pixels de decallage (nottament lors des centrages) a cause du manque de precision des calculs (mais bon c'est pour que ce soit plus rapide et mange moins de memoire, nottament sur les mobiles). Donc parfois (et contrairement a ce que disent les didaticiels 1.2), mieux faut faire un centrage maison a l'ancienne avec translateX et translateY pour avoir un afficher correct plutot que de se reposer sur le layout.

- il y a eut des changements quant au mode fullscreen : precedement quand une application fullscreen perdait le focus (ex: un dialogue quelconque non-lie a l'application pop), elle etait minimisee ; puis elle etait restauree en plein ecran quand on lui redonnait le focus. Desormais elle retrouve ses decorations et reprend sa taille initiale et on ne peut pas la remettre en plein ecran (sauf si on programme la gestion du focus ou si on met un bouton pour bien sur), ce qui peut etre plutot genant si on fait des diaporamas a la Powerpoint, si on joue de la video en plein ecran ou si on a fait une GUI sensee toujours accaparer la totalite de la surface de l'ecran.

- j'ai parfois des performances execrable des que j'utilise des gradients de trop grande taille. Dans mon test la barre titre custom de mon app se retire/coulisse vers le haut des que l'app est passee en plein ecran (apres tests, ca le fait aussi en fenetree). Si le panneau central de l'application utilise une couleur unie, pas de probleme ; si c'est un gradient... ca saccade et c'est tres lent (je ne me souviens pas avoir eut des ralentissements similaires precedement). Note : JavaFX 1.2 sur JDK 1.6.0_14
05/06/2009, 07h28
Ricky81

Salut,

Quelqu'un a essayé la nouvelle version du Plugin Eclipse réalisé par Neil Bartlett ?

http://javafx.com/docs/gettingstarted/eclipse-plugin/
05/06/2009, 09h26
bouye

non
05/06/2009, 22h45
bouye
Concernant la Production Suite, au moins 1 défaut connu de la version 1.1.1 n'est toujours pas corrigé : les gradients circulaires transformés ne sont pas correctement convertis lors du passage SVG -> FXD.

Il semble toujours y avoir des problèmes lors de l'usage de texte, ceci ne sont pas forcément transformés. Donc comme précédement dans Inkscape je converti mes textes en forme avant le passage au convertisseur de la Production Suite (pis comme les polices utilisées ne sont pas forcément présentes partout, et qu'il ne s'agit pas de texte internationalisable, c'est probablement mieux ainsi).

Précédement j'avais le code (gauge est le noeud racine UI généré à partir du FXZ, drinkButton est une des entités nommées dans le SVG) :
Code:

1 2 var autodrink = bind gauge.drinkButton.visible with inverse;
Et NetBeans m'a demandé de le remplacer par ça :
Code:

1 2 3 def drinkButton = gauge.drinkButton; var autodrink = bind drinkButton.visible with inverse;
En fait NetBeans me disait d'écrire carrément def autodrink mais j'ai comme un doute là :mrgreen:

1 pièce(s) jointe(s)

Dans la catégorie "ça sent la sortie à la va-vite avant la JavaOne" , les nomminés sont : "impossible de spécifier la couleur du texte des nouveaux composants" même en utilisant une feuille de style et également "ma Slider a toujours une grande taille malgré le fait que je lui ai dit de ne faire que 30 pixels de long".

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
def autoDrinkCheckBox = CheckBox{
    font: Font.font("Trebucher MS", FontWeight.BOLD, 10);
    text: ##"Auto drink at 2m";
    // Y a pas!
    //textFill: Color.WHITE;
}
// Marche pas et la propriété foreground n'est pas supportée.
// textFill n'a aucun effet.
// fill change le font de la case à cocher.
autoDrinkCheckBox.style="textFill: #FFFFFF; foreground: #FFFFFF;";
def volumeLabel = Label {
    font: Font.font("Trebucher MS", FontWeight.BOLD, 10);
    textFill: Color.WHITE;
    text: ##"Volume";
}
def volumeSlider = Slider {
   min:0, max: 2.0;
   value: bind player.volume with inverse;
   width: 30;
}
def panel = Panel {
   content: Stack {
       nodeVPos: VPos.CENTER;
       content : [
           background,
           VBox {
               spacing: 3;
               vpos: VPos.CENTER;
               nodeHPos: HPos.CENTER;
               content: [
                    autoDrinkCheckBox,
                    HBox {
                        spacing: 3;
                        content: [volumeLabel, volumeSlider]
                    }
               ]
           }
       ]
   }
   translateX: shadow.localToScene(shadow.boundsInLocal).minX;
   translateY: shadow.localToScene(shadow.boundsInLocal).minY;
}

Pièce jointe 48092

Parmis les trucs qui déconnent dans cette release également : le drag de fenêtre. Ainsi si je clique et tire la fenêtre de mon application d'un bord à l'autre de l'écran, celle-ci va se mettre à vaciller, apparaitre de ci-delà sur l'écran et si je relache suffisament vite la souris, je peux même arriver à mettre la fenêtre carrement intégralement hors de la surface affichable (alors que j'ai relaché ma souris dans la surface affichable).
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 def stage2:Stage = Stage { title: ##"Fire Water 2"; style: StageStyle.TRANSPARENT; scene: Scene { fill: Color.TRANSPARENT; content: Group { content: [panel, interface2UI]; /** * Makes the entire group draggable. */ onMouseDragged: function( e: MouseEvent ):Void { FX.deferAction(function():Void { stage2.x += e.dragX; stage2.y += e.dragY; }); } } } }
En formant un projet plus simple (un unique Rectangle dans la scene, le tout dans une fenêtre décorée), un code similaire fonctionne très bien avec la 1.1.1+1.6.0_14 ; MAIS a ce comportement bizarre dans la 1.2+1.6.0_14 (Note : le deferAction() ici est une tentative de résoudre le problème).

J'avoue ne pas trop savoir où est le problème d'autant plus que Sergey Malenkov fait pareil dans sa classe application (https://malenkov.dev.java.net/20090602/Application.fx) et que son application de test des nouveaux composants (http://weblogs.java.net/blog/malenko...rols_in_j.html) n'a pas le comportement hérratique de la mienne.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 [...] Rectangle { cursor: Cursor.MOVE blocksMouse: true visible: bind show and (not applet or draggable) x: bind border y: bind border width: bind width height: bind offset arcWidth: bind round arcHeight: bind round fill: bind foreground opacity: 0.1 onMouseEntered: function(event) { hover = true } onMouseExited: function(event) { hover = false } onMouseDragged: function(event) { stage.x += event.dragX; stage.y += event.dragY; } } [...]
PS : à noter qu'une fois l'animation du chrono lancée, la fenêtre a tendace à se comporter normalement.

08/06/2009, 09h39
Fr3nchK1ss

Citation:

Envoyé par bouye

- j'ai parfois des performances execrable des que j'utilise des gradients de trop grande taille. Dans mon test la barre titre custom de mon app se retire/coulisse vers le haut des que l'app est passee en plein ecran (apres tests, ca le fait aussi en fenetree). Si le panneau central de l'application utilise une couleur unie, pas de probleme ; si c'est un gradient... ca saccade et c'est tres lent (je ne me souviens pas avoir eut des ralentissements similaires precedement). Note : JavaFX 1.2 sur JDK 1.6.0_14

J'ai eu le même problème, que j'ai résolu en mettant la propriété "cache" à true au niveau du composant qui contient le gradient. De base, la valeur est à false alors JavaFX redessine tout le gradient en continue... A true, il convertit en bitmap et basta.

Sinon, moi aussi mon drag&drop déconne un peu, et j'ai aussi des problèmes de précision lors de gros zooms. Certains composants se retrouvent pas à la bonne place alors que ce n'était pas le cas avec la 1.1.1.

Citation:

Envoyé par bouye

Dans la catégorie "ça sent la sortie à la va-vite avant la JavaOne" , les nomminés sont : "impossible de spécifier la couleur du texte des nouveaux composants" même en utilisant une feuille de style et également "ma Slider a toujours une grande taille malgré le fait que je lui ai dit de ne faire que 30 pixels de long".

Et oui, moi aussi j'ai un peu halluciné (en plus du manque de la combobox). Pour l'instant, je m'en sors en enlevant le texte de la checkbox et en lui groupant (HBox) un composant Text que je customise. J'ai aussi des problèmes de dimension sur les boutons. Ils ont une taille qui varie suivant la taille de la police utilisée pour le texte interne. Width et Height n'ont aucun effet... J'utilisais des petits icons pour des boutons de type "fermer" ou "recentrer", même combat, maintenant ça fait un gros bloc gris avec le petit icon dedans... impossible de réduire la taille du bouton aux dimensions de l'image.
08/06/2009, 22h54
galien

J'attends aussi avec impatience un article de Amy Fowler sur les layouts, apparemment il faut utiliser layoutinfo mais ya des trucs zarbs
09/06/2009, 04h58
bouye

Yep, j'attends egalement cela avec impatience.

Sinon, non cache ne change rien pour moi au niveau perfs, pire suivant ou la valeur est positionnee (j'ai essaye plusieurs combinaisons), j'ai des erreurs dans le rendu.

1 pièce(s) jointe(s)

Parmis les changements on peut noter le fait que les composants Swing ont le LnF systeme par defaut et que ce n'est pas top : autant Nimbus se mariait bien avec JFX autant le LnF Windows ce n'est pas trop ca (sans compter que des composants non-opaques dans Nimbus comme la JSlider deviennent opaques en LnF windows). J'imagine que ce changement fait suite au sondage recent sur un blog d'un dev Swing qui demandait quel LnF appliquer par defaut a Swing dans Java 7 (et comme la grosse majorite j'ai repondu : le LnF du systeme... vi mais voila autant c'est glop pour Swing :ccool: autant ca l'est moins dans JFX :calim2:).

Bon bref une raison de plus d'essayer de se rabattre sur les nouveaux composants natifs. Mais bon... mes divers tentatives d'amadouer la Slider menent toujours a la meme chose : elle reste de taille fixe...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 /** * Slider node. */ def transparencySlider = Slider { min: MIN_SLIDER_VALUE; max: MAX_SLIDER_VALUE; //width: 75; layoutInfo: LayoutInfo { vpos: VPos.CENTER; minWidth: 75; maxWidth: 75; } } [...] def controlGroup:HBox = HBox { spacing: 7; vpos: VPos.CENTER; content: [visibleIcon, separator, transparencySlider ] } def backgroundShape:Rectangle = Rectangle { width: controlGroup.boundsInLocal.width + 2*7; height: controlGroup.boundsInLocal.height + 2*7; arcWidth: bind backgroundShape.height; arcHeight: bind backgroundShape.height; fill: bind fill; stroke: bind stroke; } return Stack { content: [backgroundShape, controlGroup] };
Pièce jointe 48274

Sinon je pense limiter l'usage de Stack au strict minimum vital (centrer des composants l'un sur l'autre) pour le moment... j'ai des problemes de rendu parfois des que j'en utilise. Par contre Flow, ClipView et des versions plus controlees de HBox et VBox, la pas de probleme...

10/06/2009, 06h55
bouye
PS : a noter que si on force Swing a utiliser Nimbus, on a le Nimbus aux coins carres de Swing quand on est en pur Java et non-pas le nimbus customise pour JavaFX avec des coins arrondis qu'on avait dans les versions precedentes:
Code:

1 2 3 4 5 6 7 import javax.swing.UIManager; try { UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName()); } catch (e:Exception) { }
11/06/2009, 18h10
galien
essaye avec ca chez moi ca marche
Code:

1 2 UIManager.setLookAndFeel("com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel");
Sinon j'ai un soucis avec la ListView dont la barre de défilement ne veut pas se remettre en haut quand on fait un select(0) ou un firstRow()

une idée?

Suis-je bete... c'etait Metal/Ocean et non-pas Nimbus :bug:

Sinon pour le slider :
Code:

1 2 3 4 5 6 7 8 9 def transparencySlider = Slider { min: MIN_SLIDER_VALUE; max: MAX_SLIDER_VALUE; layoutInfo: LayoutInfo { vpos: VPos.CENTER; width: 75; } }
Apparement la ListView ne me semble pas pleinement fonctionnelle... on a pas de retour de changement d'index ni de retour visuel SAUF si on a clique dessus avant le debut de la transition. Je crois que tu es bon pour aller ecrire un bug report ou un request for enhancement.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 /* * Main.fx * * Created on Jun 12, 2009, 8:34:50 AM */ package listview; import javafx.stage.Stage; import javafx.scene.Scene; import javafx.scene.control.ListView; import javafx.animation.transition.SequentialTransition; import javafx.animation.transition.PauseTransition; /** * @author fabriceb */ def list:ListView = ListView { width: bind list.scene.width; height: bind list.scene.height; items: [ ##"Zero", ##"One", ##"Two", ##"Three", ##"Four", ##"Five", ##"Six", ##"Seven", ##"Height", ##"Nine", ##"Ten"] } def index = bind list.selectedIndex on replace { println("Index changed {list.selectedIndex}"); } def value = bind list.selectedItem on replace { println("Value changed {list.selectedItem}"); } Stage { title: ##"ListView test" width: 250 height: 150 scene: Scene { content: list } } println("Selecting last row"); list.selectFirstRow(); println("{list.selectedIndex} {list.selectedItem}"); def anim = SequentialTransition { content: [ PauseTransition { duration: 2s; action: function():Void { println("Selecting last row"); list.selectLastRow(); println("{list.selectedIndex} {list.selectedItem}"); } } PauseTransition { duration: 2s; action: function():Void { println("Selecting first row"); list.selectFirstRow(); println("{list.selectedIndex} {list.selectedItem}"); } } ] } anim.playFromStart();
Autre bug dans ce test : quand je selectionne le premier element a la souris et que je descend avec le clavier jusqu'au dernier la scroll bar fini par disparaitre. Si on remonte (toujours au clavier), elle ne reapparait que lorsqu'on depasse l'element "Five".

Egalement une fois (et une seule fois) lors d'un lancement je me suis retrouve avec des cases selectionnees en bleu uni plutot que le gradient cyan-bleu normal...

Dans le meme hier j'ai integrer une ScrollBar dans mon code et elle semble se montrer incapable d'intercepter les mouvements de la roulette...
Cela se voit egalement dans l'exemple : si on scrolle avec la roulette sur la liste, elle defile, si on scrolle sur la barre rien ne se passe. Implementer la closure de gestion de la roulette sur la barre n'y change rien.

1 pièce(s) jointe(s)

Mouai....
Apres quelques semaines, mon avis perso est que les controles & layout ne sont pas vraiment au points :

- pour des raisons que je ne comprend pas il m'arrive souvent que le noeud n'acquiert sa taille definitive qu'APRES son affichage et comme le layout ne se remet pas a jour malgre le binding, j'ai des noeuds qui ne sont pas alignes ou bizarement alignes (dans un Stack ou tout devrait etre centre, l'une des HBox est complement decallee a droite par exemple) ou carrement coupe si on a voulu jouer un peu avec le clip...

-cote composant, c'est bug sur bug ou trucs pas implementes : la Slider ne supporte pas bien les valeurs negatives (essayez de bouger le bouton des sliders 2 & 3 dans l'exemple), s'affiche de maniere pourrage et se comporte mal des qu'elle est integree dans un CustomNode (bougez un peu le bouton de la slider 1 tout a gauche aussi pour voir... le track va se decaller...) ou a 80% de son API pas implementee...

Pièce jointe 48805

Test.fx

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
package slider;
 
import javafx.scene.CustomNode;
import javafx.scene.Node;
 
import javafx.scene.control.Slider;
 
/**
 * @author fabriceb
 */
 
public class Test extends CustomNode {
 
    public override function create(): Node {
        return Slider{
        }
    }
}

Main.fx

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
 
package slider;
 
import javafx.stage.Stage;
import javafx.scene.Scene;
 
import javafx.scene.layout.VBox;
 
import javafx.scene.control.Slider;
 
/**
 * @author fabriceb
 */
 
Stage {
    title: "Application title"
    scene: Scene {
        content: [
            VBox {
                content: [
                    Test {
 
                    }
                    Slider {
                        value: 0;
                        min: -180.0;
                        max: 180.0;
                    }
                    Slider {
                        value: 0;
                        min: -90.0;
                        max: 90.0;
                    }
                    Slider {
                        value:0;
                        min: 0.0;
                        max: 180.0;
                    }
                    Slider {
                        value:0;
                        min: 0.0;
                        max: 90.0;
                    }
                    Slider {
                        value:0;
                        min: 0.0;
                        max: 180.0;
                    }
                    Slider {
                        labelFormatter: function(f:Float):String {
                            return "{f}";
                        }
                        showTickMarks: true;
                        showTickLabels: true;
                        majorTickUnit:  10;
                        minorTickCount: 5;
                        value:0;
                        min: 0.0;
                        max: 10.0;
                    }
                    Slider {
                        labelFormatter: function(f:Float):String {
                            return "{f}";
                        }
                        showTickMarks: true;
                        showTickLabels: true;
                        majorTickUnit:  10;
                        minorTickCount: 5;
                        value:0;
                        min: 0.0;
                        max: 10.0;
                        vertical: true;
                    }
                ]
            }
        ]
    }
}

19/06/2009, 07h26
gifffftane

D'un autre coté, les choses avancent (lentement) dans le bon sens ; outre le support de Linux, voici maintenant... Amy Fowler on Using JavaFX with Swing. Sun semble ENFIN se préoccuper de la compatibilité FX / Swing, autrement que par le biais de hackers fous !

Ce que je me demande, moi qui suit un programmeur swing, c'est si on peut mettre JavaFX dans une livraison sous la forme de jars, en supposant que Java SE soit déjà installé, s'il n'y a pas des problèmes de licences, car je crois avoir compris que la licence était encore plus complexe que l'usage ? Y a-t-il un dépot maven ?

Si cela continue d'avancer aussi bien, dans 1 an il sera temps de se mettre à JavaFX, soyons optimistes.
19/06/2009, 14h23
bouye

Pour le moment les seuls moyens de redistribuer JavaFX serait d'installer le package du JDK dispo chez Sun qui le contient (donc exit le support du Mac), en espérant qu'il a été mis à jour pour le JDK 1.6.0_14 et JavaFX 1.2 (la release initiale contenait le JDK 1.6.0_13 et JavaFX 1.1.1).

Pour le reste, et pour le moment, c'est téléchargement lors du lancement Java Web Start ou téléchargement par le JRE lors du lancement de l'applet.

Utiliser les binaires du SDK pour les redistribuer ce n'est pas bon : d'une part la licence l'interdit mais en plus il ne contient que les lib natives du système surlequel il tourne.

Le problème de l'article d'Amy c'est qu'il ne présente rien de nouveau : tout ce qu'il indique (à part les layouts) on pouvait déjà le faire dans la version 1.0 de JavaFX. Et si elle part bien d'utiliser JavaFX pour pimenter une application Java (hum c'est bien vague ça une application Java), elle se perd rapidement en route pour retomber sur la seule chose qu'on puisse faire aujourd'hui : mettre du Swing dans une GUI JavaFX (donc en gros, ton programme Swing existant tu l'oublies et tu recodes toute ton interface en JavaFX en intégrants tes sous-composants/modules Swing existants).

Citation:

The complaint can be explained in part by the difficulty with which JavaFX could be used to enhance existing Swing applications. While adding JavaFX to a Swing application is still difficult, [...] Swing components from within JavaFX.

[...]

Once a Swing component is embedded in a JavaFX application, [...]

Voir 40 message(s) de cette discussion en une page

Fuseau horaire GMT +2. Il est actuellement 09h36.