Sollte ich die Verwendung von Set-Methoden (Preferred | Maximum | Minimum) Size in Java Swing vermeiden?

Ich wurde mehrmals dafür kritisiert, dass ich die Verwendung der folgenden Methoden vorgeschlagen habe:

1. setPreferredSize
2. setMinimumSize
3. setMaximumSize

auf SwingKomponenten. Ich sehe keine Alternative zu ihrer Verwendung, wenn ich Proportionen zwischen angezeigten Komponenten definieren möchte. Mir wurde folgendes gesagt:

Bei Layouts ist die Antwort immer dieselbe: Verwenden Sie einen geeigneten LayoutManager

Ich habe ein wenig im Internet gesucht, aber keine umfassende Analyse des Themas gefunden. Ich habe also folgende Fragen:

1. Sollte ich die Verwendung dieser Methoden vollständig vermeiden?
2. Die Methoden wurden aus einem bestimmten Grund definiert. Wann sollte ich sie verwenden? In welchem ​​Kontext? Für welche Zwecke?
3. Was genau sind die negativen Folgen dieser Methoden? (Ich kann mir nur vorstellen, Portabilität zwischen Systemen mit unterschiedlicher Bildschirmauflösung hinzuzufügen).
4. Ich glaube nicht, dass ein LayoutManager alle gewünschten Layoutanforderungen genau erfüllen kann. Muss ich wirklich für jede kleine Variation meines Layouts einen neuen LayoutManager implementieren?
5. Wenn die Antwort auf 4 "Ja" lautet, führt dies dann nicht zu einer Zunahme von LayoutManager-Klassen, deren Wartung schwierig wird?
6. Ist es in einer Situation, in der ich Proportionen zwischen untergeordneten Elementen einer Komponente definieren muss (z. B. sollte child1 10% des Speicherplatzes verwenden, child2 40%, child3 50%), möglich, dies zu erreichen, ohne einen benutzerdefinierten LayoutManager zu implementieren?

1. Sollte ich die Verwendung dieser Methoden vollständig vermeiden?

   Ja für den Anwendungscode.

2. Die Methoden wurden aus einem bestimmten Grund definiert. Wann sollte ich sie verwenden? In welchem ​​Kontext? Für welche Zwecke?

   Ich weiß es nicht, ich persönlich betrachte es als einen API-Designunfall. Etwas gezwungen durch zusammengesetzte Komponenten, die spezielle Vorstellungen über Kindergrößen haben. "Leicht", weil sie ihre Anforderungen mit einem benutzerdefinierten LayoutManager hätten implementieren sollen.

3. Was genau sind die negativen Folgen dieser Methoden? (Ich kann mir nur vorstellen, die Portabilität zwischen Systemen mit unterschiedlicher Bildschirmauflösung zu erhöhen.)

   Einige (unvollständige und leider aufgrund der Migration von SwingLabs zu java.net unterbrochene Links) technische Gründe werden beispielsweise in den Regeln (hehe) oder im Link @bendicott in seinem Kommentar zu meiner Antwort erwähnt . In sozialer Hinsicht müssen Sie Ihrem unglücklichen Kollegen, der den Code pflegen und ein kaputtes Layout aufspüren muss, eine Menge Arbeit auferlegen.

4. Ich glaube nicht, dass ein LayoutManager alle gewünschten Layoutanforderungen genau erfüllen kann. Muss ich wirklich für jede kleine Variation meines Layouts einen neuen LayoutManager implementieren?

   Ja, es gibt LayoutManager, die leistungsfähig genug sind, um eine sehr gute Annäherung an "alle Layoutanforderungen" zu erfüllen. Die großen drei sind JGoodies FormLayout, MigLayout, DesignGridLayout. Nein, in der Praxis schreiben Sie LayoutManager nur selten, außer in einfachen hochspezialisierten Umgebungen.

