Discussion :

[damtoul]

Bonjour,

Je suis en cours de développement d'une application en architecture MVC et j'ai un petit problème sur le fonctionnement du GridBag Layout manager.

Mon appli est construite comme ceci :
Dans la classe Controller j'ai JFrame=>JPanel de contenu (ContentPanel) avec un CardLayout qui contient des JPanel gérés chacun avec un GridBagLayout. J'ajoute donc dans cette même classe différents composants (JPanels, Boxes) qui sont instanciés dans une sous-classe de Controller.

A la mise en place des composants ça donne ces instructions. Dans cet exemple this.menuparamguipanel c'est le JPanel de contenu, this.menuparamguic.getMenuPanel() c'est l'instanciation de la sous-classe de Controller qui correspond à la page MenuParam et qui récupère les Jpanels à ajouter avec la méthode getXXX()

Code :

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

1
2
3
4
5
6
7
8
9
10
 
    /** Add the GUIc Menu JPanel to the menuparam GUI panel **/ 
    GridBagConstraints c20=this.createGridBagConstraints(GridBagConstraints.FIRST_LINE_START,GridBagConstraints.VERTICAL,0,0,3,7,0,0.5);
    this.menuparamguipanel.add(this.menuparamguic.getMenuPanel(),c20);
    /** Add the GUIc MAD JPanel to the menuparam GUI panel **/ 
    GridBagConstraints c21=this.createGridBagConstraints(GridBagConstraints.CENTER,GridBagConstraints.BOTH,3,0,21,7,0.8,0.5);
    this.menuparamguipanel.add(this.menuparamguic.getMADPanel(),c21);
    /** Add the GUIv Display JPanel to the menuparam GUI panel **/
    GridBagConstraints c22=this.createGridBagConstraints(GridBagConstraints.LAST_LINE_START,GridBagConstraints.BOTH,0,7,24,9,1,0.7);
    this.menuparamguipanel.add(this.view.getMenuParamGUIv().getDisplayPanel(),c22);

Avec la méthode kivabien :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 public GridBagConstraints createGridBagConstraints(int gbcanchor, int gbcfill,int gbcgrx,int gbcgry,int gbcgrw,int gbcgrh,double gbcwex,double gbcwey)
   {
    GridBagConstraints c=new GridBagConstraints();
    c.anchor=gbcanchor;
    c.fill=gbcfill;
    c.gridx=gbcgrx;
    c.gridy=gbcgry;
    c.gridwidth=gbcgrw;
    c.gridheight=gbcgrh;
    c.weightx=gbcwex;
    c.weighty=gbcwey;
    return c;
   }

Bref je ne mets pas plus de code car tout fonctionne à peu près correctement et j'ai quasi 5k lignes sur le Controller, même si j'ai l'impression que les grilles que j'ai fait pour mes JPanels ne sont pas trop respectées et que les poids prennent le dessus.
Mon plus gros problème c'est que le layout redimensionne les fenêtres si des composants changent de taille : JComboBox, JLabels, JTextFields, etc... J'aimerais savoir d'où ça peut venir et si on peut désactiver ça? Ca ne gène pas le déroulement de l'appli mais c'est assez désagréable à l'oeil.

Par exemple : le panneau display fait la moitié inférieure de l'écran et même en ne touchant à rien il peut gagner un bon cm de hauteur. Java semble faire un repaint() à sa propre initiative.

Bref si des experts peuvent me donner des pistes de recherche.

[joel.drigo]

Salut,

Mon plus gros problème c'est que le layout redimensionne les fenêtres si des composants changent de taille : JComboBox, JLabels, JTextFields, etc... J'aimerais savoir d'où ça peut venir et si on peut désactiver ça? Ca ne gène pas le déroulement de l'appli mais c'est assez désagréable à l'oeil.

Je pense que tu fais les mêmes confusions que beaucoup qui essaye d'utiliser le GridBagLayout.

Tout d'abord, il ne faut pas considérer la grille complètement comme une espèce de canevas à emplacement qui serait fixe. Les composants que tu y mets, et les emplacements (gridx, gridy, gridwidth, gridheight) s'adaptent les uns par rapport aux autres.

Si tu regardes le résultat de ce code :

Code :

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

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
public class GridBagLayoutExemple {
 
