Swing Swing - Eigene Komponenten erstellen

[White_Fox]

Moin Leute

Mal eine Frage: Wie kann ich aus primitiven Formen eine eigene Swing-Komponente erstellen?

Ich würde gerne für meinen Zehn-Finger-Trainer eine kleine Visualisierung bauen, die eine Tastatur zeigt und die Taste markiert die als nächstes zu drücken ist.

Anfangs wollte ich eigentlich ein Bild (Tastatur) einfügen, und ein zweites Bild (eine Art Cursor) darüberlegen und die Cursorgraphik einfach verschieben. Aber das sieht einfach kagge aus.

Mein nächster Plan war, ein JPanel zu nehmen, darin lauter Rechtecke zu zeichnen und die Konturlinien einfach umzufärben...schön, wenn es so einfach wäre. Ich nahm eigentlich an, daß ein Rechteck einfach ein Objekt wäre dessen Eigenschaften ich nach Belieben anpassen kann. Stattdessen gibt es die drawRoundRect-Methode (die Tasten sollen ja runde Ecken haben), deren Einsatz ich aber ehrlich gesagt nicht verstehe. Z.B. hier:

Draw Rounded Rectangle Using Graphics Object in Java

Explore how to effectively draw a rounded rectangle using the Graphics object in Java.

www.tutorialspoint.com

Wann wird die paint-Methode denn eigentlich aufgerufen? Ich sehe das im Code nicht. Andere Tutorials finde ich nicht viel verständlicher (meist immer ein Codeschnipsel mit etwas Text, der aber keine Hintergründe erklärt).

Am liebsten hätte ich am Ende ein Keyboard-Objekt, in das ich einen String werfe und das dann die Zeichnung selber vornimmt. Das werde ich wohl selber machen müssen, aber wie am besten? Hat jemand einen guten Vorschlag?

 

[Oneixee5]

Du kannst mal bei Github suchen das andere umgesetzt haben:

GitHub - wcmjunior/virtualkeyboard: A virtual keyboard in Swing for Java SE applications.

A virtual keyboard in Swing for Java SE applications. - wcmjunior/virtualkeyboard

github.com

GitHub - WhizASh/Swing_Virtual_Keyboard: Virtual_Keyboard_Demo made using swing in java

Virtual_Keyboard_Demo made using swing in java. Contribute to WhizASh/Swing_Virtual_Keyboard development by creating an account on GitHub.

github.com

...

 

[White_Fox]

Eine erste Grundlage habe ich jetzt hinbekommen. JComponent erweitern...klar.

Mal schauen wie lahm das wird, zig Tasten zu zeichnen...aber wir werden sehen.

 

[KonradN]

Eine erste Grundlage habe ich jetzt hinbekommen. JComponent erweitern...klar.

Mal schauen wie lahm das wird, zig Tasten zu zeichnen...aber wir werden sehen.

Mach es doch nur einmal und nutze dies dann immer wieder:
BufferedImage erstellen und da alles einmal hinein malen. Dann reicht es, das BufferedImage zu malen was ggf. schneller ist.

 

[White_Fox]

Gute Idee...für jede Taste ein BufferedImage...ich denke so mache ich es.

 

[White_Fox]

So...ich habe es jetzt doch etwas anders gelöst: Ich habe für meine Tastatatur eine Klasse erstellt, die als JComponent daherkommt. Für die Tasten auch nochmal ein paar Klassen, so daß ich lauter Objekte habe die jeweils eine Taste zeichnen.

Und dann muß ich für jede Änderung nur zwei Tasten neu zeichnen lassen und spare mir die Sache mit dem BufferedImage.



Ich habe erstmal nur das Zeichnen implementiert, das Neuzeichnen kommt erst noch. Aber so sieht das gar nichtmal so schlecht aus, finde ich. Obwohl es Swing ist. Und man kann das Programm endlich sinnvoll nutzen...die letzte Version ohne Tastaturvisualisierung ist zum Lernen einfach ungeeignet.