5. Wenn die Antwort auf 4 "Ja" lautet, führt dies dann nicht zu einer Zunahme von LayoutManager-Klassen, deren Wartung schwierig wird?

   (Die Antwort auf 4 lautet "nein".)

6. Ist es in einer Situation, in der ich Proportionen zwischen untergeordneten Elementen einer Komponente definieren muss (z. B. sollte untergeordnetes Element 1 10% des Speicherplatzes verwenden, untergeordnetes Element 2 40%, untergeordnetes Element 3 50%), möglich, dies zu erreichen, ohne einen benutzerdefinierten LayoutManager zu implementieren?

   Jeder der Big-Three kann, kann nicht einmal GridBag (nie die Mühe gemacht, wirklich zu meistern, zu viel Ärger für zu wenig Power).

Einige Heuristiken:

• Verwenden Sie nicht , set[Preferred|Maximum|Minimum]Size()wenn Sie wirklich außer Kraft zu setzen bedeuten get[Preferred|Maximum|Minimum]Size(), wie es bei der Erstellung Ihre eigene Komponente erfolgen, gezeigt hier .

• Nicht verwenden, set[Preferred|Maximum|Minimum]Size()wenn Sie sich darauf verlassen können, dass eine Komponente sorgfältig überschrieben wird getPreferred|Maximum|Minimum]Size, wie hier und unten gezeigt.

• Verwenden Sie set[Preferred|Maximum|Minimum]Size()diese Option validate(), um die Postgeometrie abzuleiten , wie unten und hier gezeigt .

• Wenn eine Komponente keine bevorzugte Größe hat JDesktopPane, müssen Sie möglicherweise den Container dimensionieren, aber eine solche Auswahl ist willkürlich. Ein Kommentar kann helfen, die Absicht zu verdeutlichen.

• Ziehen Sie alternative oder benutzerdefinierte Layouts in Betracht, wenn Sie feststellen, dass Sie viele Komponenten durchlaufen müssen, um abgeleitete Größen zu erhalten, wie in diesen Kommentaren erwähnt .

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());
            }
        }
    }
}

Sollte ich die Verwendung dieser Methoden vollständig vermeiden?

Nein, es gibt keine formalen Beweise dafür, dass das Aufrufen oder Überschreiben dieser Methoden nicht zulässig ist. Laut Oracle werden diese Methoden verwendet, um Größenhinweise zu geben: http://docs.oracle.com/javase/tutorial/uiswing/layout/using.html#sizealignment .

Sie können auch außer Kraft gesetzt werden (das ist die beste Praxis für Swing) , wenn Verlängerung eine Swing - Komponente (anstatt Aufruf der Methode auf dem benutzerdefinierten Komponenteninstanz)

Unabhängig davon, wie Sie die Größe Ihrer Komponente angeben, stellen Sie sicher, dass der Container Ihrer Komponente einen Layout-Manager verwendet, der die angeforderte Größe der Komponente berücksichtigt.

Die Methoden wurden aus einem bestimmten Grund definiert. Wann sollte ich sie verwenden? In welchem ​​Kontext? Für welche Zwecke?

Wenn Sie dem Layout-Manager des Containers benutzerdefinierte Größenhinweise geben müssen, damit die Komponente gut angeordnet ist

Was genau sind die negativen Folgen dieser Methoden? (Ich kann nur daran denken, die Portabilität zwischen Systemen mit unterschiedlicher Bildschirmauflösung zu erhöhen).

• Viele Layout-Manager achten nicht auf die angeforderte maximale Größe einer Komponente. Aber BoxLayoutund SpringLayouttun. Darüber hinaus GroupLayoutbietet die Möglichkeit , die minimalen, bevorzugte oder maximale Größe explizit zu setzen, ohne die Komponente zu berühren.

• Stellen Sie sicher, dass Sie die genaue Größe der Komponente wirklich einstellen müssen. Jede Swing-Komponente hat eine andere bevorzugte Größe, abhängig von der verwendeten Schriftart und dem Erscheinungsbild. So hat eine festgelegte Größe variiert produzieren könnte Blicke auf verschiedene Systeme der UI

