Dois-je éviter d'utiliser les méthodes set(Preferred|Maximum|Minimum)Size dans Java Swing ?

Question

J'ai été plusieurs fois critiqué pour avoir suggéré l'utilisation des méthodes suivantes :

1. setPreferredSize
2. setMinimumSize
3. setMaximumSize

sur Swing composants. Je ne vois pas d'alternative à leur utilisation lorsque je veux définir des proportions entre les composants affichés. On m'a dit ceci :

En ce qui concerne les mises en page, la réponse est toujours la même : utilisez un gestionnaire de mise en page approprié. LayoutManager

J'ai fait quelques recherches sur le web, mais je n'ai pas trouvé d'analyse complète sur le sujet. J'ai donc les questions suivantes :

1. Dois-je éviter complètement l'utilisation de ces méthodes ?
2. Les méthodes ont été définies pour une raison. Alors, quand faut-il les utiliser ? Dans quel contexte ? À quelles fins ?
3. Quelles sont exactement les conséquences négatives de l'utilisation de ces méthodes ? (Je ne pense qu'à ajouter la portabilité entre des systèmes ayant une résolution d'écran différente).
4. Je ne pense pas qu'un LayoutManager puisse répondre exactement à tous les besoins de mise en page souhaités. Dois-je vraiment implémenter un nouveau LayoutManager pour chaque petite variation de ma mise en page ?
5. Si la réponse à la question 4 est "oui", cela ne va-t-il pas conduire à une prolifération de classes LayoutManager qui deviendront difficiles à maintenir ?
6. Dans une situation où j'ai besoin de définir les proportions entre les enfants d'un composant (par exemple, child1 doit utiliser 10% de l'espace, child2 40% ,child3 50%), est-il possible d'y parvenir sans mettre en œuvre un LayoutManager personnalisé ?

Answer 1

1. Dois-je éviter complètement l'utilisation de ces méthodes ?

   Oui pour le code d'application.

2. Les méthodes ont été définies pour une raison. Alors, quand faut-il les utiliser ? Dans quel contexte ? À quelles fins ?

   Je ne sais pas, personnellement je pense que c'est un accident de conception de l'API. Légèrement forcé par les composants composés ayant des idées spéciales sur les tailles des enfants. "Légèrement", parce qu'ils auraient dû implémenter leurs besoins avec un LayoutManager personnalisé.

3. Quelles sont exactement les conséquences négatives de l'utilisation de ces méthodes ? (Je ne peux penser qu'à ajouter la portabilité entre des systèmes ayant une résolution d'écran différente).

   Certaines raisons techniques (incomplètes, et malheureusement les liens sont rompus en raison de la migration de SwingLabs vers java.net) sont par exemple mentionnées dans l'article suivant Règles (hehe) ou dans le enlace @bendicott a trouvé dans son commentaire à ma réponse . D'un point de vue social, cela impose des tonnes de travail à votre malheureux compagnon qui doit maintenir le code et retrouver une mise en page cassée.

4. Je ne pense pas qu'un LayoutManager puisse satisfaire exactement tous les besoins de mise en page souhaités. Dois-je vraiment implémenter un nouveau LayoutManager pour chaque petite variation de ma mise en page ?

   Oui, il existe des LayoutManagers suffisamment puissants pour satisfaire une très bonne approximation de "tous les besoins de mise en page". Les trois principaux sont FormLayout, MigLayout et DesignGridLayout de JGoodies. Donc non, en pratique, vous écrivez rarement des LayoutManagers sauf pour des environnements simples et hautement spécialisés.

5. Si la réponse à la question 4 est "oui", cela ne va-t-il pas conduire à une prolifération de classes LayoutManager qui deviendront difficiles à maintenir ?

   (La réponse à la question 4 est "non").

6. Dans une situation où je dois définir des proportions entre les enfants d'un composant (par exemple, l'enfant 1 doit utiliser 10 % de l'espace, l'enfant 2 40 %, l'enfant 3 50 %), est-il possible d'y parvenir sans mettre en œuvre un LayoutManager personnalisé ?

   N'importe lequel des Big-Three peut, ne peut même pas GridBag (je n'ai jamais pris la peine de vraiment le maîtriser, trop de problèmes pour trop peu de pouvoir).

Answer 2

Quelques heuristiques :

• N'utilisez pas set[Preferred|Maximum|Minimum]Size() quand vous voulez vraiment passer outre get[Preferred|Maximum|Minimum]Size() comme on pourrait le faire en créant son propre composant, montré aquí .

• N'utilisez pas set[Preferred|Maximum|Minimum]Size() quand vous pouviez compter sur un composant soigneusement surchargé getPreferred|Maximum|Minimum]Size comme indiqué aquí et ci-dessous.

