क्या मुझे जावा स्विंग में सेट (प्रीफ़र्ड | अधिकतम | न्यूनतम) आकार विधियों के उपयोग से बचना चाहिए

Question

निम्न विधियों के उपयोग का सुझाव देने के लिए कई बार मेरी आलोचना की गई है:

1. setPreferredSize
2. setMinimumSize
3. setMaximumSize

Swingघटकों पर । जब मैं प्रदर्शित घटकों के बीच अनुपात को परिभाषित करना चाहता हूं तो मुझे उनके उपयोग का कोई विकल्प नहीं दिखता है। मुझे यह बताया गया है:

लेआउट के साथ उत्तर हमेशा समान होता है: एक उपयुक्त लेआउट प्रबंधक का उपयोग करें

मैंने वेब को थोड़ा खोजा है, लेकिन मुझे इस विषय का कोई व्यापक विश्लेषण नहीं मिला है। इसलिए मेरे पास निम्नलिखित प्रश्न हैं:

1. क्या मुझे उन तरीकों के इस्तेमाल से पूरी तरह बचना चाहिए?
2. तरीकों को एक कारण के लिए परिभाषित किया गया है। तो मुझे उनका उपयोग कब करना चाहिए? किस संदर्भ में? किन उद्देश्यों के लिए?
3. वास्तव में उन तरीकों का उपयोग करने के नकारात्मक परिणाम क्या हैं? (मैं केवल विभिन्न स्क्रीन रिज़ॉल्यूशन वाले सिस्टम के बीच पोर्टेबिलिटी जोड़ने के बारे में सोच सकता हूं)।
4. मुझे नहीं लगता कि कोई भी लेआउट मैनजर सभी वांछित लेआउट जरूरतों को पूरा कर सकता है। क्या मुझे वास्तव में अपने लेआउट पर हर छोटे बदलाव के लिए एक नया LayoutManager लागू करने की आवश्यकता है?
5. यदि 4 का उत्तर "हाँ" है, तो क्या यह लेआउटमैनेजर वर्गों के प्रसार का कारण नहीं होगा जिसे बनाए रखना मुश्किल हो जाएगा?
6. ऐसी स्थिति में जहां मुझे एक घटक के बच्चों के बीच अनुपात को परिभाषित करने की आवश्यकता है (उदाहरण के लिए, चाइल्ड 1 को 10% स्थान का उपयोग करना चाहिए, चाइल्ड 2 40%, चाइल्ड 3 50%), क्या यह संभव है कि बिना कस्टम लेआउट मैनजर को लागू किए?

Answer 1

1. क्या मुझे उन तरीकों के इस्तेमाल से पूरी तरह बचना चाहिए?

   आवेदन कोड के लिए हाँ।

2. तरीकों को एक कारण के लिए परिभाषित किया गया है। तो मुझे उनका उपयोग कब करना चाहिए? किस संदर्भ में? किन उद्देश्यों के लिए?

   मुझे नहीं पता, व्यक्तिगत रूप से मैं इसे एपीआई डिजाइन दुर्घटना के रूप में समझता हूं। बच्चे के आकार के बारे में विशेष विचार रखने वाले यौगिक घटकों द्वारा थोड़ा मजबूर। "थोड़ा", क्योंकि उन्हें एक कस्टम लेआउट मैनजर के साथ अपनी आवश्यकताओं को लागू करना चाहिए था।

3. वास्तव में उन तरीकों का उपयोग करने के नकारात्मक परिणाम क्या हैं? (मैं केवल विभिन्न स्क्रीन रिज़ॉल्यूशन वाले सिस्टम के बीच पोर्टेबिलिटी जोड़ने के बारे में सोच सकता हूं।)

   कुछ (अपूर्ण, और दुर्भाग्य से लिंक स्वैगलैब्स के java.net के माइग्रेशन के कारण टूट गए हैं) तकनीकी कारण नियमों में उल्लेखित हैं (hehe) या लिंक में @bendicott पाया गया जो कि मेरे उत्तर के लिए उसकी टिप्पणी है । सामाजिक रूप से, अपने दुर्भाग्यपूर्ण साथी पर काम का टन डालना, जिसे कोड को बनाए रखना होगा और टूटे हुए लेआउट को ट्रैक करना होगा।

4. मुझे नहीं लगता कि कोई भी लेआउट मैनजर सभी वांछित लेआउट जरूरतों को पूरा कर सकता है। क्या मुझे वास्तव में अपने लेआउट के हर छोटे बदलाव के लिए एक नया LayoutManager लागू करने की आवश्यकता है?

   हां, "सभी लेआउट आवश्यकताओं" के लिए एक बहुत अच्छा सन्निकटन को संतुष्ट करने के लिए लेआउटमैन काफी शक्तिशाली हैं। बड़े तीन हैं JGoodies FormLayout, MigLayout, DesignGridLayout। तो नहीं, व्यवहार में, आप शायद ही कभी साधारण अति विशिष्ट वातावरण को छोड़कर लेआउट मैनेजर लिखते हैं।

5. यदि 4 का उत्तर "हाँ" है, तो क्या यह लेआउटमैनेजर वर्गों के प्रसार का कारण नहीं होगा जिसे बनाए रखना मुश्किल हो जाएगा?

   (4 का उत्तर "नहीं" है।)

6. ऐसी स्थिति में जहां मुझे एक घटक के बच्चों के बीच अनुपात को परिभाषित करने की आवश्यकता है (उदाहरण के लिए, बच्चे 1 को 10% स्थान, बच्चे 2 40%, बच्चे 3 50% का उपयोग करना चाहिए), क्या यह संभव है कि बिना किसी कस्टम लेआउट मैनजर को लागू किए?

   बिग-थ्री कैन में से कोई भी ग्रिडबाग (कभी भी वास्तव में मास्टर के लिए परेशान नहीं, बहुत कम बिजली के लिए बहुत परेशान) नहीं कर सकता।

Comments

मुझे पूरा यकीन नहीं है कि मैं कम से कम दो स्थितियों में इस सलाह से सहमत हूं। 1) कस्टम रेंडर किए गए घटक 2) JEditorPaneHTML के साथ उपयोग करना जो स्वयं एक चौड़ाई का सुझाव नहीं देता है। ओटोह मुझे यकीन नहीं है कि मैंने कुछ याद किया है। मैं थ्रेड पर उत्तरों की सावधानीपूर्वक समीक्षा करूंगा, लेकिन यदि आपके पास कोई टिप्पणी थी, तो विशेष रूप से बाद के मामले में आपकी रुचि थी।