• Manchmal können Probleme mit GridBagLayoutund Textfeldern auftreten. Wenn die Größe des Containers kleiner als die bevorzugte Größe ist, wird die Mindestgröße verwendet, was dazu führen kann, dass Textfelder erheblich verkleinert werden.

• JFrameerzwingt keine Überschreibung getMinimumSize(), indem nur setMinimumSize(..)seine Werke aufgerufen werden

Ich glaube nicht, dass ein LayoutManager alle gewünschten Layoutanforderungen genau erfüllen kann. Muss ich wirklich für jede kleine Variation meines Layouts einen neuen LayoutManager implementieren?

Wenn mit Implementierung gemeint ist, dann ja. Nicht jeder LayoutMangerkann mit allem umgehen, jeder LayoutManagerhat seine Vor- und Nachteile, so dass jeder zusammen verwendet werden kann, um das endgültige Layout zu erstellen.

Referenz:

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

Hier gibt es viele gute Antworten, aber ich möchte etwas mehr über die Gründe hinzufügen, warum Sie diese normalerweise vermeiden sollten (die Frage wurde gerade in einem doppelten Thema erneut gestellt):

Mit wenigen Ausnahmen, wenn Sie diese Methoden verwenden, optimieren Sie wahrscheinlich Ihre GUI so, dass sie in einem bestimmten Erscheinungsbild gut aussieht (und mit Ihren systemspezifischen Einstellungen, z. B. Ihrer bevorzugten Desktop-Schriftart usw.). Die Methoden selbst sind nicht von Natur aus böse, aber die typischen Gründe für ihre Verwendung sind . Sobald Sie anfangen, Pixelpositionen und -größen in einem Layout zu optimieren, besteht die Gefahr, dass Ihre GUI auf anderen Plattformen beschädigt wird (oder zumindest schlecht aussieht).

Versuchen Sie beispielsweise, das Standard-Erscheinungsbild Ihrer Anwendung zu ändern. Selbst mit den auf Ihrer Plattform verfügbaren Optionen können Sie überrascht sein, wie schlecht die Ergebnisse wiedergegeben werden können.

Um Ihre GUI auf allen Plattformen funktionsfähig und ansprechend zu halten (denken Sie daran, einer der Hauptvorteile von Java ist die plattformübergreifende Funktionalität), sollten Sie sich auf Layout-Manager usw. verlassen, um die Größe von automatisch anzupassen Ihre Komponenten, damit sie außerhalb Ihrer spezifischen Entwicklungsumgebung korrekt gerendert werden.

Trotzdem können Sie sich durchaus Situationen vorstellen, in denen diese Methoden gerechtfertigt sind. Auch hier sind sie nicht von Natur aus böse, aber ihre Verwendung ist normalerweise eine große rote Fahne, die auf mögliche Probleme mit der Benutzeroberfläche hinweist. Stellen Sie einfach sicher, dass Sie sich des hohen Komplikationspotenzials bewusst sind, wenn / wenn Sie sie verwenden, und versuchen Sie immer zu überlegen, ob es eine andere Look-and-Feel-unabhängige Lösung für Ihre Probleme gibt - meistens werden Sie feststellen, dass diese auftreten Methoden sind nicht notwendig.

Übrigens, wenn Sie mit Standard-Layout-Managern frustriert sind, gibt es viele gute kostenlose Open-Source- Angebote vonFormLayout Drittanbietern, zum Beispiel JGoodies oder MigLayout. Einige GUI-Builder bieten sogar integrierte Unterstützung für Layout-Manager von Drittanbietern. Der WindowBuilder-GUI-Editor von Eclipse bietet beispielsweise Unterstützung für FormLayoutund MigLayout.

Wenn Sie Probleme mit Layouts in Java Swing haben, kann ich die JGoodies, FormLayoutdie Karsten Lentzsch hier als Teil der Freeware-Bibliothek Forms zur Verfügung stellt, wärmstens empfehlen .