• Utilisez set[Preferred|Maximum|Minimum]Size() pour dériver des post- validate() géométrie, comme indiqué ci-dessous et aquí .

• Si un composant n'a pas de taille préférée, par exemple JDesktopPane il se peut que vous deviez dimensionner le conteneur, mais ce choix est arbitraire. Un commentaire peut aider à clarifier l'intention.

• Envisagez des mises en page alternatives ou personnalisées lorsque vous constatez que vous devez passer en boucle par de nombreux composants pour obtenir des tailles dérivées, comme indiqué dans les exemples suivants commentaires .

import java.awt.Component;
import java.awt.Dimension;
import java.awt.EventQueue;
import java.awt.GridLayout;
import java.awt.KeyboardFocusManager;
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.util.ArrayList;
import java.util.List;
import javax.swing.JComponent;
import javax.swing.JDesktopPane;
import javax.swing.JFrame;
import javax.swing.JInternalFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JTextField;
import javax.swing.SwingUtilities;

/**
 * @see https://stackoverflow.com/questions/7229226
 * @see https://stackoverflow.com/questions/7228843
 */
public class DesignTest {

    private List<JTextField> list = new ArrayList<JTextField>();
    private JPanel panel = new JPanel();
    private JScrollPane sp = new JScrollPane(panel);

    public static void main(String args[]) {
        EventQueue.invokeLater(new Runnable() {

            @Override
            public void run() {
                DesignTest id = new DesignTest();
                id.create("My Project");
            }
        });
    }

    private void addField(String name) {
        JTextField jtf = new JTextField(16);
        panel.add(new JLabel(name, JLabel.LEFT));
        panel.add(jtf);
        list.add(jtf);
    }

    private void create(String strProjectName) {
        panel.setLayout(new GridLayout(0, 1));
        addField("First Name:");
        addField("Last Name:");
        addField("Address:");
        addField("City:");
        addField("Zip Code:");
        addField("Phone:");
        addField("Email Id:");
        KeyboardFocusManager.getCurrentKeyboardFocusManager()
            .addPropertyChangeListener("permanentFocusOwner",
            new FocusDrivenScroller(panel));
        // Show half the fields
        sp.setVerticalScrollBarPolicy(JScrollPane.VERTICAL_SCROLLBAR_ALWAYS);
        sp.validate();
        Dimension d = sp.getPreferredSize();
        d.setSize(d.width, d.height / 2);
        sp.setPreferredSize(d);

        JInternalFrame internaFrame = new JInternalFrame();
        internaFrame.add(sp);
        internaFrame.pack();
        internaFrame.setVisible(true);

        JDesktopPane desktopPane = new JDesktopPane();
        desktopPane.add(internaFrame);

        JFrame frmtest = new JFrame();
        frmtest.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frmtest.add(desktopPane);
        frmtest.pack();
        // User's preference should be read from java.util.prefs.Preferences
        frmtest.setSize(400, 300);
        frmtest.setLocationRelativeTo(null);
        frmtest.setVisible(true);
        list.get(0).requestFocusInWindow();
    }

    private static class FocusDrivenScroller implements PropertyChangeListener {

        private JComponent parent;

        public FocusDrivenScroller(JComponent parent) {
            this.parent = parent;
        }

        @Override
        public void propertyChange(PropertyChangeEvent evt) {
            Component focused = (Component) evt.getNewValue();
            if (focused != null
                && SwingUtilities.isDescendingFrom(focused, parent)) {
                parent.scrollRectToVisible(focused.getBounds());
            }
        }
    }
}

Answer 3

Dois-je éviter complètement l'utilisation de ces méthodes ?

Non, il n'y a aucune preuve formelle qui suggère que l'appel ou le remplacement de ces méthodes n'est pas autorisé. En fait, Oracle affirme que ces méthodes sont utilisées pour donner des indications de taille : http://docs.oracle.com/javase/tutorial/uiswing/layout/using.html#sizealignment .

Ils peuvent également être remplacés (ce qui est la meilleure pratique pour Swing) quand extension de un composant Swing (plutôt que d'appeler la méthode sur l'instance du composant personnalisé)

Surtout, quelle que soit la façon dont vous spécifiez la taille de votre composant, assurez-vous que le conteneur de votre composant utilise un gestionnaire de mise en page qui respecte la taille demandée du composant.

Les méthodes ont été définies pour une raison précise. Alors quand faut-il les utiliser ? Dans quel contexte ? À quelles fins ?

Lorsque vous devez fournir des indications de taille personnalisées au gestionnaire de mise en page des conteneurs afin que le composant soit bien disposé.