— एंड्रयू थॉम्पसन

@Andrew थॉम्पसन 1) कस्टम कम्प्स: यह खुद ही वह कंपास है जो उपयोगी लेआउट संकेत वापस करने के लिए ज़िम्मेदार है, अगर वे डंप नहीं करते हैं तो छोटी गाड़ी है 2) यहां तक ​​कि कोर कंप्स भी छोटी गाड़ी हैं ;-) 3) मुझे श्वेत स्थान पर ध्यान नहीं है (हालांकि यह नहीं था इस बार जानबूझकर, धन्यवाद :-)

— kleopatra

मुझे विश्वास नहीं हो रहा है कि स्वीकृत उत्तर वह है जो सेटएक्सएक्सएक्सएक्स () विधियों का उपयोग करने से बचने के लिए कहता है। कभी-कभी आपको लेआउट प्रबंधक को संकेत देने के लिए बस उनकी आवश्यकता होती है। यदि आप एक पैनल बिछा रहे हैं तो आपको आवश्यक होने पर इन तरीकों का उपयोग करने के लिए स्वतंत्र महसूस करना चाहिए। यह कहते हुए कि मुझे लगता है कि यदि आप उपयुक्त लेआउट प्रबंधक का उपयोग करते हैं, तो आप पाएंगे कि आपको इन विधियों की आवश्यकता नहीं है, लेकिन इस अवसर पर आपको बस उनकी आवश्यकता है। एक X_AXIS BoxLayout में JComboBox या JSpinner डालने का प्रयास करें और उनका उपयोग न करें, विश्वास करें कि आपको वहाँ setMaximumSize () की आवश्यकता होगी।

— माइकल

@ मिचेल नहीं, मुझे इसकी बिल्कुल आवश्यकता नहीं है - इसका उत्तर हमेशा एक सभ्य लेआउटमैन का उपयोग करना है और प्रबंधक स्तर (बनाम घटक-स्तर) पर कोई भी बारीक-बारीक काम करना है

— kleopatra

आप कह रहे हैं "एक सभ्य लेआउट प्रबंधक का उपयोग करें और यह बताएं कि आप सभी आकारों में क्या चाहते हैं" सभी स्टैकओवरफ़्लो पर, लेकिन आप कभी भी "सभ्य" लेआउटमैनगर का कोई विशिष्ट उदाहरण नहीं देते हैं। और कोई भी मानक प्रबंधक सीधे आकारों को नियंत्रित करने की अनुमति नहीं देता है।

— तिवारी मारगा

Answer 2

कुछ अनुमान:

• set[Preferred|Maximum|Minimum]Size()जब आप वास्तव में ओवरराइड करने का मतलब नहीं करते हैं get[Preferred|Maximum|Minimum]Size(), तो अपना स्वयं का घटक बनाने में उपयोग न करें , यहां दिखाया गया है ।

• set[Preferred|Maximum|Minimum]Size()जब आप किसी घटक के सावधानीपूर्वक ओवरराइड पर भरोसा कर सकते हैं, तो उसका उपयोग न करें getPreferred|Maximum|Minimum]Size, जैसा कि यहां और नीचे दिखाया गया है ।

• set[Preferred|Maximum|Minimum]Size()पोस्ट- validate()जियोमेट्री को प्राप्त करने के लिए उपयोग करें , जैसा कि नीचे और यहां दिखाया गया है ।

• यदि किसी घटक का कोई पसंदीदा आकार नहीं है, उदाहरण के लिए JDesktopPane, आपको कंटेनर को आकार देना पड़ सकता है, लेकिन ऐसी कोई पसंद मनमानी है। एक टिप्पणी इरादे को स्पष्ट करने में मदद कर सकती है।

• वैकल्पिक या कस्टम लेआउट पर विचार करें जब आप पाते हैं कि आपको व्युत्पन्न आकार प्राप्त करने के लिए कई घटकों के माध्यम से लूप करना होगा, जैसा कि इन टिप्पणियों में उल्लेख किया गया है ।

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 /programming/7229226
 * @see /programming/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());
            }
        }
    }
}

Comments

असहमति (जैसा कि आप अनुमान लगा सकते हैं :-) "बाहरी कारकों" द्वारा तर्क के साथ: XXSize गुण केवल आंतरिक आवश्यकताओं को व्यक्त करने के लिए है। बाहर से उन लोगों को तोड़-मरोड़ कर गलत उपयोग किया जाता है, उर्फ ​​हैकिंग। यदि आप चाहते हैं कि एक (आंतरिक- या- जे) फ्रेम एए स्पेसक के आकार के सापेक्ष हो तो यह पसंद किया जाता है ... फ्रेम को आकार दें, सामग्री नहीं

— क्लेओपेट्रा

@kleopatra: बस थोड़ा सा जिद करने के लिए: अगर setXXSize के तरीकों का इस्तेमाल कभी भी बाहर से नहीं किया जाना चाहिए, तो इसे निजी या संरक्षित क्यों नहीं घोषित किया गया है? क्या यह डिजाइन की कमी नहीं है? क्या सार्वजनिक संशोधक का अर्थ यह नहीं है कि उपयोगकर्ता उन तरीकों का उपयोग कर सकता है?

— हाइजेनबग

मुझे @kleopatra से सहमत होना होगा: setPreferredSize()हमेशा घटक की गणना को एक मनमानी पसंद के साथ बदलता है।

— ट्रैशगोड

@trashgod +100 आपको लगता है कि इन तरीकों को ओवरराइड करने में कोई समस्या नहीं है, यहां तक ​​कि उन्हें कॉल करने से भी (लेकिन निश्चित रूप से इसका मतलब होगा कि आपके पास एक कस्टम घटक होगा, इस तरह से ओवरराइड करना बेहतर होगा)

— डेविड क्राउकैंप

@DavidKroukamp: धन्यवाद। मैं क्लियोपेट्रा के अधिक से अधिक अनुभव को टालता हूं, लेकिन मैं इसके विपरीत मूल्य की आलोचनात्मक दृष्टि से जांच करता हूं।