Dann werde ich mal noch machen daß man statt des QWERTZ auch z.B. QWERTY und andere Tastaturlayouts anzeigen lassen kann...und ich denke, dann kann es so bleiben wie es ist.

 

[White_Fox]

So...jetzt habe ich doch nochmal eine Frage: Warum kann ich ein JComponent nicht repainten?

Ich habe folgende Methode:

public void refreshKeyHighlighting(String nextPhrase) {
        String nextChar = nextPhrase.substring(0, 1).toUpperCase(Locale.forLanguageTag("ru"));

        if (!nextChar.equals(lastChar)) {
            BasicKey currentlyMarkedKey = keys.get(lastChar);
            currentlyMarkedKey.setHighlighting(DisplayMode.STANDARD);
            currentlyMarkedKey.repaint();

            BasicKey nextKey = keys.get(nextChar);
            nextKey.setHighlighting(DisplayMode.HIGHLIGHTED);
            nextKey.repaint();
        }

        lastChar = nextChar;
    }

BasicKey ist eine Ableitung von JComponent. Wenn ich die repaint()-Methode aufrufe hätte ich erwartet, das irgendwann die (überschriebene) paintComponent() aufgerufen wird. Aber das passiert nie. Warum?

Zum Selberausprobieren und mit allem möglichen Kontext dazu:

Simple Russian Typing Trainer / git / [dcc72f]

sourceforge.net

Besagte Methode befindet sich in der Klasse SwingKeyboard.java ab Zeile 33.

 

[Robert Zenz]

repaint ist da nicht direkt, aus der Beschreibung der Methode:

If this component is a lightweight component, this method causes a call to this component's paintmethod as soon as possible. Otherwise, this method causes a call to this component's update method as soon as possible.

Man beachte "as soon as possible". Wenn ich mich richtig erinnere ist validate() oder invalidate() die Methode der Wahl damit erzwungen wird dass die Komponente neu gezeichnet wird. Eventuell muss man das fuer einen Teilbaum in dem die Komponente haengt machen. Eventuell muss man das repaint auch den Baum hinauf machen damit alle sich neuzeichnen.

Das "Problem" ist dass dann das Neuzeichnen erst passiert wenn wieder ein Neuzeichnen im Swing-EDT passiert, wenn ich mich richtig erinnere, und dass ist teilweise undurchsichtig weil viel Caching passiert.

 

[White_Fox]

Schade, weder mit validate() noch invalidate() funktioniert es.

So langsam bin ich versucht, das Graphicsobjekt aufzuheben und damit neuzuzeichnen...aber ob das eine gute Idee ist?

 

[mihe7]

Also, das kann so nicht funktionieren. Du fügst die Komponente nicht als Kindkomponente des Keyboard hinzu. Daher bringt Dir ein repaint der Keys wenig. Abgesehen davon: warum erzeugst Du in paintComponent jedesmal ein neues Set?

 

[White_Fox]

Abgesehen davon: warum erzeugst Du in paintComponent jedesmal ein neues Set?

Guter Punkt.

Ursprünglich wollte ich mir mal die vielen Zeilen key.paintComponent(g); sparen, und habe am Ende einfach über die HashMap iteriert, die brauchte ich ja sowieso. Dann ist mir später aufgegangen, daß ich ja längst nicht alle Keyobjekte in der HashMap brauche...und habe ein zweites HashSet erstellt. Was natürlich widersinnig ist, dann dann brauche ich jedes Mal eine Extrazeile um das Keyobjekt ins HashSet zu legen. Da muß ich nochmal zwei Schritte zurückgehen, das ist so jedenfalls Käse.

Edit:
@mihe7 Meinst du so etwas?

for (BasicKey k : keys.values()) {
    this.add(k);
    k.paintComponent(g);
}

Damit machen repaint()/validate() aber immer noch nichts...irgendwas scheint mir da immernoch zu fehlen. Nur was?

 