Dieser sehr beliebte Layout-Manager ist äußerst flexibel und ermöglicht die Entwicklung sehr ausgefeilter Java-Benutzeroberflächen.

Sie finden Karsten Dokumentation in finden hier , und einige ziemlich gute Dokumentation von Eclipse hier .

Diese Methoden werden von den meisten Menschen kaum verstanden. Sie sollten diese Methoden auf keinen Fall ignorieren. Es ist Sache des Layout-Managers, diese Methoden einzuhalten. Diese Seite enthält eine Tabelle, die zeigt, welche Layout-Manager welche dieser Methoden einhalten:

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

Ich schreibe seit mehr als 8 Jahren Swing-Code und die im JDK enthaltenen Layout-Manager haben immer meine Bedürfnisse erfüllt. Ich habe noch nie einen Layout-Manager eines Drittanbieters benötigt, um meine Layouts zu erstellen.

Ich werde sagen, dass Sie nicht versuchen sollten, dem Layout-Manager mit diesen Methoden Hinweise zu geben, bis Sie sicher sind, dass Sie sie benötigen. Führen Sie Ihr Layout ohne Größenangaben aus (dh lassen Sie den Layout-Manager seine Arbeit erledigen), und nehmen Sie bei Bedarf kleinere Korrekturen vor.

Ist es in einer Situation, in der ich Proportionen zwischen Kindern einer Komponente definieren muss (Kind 1 sollte 10% des Speicherplatzes verwenden, Kind2 40%, Kind3 50%), möglich, dies zu erreichen, ohne einen benutzerdefinierten Layout-Manager zu implementieren?

Vielleicht GridBagLayoutwürde Ihre Bedürfnisse befriedigen. Außerdem gibt es im Web eine Menge Layout-Manager, und ich wette, es gibt einen, der Ihren Anforderungen entspricht.

Ich sehe es anders als die akzeptierte Antwort.

1) Sollte ich die Verwendung dieser Methoden vollständig vermeiden?

Niemals meiden! Sie dienen dazu, dem Layout-Manager die Größenbeschränkungen Ihrer Komponenten auszudrücken. Sie können sie vermeiden, wenn Sie keinen Layout-Manager verwenden, und versuchen, das visuelle Layout selbst zu verwalten.

Leider wird Swing nicht mit angemessenen Standardabmessungen geliefert. Anstatt die Abmessungen einer Komponente festzulegen, ist es jedoch besser, die eigene Komponente mit angemessenen Standardeinstellungen herabzusetzen. (In diesem Fall rufen Sie setXXX in Ihrer Nachkommenklasse auf.) Alternativ können Sie die getXXX-Methoden für denselben Effekt überschreiben.

2) Die Methoden wurden aus einem bestimmten Grund definiert. Wann sollte ich sie verwenden? In welchem ​​Kontext? Für welche Zwecke?

Immer. Wenn Sie eine Komponente erstellen, legen Sie ihre realistische minimale / bevorzugte / maximale Größe entsprechend der Verwendung dieser Komponente fest. Wenn Sie beispielsweise ein JTextField für die Eingabe von Ländersymbolen wie UK haben, muss seine bevorzugte Größe so breit sein, dass zwei Zeichen (mit der aktuellen Schriftart usw.) passen. Wahrscheinlich ist es jedoch bedeutungslos, es größer werden zu lassen. Ländersymbole sind schließlich zwei Zeichen. Wenn Sie dagegen ein JTextField zur Eingabe eines Kundennamens haben, kann es eine bevorzugte Größe wie die Pixelgröße für 20 Zeichen haben, kann jedoch größer werden, wenn die Größe des Layouts geändert wird. Stellen Sie daher die maximale Größe auf mehr ein. Gleichzeitig ist es sinnlos, ein 0px breites JTextField zu haben. Legen Sie daher eine realistische Mindestgröße fest (ich würde sagen, die Pixelgröße beträgt 2 Zeichen).