— ट्रैशगोड

Answer 3

क्या मुझे उन तरीकों के इस्तेमाल से पूरी तरह बचना चाहिए?

नहीं, इन विधियों को कॉल करने या ओवरराइड करने का सुझाव देने के लिए कोई औपचारिक सबूत नहीं है। वास्तव में, ओरेकल का कहना है कि इन विधियों का उपयोग आकार संकेत देने के लिए किया जाता है: http://docs.oracle.com/javase/tutorial/uiswing/layout/use.html#sizealignment ।

जब वे स्विंग घटक (कस्टम घटक उदाहरण पर विधि को कॉल करने के बजाय ) को बढ़ाते हैं तो उन्हें ओवरराइड भी किया जा सकता है (जो कि स्विंग के लिए सबसे अच्छा अभ्यास है )

सबसे महत्वपूर्ण बात यह है कि आप अपने घटक के आकार को कैसे निर्दिष्ट करते हैं, सुनिश्चित करें कि आपके घटक के कंटेनर लेआउट प्रबंधक का उपयोग करता है जो घटक के अनुरोधित आकार का सम्मान करता है।

तरीकों को एक कारण के लिए परिभाषित किया गया है। तो मुझे उनका उपयोग कब करना चाहिए? किस संदर्भ में? किन उद्देश्यों के लिए?

जब आपको कंटेनर लेआउट प्रबंधक को अनुकूलित आकार संकेत प्रदान करने की आवश्यकता होती है, ताकि घटक को अच्छी तरह से रखा जा सके

वास्तव में उन तरीकों का उपयोग करने के नकारात्मक परिणाम क्या हैं? (मैं केवल विभिन्न स्क्रीन रिज़ॉल्यूशन वाले सिस्टम के बीच पोर्टेबिलिटी जोड़ने के लिए सोच सकता हूं)।

• कई लेआउट प्रबंधक एक घटक के अनुरोधित अधिकतम आकार पर ध्यान नहीं देते हैं। हालाँकि, BoxLayoutऔर SpringLayoutकरते हैं। इसके अलावा, GroupLayoutघटक को छूने के बिना, स्पष्ट रूप से न्यूनतम, पसंदीदा या अधिकतम आकार निर्धारित करने की क्षमता प्रदान करता है।

• सुनिश्चित करें कि आपको वास्तव में घटक के सटीक आकार को सेट करने की आवश्यकता है। प्रत्येक स्विंग घटक का एक अलग पसंदीदा आकार होता है, जो इसके उपयोग किए जाने वाले फॉन्ट और लुक और फील पर निर्भर करता है। इस प्रकार एक सेट आकार होने पर विभिन्न प्रणालियों पर यूआई के विभिन्न रूप दिखाई देते हैं

• कभी-कभी समस्याओं का सामना करना पड़ सकता है GridBagLayoutऔर पाठ क्षेत्रों के साथ, जिसमें यदि कंटेनर का आकार पसंदीदा आकार से छोटा है, तो न्यूनतम आकार का उपयोग किया जाता है, जिससे पाठ क्षेत्र काफी हद तक सिकुड़ सकते हैं।

• JFramegetMinimumSize()केवल setMinimumSize(..)अपने कार्यों पर कॉल करने के लिए ओवरराइड लागू नहीं करता है

मुझे नहीं लगता कि कोई भी लेआउट मैनजर सभी वांछित लेआउट जरूरतों को पूरा कर सकता है। क्या मुझे वास्तव में अपने लेआउट के हर छोटे बदलाव के लिए एक नया LayoutManager लागू करने की आवश्यकता है?

यदि लागू करने से आप का उपयोग करने का मतलब है तो हाँ। कोई भी LayoutMangerसबकुछ नहीं संभाल सकता है, प्रत्येक के LayoutManagerपास इसके पेशेवरों और विपक्ष हैं इस प्रकार प्रत्येक को अंतिम लेआउट का उत्पादन करने के लिए एक साथ इस्तेमाल किया जा सकता है।

संदर्भ:

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

Comments

स्वनिर्धारित आकार संकेत प्रदान करना जो अपने आप में एक विरोधाभास है: नौकरशाही का आकार घटाने (px में!) घटक का विशेष कार्य है। यह आंतरिक स्थिति के विवरण के आधार पर उनकी गणना करता है जिसे स्वयं के अलावा कोई अन्य पार्टी नहीं जान सकती (न ही ट्रैक रख सकती है)। ग्राहक के दृष्टिकोण से, अनुकूलन के माध्यम एक उपयुक्त LayoutManager और / या घटक "अर्थ" आकार-प्रासंगिक गुण, एक पाठ घटक में पंक्तियों / स्तंभों की फाई संख्या के मामले में आकार आवश्यकताओं को विन्यस्त करने की अनुमति देता है कि विशेषज्ञता हासिल एपीआई हो सकता है

— Kleopatra

