Discussion :

[bulbo]

Je te conseille le bouquin : "Les cahiers du programmeur Swing". C'est très bien fait pour comprendre et maîtriser les différents aspects de Swing.

Comme dit dans un autre post, coder un GridBagLayout à la main c'est du masochisme alors renseigne toi sur le FormLayout et/ou TableLayout.

J'utilise a 98% du GridBagLayout pour des GUI complexes (et a la main!), j'ai une fois été confronté a un problème du fait que je n'avais pas la main sur le container principal (dans le NetBeans RCP) et le FormLayout m'a sorti de la panade.

Si tu écris proprement ton code, un GridBagLayout c'est très maintenable et plus simple au final que les empilements délirant de Panel que l'on voit parfois, chacun avec son propre layout (plus simple que le gridBag) mais qui réagissent pas toujours comme on s'y attend une fois que l'on commence a changer la dimension de la fenêtre..

Le seul inconvénient du GridBag est qu'il y a un apprentissage a faire, ceux qui connaissent ne jure plus que par ça, les autres suivant leur talents soient bidouilles avec des layouts simple ou d'autres genre Form et TableLayout, les plus doués (et maso) développent le leur ce qu'a fait un collègue a moi un truc a mi-chemin entre le Form et le Table avec plus de chose a connaitre au final que pour un gridBag et quant j'ai viré son truc pour mettre un GridBag certains bug au redimensionnement ont disparu et le code a perdu beaucoup de lignes et de panel inutiles.

Je reproche au FormLayout une terminologie complexe et finalement moins de flexibilite que le GridBag.

Ajouter un composant au milieu d'une fenêtre avec un Form (et surement aussi avec un Table mais je connais pas trop celui la) signifie revoir les contraintes de tous les composants ajoutés après celui la
Niveau maintenance on a vu mieux.

Dans un GridBag il suffit de mettre les contraintes qui vont bien pour ce composant et zou .. dans les cas les plus complexes il faut rajouter 1 a la hauteur d'un composant sur un des cotés mais en général on n'affecte pas le reste des composants..

Bulbo

[xixi31]

sans compter que le layout de jgoodies a parfois quelques défauts quant à la gestion de JScrollPane... malgré tout ca reste un excellent layout....
je sors un peu du sujet là, non ?

[bulbo]

sans compter que le layout de jgoodies a parfois quelques défauts quant à la gestion de JScrollPane... malgré tout ca reste un excellent layout....
je sors un peu du sujet là, non ?

Meuh non .. et JGoodies n'est pas le seul a avoir des problèmes avec les scrollpane, le GridBag a le même problème.. une sombre histoire de minimumsize et de preferredsize si je me rappelle bien..

Bulbo

[natha]

GridBagLayout

J'avoue avoir été un peu extrême à dire "masochisme". Je m'excuse et retire.
Dans notre cadre d'utilisation le FormLayout est massivement employé car nous faisons... des formulaires Pour mettre des labels et des texfield, radio, checkbox, etc..., c'est top ! Pour créer une hiérarchie complexe de panels, c'est pas top, et des fois on utilise le FormLayout à tord.

Maintenant avec l'habitude on s'en sort très bien et on connait les pièges à éviter au niveau du redimensionnement donc ça roule.

Nous avons de plus beaucoup de débutants, alors les former chacun à faire un GridBagLayout complexe... très peu pour moi Le FormLayout est bien plus accessible.

[Uther]

Personelement je trouve de GridBag infame et je suis un farouche partisan de l'empilement de panel avec différents Layouts, A plupart du temps, je m'en tire bien avec seulement des BorderLayout, BoxLayout et GroupLayout

Ca doit dépendre des gouts.

[xixi31]

je ne voulais pas taper sur le FormLayout, il m'a rendu bien des services et il est relativement simple à utiliser .

Globalement tant qu'on en est a parlé de Layout, pour moi, les 2 indispensables sont le BoxLayout (qui semble gérer parfaitement les JScrollPane ) et le GridBagLayout.

[bulbo]

Personelement je trouve de GridBag infame et je suis un farouche partisan de l'empilement de panel avec différents Layouts, A plupart du temps, je m'en tire bien avec seulement des BorderLayout, BoxLayout et GroupLayout

Ca doit dépendre des gouts.

Tant que tu obtiens ce que tu veux c'est parfait..

Maintenant tu peux ne pas aimer le GridBag mais niveau maintenance ton truc est un cauchemar..

Pour savoir comment va se redimensionner un composant tu dois refaire en sens inverse la hiérarchie de panel et appliquer dans le bon ordre les règles de chaque layout rencontré en chemin ..
En plus niveau perf, les events doivent se ballader a travers tout ce bazar, ce qui prend plus de temps (ok je chipote a mort la )

Bulbo

[dingoth]