	public static void main(String[] args) {
 
 
		JFrame frame = new JFrame("Démo");
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
 
		frame.getContentPane().setLayout(new GridBagLayout());
 
		JLabel labelx = createLabel("xxxx");
		JLabel labelo = createLabel("oooo");
 
		frame.add(labelx, createGridBagLayout(0,0,1,1));
		frame.add(labelo, createGridBagLayout(0,42,1,1));
 
		frame.setSize(300, 200);
		frame.setLocationRelativeTo(null);
		frame.setVisible(true);
 
	}
 
	private static JLabel createLabel(String string) {
		JLabel label = new JLabel(string);
		label.setBackground(Color.WHITE);
		label.setOpaque(true);
		return label;
	}
 
	private static GridBagConstraints createGridBagLayout(int gridx, int gridy, int gridwidth, int gridheight) {
		GridBagConstraints constraint = new GridBagConstraints();
		constraint.gridx = gridx;
		constraint.gridy = gridy;
		constraint.gridwidth = gridwidth;
		constraint.gridheight = gridheight;
		return constraint;
	}
 
}

Tu verras les 2 labels l'un en dessous de l'autre, malgré qu'il y ait 42 lignes de grille entre les deux !



La contrainte fill BOTH dit que ton composant s'étend. Donc c'est normal qu'il se redimensionne. Pour un composant, de type texte à une ligne (JTextField, JLabel, JCombo, etc...) on utilise plutôt HORIZONTAL, pour que le composant remplisse bien l'espace horizontalement, mais qu'il reste de dimension convenable lors d'un redimensionnement vertical :

Code :

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

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
public class GridBagLayoutExemple2 {
 
	public static void main(String[] args) {
 
 
		JFrame frame = new JFrame("Démo");
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
 
		frame.getContentPane().setLayout(new GridBagLayout());
 
		JTextField fieldx = createField("xxxx");
		JTextField fieldo = createField("oooo");
 
		frame.add(fieldx, createGridBagLayout(0,0,1,1));
		frame.add(fieldo, createGridBagLayout(0,42,1,1));
 
		frame.setSize(300, 200);
		frame.setLocationRelativeTo(null);
		frame.setVisible(true);
 
	}
 
	private static JTextField createField(String string) {
		JTextField field = new JTextField(string); 
		return field;
	}
 
	private static GridBagConstraints createGridBagLayout(int gridx, int gridy, int gridwidth, int gridheight) {
		GridBagConstraints constraint = new GridBagConstraints();
		constraint.gridx = gridx;
		constraint.gridy = gridy;
		constraint.gridwidth = gridwidth;
		constraint.gridheight = gridheight;
		constraint.fill = GridBagConstraints.HORIZONTAL;
		constraint.weightx = 1;
		return constraint;
	}
 
}

Voir à sujet, le résumé que je fais dans ce post.

Java semble faire un repaint() à sa propre initiative.