@kleopatra मुझे अभी भी यह जानकर बहुत अच्छा लगेगा कि ओरेकल क्यों हमें इन तरीकों का उपयोग करने का तरीका बताता है और उनका उपयोग करने का सही तरीका। हमारी अपनी प्राथमिकताएँ हो सकती हैं, लेकिन हम कहते हैं कि डिज़ाइनर इसका उपयोग तब नहीं करेंगे जब इसका सुझाव देने के लिए कोई सबूत न हो। लेकिन यही कारण है कि अगर मैं दूसरों को आकर्षित कर सकता हूं तो यह देखिए कि क्या यह एक विश्वसनीय स्रोत से एक जानकारी दे सकता है, जहां पर ऑर्कल इन विधियों का उपयोग नहीं करने के लिए कहता है (इस प्रकार यह बुरा अभ्यास कर रहा है यदि आप करते हैं, उदाहरण के लिए setMinimumSize होना चाहिए JSplitPane आदि जैसी चीजों पर कॉल किया जा सकता है, इसे विभाजित पैन के ओरेकल ट्यूटोरियल में देखा जा सकता है।

— डेविड क्राउकम्प

@ डेविड: मैं setXxxSizeएक लाल झंडे के रूप में तरीकों को देखने आया हूं, जिसे मैं यहां पर हवा दे सकता हूं , यहां तक ​​कि जब डॉक्स इसे सुझाते हैं। मुझे लगभग हमेशा ओवरराइड करना चाहिए था getXxxSize, जहां किसी की आवश्यक ज्यामिति तक पहुंच होती है; और भी छोटे उदाहरणों को जितना मैं सोचना चाहता हूं, उससे कहीं अधिक पुनर्नवीनीकरण मिलता है। +1 लेआउट प्रबंधकों के बीच भिन्नता का उल्लेख करने और ट्यूटोरियल का हवाला देने के लिए।

— ट्रैशगॉड

D'oh, ऊपर मेरी टिप्पणी में, मेरा मतलब यहाँ उत्तर का हवाला देना है ।

— ट्रैशगोड

+1 "नहीं, इन तरीकों को कॉल करने या ओवरराइड करने का सुझाव देने के लिए कोई औपचारिक सबूत नहीं है।" सटीक। उत्तर के रूप में टैग की गई पोस्ट सादे बीएस है।

— टीटी।

Answer 4

यहाँ बहुत सारे अच्छे उत्तर हैं, लेकिन मैं उन कारणों के बारे में थोड़ा और जोड़ना चाहता हूं कि आपको सामान्य रूप से इनसे क्यों बचना चाहिए (यह प्रश्न अभी एक डुप्लिकेट विषय में फिर से आया है):

कुछ अपवादों के साथ, यदि आप इन विधियों का उपयोग कर रहे हैं, तो आप विशिष्ट GU- एंड-फील (और अपने सिस्टम-विशिष्ट सेटिंग्स, जैसे आपके पसंदीदा डेस्कटॉप फ़ॉन्ट, आदि) पर अच्छा दिखने के लिए अपने GUI को ठीक कर रहे हैं। तरीके स्वयं स्वाभाविक रूप से बुरे नहीं हैं, लेकिन इनका उपयोग करने के विशिष्ट कारण हैं । जैसे ही आप एक लेआउट में पिक्सेल स्थिति और आकार ट्यूनिंग शुरू करते हैं, आप अन्य प्लेटफार्मों पर अपने जीयूआई को तोड़ने (या कम से कम, खराब दिख रहे) के जोखिम को चलाते हैं।

इसके एक उदाहरण के रूप में, अपने एप्लिकेशन के डिफ़ॉल्ट रूप और परिवर्तन को बदलने का प्रयास करें। यहां तक ​​कि सिर्फ अपने प्लेटफॉर्म पर उपलब्ध विकल्पों के साथ, आप आश्चर्यचकित हो सकते हैं कि परिणाम कैसे खराब हो सकते हैं।

इसलिए, अपने जीयूआई को सभी प्लेटफार्मों पर कार्यात्मक और अच्छा दिखने के नाम पर (याद रखें, जावा के प्रमुख लाभों में से एक इसका क्रॉस-प्लेटफॉर्म है), आपको लेआउट प्रबंधकों आदि पर भरोसा करना चाहिए, ताकि स्वचालित रूप से आकारों को समायोजित कर सकें। आपके घटक ताकि यह आपके विशिष्ट विकास वातावरण के बाहर सही ढंग से प्रस्तुत हो।

उन सभी ने कहा, आप निश्चित रूप से उन स्थितियों के बारे में सोच सकते हैं जहां ये विधियां उचित हैं। फिर, वे स्वाभाविक रूप से बुरे नहीं हैं, लेकिन उनका उपयोग आम तौर पर संभावित जीयूआई मुद्दों को इंगित करने वाला एक बड़ा लाल झंडा है। बस सुनिश्चित करें कि आप जटिलताओं के लिए उच्च क्षमता से अवगत हैं / यदि आप उनका उपयोग करते हैं, और हमेशा कोशिश करें और सोचें कि क्या आपकी समस्याओं का एक और रूप-और-स्वतंत्र समाधान है - अधिक बार नहीं तो आप पाएंगे कि ये विधियाँ आवश्यक नहीं हैं।

वैसे, यदि आप खुद को मानक लेआउट प्रबंधकों से निराश होते हुए पाते हैं, तो बहुत सारे अच्छे, खुले स्रोत वाले तृतीय-पक्ष वाले हैं, उदाहरण के लिए JGoodies 'FormLayout , या MigLayout। कुछ GUI बिल्डरों के पास थर्ड-पार्टी लेआउट मैनेजरों के लिए बिल्ट-इन सपोर्ट भी है - Eclipse's WindowBuilder GUI एडिटर, उदाहरण के लिए, शिप फॉर सपोर्ट FormLayoutऔर MigLayout।

Comments

+1 विचारशील उत्तर - वे केवल इस बात से असहमत हैं कि वे स्वाभाविक रूप से बुरे नहीं हैं क्योंकि वे आमतौर पर :-) आमतौर पर, बाहर के ग्राहकों को अनुमान लगाने का कोई मौका नहीं मिलता है - और केवल धारणाएं बाहरी लोगों के जितनी करीब हो सकती हैं - आधी सही लेआउट संकेत घटकों को स्वयं कुछ भी उपयोगी वापस करने के लिए हर समय सभी जानकारी होती है। और जब से बाहरी लोग हस्तक्षेप करते हैं, तो यह उनकी जिम्मेदारी है कि वे उन संकेतों को अप-टू-डेट रखें जो वे नहीं कर सकते।

— क्लेओपेट्रा

ठीक है, आप जानते हैं, मेरे पास और अधिक "बंदूकें लोगों को नहीं मारती हैं, लोग लोगों को मारते हैं" इस तरह की चीजों को देखते हुए। :) तो किसी को इन तरीकों का उपयोग करता है, वे की जरूरत है अच्छा अंक आप लेआउट संकेत के अप्रत्याशित उपयोग के बारे में बढ़ा जैसी चीजों के बारे में पता होना करने के लिए (जिसके कारण स्थितियों में, जहां इन तरीकों उपयुक्त हैं वास्तव में दुर्लभ हैं)।

— जेसन सी