[mihe7]

@mihe7 Meinst du so etwas?

Naja, es gibt halt zwei Möglichkeiten:

a) in einer Komponente etwas zeichnen (paintComponent überschreiben)
b) Komponenten einer Komponente hinzufügen (dann werden die Komponenten automatisch gezeichnet).

Du machst hier eine seltsame Mischung: Du erstellst einerseits Komponenten, verwendest die dann aber, um sie nur zu zeichnen. Das geht natürlich, aber dann muss klar sein, dass die meisten Methoden von JComponent eigentlich keine Rolle spielen.

Wenn Du Deine Komponenten einfach zusätzlich addest, kann es sein, dass Du einmal eine automatisch gezeichnete Komponente hast (von der Du aber ggf. nichts siehst, weil Du außerhalb ihrer Grenzen zeichnest) und gleichzeitig einmal eine Komponente in paintComponent zeichnest. Da bringt Dir ein repaint auf der Komponente nichts.

Vielleicht mal von vorne. Eine Komponente hat "Bounds", also Location und Size. Wenn Du eine Komponente in einen java.awt.Container (JComponent ist davon abgeleitet) hinzufügst, greift normalerweise der LayoutManager des Containers. Der gibt einerseits Auskunft über die bevorzugte Größe und ist andererseits dafür verantwortlich, die im Container befindlichen Komponenten innerhalb eines gegebenen Platzes zu verteilen, sprich Location und Size der Komponenten festzulegen. Dabei kann der LayoutManager die Methoden getPreferredSize(), getMinimumSize() und getMaximumSize() der jeweiligen Kindkomponente bedienen.

Jede Komponente hat ihr eigenes Koordinatensystem, d. h. in paintComponent ist (0,0) die obere linke Ecke der Komponente - und die hat eine Größe (s. getWidth(), getHeight()). Wenn Du also in paintComponent zeichnest, muss Dich die endgültige Position nicht interessieren. Darum kümmert sich das Framework, dass paintComponent den passenden Graphics-Kontext bekommt. Die ganze Positionsberechnerei würdest Du dem LayoutManager überlassen.

Ich kann Dir nachher mal ein paar Klassen reinstellen.

Nachtrag:

Wenn Du die Keys nicht als "echte" Swing-Komponenten haben möchtest, sondern einfach nur das Zeichnen in andere Klassen auslagern willst, brauchst Du eigentlich nicht von JComponent ableiten. Wie auch immer: in jedem Fall müsstest Du dann das Keyboard repainten, denn das ist für Swing die Komponente. Man kann auch angeben, welcher Bereich neu gezeichnet werden soll und das entsprechend in paintComponent berücksichtigen.

Bevor ich da jetzt was anfange, wäre die Frage, was Dir lieber ist? Buttons als Swing-Komponenten, oder Buttons nur zeichnen?

 

[Oneixee5]

Die Darstellung von JComponent usw. wird (vereinfacht) über den Layoutmanager geregelt. Man ruft paint oder paintComponent nicht selbst auf, s. dazu: https://www.oracle.com/java/technologies/painting.html#smart u. https://www.oracle.com/java/technologies/painting.html#swing
Einfach in paintComponent irgendwelche JComponent's erzeugen und dann davon paintComponent aufzurufen, habe ich noch nie in einem Programm gesehen. Ich vermute die Key-Klassen werden schon irgendwie gezeichnet, aber an irgendwelchen Koordinaten, wo sie nicht sichtbar oder sofort übermalt werden. Sie werden niemals in irgendein Layout angereiht. Jede JComponent hat ihr eigenes Koordinatensystem, welches bei 0:0 beginnt und ihre eigene Dimension. Der Layoutmanager handhabt dann die relative Darstellung zu anderen Komponenten, sowie u.U. die Größe.

 

[White_Fox]

Hui...das scheint doch etwas schwieriger zu sein als zunächst gedacht.