Personnellement, je suis pas fan du GridBag. Trop complexe alors que tout ce que j'aime, c'est essentiellement faire de la programmation métier. Alors, bah, je sais ce que fait tel layout, ou tel layout. Il n'est pas rare que j'utilise 2 ou 3 layouts externes à ceux dispos dans AWT/Swing pour une même application (TableLayout étant le premier et ExplicitLayout le second) parce que ceux d'AWT/Swing ne me conviennent pas. Les uns pour leur trop grande simplicité et le gbl pour sa trop grande compléxité.

Mais la discussion semble trop s'orienter dans les layouts, alors que Swing n'est pas que ça (encore heureux).

Swing est un excellent outil pour réaliser des interfaces, mais pour le moment, je n'ai jamais eu l'occasion d'en développer une graphiquement. Mon expérience se limite donc à la création d'interfaces complexes à la main. L'avantage, c'est qu'il ne faut pas se restreindre à ce que propose l'outil d'interface. L'inconvénient est le temps mis à coder cette interface. Mais bon, cela me permet de bien approfondir ma connaissance de Swing. Du simple JButton aux complexes JTable et JTree (à quand le JTreeTable dans Swing, d'ailleurs ? )

Pour les besoins d'une application, je me suis mis à l'HTML dans Swing, et là, il y a nettement du progrès à faire. À nouveau, j'ai du me tourner vers la communauté pour trouver quelque chose d'utilisable, et j'ai trouvé deux outils intéressants : l'un (dont je ne me souviens plus du nom) payant et l'autre gratuit/libre appelé FlyingSaucer. Ces deux outils m'ont permis d'utiliser la souplesse du HTML/CSS dans Java, ce qui a nettement boosté ma productivité. Si bien que maintenant, dès que j'ai une interface complexe à réaliser, je me demande s'il est possible de transposer ça aisément en HTML pour utiliser FlyingSaucer. L'ennui, c'est que je suis obligé de tout faire à la main, je n'aurai pas la possibilité d'utiliser un GUI builder, si jamais je m'y mets un jour.

Néanmoins, si je peux vous conseiller, en attendant l'arrivée de Java 7, utilisez AppFramework afin de vous faciliter le développement. Cet outil est une merveille qui sera intégrée dans Java 7 sous le package javax.swing.application (enfin, si tout va bien ). Vous qui aimez travailler sur vos classes métier, il y a là un gain de temps extrêmement important !

[bassim]

Ayant appris à créer mes interfaces à la main au début, je confirme que ça peut aider pour comprendre ce qui se passe derrière.

Le GridBagLayout permet pratiquement de tout faire en contrepartie d'une certaine complexité même pour des IHMs simples, et c'est là que je préfère utiliser le GroupLayout (mais avec Matisse, pour ceux qui savent ce que y a derrière, un petit retour d'expérience serait le bienvenue).

Le FormLayout reste préférable aussi pour certaines IHMs, plus facile à créer qu'avec un GridBagLayout.

La connaissance des mécanismes qui sont derrière Swing (MVC, Listeners ...)est une nécessité si on veut aller loin avec !

Sur ce bon codage !

[rthriller]

En conclusion, a après l'essai de pas mal d'outil pour le développement swing, partant de notepad++ jusqu'au trials des top des outils commerciaux, j'ai trouvé un bon compromis, entre édition visuelle et coding à la main. Il s'agit de JBuilder (la version turbo est gratuite) qui permet en temps réel de passer de la souris au clavier.

Donc il me créé ma JFrame et certains composants, et j'ajuste à la main tout en voyant en temps réel ce qui se passe visuellement! Et même le code qu'il génère est très propre.

Au fait ce n''est que le visual editor de eclipse

[Alec6]

C'est bien jolie le wyzywig.

En 4 ans de Swing j'ai pas eu un seul projet ou je n'ai été contraint de produire des composants, ou d'affiner ceux de Java pour obtenir une haute rigueur.

Ensuite il faut souvent étendre les models (c'est le cas pour les tableaux), il faut définir les renderers. Mettre en place des patterns médiator à gogo, genre pour griser des boutons d'un menu selon le contexte etc... Il faut inventer des layouts managers (pour avoir des boutons sur une courbe par exemple) ou avoir une IHM scalable (zoom). Parfois on enregistre les actions utilisateurs pour faire des stats sur les chemins suivis et donc sur la cohérence de l'application (cf théorie des graphes).

Souvent l'IHM est polymorphe. C'est à dire qu'elle est générée de façon dynamique pour répondre à des contraintes. Je sais pas si un wyzywig aide pour cela.

Franchement la mise en page c'est rien à coté du don architectural qu'il faut avoir pour faire une GUI de haut niveau.

En peu de temps en lisant du code on voit l'IHM, comme un musicien entend la musique en lisant la partition (je deviens philosophe).

Maintenant si c'est pour faire un CRUD sur un base de données ok, ou une maquette ou un proof of concept, je pense que c'est bien.

PS: pour jsf aussi je trouve ca naif, car les IHM de demain ne sont pas de simples vues dont on passe de l'une à l'autre.

[eclesia]

Ensuite il faut souvent étendre les models (c'est le cas pour les tableaux), il faut définir les renderers. Mettre en place des patterns médiator à gogo, genre pour griser des boutons d'un menu selon le contexte etc...

faisable

Il faut inventer des layouts managers (pour avoir des boutons sur une courbe par exemple) ou avoir une IHM scalable (zoom).

ca non.

Franchement la mise en page c'est rien à coté du don architectural qu'il faut avoir pour faire une GUI de haut niveau.

un don? faut pas exagerer non plus
on en est pas encore a sacrifier une chevre sur l'autel pour que le bidouillage marche. (on est loin de l'editeur visuel visual basic)


J'apprécie vraiment l'editeur matisse et tant que je peux je l'utilise. Il est quand meme tres flexible, on peut ajouter nos propres composants dans la palette. L'Internationalisation est aussi grandement simplifié (je ne dis pas que c'est dur de faire un ResouceBundle ...etc... mais ca fait ca de moins a penser) on est sur d'avoir toujours les clés présentes dans le bundle. Quand on a plus d'une trentaine de panneaux... je vous avous que ca m'enerve d'en avoir un qui refuse de s'afficher parceque j'ai mal ecrit une clé.


Quand il y a dans les interfaces des zones "dynamiques" c'est simple. Je colle un JPanel a cet endroit et je gere cette partie de l'interface en code.


C'est une aide, ca ne fait pas tout mais c'est un plus considérable.

[rthriller]

Même les composants produits s'intègre facilement dans un éditeur wyzywig, et même les composants produits restent disponibles au programmeur pour subir tout type de manip (griser, cacher, ...)

Je ne parle pas d'une voix de grands expert, je n'ai pas tes 4 ans de swing. Je comprend bien qu'il est parfois plus facile de générer une interface avec du code, tu mets 2 boucles imbriqués et t'as ta calculatrice "prête à l'emploi".
Mais en général, faire des boutons qui suivent une courbe, ou qui se balladent dans un labyrinthe et tirent su tout ce qui bougent ça devient du counter strike (je rigole ), et ce n'est pas vraiment monnaie courante dans le développement des applications classiques (gestion, comptabilité, commerce, ...)

Je suis à 80% d'accord avec toi, surtout pour ce qui est du polymorphisme de l'interface, qui doit tenir compte des droits et autorisation de chaque utilisateur à accéder à tel ou tel module de l'application, ce qui implique la disparition des menus et boutons correspondant, ...

Le grand intéret des wyzywig (comme tu les appelle) c'est de mettre en place la disposition initiale et par défaut de l'interface (ça remplace le papier et le crayon), puis bien sur on a le choix selon le projet, de continuer visuellement ou repasser en mode texte.

Te faches pas de mes remarques, si je parles de couter strike c'est que ça me manque

[natha]

Pour info ce n'est pas "wyzywig" mais "wysiwyg" pour "What You See Is What You Get"

[n!co]

Je crois quand même que vous oubliez l'essentiel ! (si on dérive un peu du sujet et que l'on se concentre plus sur un bon développeur d'interface que de la simple mise en page swing)

Pour moi, une interface applicative, en plus de la mise en page, c'est avant tout une véritable expérience utilisateur, une bonne gestion des évenements(de la validation, de l'animation, ...), un binding avec la couche de données souple et performant et une bonne gestion du multi-threading.

Hors c'est souvent là que les interfaces ont des lacunes, la cause à trop de temps passé sur la mise en page, alors que les editeurs visuels s'en chargent tres bien et nous font gagner énormément de temps

Je pense que le vrai défi de ces prochaines années, c'est alors de disposer d'editeurs et de bibliothèques performants pour que les développeurs finissent de perdre du temps sur les problématiques techniques et qu'ils se concentrent d'avantage sur les véritables problèmatiques des utilisateurs, en leur proposant des interfaces toujours plus agréables à utiliser.
En adéquation directe avec ce qui se passe depuis quelques années sur la partie backoffice avec les spring, hibernate, jee, ... pour ne citer que ceux là.

Bon un peu hors sujet, mais je pense que ca méritait d'être souligné.

[rdurieux]

Hello.
Je suis entièrement d'accord sur le fait que lorsqu'on travaille le modèle d'une table ou ses renderers/editors (idem pour un arbre), il est vraiment indispensable de coder à la main. Mais jusqu'à preuve du contraire, ces compsants ne constituent quand même pas l'essentiel d'une IHM! On trouve souvent des tonnes de textFields, combo, checkbox, boutons, ... et pour tous ces composants basiques, le code "à la main" n'a aucun intérêt! Même remarque pour tous les conteneurs intermédiaires type splitPane, tabbedPane, ...

Vive les builders

PS : ceci dit, je continue de penser que le builder idéal est loin d'exister en java. Matisse apporte pas mal, mais c'est pas encore le rêve... Et j'attend vraiment avec impatience l'environnement complet, avec GUI builder + RCP, tout intégré et facile à manipuler. Se tapper Matisse et le RCP Netbeans, ça demande quand même d'avoir fait pas mal d'études . Et la productivité n'est pas au top...
Si certains d'entre vous ont trouvé le bonheur, merci de partager!