मुझे लगता है कि पसंदीदा आकार सेट करना एक बड़ा लाल झंडा नहीं है। सेट नहीं करके यह है एक बड़ा लाल झंडा बजाय। मुझे विस्तार से बताएं लेआउट प्रबंधक - कोई फर्क नहीं पड़ता कि यह कितना स्मार्ट है - एक gui विजेट के तार्किक कार्य के बारे में कोई विचार नहीं है। उदाहरण के लिए, लेआउट प्रबंधक ज़िप कोड दर्ज करने के लिए JTextField और एक नाम दर्ज करने के लिए JTextField के बीच अंतर नहीं कर सकता है। इसी तरह यह JTextField के बगल में एक टूल बटन या फॉर्म के निचले भाग में एक बड़े OK बटन के बीच अंतर नहीं कर सकता है। इसलिए या तो एक बेहतर विजेट सेट, या कुछ आकार संकेत की आवश्यकता है, नहीं?

— जी बी

@GeeBee नहीं, यह वास्तव में एक लाल झंडे का एक प्रमुख उदाहरण है। आपको जो करना चाहिएJTextField.setColumns वह कॉलम की गिनती सेट करने के लिए उपयोग किया जाता है, जो तदनुसार पसंदीदा आकार को समायोजित करता है। यदि आप ऐसा करते हैं setPreferredSizeतो आप एक आकार को हार्ड-कोडिंग कर रहे हैं, जो प्लेटफ़ॉर्म फ़ॉन्ट आकार के आधार पर आपके लेआउट को तोड़ देगा। यहां ग्रिड बैग लेआउट में कुछ पाठ फ़ील्ड setColumnsउचित रूप से कहा जाता है । अपने बटनों के लिए, आकारों को नियंत्रित करने के लिए उपयुक्त लेआउट / ग्रिड वेट का उपयोग करें।

— जेसन सी

@GeeBee और अब, सही ढंग से किए जाने के साथ, ध्यान दें कि जब मैं फ़ॉन्ट का आकार घटाता हूं तो टेक्स्ट फ़ील्ड की चौड़ाई कैसे कम हो जाती है: i.snag.gy/ZULulh.jpg । यहां तक ​​कि मक्खी पर फ़ॉन्ट आकार बदलने से अब आप के बजाय स्वचालित रूप से काम करता है, कहते हैं, सभी पाठ क्षेत्र की चौड़ाई पुनर्गणना करने और स्पष्ट रूप से प्रत्येक के लिए फिर से निर्धारित करें, आप सभी को करना होगा लेआउट को अमान्य और उनके आकार समायोजित करेगा।

— जेसन सी

Answer 5

यदि आप जावा स्विंग में लेआउट से परेशान हैं, तो मैं यहांFormLayout कार्स्ट लेंट्ज़्च द्वारा फॉर्म फ्रीवेयर लाइब्रेरी के भाग के रूप में स्वतंत्र रूप से प्रदान की गई JGoodies की अत्यधिक अनुशंसा कर सकता हूं ।

यह बहुत लोकप्रिय लेआउट प्रबंधक बेहद लचीला है, जो बहुत पॉलिश जावा यूआई को विकसित करने की अनुमति देता है।

आपको यहाँ पर कार्स्टन के दस्तावेज़ मिलेंगे , और कुछ ग्रहण यहाँ से अच्छे दस्तावेज़ हैं ।

Answer 6

इन तरीकों को ज्यादातर लोगों द्वारा खराब तरीके से समझा जाता है। आपको इन तरीकों को बिल्कुल नजरअंदाज नहीं करना चाहिए। यदि वे इन विधियों का सम्मान करते हैं तो यह लेआउट प्रबंधक पर निर्भर है। इस पृष्ठ में एक तालिका है जो दिखाती है कि लेआउट प्रबंधक उन तरीकों में से किसका सम्मान करते हैं:

http://thebadprogrammer.com/swing-layout-manager-sizing/

मैं 8+ वर्षों से स्विंग कोड लिख रहा हूं और JDK में शामिल लेआउट प्रबंधकों ने हमेशा मेरी जरूरतों को पूरा किया है। मुझे अपने लेआउट को प्राप्त करने के लिए कभी भी तीसरे पक्ष के लेआउट प्रबंधक की आवश्यकता नहीं है।

मैं कहूंगा कि आपको इन तरीकों के साथ लेआउट प्रबंधक संकेत देने की कोशिश नहीं करनी चाहिए जब तक कि आप सुनिश्चित न हों कि आपको उनकी आवश्यकता है। अपने लेआउट को बिना किसी आकार के संकेत दिए (यानी लेआउट प्रबंधक को अपना काम करने दें) और फिर आपको ज़रूरत पड़ने पर मामूली सुधार कर सकते हैं।

Comments

या तो थोड़ी सी गलतफहमी है (आपकी ओर से) या गलतफहमी (मेरी ओर से), अपनी पसंद ले लें :-) आप दोहराते रहते हैं (यहां, अपने ब्लॉग में, अपने जवाब में BoxLayout से संबंधित) सेट XXSize महत्वपूर्ण होने के नाते - वास्तव में LayoutManager XXSize में रुचि रखता है (या नहीं), जो इस बारे में स्वतंत्र साइज़िंग संकेत है कि यह कैसे आया (घटक द्वारा आंतरिक गणना या एप्लिकेशन कोड द्वारा मैन्युअल रूप से मजबूर किया गया)

— kleopatra

मुझे यकीन नहीं है कि मैं समझता हूं कि आप यहां क्या कर रहे हैं। मैं ऊपर उल्लेख करता हूं कि XXSize () विधियां सिर्फ संकेत हैं। मैं वास्तव में लेआउट प्रबंधक को थोड़ा संकेत देने के साथ कुछ भी गलत नहीं देखता, अगर जरूरत हो। मेरे स्विंग कोड में, आपको एक सामयिक setXXSize () विधि मिलेगी। कई नहीं, लेकिन हर बार एक समय में मुझे लगता है कि उनकी जरूरत है। JComboBox और JSpinner को अक्सर संकेत की आवश्यकता होती है। विशेष रूप से एक JComboBox जो एहसास होने के बाद आबाद है। आप इन तरीकों में से किसी भी और सभी उपयोग के खिलाफ लग रहे हैं और मुझे पता नहीं क्यों। (शायद मुझे लगता है मैं इस पर नाव लापता एक हूँ)।

— माइकल

