Discussion :

[azerty09]

bonjour,

1)Est ce qu'il y a une différence entre un Canvas et JPanel mis a part que l'une est de awt et l'autre de swing , ce que je veut dire c'est que pour dessiner est ce qu'un jpanel est mieux qu'un canvas????

2)dans un canvas pour écrire du texte récupérer à partir du clavier je met

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Graphics g = getGraphics ();
g.drawString(s,X,Y+nbl) // s un string

Comment faire la même chose dans un JPanel

merci d'avance

[Orian]

JPanel a pour but de remplacer le Canvas de awt (il n'y a pas de JCanvas d'ailleurs).

Pour dessiner dans un JPanel tu dois surcharger la méthode paintComponent (au lieu de paint dans le cas du canvas).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public void paintComponent(Graphics g) {
  super.paintComponent(g);
  ... //ce qu tu veux...
}

Pour ce qui est du dessin dans une JPanel, c'est exactement comme dans un Canvas. Par contre si c'est pour simplement une String j'utiliserais un JLabel (mais c'est personnel peut être)

[azerty09]

Bonsoir,
merci
pour dessiner c'est ok mais pour écrire je ne voit toujours pas comment ???

[Orian]

Pour écrire c'est de la même manière qu'avec un Canvas, tu utilise la méthode drawString du graphics de ton composant...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
g.setColor(Color.black);
g.setFont(new Font("SansSerif",Font.PLAIN,10));
g.drawString("ton texte",x,y);

[dingoth]

JPanel a pour but de remplacer le Canvas de awt (il n'y a pas de JCanvas d'ailleurs).

Ah bon ? Depuis quand ?

Le Canvas a toujours son utilité, à l'heure d'aujourd'hui. Et si on devait garder un seul élément de AWT, ce serait celui-là !

Le Canvas fait pour qu'on dessine dessus. Pourquoi ? Parce que c'est le seul élément vide. Il n'a que les événements minimaux et ne contient rien du tout. C'est pour ne pas gaspiller la mémoire. Mais alors, quelle est la vraie utilité du Canvas ? Typiquement, c'est sur lui qu'on dessine un jeu en 2D. Dès qu'on souhaite faire du plein écran, on devrait se tourner vers lui. Dès qu'on cherche à dessiner toute une interface (sans réutiliser les éléments de AWT/Swing, entendons-nous), il est préférable d'utiliser un Canvas.

Un JPanel est, lui, réellement destiné à recevoir d'autres éléments graphiques de Java Swing. C'est ce qu'on appelle un conteneur, là où Canvas est un élément final, comme un bouton, un ascenseur, etc.

D'ailleurs, suffit de lire la doc :
JPanel : « JPanel is a generic lightweight container. »
Canvas : « A Canvas component represents a blank rectangular area of the screen onto which the application can draw or from which the application can trap input events from the user. »

[Orian]

Tu a mal saisi ce que je voulait dire : JPanel remplace Canvas pour SWING, c'est pour ça que je précise qu'il n'y a pas de JCanvas... Je ne dis en rien que le Canvas est à mettre à la décharge, il est utile, mais si on travaille en AWT.
En effet, il est préférable je pense de ne pas mélanger AWT et SWING, donc Canvas si on travaille en AWT mais JPanel si on est en SWING.

[dingoth]

Sauf que le Canvas n'a PAS d'équivalent en Swing, ce n'est pas un oubli car le Canvas est le seul composant AWT recommandé pour Swing. Hormis ce composant, il ne faut effectivement pas mélanger AWT et Swing.

Il faut toutefois l'utiliser à bon escient.

Le JPanel, lui n'est nullement destiné à être redessiné. C'est un conteneur, c'est tout.

Edit : pourquoi le Canvas serait-il présent sur cette page officielle du site de sun aux côtés de composants swing et d'aucun autre AWT ?

[bouye]

Hormis des besoins tres specifiques pour dessiner en Swing, tu surcharges JComponent ou JPanel, c'est suffisant pour 99% des cas et c'est comme ca, c'est tout. C'est la METHODE RECOMMANDEE pour dessiner en Swing.

Et avant que tu ne repondes davantage, n'importe quel Component ou JComponent a pour vocation a pouvoir etre un conteneur, c'est comme ca (meme une Canvas) c'est dans leur conception : ils heritent tous de Container...

Alors pourquoi c'est indique comme ca ?

Pre-Made UI Components
[...]
Drawing areas (java.awt.Canvas)
[...]

Car avec une Canvas on peut creer une BufferStrategy qui est utile quand on veut directement dessiner dans la memoire de la carte video, ce qui est franchement utile dans 1% des cas. Et ca on ne peut pas le faire avec un JComponent (la methode existe dans Component mais est package protected, elle est uniquement publique dans Canvas).
Mais, si tu sais correctement faire un rendu en Swing tu peux t'en passer.

Encore une fois, GENERALEMENT, melanger AWT et Swing c'est MAL. CEPENDANT, et TRES RAREMENT, il est parfois necessaire de le faire.

[dingoth]

Allez, je vais te laisser le dernier mot, ça sert jamais à rien de discuter ici...

N'empêche, merci de copier/coller 99% de mes paroles en tentant de me contredire au global

[bouye]

Pourtant...

Le JPanel, lui n'est nullement destiné à être redessiné. C'est un conteneur, c'est tout.

En gros : JPanel = JComponent opaque + bonnes options d'accessibilite.

[dingoth]