Quelles sont exactement les conséquences négatives de l'utilisation de ces méthodes ? (I pense seulement à ajouter de la portabilité entre des systèmes avec différentes résolution d'écran).

• De nombreux responsables de la mise en page ne prêtent pas attention à la taille maximale requise pour un composant. Cependant, BoxLayout y SpringLayout faire. En outre, GroupLayout offre la possibilité de définir explicitement la taille minimale, préférée ou maximale, sans toucher au composant.

• Assurez-vous que vous avez réellement besoin de définir la taille exacte du composant. Chaque composant Swing a une taille préférée différente, en fonction de la police qu'il utilise et de son apparence. Ainsi, le fait de définir une taille précise peut produire des regarde de l'interface utilisateur sur différents systèmes

• parfois des problèmes peuvent être rencontrés avec GridBagLayout et des champs de texte, où si la taille du conteneur est inférieure à la taille préférée, la taille minimale est utilisée, ce qui peut entraîner un rétrécissement assez important des champs de texte.

• JFrame n'applique pas le principe de la surcharge getMinimumSize() uniquement la vocation setMinimumSize(..) sur ses travaux

Je ne pense pas qu'un LayoutManager puisse répondre exactement à tous les besoins. Ai-je vraiment besoin d'implémenter un nouveau LayoutManager pour chaque petite variation de ma mise en page ?

Si par mise en œuvre vous voulez dire utilisation, alors oui. Pas un LayoutManger peut tout gérer, chaque LayoutManager a ses avantages et ses inconvénients ; ainsi, chacune peut être utilisée conjointement pour produire la mise en page finale.

Référence :

• http://docs.oracle.com/javase/tutorial/uiswing/layout/problems.html

Answer 4

Il y a beaucoup de bonnes réponses ici, mais je veux ajouter un peu plus de raisons. pourquoi vous devriez normalement les éviter (la question vient de revenir dans un sujet en double) :

À quelques exceptions près, si vous utilisez ces méthodes, vous êtes probablement en train de peaufiner votre interface graphique pour qu'elle ait un aspect et une apparence spécifiques (et avec les paramètres propres à votre système, par exemple votre police de bureau préférée, etc.) Les méthodes elles-mêmes ne sont pas intrinsèquement mauvaises, mais les raisons typiques de leur utilisation sont les suivantes sont . Dès que vous commencez à régler la position et la taille des pixels dans une mise en page, vous courez le risque de voir votre interface graphique se briser (ou au minimum, avoir une mauvaise apparence) sur d'autres plateformes.

À titre d'exemple, essayez de modifier l'aspect et la convivialité par défaut de votre application. Même avec les seules options disponibles sur votre plate-forme, vous pourriez être surpris de la médiocrité du rendu.

Ainsi, pour que votre interface graphique reste fonctionnelle et agréable à regarder sur toutes les plates-formes (n'oubliez pas que l'un des principaux avantages de Java est son caractère multiplateforme), vous devez vous fier aux gestionnaires de mise en page, etc., pour ajuster automatiquement la taille de vos composants afin d'obtenir un rendu correct en dehors de votre environnement de développement spécifique.

Tout cela dit, on peut certainement concevoir des situations où ces méthodes sont justifiées. Encore une fois, elles ne sont pas intrinsèquement mauvaises, mais leur utilisation est normalement une grand drapeau rouge indiquant des problèmes potentiels d'interface graphique. Assurez-vous simplement d'être conscient du potentiel élevé de complications si/quand vous les utilisez, et essayez toujours de voir s'il existe une autre solution indépendante de l'apparence et de la sensation à vos problèmes -- le plus souvent, vous trouverez que ces méthodes ne sont pas nécessaires.

À propos, si vous vous sentez frustré par les gestionnaires de mise en page standard, il existe un grand nombre de bons gestionnaires tiers gratuits et à code source ouvert, par exemple JGoodies' FormLayout ou MigLayout . Certains éditeurs d'interface graphique ont même un support intégré pour les gestionnaires de mise en page tiers -- l'éditeur d'interface graphique WindowBuilder d'Eclipse, par exemple, est livré avec un support pour les gestionnaires de mise en page suivants FormLayout y MigLayout .

Answer 5

Si vous rencontrez des difficultés avec les mises en page dans Java Swing, je vous recommande vivement le logiciel JGoodies FormLayout fourni gratuitement dans le cadre de la bibliothèque freeware Forms par Karsten Lentzsch aquí .

Ce gestionnaire de mise en page très populaire est extrêmement flexible et permet de développer des interfaces utilisateur Java très soignées.

Vous trouverez la documentation de Karsten dans aquí et une bonne documentation sur eclipse aquí .