So grundsätzlich ist das ganze Keyboard-Ding eine einzige Visualisierung. Ich will die bei jedem Tastendruck aktualisieren oder zumindest auf Aktualisierung prüfen. Es wird nicht immer nötig sein, das hängt von den Benutzereinstellungen ab. Wenn die nachzutippende Zeichenkette "АААА ПППП ЯЯЯЯ ИИИИ" lautet, erscheint ständiges Aktualisieren unnötig, sie kann in der höchsten Schwierigkeitsstufe aber auch "АПЁК ЯЧСМ НГШЛ ДЛДЯ" lauten.

Eigentlich war mein Plan, die eigentliche Zeichenarbeit in die Key-Klassen zu verlegen und die Keyboard-Klasse soll das Zeichnen (wo, in welcher Farbe, usw.) lediglich koordinieren. Und damit das Zeichnen nicht zuviel Zeit in Anspruch nimmt, wollte ich nur das neu zeichnen was neu gezeichnet werden muß. Also einzelne Tasten, nicht die ganze Tastatur. Daher habe ich auch die Key-Klassen als JComponent angelegt, aber weiter notwendig ist das nicht unbedingt.

Vielen Dank für eure Hilfe bisher. Ich bin jetzt erstmal etwas ratlos, wie ich das neu strukturiere. Mal schauen und überlegen...

 

[mihe7]

Hui...das scheint doch etwas schwieriger zu sein als zunächst gedacht.

Ne, eigentlich nicht

Die Idee der LayoutManager ist eigentlich recht einfach. Wenn Du Deine Key-Klassen anschaust, hast Du dort eine gewisse Logik für Position und Größe. Der LayoutManager ist einfach die objektorientierte Darstellung davon: ein Objekt, das sich darum kümmert, Position und Größe der Komponenten festzulegen. Warum? Weil der zur Verfügung stehende Platz nicht fix ist. Unterschiedliche Auflösungen, unterschiedliche Fenstergrößen, unterschiedliche Schriftgrößen, ...

die eigentliche Zeichenarbeit in die Key-Klassen zu verlegen und die Keyboard-Klasse soll das Zeichnen (wo, in welcher Farbe, usw.) lediglich koordinieren

Kannst Du machen, dazu musst Du die Key-Klassen aber nicht von JComponent ableiten. Du rufst halt einfach eine Methode auf, der Du den Graphics-Kontext mitgibst.

wollte ich nur das neu zeichnen was neu gezeichnet werden muß. Also einzelne Tasten, nicht die ganze Tastatur.

Kannst Du auch machen. Graphics#getClipBounds ist Dein Freund. Dann musst Du halt ausrechnen, welche Tasten neu gezeichnet werden müssen.

 

[White_Fox]

Die Idee der LayoutManager ist eigentlich recht einfach. Wenn Du Deine Key-Klassen anschaust, hast Du dort eine gewisse Logik für Position und Größe. Der LayoutManager ist einfach die objektorientierte Darstellung davon: ein Objekt, das sich darum kümmert, Position und Größe der Komponenten festzulegen. Warum? Weil der zur Verfügung stehende Platz nicht fix ist. Unterschiedliche Auflösungen, unterschiedliche Fenstergrößen, unterschiedliche Schriftgrößen, ...

Ich denke, ich muß das noch detailierter ausführen. Den LayoutManager wollte ich da gerade nicht benutzen bzw. von den Keys und deren Platzierung schön fernhalten wollen. Ich glaube nicht daß die bestehenden LM das so hinplatziert bekommen, daß es anständig aussieht.

Stattdessen habe ich die Keyboardklasse von JPanel abgeleitet, um eine definierte Fläche zu reservieren, die der LayoutManager auch gerne verschieben könnte. Die Keys zeichnet Keyboard (extends JPanel) in Bezug auf sein eigenes Koordinatensysten. So könnte ich theoretisch auch damit umgehen, wenn der Benutzer die Fenstergröße ändert, allerdings habe ich das momentan nicht implementiert und stattdessen eine Fenstergröße fix vorgegeben.

