Java Swing - Page 2

oué enfin on peut meme dire early 1990 vu que Win 3.11 date de 1991... enfin bref et non franchement ça n'a que peut de rapport avec motif

Le premier look&feel Metal utilisait les mêmes couleurs affreuses (gris et violet).
Mais c'est vrai que le look par défaut de la version actuelle de OpenJDK est plus présentable et n'est plus en violet et gris. Mais ce qui reste est que le look par défaut est totalement hors de place, ce n'est pas le look&feel du système.

Edited_3713

Orion: C'est pourtant ce que bon nombre de gens font/on fait

et c quoi le probleme avec ca?

Ben pour les grosses interfaces c'est chiant et inutile ?

Sauf que pour beacoup de chose, c'est impossible de se passer de la possibilitée de generer le contenu a la volée

Kevin Kofler (./28) :
Mais Qt fonctionne vraiment. Et ça ne rame pas à fond, aussi. Et ils ont aussi compris que le bon look&feel par défaut, c'est celui de la plateforme (enfin, techniquement parlant, dans KDE, c'est KDE qui règle le style Qt, mais partout ailleurs Qt se règle vers le style natif tout seul), pas une horreur violette et grise nommée "Metal" alors qu'elle n'a rien de métallique qui semble rescapée des années 1970.

Swing fonctionne vraiment. Il est un peu parfois être plus lent parfois mais ne rame pas systématiquement.
Quant au look and feel :
- C'est pas comme s'il était impossible de choisir le look natif: ça prend une ligne de code. D'ailleurs c'est tout a fait justifié, Java essaye d'avoir la compatibilité cross plateforme la meilleure possible. Avoir un l&f commun va dans ce sens.
- Le look&feel métal a été remplacé par un truc plus agréable il y a un moment maintenant.

Uther (./38) :
D'ailleurs c'est tout a fait justifié, Java essaye d'avoir la compatibilité cross plateforme la meilleure possible. Avoir un l&f commun va dans ce sens.

Bah non, la meilleure compatibilité cross-plateforme, c'est de s'adapter automatiquement au look&feel de la plateforme comme le fait Qt, c'est débile de devoir mettre du code exprès pour ça, surtout parce que la plupart des logiciels ne mettent pas cette ligne de code (ou pire, activent un look&feel propre à l'application, histoire de semer encore un peu plus le bordel), à commencer par les applications de Sun (les 2-3 outils en Swing livrés avec OpenJDK utilisent tous le look&feel par défaut de Swing).

Attention je vais faire Chwing !

Si on veut alléger une interface Swing, est-ce qu'il existe une Swing gomme ?

Uther (./26) :

Nil (./8) :
Sinon ça fait longtemps que je n'ai pas fait de Java (JDK 1.2), mais faut toujours 100 lignes pour avoir une fenêtre et trois boutons en swing ?

Perso, je fais ça en une ligne.

new FenetreA3Boutons().setVisible(true) ?

beh non, ca peut pas etre ca... ca compile meme pas

Non plutot:

JOptionPane.showOptionDialog(null, "Ma fenetre à 3 bouttons", "Voila", JOptionPane.INFORMATION_MESSAGE, JOptionPane.WARNING_MESSAGE, null, new String[]{ "Boutton 1", "Boutton 2", "Boutton 3" }, "Boutton1");

ah ok mais c'est pas une fenêtre c'est une boîte de dialogue ça... (je pense que Nil voulait parler d'une vraie fenêtre où tu peux rajouter des choses, avoir un bouton plus gros que les autres, etc) ((et puis ta "ligne" est tellement longue qu'elle nique la mise en page ))

Oué mais bon une ligne de 15km de long pour remplacer 15 lignes :/

Ué, comme a dit Popo...
Bon, j'ai un peu exagéré, j'ai regardé mes sources de l'époque, il me fallait 4 lignes pour afficher une fenêtre et la préparer à recevoir des éléments.

Et pour toi 4 lignes c'est trop? je crois pas que les autre langages fassent vraiment mieux.

C'est surtout le fait qu'il faille faire une fenêtre, un layout, un panel... on ne comprenait pas l'intérêt d'avoir une telle granularité à l'époque. Surtout qu'on venait de la programmation DOS, où l'écran était la surface de travail .

Orion> c'est pour ça que depuis on a inventé netbeans, jbuilder, etc qui ont un éditeur de dialogues aux petits oignons qui permet d'avoir a écrire seulement les handlers d'évènements.

et accessoirement swing gère les look and feels donc ça peut ressembler fortement à du natif, sauf si on veut se branler sur les différences de taille au pixel près.

les pointillés c'est des repères de "collage" pour aligner les widgets.

Le problème est que le look&feel natif n'est pas le look&feel par défaut.

Peut-être parce qu'une application ne peut pas être 100% utilisable si on n'est pas certain que sa mise en forme soit correcte ? Il suffit de voir la (magnifique) skin charamel pour Firefox pour sen rendre compte : les boutons débordent, des zones prévues comme fixes ne sont plus utilisables, etc.

Personnellement, ça ne me choque pas, d'autant que l'intégration native est possible (et qu'on peut même parfois le choisir à la volée dans l'application).

l'avantage c'est que le LAF par défaut est strictement identique sur toutes les plate formes. donc ça pète pas le design.

enfin bref trollez sans moi j'ai juste répondu à la question d'Orion.

@Nil: Qt s'en sort très bien avec le look&feel natif (par défaut)!

@squalyl: Si, justement une application avec un look&feel non-natif pète le design de la plateforme!
Mais c'est bien ça le problème, Java se prend pour une plateforme alors que c'est seulement un langage de programmation.

non c'est un ensemble de lib avec.

gcc+libc quoi.

-erreur-

squalyl (./55) :
non c'est un ensemble de lib avec.
gcc+libc quoi.

Oui, mais ce n'est pas une plateforme (système d'exploitation + interface graphique), donc ça n'a pas à définir un "look&feel de la plateforme", ça a à s'intégrer au look&feel défini par la plateforme!

@Uther: Bah, pour une fois Apple a compris ce qu'ils font...

va troller chez sun ils te diront sans doute mieux que moi ce qu'ils en pensent.

Ils doivent avoir des mailing lists pour ça , ou même une FAQ.

(je sais pas pour vous, mais pour qu'une appli se comporte comme une appli native, il faut pas seulement que les fenêtres aient la bonne couleur ^^)

c'est clair