नहीं तरीकों संकेत दिए हैं, गुण हैं: घटकों सभी संकेत के लिए कुछ उचित रिपोर्ट करना चाहिए, कुछ (फाई JComboBox के रूप में) नहीं है - maxInteger या तो लौटने में। यह एक बग है और कॉम्बो द्वारा तय किया जाना चाहिए। अपनी आदत के अनुसार: सुनिश्चित करें कि जब दूर रखने वाले कोलीग को साफ करना है तो बहुत दूर होना चाहिए :) हार्ड-कोडेड संकेत थोड़े से बदलाव पर लेआउट को बर्बाद कर देते हैं और टूटे हुए लेआउट के कारण का पता लगाना कठिन होता है।

— क्लेओपेट्रा

Answer 7

ऐसी स्थिति में जहां मुझे एक घटक के बच्चों के बीच अनुपात को परिभाषित करने की आवश्यकता है (बच्चे 1 को 10% स्थान का उपयोग करना चाहिए, चाइल्ड 2 40%, बच्चे 3 50%), क्या कस्टम लेआउट प्रबंधक को लागू किए बिना इसे प्राप्त करना संभव है?

शायद GridBagLayoutआपकी जरूरतों को पूरा करेगा। इसके अलावा, वेब पर लेआउट प्रबंधकों का एक टन है, और मैं शर्त लगाता हूं कि आपकी आवश्यकताओं के अनुरूप है।

Comments

जवाब के लिए धन्यवाद। मुझे यह मान लेना है कि आपका भी मतलब था: "सेटप्रिफ्रेड्रेडाइज़ का उपयोग बिल्कुल न करें", है ना?

— Heisenbug

GridBagLayout बाधाओं का उपयोग करता है, जहां आप किसी दिए गए घटक के लिए X और Y दोनों में "वजन" निर्दिष्ट कर सकते हैं, इसलिए LayoutManager यह तय कर सकता है कि एक रिसाइज़ पर अतिरिक्त स्थान के साथ क्या करना है। लेकिन आपको अभी भी प्रत्येक घटक के पसंदीदा आकार को निर्धारित करने के लिए setPreferredSize का उपयोग करना चाहिए / कर सकते हैं , ध्यान दें कि "पसंदीदा" का मतलब यह नहीं है कि यह हमेशा सम्मानित होने वाला है। विशेष मामलों के लिए भी आपको setMinimumSize और setMaximumSize की आवश्यकता हो सकती है। वे बुराई नहीं हैं , उस में नहीं खरीदते हैं। docs.oracle.com/javase/tutorial/uiswing/layout/gridbag.html

— マ ゃ

Answer 8

मैं इसे स्वीकृत उत्तर से अलग देख रहा हूं।

1) क्या मुझे उन तरीकों के उपयोग से पूरी तरह से बचना चाहिए?

कभी न टालें! वे लेआउट प्रबंधक के लिए आपके घटकों के आकार की बाधाओं को व्यक्त करने के लिए वहां मौजूद हैं। यदि आप किसी लेआउट प्रबंधक का उपयोग नहीं कर रहे हैं, तो आप उनका उपयोग करने से बच सकते हैं और अपने आप दृश्य दृश्य को प्रबंधित करने का प्रयास कर सकते हैं।

दुर्भाग्य से, स्विंग उचित डिफ़ॉल्ट आयामों के साथ नहीं आ रहा है। हालांकि, एक घटक के आयामों को स्थापित करने के बजाय, उचित चूक के साथ अपने स्वयं के घटक को नीचे उतारना बेहतर OOP है। (उस मामले में आप अपने वंशज वर्ग में सेटएक्सएक्सएक्सएक्स कहते हैं।) वैकल्पिक रूप से, आप एक ही प्रभाव के लिए गेटएक्सएक्सएक्स तरीकों को ओवरराइड कर सकते हैं।

2) तरीकों को एक कारण के लिए परिभाषित किया गया है। तो मुझे उनका उपयोग कब करना चाहिए? किस संदर्भ में? किन उद्देश्यों के लिए?

हमेशा। जब आप एक घटक बनाते हैं, तो उस घटक के उपयोग के अनुसार उसका यथार्थवादी न्यूनतम / पसंदीदा / अधिकतम आकार निर्धारित करें। उदाहरण के लिए, यदि आपके पास यूके जैसे देश के प्रतीकों को दर्ज करने के लिए एक JTextField है, तो इसका पसंदीदा आकार दो वर्णों (वर्तमान फ़ॉन्ट, आदि) के साथ फिट होने के लिए व्यापक होगा, लेकिन शायद यह किसी भी बड़े को बढ़ने देने के लिए अर्थहीन है। आखिरकार, देश के प्रतीक दो वर्ण हैं। इसके विपरीत, यदि आपके पास ग्राहक नाम उदा जैसे दर्ज करने के लिए JTextField है, तो इसका आकार 20 वर्णों के लिए पिक्सेल आकार की तरह हो सकता है, लेकिन लेआउट बड़ा होने पर बड़ा हो सकता है, इसलिए अधिकतम आकार को अधिक पर सेट करें। उसी समय, 0px चौड़ा JTextField का होना व्यर्थ है, इसलिए एक यथार्थवादी न्यूनतम आकार सेट करें (मैं 2 वर्णों के पिक्सेल आकार कहूँगा)।

3) उन तरीकों का उपयोग करने के नकारात्मक परिणाम क्या हैं?

(मैं केवल विभिन्न स्क्रीन रिज़ॉल्यूशन वाले सिस्टम के बीच पोर्टेबिलिटी जोड़ने के बारे में सोच सकता हूं)।

कोई नकारात्मक परिणाम नहीं। ये लेआउट प्रबंधक के लिए संकेत हैं।

4) मुझे नहीं लगता कि कोई भी लेआउट मैनजर सभी वांछित लेआउट जरूरतों को पूरा कर सकता है।

क्या मुझे वास्तव में अपने लेआउट पर हर छोटे बदलाव के लिए एक नया LayoutManager लागू करने की आवश्यकता है?

नहीं, बिलकुल नहीं। सामान्य दृष्टिकोण क्षैतिज और ऊर्ध्वाधर लेआउट जैसे विभिन्न बुनियादी लेआउटमैन को कैस्केड करना है।

उदाहरण के लिए, नीचे दिया गया लेआउट:

<pre>
+--------------+--------+
| ###JTABLE### | [Add]  | 
| ...data...   |[Remove]|
| ...data...   |        |
| ...data...   |        |
+--------------+--------+
</pre>

दो भागों में है। बाएँ और दाएँ भाग एक क्षैतिज लेआउट हैं। दाहिना भाग क्षैतिज लेआउट में जोड़ा गया एक JPanel है, और इस JPanel में एक ऊर्ध्वाधर लेआउट है, जो बटन को लंबवत रूप से देता है।

बेशक, यह एक वास्तविक जीवन लेआउट के साथ मुश्किल बढ़ सकता है। इसलिए ग्रिड-आधारित लेआउट प्रबंधक जैसे कि MigLayout बहुत बेहतर है यदि आप कुछ भी गंभीर विकसित करने वाले हैं।

5) यदि 4 का उत्तर "हाँ" है, तो क्या इससे लेआउटमैनगर वर्गों का प्रसार नहीं होगा जिसे बनाए रखना मुश्किल हो जाएगा?

नहीं, आप निश्चित रूप से लेआउट प्रबंधकों का विकास नहीं करेंगे, जब तक कि आपको कुछ बहुत विशेष की आवश्यकता न हो।

6) ऐसी स्थिति में जहां मुझे अनुपात को परिभाषित करने की आवश्यकता होती है ...

एक घटक के बच्चों के बीच (उदाहरण के लिए, child1 को 10% स्थान, चाइल्ड 2 40%, चाइल्ड 3 50% का उपयोग करना चाहिए), क्या यह संभव है कि बिना कस्टम लेआउटमैनेजर को लागू किए?

मूल रूप से, एक बार पसंदीदा आकार सही सेट हो जाने के बाद, आप प्रतिशत में कुछ भी नहीं करना चाहेंगे। बस, क्योंकि प्रतिशत व्यर्थ हैं (जैसे कि JTextField में विंडो आकार का 10% होना व्यर्थ है - क्योंकि कोई विंडो को सिकोड़ सकता है ताकि JTextField 0px चौड़ा हो जाए, या विंडो का विस्तार कर सके ताकि JFextField एक डिस्प्ले पर दो डिस्प्ले के पार हो बहु-प्रदर्शन सेटअप)।

लेकिन, कई बार आप अपने गुई के बड़े बिल्डिंग ब्लॉक्स (उदाहरण के लिए) के आकार को नियंत्रित करने के लिए प्रतिशत का उपयोग कर सकते हैं।

आप JSplitPane का उपयोग कर सकते हैं जहाँ आप दोनों पक्षों के अनुपात को पूर्व-निर्धारित कर सकते हैं। या, आप MigLayout का उपयोग कर सकते हैं जो आपको प्रतिशत, पिक्सेल और अन्य इकाइयों में ऐसी बाधाओं को सेट करने की अनुमति देता है।

Comments

वास्तव में? यह 0 पर था? यह स्वीकृत उत्तर से बेहतर है जिसमें 100+ अप हैं। यह मूल रूप से कहता है कि "तू नीवर का उपयोग करेगा जो कठिन है। मेरे काम की लाइन में, विशिष्ट आकार की आवश्यकताओं का एक बहुत कुछ है, जैसे कि "टच स्क्रीन पर बटन [वाई] [एम] एक्स [एन] के साथ [सुरक्षा] सुरक्षा आवश्यकता के बीच होना चाहिए। btnBar.setPreferredSize( dimTouchBtn );ऐसा करने का सबसे अच्छा तरीका है। सीधे, कस्टम लेआउट प्रबंधक के लिए कोई ज़रूरत नहीं है। मैं ज्यादातर GridBagLayoutकुछ के साथ उपयोग करता हूं BorderLayoutऔर BoxLayout, सुविधाजनक होने पर घोंसला बनाता हूं । यह एक मजबूत संयोजन और उपयोग करने में आसान है।

— लादुविज्क

मैं अपनी उपरोक्त टिप्पणी में जल्दबाजी कर रहा था। यह पहला उत्तर था जिसे मैंने स्वीकृत उत्तर के बाद देखा था। एसओ अब वोटों की गिनती क्यों नहीं कर रहा है? मुझे लगा कि मूल रूप से वोटों की गिनती के मूल कारणों में से एक था। मैं अभी भी मूल टिप्पणी से खड़ा हूँ; यह बेहतर उत्तरों में से एक है। इसके बिंदु # 6 को छोड़कर - वह उतना महान नहीं है। बहुत सारे हैं (अल्पसंख्यक अभी भी बड़ी संख्या में हो सकते हैं) कारणों का आकार बदलने के लिए, और GridBagLayout ज्यादातर मामलों में मेरा समर्थन करता है।

— लादुविज्क

मुझे लगता है कि बनाम आकार परिवर्तन नहीं एक धार्मिक निर्णय माना जाएगा। ऐसे मामलों का उपयोग किया जाता है जब कोई भी कभी भी कुछ भी आकार बदलना नहीं चाहता है, उदाहरण के लिए यदि आप एक कियोस्क के लिए एक पूर्व-निर्धारित प्रस्ताव के साथ जीयूआई विकसित करते हैं। यदि आपके पास अलग-अलग लक्ष्य हैं, जैसे कि औद्योगिक एचएमआई प्रदर्शित करता है और "बटन" का मामला है, तो हाँ, आपको टच स्क्रीन पर एक बटन के लिए कम से कम 1 सेमी 1 सेमी होना चाहिए। इस स्थिति में, स्क्रीन का DPI सेट करता है कि आप किस प्रकार का आकार बदलते हैं। पाठ इनपुट जैसे अन्य इनपुट को वर्टिकल रूप से बिल्कुल भी रीसाइज़ नहीं किया जा सकता है, और कभी-कभी (जैसे कि ज़िपकोड) हॉरिजॉन्टल आकार भी बेकार होता है।

— जी बी

Answer 9