Ich werde mal damit beginnen, den Vererbungsbaum der Keyobjekte von JComponent zu trennen.

Kannst Du auch machen. Graphics#getClipBounds ist Dein Freund. Dann musst Du halt ausrechnen, welche Tasten neu gezeichnet werden müssen.

Die Tasten herauszufinden, die ich neu zeichnen will, ist sehr einfach: Dafür ist ja die HashMap<String, Key> da. Dann nur noch eine Membervariable, welches Keyobjekt zuletzt angemarkert wurde, und das erste Zeichen aus dem momentan abzutippenden Trainingsstring...

Worüber ich allerdings unschlüssig bin (und was ein Grund für diese seltsame Struktur war): Wo bekomme ich ein Graphicsobjekt her? Die einzige Methode, die ich momentan kenne, ist im Argument der paintComponentmethode. Allerdings müßte das Graphicsobjekt schon ziemlich stark vorparametriert sein, ansonsten würden z.B. die ganzen Koordinatenangaben beim Zeichnen nicht so funktionieren, wie sie es tun.

Mal eine Frage: Würde mir so etwas Probleme bescheren?

public class Keyboard extends JComponent{
    private Graphics graphics;
    
    public void refreshKeyboard(){
        //Male mit dem Graphicsobjekt aus paintComponent herum...
    }
    
    @Override
    protected void paintComponent(Graphics g){
        this.graphics = g; //Halte das letzte Graphicsobjekt vor
        
        //...male Swingkomponente...
    }
    
    
    
}

Geht das so, oder schieße ich mir damit an anderer Stelle ins Knie...?

 

[KonradN]

Die Graphics Instanz dient nur der Nutzung in der paint bzw paintComponent Methode. Wenn Du selbst etwas malen willst, dann kannst Du Dir jederzeit ein Graphics Objekt holen: JComponent::getGraphics

Aber wozu dieser Aufwand? Warum kannst Du nicht den normalen Weg gehen?

Du hast eine Komponente, die das Keyboard darstellen soll. Diese fügst Du dann alls Komponente einer Parent Komponente hinzu per add.
Dann wird, wamm immer notwendig, diese Komponente von Dir dargestellt. Dazu wird in dieser Komponente paintComponent aufgerufen. Diese muss dann das Keyboard malen.
Dazu musst Du entweder in Keyboard das Keyboard malen. Dann wären die Daten dafür in irgendwelchen Klassen, welche keine Swing Controls sind. Sprich: paintComponent geht da alles durch und mal jede Taste selbst (natürlich kannst Du da auch irgend welche Methoden aufrufen, aber das ist egal).

Oder Dein Keyboard ist auch nur ein Container für weitere Controls. Dann nutzt Du die Swing Technologie, bei der jedes Control eine Position und Größe hat. Dafür hat der Swing Container in seiner Methode drin, dass er alle Child Objekte durchgeht, ein neues Graphics Objekt erzeugt speziell für das Child Control (Dann kann es nur seinen Bereich bemalen und das beginnend bei 0,0) um dann paintComponent des Childs aufzurufen und danach das Graphics Objekt zu disposen. (Was die erste Frage von Dir etwas beantwortet, Graphics bietet eine dispose() Methode an)

Letzteres hat den Vorteil, dass Du keine Arbeit mehr hast. Egal, was für einen LayoutManager die Anwendung benutzt: Du bist ja dennoch frei bei der Platzierung innerhalb deines Controls.Daher kannst Du da alles frei setzen wie Du möchtest. Und du kannst nutzen, was Dir Swing bietet wie MouseOver und so.

Klar: kannst Du alles nachbauen, aber das macht nicht wirklich Sinn...

 

[White_Fox]

So...es funktioniert jetzt, sogar ziemlich gut.

Eigentlich ganz einfach – im nachhinein. Vielen Dank euch.