3) Was genau sind die negativen Folgen dieser Methoden?

(Ich kann mir nur vorstellen, Portabilität zwischen Systemen mit unterschiedlicher Bildschirmauflösung hinzuzufügen).

Keine negativen Folgen. Dies sind Hinweise für den Layout-Manager.

4) Ich glaube nicht, dass ein LayoutManager alle gewünschten Layoutanforderungen genau erfüllen kann.

Muss ich wirklich für jede kleine Variation meines Layouts einen neuen LayoutManager implementieren?

Nein, definitiv nicht. Der übliche Ansatz besteht darin, verschiedene grundlegende Layoutmanager wie das horizontale und das vertikale Layout zu kaskadieren.

Zum Beispiel das folgende Layout:

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

hat zwei Teile. Der linke und der rechte Teil sind horizontal angeordnet. Der rechte Teil ist ein JPanel, das dem horizontalen Layout hinzugefügt wurde, und dieses JPanel hat ein vertikales Layout, das die Schaltflächen vertikal anordnet.

Natürlich kann dies mit einem realen Layout schwierig werden. Daher sind gitterbasierte Layout-Manager wie MigLayout viel besser, wenn Sie etwas Ernstes entwickeln möchten.

5) Wenn die Antwort auf 4 "Ja" lautet, führt dies dann nicht zu einer Zunahme von LayoutManager-Klassen, deren Wartung schwierig wird?

Nein, Sie sollten definitiv keine Layout-Manager entwickeln, es sei denn, Sie benötigen etwas ganz Besonderes.

6) In einer Situation, in der ich Proportionen definieren muss ...

Ist es zwischen Kindern einer Komponente (z. B. Kind1 sollte 10% des Speicherplatzes verwenden, Kind2 40%, Kind3 50%) möglich, dies zu erreichen, ohne einen benutzerdefinierten LayoutManager zu implementieren?

Sobald die bevorzugten Größen richtig eingestellt sind, möchten Sie möglicherweise nichts mehr in Prozent tun. Einfach, weil Prozentsätze sinnlos sind (z. B. ist es sinnlos, ein JTextField zu haben, das 10% der Fenstergröße beträgt - da man das Fenster verkleinern kann, sodass JTextField 0 Pixel breit wird, oder das Fenster so erweitern kann, dass sich das JTextField über zwei Anzeigen auf einem befindet Multi-Display-Setup).

Möglicherweise verwenden Sie die Prozentsätze jedoch, um die Größe größerer Bausteine ​​Ihrer GUI (z. B. Panels) zu steuern.

Sie können JSplitPane verwenden, wo Sie das Verhältnis der beiden Seiten voreingestellt haben. Sie können auch MigLayout verwenden, mit dem Sie solche Einschränkungen in Prozent, Pixeln und anderen Einheiten festlegen können.

Sollte ich die Verwendung dieser Methoden vollständig vermeiden? Ich würde nicht sagen "meide" sie. Ich würde sagen, wenn du denkst, dass du sie brauchst, machst du wahrscheinlich etwas falsch. Komponentengrößen werden im Kontext bestimmt. Die Größe von Textkomponenten wird beispielsweise durch die Anzahl der von Ihnen angegebenen Zeilen und Spalten in Kombination mit der von Ihnen ausgewählten Schriftart bestimmt. Ihre Schaltflächen- und Beschriftungsgröße entspricht der Größe der Grafik, falls Sie eine festlegen, oder dem Platz, der zum Anzeigen des von Ihnen festgelegten Texts erforderlich ist. Jede Komponente hat eine natürliche Größe, und die Layout-Manager verwenden diese, um alles zu gestalten, ohne dass Sie Größen angeben müssen. Die Hauptausnahme ist das JScrollPane, dessen Größe unabhängig von dem ist, was es enthält. Für diese werde ich manchmal anrufen setSize()und diese Größe die anfängliche Fenstergröße durch Aufrufen bestimmen lassenJFrame.pack(). Normalerweise lasse ich die Fenstergröße die JScrollPane-Größe bestimmen. Der Benutzer bestimmt die Größe des Fensters. Viele Layout-Manager ignorieren die von Ihnen festgelegten Größen ohnehin und tun daher oft nicht viel Gutes.