क्या मुझे उन तरीकों के इस्तेमाल से पूरी तरह बचना चाहिए? मैं उन्हें "टालना" नहीं कहूंगा। मैं कहूंगा कि यदि आपको लगता है कि आपको उनकी आवश्यकता है, तो आप शायद कुछ गलत कर रहे हैं। घटक आकार संदर्भ में निर्धारित किए जाते हैं। उदाहरण के लिए, पाठ घटक आकार आपके द्वारा निर्दिष्ट फ़ॉन्ट के साथ संयुक्त पंक्तियों और स्तंभों की संख्या से निर्धारित होता है। यदि आप एक सेट करते हैं, तो आपके बटन और लेबल का आकार ग्राफिक का आकार होगा, या आपके द्वारा सेट किए गए पाठ को प्रदर्शित करने के लिए आवश्यक स्थान। प्रत्येक घटक में एक प्राकृतिक आकार होता है, और लेआउट प्रबंधक उन सभी का उपयोग करने के लिए उपयोग करेंगे जो आपको आकार निर्दिष्ट करने की आवश्यकता के बिना सब कुछ बाहर करने के लिए करेंगे। मुख्य अपवाद JScrollPane है, जिसके पास जो कुछ भी है उसका आकार स्वतंत्र है। उन लोगों के लिए, मैं कभी-कभी कॉल करूंगा setSize(), और उस आकार को प्रारंभिक विंडो का आकार निर्धारित करके, कॉल करके बता सकता हूंJFrame.pack()। आमतौर पर, मैं खिड़की के आकार को JScrollPane के आकार को निर्धारित करने दूंगा। उपयोगकर्ता विंडो के आकार का निर्धारण करेगा। कई लेआउट प्रबंधक वैसे भी आपके द्वारा निर्धारित आकारों की उपेक्षा करते हैं, इसलिए वे अक्सर बहुत अच्छा नहीं करते हैं।

तरीकों को एक कारण के लिए परिभाषित किया गया है। तो मुझे उनका उपयोग कब करना चाहिए? किस संदर्भ में? किन उद्देश्यों के लिए? मेरा मानना ​​है कि वे लेआउट प्रबंधकों को संकेत प्रदान करने के लिए जोड़े गए थे। वे ऐतिहासिक कारणों से लिखे गए हो सकते हैं, क्योंकि लेआउट प्रबंधक नए थे, और लोगों ने उन पर पूरी तरह भरोसा नहीं किया। मैं कुछ डेवलपर्स को जानता हूं जिन्होंने लेआउट प्रबंधकों से परहेज किया और मैन्युअल रूप से सब कुछ रखा, सिर्फ इसलिए कि वे नए प्रतिमान सीखने के साथ परेशान नहीं करना चाहते थे। यह एक भयानक विचार है।

वास्तव में उन तरीकों का उपयोग करने के नकारात्मक परिणाम क्या हैं? (मैं केवल विभिन्न स्क्रीन रिज़ॉल्यूशन वाले सिस्टम के बीच पोर्टेबिलिटी जोड़ने के बारे में सोच सकता हूं)। वे अप्रभावी हैं, और वे खराब लेआउट का उत्पादन करते हैं, वस्तुओं के साथ निचोड़ा हुआ या गैर-प्राकृतिक आकारों तक फैला हुआ है। और लेआउट भंगुर होंगे। खिड़की के आकार में परिवर्तन कभी-कभी लेआउट को तोड़ देगा और चीजों को गलत स्थानों पर डाल देगा।

मुझे नहीं लगता कि कोई भी लेआउट मैनजर सभी वांछित लेआउट जरूरतों को पूरा कर सकता है। क्या मुझे वास्तव में अपने लेआउट पर हर छोटे बदलाव के लिए एक नया LayoutManager लागू करने की आवश्यकता है? आपको एक नया लेआउट प्रबंधक "कार्यान्वित" नहीं करना चाहिए। आपको मौजूदा लोगों को तुरंत करना चाहिए। मैं अक्सर एक विंडो में कई लेआउट प्रबंधकों का उपयोग करता हूं। प्रत्येक JPanel का अपना लेआउट प्रबंधक होगा। कुछ लोग नेस्टेड लेआउट में गंजे होते हैं, क्योंकि उन्हें बनाए रखना मुश्किल होता है। जब मैं उनका उपयोग करता हूं, तो मैं प्रत्येक को अपनी निर्माण विधि देता हूं ताकि यह देखना आसान हो सके कि प्रत्येक क्या करता है। लेकिन मैं लेआउट मैनेजर को कभी "लागू" नहीं करता। मैं बस उन्हें तुरंत देता हूं।

यदि 4 का उत्तर "हाँ" है, तो क्या यह लेआउटमैनेजर वर्गों के प्रसार का कारण नहीं होगा जिसे बनाए रखना मुश्किल हो जाएगा? यदि आप लेआउट में मामूली बदलाव के लिए नए लेआउट प्रबंधक कक्षाएं लागू कर रहे हैं, तो आप उनका गलत उपयोग कर रहे हैं। यदि आप नए लेआउट प्रबंधकों को लागू कर रहे हैं, तो आप शायद कुछ गलत कर रहे हैं। एकमात्र बार जब मैंने एक LayoutManager वर्ग बढ़ाया है, तो उसे JScrollPane में एक ज़ूम स्लाइडर जोड़ना था।

ऐसी स्थिति में जहां मुझे एक घटक के बच्चों के बीच अनुपात को परिभाषित करने की आवश्यकता होती है (उदाहरण के लिए, चाइल्ड 1 को 10% स्थान, चाइल्ड 2 40%, चाइल्ड 3 50% का उपयोग करना चाहिए), क्या यह संभव है कि बिना कस्टम लेआउट मैनजर को लागू किए? JSplitPane को प्रत्येक घटक को मिलने वाले प्रतिशत को निर्दिष्ट करने का एक तरीका है। विभक्त डिफ़ॉल्ट रूप से चल रहा है, लेकिन आप चाहें तो इसे बंद कर सकते हैं। मैं उस सुविधा का अधिक उपयोग नहीं करता। मेरे पास आमतौर पर कुछ घटक होते हैं जो एक सेट आकार लेते हैं, और शेष स्थान को एक स्क्रॉल फलक द्वारा लिया जाता है। स्क्रॉल फलक का आकार विंडो के आकार के साथ समायोजित होगा। यदि आपके पास दो स्क्रॉल पैन हैं, तो आप उन्हें JSplitPane में रख सकते हैं और उपयोगकर्ता द्वारा विस्तारित और अनुबंधित खिड़कियों के रूप में प्रत्येक को दिए गए नए स्थान का प्रतिशत निर्दिष्ट कर सकते हैं।