Ah, tu veux pas que je te laisse le dernier mot ?

Entièrement d'accord avec toi.

Mais ce n'est pas parce qu'il a les capacités du JComponent (et donc celles de java.awt.Component et de java.awt.Container) que son but est d'être redessiné. Son but est d'être un conteneur.

C'est aisément compréhensible que tous les composants Swing héritent de JComponent. C'est même logique.

Mais Swing est un toolkit de widgets et même s'il faut dessiner pour créer de nouveaux widgets, Swing n'a pas besoin qu'on redessine sur lui. Cela reste délégué à java.awt.Canvas.

Si je reprends Wikipédia (anglophone, car les pages francophones sont on-ne-peut-plus-succintes) :
Swing : "Swing is a widget toolkit for Java."
AWT : "The Abstract Window Toolkit (AWT) is Java's original platform-independent windowing, graphics, and user-interface widget toolkit".

Je crois que là c'est clair :
AWT est là pour gérer les fenêtres, les graphics/dessins et un toolkit de widgets. Swing n'est là que pour faire un toolkit de widgets (et améliorer les fenêtres).

[Gfx]

dingoth : Ayant travaillé sur Swing chez Sun je vais me permettre de donner mon avis. On utilise il est vrai souvent le JPanel pour dessiner parce qu'il propose un fond opaque, mais en pratique on devrait partir du JComponent. Et on procède ainsi parce que la plupart du temps on crée un nouveau composant destiné à s'intégrer dans une UI Swing. Alors certes, si tu fais un jeu tu peux te contenter du Canvas.

Néanmoins tu as tort lorsque tu dis cela :

Mais Swing est un toolkit de widgets et même s'il faut dessiner pour créer de nouveaux widgets, Swing n'a pas besoin qu'on redessine sur lui. Cela reste délégué à java.awt.Canvas.

Swing ne délègue absolument pas le rendu à Canvas. Swing et AWT utilisent tous les deux un Graphics comme contexte mais le Canvas est propre à AWT et le reste.

L'utilisation de JComponent au lieu de Canvas a d'autres avantages non négligeables. Par exemple, les composants Swing utilisent du double-buffering par défaut, ce qui évite de le faire soi-même. Encore une fois, à moins de faire un jeu, c'est très intéressant.

AWT ne sert maintenant que de plomberie entre l'OS et Swing, fournissant comme tu le dis la fenêtre. Mais le dessin est géré par Java2D (donc Graphics2D) qui lui se contrefout du Canvas.

Bref, le Canvas n'est en rien recommandé pour utilisation avec Swing puisqu'il provoque les fameux problèmes de lightweight/heavyweight. Comme l'a dit bouye, dans 99% des cas tu n'as pas besoin du Canvas donc autant éviter les emmerdes et partir de JComponent.

Et JComponent, même s'il hérite de Container, est tout à fait destiné à être redessiné. C'est bien pour ça qu'il est non opaque et entièrement transparent par défaut.

[dingoth]

S'il te plaît, ne me fais pas dire ce que je n'ai pas dit : Swing ne délègue rien à Canvas, je le sais bien et je n'ai pas dit le contraire. Ma phrase, après relecture, peut prêter à confusion mais ce n'est pas là ce que j'ai voulu dire. Ce que je voulais dire, c'est : "Mais Swing est un toolkit de widgets et, dans un cadre d'utilisation propre, utilisez Swing pour dessiner de nouveaux composants Swing, pas tout et n'importe quoi. On préférera alors Canvas."

Comme tu le dis et comme je l'ai dit, dessiner sur Swing est une approche essentiellement orientée composants. Voilà enfin quelqu'un qui utilise un JPanel pour un conteneur et pas pour une table de dessin. Et tout ce que tu dis rejoint ma pensée, à la seule différence que je dis : "Ola, ne dénigrez pas Canvas : s'il y a une seule chose à garder d'AWT (en tant que collection de widgets), c'est Canvas pour faire des dessins."

Quant à mon intervention initiale servait uniquement à dire que chaque objet a une utilisation normale et des utilisations possibles. Chaque composant Swing peut contenir d'autres composants, mais chacun a son utilité propre : on ne va pas demander une JTable pour afficher une seule icône dans le coin supérieur droit et utiliser le reste des cellules comme un layout ; on ne va pas demander une Combobox pour afficher une liste d'objets ; etc.

Alors oui, je n'ai peut-être pas pensé à dire qu'azerty09 ferait mieux d'étendre un JComponent, de le rendre opaque (parce que même si je ne m'estime pas mauvais développeur, je ne pense pas à tout non plus), mais j'ai au moins dit que le JPanel n'a pas pour but d'être redessiné de cette manière, et que comme composant de dessin, dans un cadre d'utilisation propre, le Canvas est plus approprié (mais tu as raison, le JComponent l'est davantage dans certains cas).

[Gfx]

S'il te plaît, ne me fais pas dire ce que je n'ai pas dit

Exprime-toi clairement alors.

Le Canvas est utile dans une application Swing dans des cas très particuliers. Il n'apporte presque aucun avantage par rapport à JComponent et peut au contraire se révéler problématique. Dans ce cas je ne considère pas une bonne idée de conseiller Canvas plutôt que JComponent. Surtout quand JComponent aide en proposant le double-buffering.

Swing est déjà suffisamment complexe comme ça sans embrouiller inutilement les choses. JComponent est bien la meilleure manière de dessiner en Swing, point barre.

[dingoth]

point barre.

Évidemment :]