Die Methoden wurden aus einem bestimmten Grund definiert. Wann sollte ich sie verwenden? In welchem ​​Kontext? Für welche Zwecke? Ich glaube, sie wurden hinzugefügt, um den Layout-Managern Hinweise zu geben. Sie wurden möglicherweise aus historischen Gründen geschrieben, weil Layout-Manager neu waren und die Leute ihnen nicht voll vertrauten. Ich kenne einige Entwickler, die Layout-Manager vermieden und alles manuell platziert haben, nur weil sie sich nicht mit dem Erlernen eines neuen Paradigmas beschäftigen wollten. Es ist eine schreckliche Idee.

Was genau sind die negativen Folgen dieser Methoden? (Ich kann mir nur vorstellen, Portabilität zwischen Systemen mit unterschiedlicher Bildschirmauflösung hinzuzufügen). Sie sind ineffektiv und erzeugen schlechte Layouts, wobei Objekte zusammengedrückt oder auf nicht natürliche Größen gedehnt werden. Und die Layouts werden spröde. Änderungen an der Fenstergröße führen manchmal zu einer Unterbrechung des Layouts und zu falschen Positionen.

Ich glaube nicht, dass ein LayoutManager alle gewünschten Layoutanforderungen genau erfüllen kann. Muss ich wirklich für jede kleine Variation meines Layouts einen neuen LayoutManager implementieren? Sie sollten keinen neuen LayoutManager "implementieren". Sie sollten vorhandene instanziieren. Ich verwende oft mehrere Layout-Manager in einem einzigen Fenster. Jedes JPanel verfügt über einen eigenen Layout-Manager. Einige Leute scheuen verschachtelte Layouts, weil sie schwer zu pflegen sind. Wenn ich sie benutze, gebe ich jedem seine eigene Erstellungsmethode, damit ich leichter sehen kann, was jeder tut. Aber ich "implementiere" niemals einen Layout-Manager. Ich instanziiere sie einfach.

Wenn die Antwort auf 4 "Ja" lautet, führt dies dann nicht zu einer Zunahme von LayoutManager-Klassen, deren Wartung schwierig wird? Wenn Sie neue Layout-Manager-Klassen für geringfügige Abweichungen im Layout implementieren, verwenden Sie diese falsch. Wenn Sie nur neue Layout-Manager implementieren, machen Sie wahrscheinlich etwas falsch. Das einzige Mal, dass ich eine LayoutManager-Klasse erweitert habe, war das Hinzufügen eines Zoom-Schiebereglers zu einem JScrollPane.

Ist es in einer Situation, in der ich Proportionen zwischen untergeordneten Elementen einer Komponente definieren muss (z. B. sollte child1 10% des Speicherplatzes verwenden, child2 40%, child3 50%), möglich, dies zu erreichen, ohne einen benutzerdefinierten LayoutManager zu implementieren? Im JSplitPane kann der Prozentsatz angegeben werden, den jede Komponente erhalten soll. Der Teiler ist standardmäßig beweglich, aber Sie können ihn deaktivieren, wenn Sie möchten. Ich benutze diese Funktion nicht viel. Normalerweise habe ich einige Komponenten, die eine festgelegte Größe einnehmen, und der Rest des Speicherplatzes wird von einem Bildlauffenster eingenommen. Die Größe des Bildlauffensters wird mit der Fenstergröße angepasst. Wenn Sie zwei Bildlauffenster nebeneinander haben, können Sie sie in ein JSplitPane einfügen und den Prozentsatz des neuen Speicherplatzes angeben, der jedem Fenster zugewiesen wird, wenn der Benutzer die Fenster erweitert und verkleinert.