Oui, c'est normal, mais ça n'a rien à voir. Attention, malheureusement, il ne le fait pas toujours (il ne le fait que quand il sait qu'il doit le faire : par exemple, si on change la taille de la fenêtre).

[damtoul]

Bonjour Joel,

Merci beaucoup pour ta réponse détaillé et ta confirmation sur la grille.

Je précise bien pour que ça soit clair : chaque JPanel qui a le GridBagLayout ne met en place que des JPanels comme montré dans mon exemple. Par exemple ci-dessous un JPanel "main" serait composé de 6 JPanels différents managés par le GBLayout.

1 2 3
4444
5566

Dans mon appli le JPanel contient par exemple une Box Verticale qui contient des Horizontal qui contiennent des boutons par exemple. Dans le JPanel2 je vais avoir des JTextField. Bref travaillant sur grand écran les composants tels les TextFields ont assez de place et je ne comprends pas ces "repaint" intempestifs, d'autant plus que ceux-ci peuvent intervenir lordque je ne touche à rien.

Bref tu sembles maitriser : si tu avais ce problème comment t'y prendrais-tu pour le debug? J'ai des validate() qui trainent deci delà, est-ce que cela pourrait venir de là? J'en ai enlevé certains car je voulais rafraichir l'iHM mais je me suis aperçu que c'était inutile dans mon cas en plus de consommer de la ressource.

[joel.drigo]

Bonjour Joel,

Merci beaucoup pour ta réponse détaillé et ta confirmation sur la grille.

Je précise bien pour que ça soit clair : chaque JPanel qui a le GridBagLayout ne met en place que des JPanels comme montré dans mon exemple. Par exemple ci-dessous un JPanel "main" serait composé de 6 JPanels différents managés par le GBLayout.

1 2 3
4444
5566

Bien que ça soit peut-être faisable avec un GrigBagLayout en se cassant la tête, de prime abord, je dirais qu'on va se prendre la tête avec le fait qu'il y 3 composants pour la première ligne et 2 pour la dernière : du coup, la grille ne s'adaptera jamais comme on veut (le composant 2 centré à cheval sur 5 et 6).
Il est souvent beaucoup plus simple de faire une hiérarchie de JPanel. De toute manière, pour ton contrôleur ça ne changera pas grand chose, et pour le modèle rien, car il n'a même pas à connaitre la vue.

Dans mon appli le JPanel contient par exemple une Box Verticale qui contient des Horizontal qui contiennent des boutons par exemple. Dans le JPanel2 je vais avoir des JTextField.

Celui agencé par GridBagLayout ? Par Box, tu entends bien JPanel + BoxLayout ? Attention : ce composant agence ses composants.

Bref travaillant sur grand écran les composants tels les TextFields ont assez de place

Grand ou petit écran, ça n'a pas d'importance. Ce n'est pas vraiment le problème d'avoir assez de place, c'est d'une part le fait que JTextField ne décide de sa taille (préférentielle) que par sa limite (le nombre maxi de caractères), son contenu (s'il est vide sans limite, il s'affichera de base large de quelques pixels rendant toute saisie quasiment impossible) et ses styles (police), donc on cherche a lui faire avoir un minimum de taille, et c'est le fait de ne pas laisser d'espace vide dans la fenêtre d'autre part (on essaye de lui faire occuper un maximum de place). C'est pourquoi on étend les composants de type saisie. Pour les boutons on essaye de les aligner, et de les répartir, pour des questions esthétiques, mais eu aussi, décide de leur taille par leur contenu.

et je ne comprends pas ces "repaint" intempestifs, d'autant plus que ceux-ci peuvent intervenir lordque je ne touche à rien.

Faut voir le code, là. Si tu ne touches à rien, et qu'il n'y pas d'appel de repaint() explicite, par exemple dans un Timer, y'a pas de raison d'avoir des repaint().

Bref tu sembles maitriser : si tu avais ce problème comment t'y prendrais-tu pour le debug?

Ce n'est pas simple de déboguer de l'UI : on ne peut déboguer qu'avec du pas à pas, donc des breakpoints. Des breakpoints dans les méthodes d'UI, c'est pénible, voire ingérable (la gestion des focus entre la fenêtre de débogage et la fenêtre déboguée cause des cycles inextricables). On peut essaye de mettre des breaks conditionelles, mais c'est fastidieus, oblige à faire beaucoup de modification temporaire du code.
Bref, j'utiliserais des traces (System.out.println() pour afficher les états),et un new Throwable().printStackTrace()pour marquer la pile d'appel de la méthode paint ou repaint(). Attention, le log peut devenir conséquent, penser à augmenter la taille du buffer dans l'IDE.

J'ai des validate() qui trainent deci delà, est-ce que cela pourrait venir de là? J'en ai enlevé certains car je voulais rafraichir l'iHM mais je me suis aperçu que c'était inutile dans mon cas en plus de consommer de la ressource.

Oui, c'est possible.
Utilise plutôt revalidate() que validate() : ça limite le traitement à ce qui est nécessaire d'être traité (ce qui est marqué invalide). Ensuite, c'est en général inutile : ça ne sert que si on ajoute des composants à un container déjà affiché (ou si on en retire)), ou vraiment pour des composants personnalisé (avec redéfinition d'une méthode paintXXX()).
Le cardlayout t'oblige peut-être à faire quelque chose par rapport au fait que chaque layer n'a pas la même taille ? Tu peux aussi bien faire un doLayout(), ou un pack() sur la fenêtre et un repositionnent. Faut voir aussi si ce cardlayout est bien nécessaire.

[damtoul]

Bien que ça soit peut-être faisable avec un GrigBagLayout en se cassant la tête, de prime abord, je dirais qu'on va se prendre la tête avec le fait qu'il y 3 composants pour la première ligne et 2 pour la dernière : du coup, la grille ne s'adaptera jamais comme on veut (le composant 2 centré à cheval sur 5 et 6).
Il est souvent beaucoup plus simple de faire une hiérarchie de JPanel. De toute manière, pour ton contrôleur ça ne changera pas grand chose, et pour le modèle rien, car il n'a même pas à connaitre la vue.
Celui agencé par GridBagLayout ? Par Box, tu entends bien JPanel + BoxLayout ? Attention : ce composant agence ses composants.

Non, voici comment s'est organisé :
JFrame=>contentpanel.set(CardLayout)
Chaque "card" du contentpanel est un JPanel qui correspond à une page d'affichage du logiciel. Chaque JPanel a le gridBagLayout. c'est this.menuparamguipanel dans mon exemple de code. Sur chaque JPanel avec le GBL j'y place des JPanels de Control et View. Ces sous JPanels peuvent contenir des Jpanels avec des layout Border, mais aussi des VerticalBox et HorizontalBox. Je comprends que le BoxLayout agence les composants, je le fais d'ailleurs avec des Struts et Glue, mais le JPanel conteneur ne devrait pas bouger non?

Grand ou petit écran, ça n'a pas d'importance. Ce n'est pas vraiment le problème d'avoir assez de place, c'est d'une part le fait que JTextField ne décide de sa taille (préférentielle) que par sa limite (le nombre maxi de caractères), son contenu (s'il est vide sans limite, il s'affichera de base large de quelques pixels rendant toute saisie quasiment impossible) et ses styles (police), donc on cherche a lui faire avoir un minimum de taille, et c'est le fait de ne pas laisser d'espace vide dans la fenêtre d'autre part (on essaye de lui faire occuper un maximum de place). C'est pourquoi on étend les composants de type saisie. Pour les boutons on essaye de les aligner, et de les répartir, pour des questions esthétiques, mais eu aussi, décide de leur taille par leur contenu.

Oui c'est ce que je fais : notamment sur les JTextArea j'ai mis un JScrollPane car j'avais remarqué qu'en rentrant beaucoup de caractères ma zone de texte s'agrandissait et agrandissait le JPanel conteneur en même temps et écrasait les autres JPanels du GBL par ce fait. En fait en te lisant j'ai l'impression que mon problème doit venir d'un composant qui n'a pas de taille fixe et donc le GBL s'ajuste en conséquence d'où mes changements de taille...

Faut voir le code, là. Si tu ne touches à rien, et qu'il n'y pas d'appel de repaint() explicite, par exemple dans un Timer, y'a pas de raison d'avoir des repaint().

Ce n'est pas simple de déboguer de l'UI : on ne peut déboguer qu'avec du pas à pas, donc des breakpoints. Des breakpoints dans les méthodes d'UI, c'est pénible, voire ingérable (la gestion des focus entre la fenêtre de débogage et la fenêtre déboguée cause des cycles inextricables). On peut essaye de mettre des breaks conditionelles, mais c'est fastidieus, oblige à faire beaucoup de modification temporaire du code.
Bref, j'utiliserais des traces (System.out.println() pour afficher les états),et un new Throwable().printStackTrace()pour marquer la pile d'appel de la méthode paint ou repaint(). Attention, le log peut devenir conséquent, penser à augmenter la taille du buffer dans l'IDE.

Au moins c'est clair, j'ai plus qu'à mettre les mains dans le cambouis. Je vais nettoyer le code des validate() et faire des tests de fixing de taille sur les composants voir l'effet.

Oui, c'est possible.
Utilise plutôt revalidate() que validate() : ça limite le traitement à ce qui est nécessaire d'être traité (ce qui est marqué invalide). Ensuite, c'est en général inutile : ça ne sert que si on ajoute des composants à un container déjà affiché (ou si on en retire)), ou vraiment pour des composants personnalisé (avec redéfinition d'une méthode paintXXX()).
Le cardlayout t'oblige peut-être à faire quelque chose par rapport au fait que chaque layer n'a pas la même taille ? Tu peux aussi bien faire un doLayout(), ou un pack() sur la fenêtre et un repositionnent. Faut voir aussi si ce cardlayout est bien nécessaire.

Oui le cardlayout est nécessaire : mon logiciel a plusieurs pages distinctes à laquelle tu accèdes par des boutons dans un menu. C'est donc le layout idéal pour ce genre de chose.

Je te remercie pour cette discussion qui m'a donné des axes de recherche. : jap :

[joel.drigo]

... mais le JPanel conteneur ne devrait pas bouger non?

Ça dépend de son layout manager, et c'est le cas justement avec un GridBagLayout : la taille préférentielle (et min, et max) du composant peut être exploitée, ce qui pourra avoir une influence sur la dimension de son parent.

En fait en te lisant j'ai l'impression que mon problème doit venir d'un composant qui n'a pas de taille fixe et donc le GBL s'ajuste en conséquence d'où mes changements de taille...

Pas impossible : pas directement, mais indirectement. Il faut (re)voir ses contraintes. C'est juste un filler, ou c'est un conteneur de composants ?



Au moins c'est clair, j'ai plus qu'à mettre les mains dans le cambouis. Je vais nettoyer le code des validate() et faire des tests de fixing de taille sur les composants voir l'effet.

Oui le cardlayout est nécessaire : mon logiciel a plusieurs pages distinctes à laquelle tu accèdes par des boutons dans un menu. C'est donc le layout idéal pour ce genre de chose.

Voir quand même si un JDesktopPane avec JInternalFrame ne simplifie pas tout ça. Faire une application entière à base d'une pile de conteneurs peut être lourd à gérer pour Swing. Tout dépend du nombre de couches et de ce qu'il y a dedans, mais si ça fait 30000 composants Swing en tout, juste pour en avoir 50 utilisables au même moment, on gère 29950 composants continuellement pour rien. On peut aussi, créer et supprimer les couches au besoin, même si le modèle est commun.

[damtoul]

Ça dépend de son layout manager, et c'est le cas justement avec un GridBagLayout : la taille préférentielle (et min, et max) du composant peut être exploitée, ce qui pourra avoir une influence sur la dimension de son parent.

Pas impossible : pas directement, mais indirectement. Il faut (re)voir ses contraintes. C'est juste un filler, ou c'est un conteneur de composants ?

Voir quand même si un JDesktopPane avec JInternalFrame ne simplifie pas tout ça. Faire une application entière à base d'une pile de conteneurs peut être lourd à gérer pour Swing. Tout dépend du nombre de couches et de ce qu'il y a dedans, mais si ça fait 30000 composants Swing en tout, juste pour en avoir 50 utilisables au même moment, on gère 29950 composants continuellement pour rien. On peut aussi, créer et supprimer les couches au besoin, même si le modèle est commun.

Mmm non je n'ai pas énormément de composants et l'appli tourne très bien, hormis mon petit problème visuel. Donc oui je suis confiant sur le choix de mes layouts.

Par contre qu'est-ce que tu entends par filler ou conteneur? Oui il faut que je revoie les contraintes sur chaque JPanel composant le GBL, mais au delà de ça, hormis quelques micro ajustements, je pense que le problème vient des composants internes qui demandent à agrandir le JPanel. Je viens de tester, ça arrive par exemple quand je modifie le Border d'une ComboBox, le JPanel qui la contient s'agrandit légèrement et le GBL réajuste tous les Panels de l'écran en conséquence. Je dois fixer la taille des tous les "petits" composants et laisser un peu de marge sur les panels conteneurs.

[joel.drigo]

Par contre qu'est-ce que tu entends par filler ou conteneur?

J'entends pas filler, un JPanel qui ne sert qu'à remplir une case de la grille (GBL) pour raison de présentation. Contrairement à un conteneur, un JPanel qui contient effectivement des composants, il aura une taille préférentielle de 0x0, donc la place qu'il prendra ne sera dépendante que de la GBC et de la grille/conteneur de la grille. Il sera donc effectivement propice à absorder la modification de taille des conteneurs à côté (soit en étant agrandi, soit réduit, par le GBL).

ça arrive par exemple quand je modifie le Border d'une ComboBox, .

Tu peux renforcer la stabilité de ton layout en mettant un empty layout. Je suppose que le border que tu ajoutes sert à souligne un champ, dans une fonction de validation par exemple. Genre tu mets un cadre rouge, et tu affiches un message "Erreur de saisie dans le champ truc...". Si tu mets un empty border de même insets que le border (le cadre rouge), tu passes de l'un à l'autre, sans impact sur la taille préférentielle du composant, donc sans impact sur le layout globalement. Ensuite, tu peux compenser cet espace systématiquement occupé, en rognant sur les gaps, et autres insets dans le composant.

[damtoul]

Ok pour le filler.

Et merci pour le coup du empty border c'est vrai que je n'y avais pas pensé!! Je suis effectivement bien dans le cas que tu décris mais je changeais juste la taille du border donc modif de taille du panel.

Je fais toutes les modifs pour Mercredi je posterai un retour.

[damtoul]

Bonjour,

Encore merci Joel pour la discussion j'ai pu rééquilibrer beaucoup de choses, même si j'ai encore du travail.

J'ai revu les poids de chaque panel dans mon GBlayout, j'ai fixé les tailles de certains composants et je n'ai plus ce redimensionnement intempestif.

Du coup je passe le topic en résolu.

Dam.