Verzögerung à la Tooltip bei mouseEntered

[Wolfgang Lenhard]

Hi,
ich stehe gerade auf dem Schlauch: Ich möchte für die Buttons einer Anwendung nicht nur Tooltips anzeigen, sondern nachdem die Maus eine gewisse Zeit über dem Button geruht hat, soll schließlich auch eine Audioerklärung starten. Ich habe allerdings keine vernünftige Idee, wie die Verzögerung am Besten zu realisieren ist. Das Audio soll nicht einfach nur verzögert wiedergegeben werden, da sich für die Wiedergabe der Zeiger noch über dem Button befinden soll. Wie prüft man denn am schlausten bei einem MouseEvent, ob sich die Maus nach einer gewissen Latenzzeit noch über dem Button befindet? Wie macht das ein Tooltip?

Viele Grüße und vielen Dank,
Wolfgang

P.S.: Sollte man das über mouseEvent.getComponent() abfangen und prüfen, ob sich x- und y-koordinate des Mauszeigers noch über der Komponente befinden, oder geht es auch einfacher?

 

[Verjigorm]

Maus drüber -> flag setzen
Maus weg -> flag zurücksetzen

Wenn Maus drüber -> Starte Thread, warte x ms, schaue ob flag immer noch gesetzt
Ja -> Spiele Audio
Nein -> Ende

 

[Wolfgang Lenhard]

Ah, ok! Vielleicht ist das wirklich ein praktikabler Ansatz. Ich denke, ich mache ein Singelton, damit der Code-Wildwuchs nicht zu sehr zunimmt. Danke!

 

[Ebenius]

Nur als Ergänzung: An der Stelle bietet sich eigentlich der javax.swing.Timer anstatt eines Threads an.

Ebenius

 

[Verjigorm]

Gibt es irgendwo ne Übersucht Thread vs Timer?
Grad bissl gegoogelt aber nix berauschendes gefunden.
Ich kann mir nie merken, wann und wieso man einen Timer benutzen soltle

 

[Ebenius]

Swing Timer (javax.swing.Timer) benutzt man, wenn billige GUI-Änderungen verzögert oder wiederholt GUI-Inhalte ausführen möchte. Der Action Listener wird vom EDT aufgerufen. Klassischer Anwendungsfall wäre: [HIGHLIGHT=Java]final String[] waitTexts = { "Hold on .", "Hold on ..", "Hold on ..." };
final JLabel waitLabel = new JLabel(waitTexts[0]);
new javax.swing.Timer(500, new ActionListener() {

int textIndex = 0;

@Override
public void actionPerformed(ActionEvent e) {
waitLabel.setText(waitTexts[++textIndex % waitTexts.length]);
}
}).start();[/HIGHLIGHT]
Ebenius

 

[Verjigorm]

Also ich spare mir quasi das invokeLater, welches ich in einem Thread benutzen würde um GUI-Elemente aus dem Thread raus zu verändern?

 

[Ebenius]

Also ich spare mir quasi das invokeLater, welches ich in einem Thread benutzen würde um GUI-Elemente aus dem Thread raus zu verändern?

... und Du sparst Dir einen extra Thread, was ganz sicher nicht zu verachten ist.

Ebenius

 

[Verjigorm]

Hm ich bin davon ausgegangen, dass Timer intern auch einen Thread benutzt

 

[Illuvatar]

Ah, ok! Vielleicht ist das wirklich ein praktikabler Ansatz. Ich denke, ich mache ein Singelton, damit der Code-Wildwuchs nicht zu sehr zunimmt. Danke!

Ähm... das ist selten zu empfehlen. Siehe zum Beispiel hier:
http://www.java-forum.org/java-basics-anfaenger-themen/80294-singleton-diesem-fall-sinnvoll.html

 

[Ebenius]

Hm ich bin davon ausgegangen, dass Timer intern auch einen Thread benutzt

Genau einen. Den EDT.

Ebenius

 

[Gast2]

Soviel ich weiß ist der ToolTipManager auch ein Singleton...

 

[tfa]

Genau einen. Den EDT.

Und den, der in javax.swing.TimeQueue gestartet wird. Wie soll das auch nur mit einem funktionieren?

 

[Ebenius]

Und den, der in javax.swing.TimeQueue gestartet wird. Wie soll das auch nur mit einem funktionieren?

Hab mich blöd ausgedrückt. Es wird halt für alle Swing Timers nur eine einzige Instanz der TimerQueue verwendet.

Ebenius

 

[Wolfgang Lenhard]

Vielen Dank für den Hinweis auf die Timer-Klasse, die wirklich einen Blick wert ist.

Zur Singleton-Problematik: Ich sehe hier ehrlich gesagt keine Alternative. Ansonsten könnte es sein, dass mehrere Erklärungen gleichzeitig abgespielt werden. In einer Singleton-Klasse lässt sich das prima handhaben: Entweder wird ein laufender Sound abgebrochen, wenn ein neuer gestartet werden soll, oder es wird kein neuer gestartet, falls gerade noch einer läuft. Ist ja im Grunde das gleiche wie bei den Tooltips: Da ist stets nur einer sichtbar.
Design-Fragen sind in diesem Fall für mich offen gesagt eher nebensächlich, da der Anwender nicht die Schönheit des Codes sondern die Handhabbarkeit des Programms bewertet.

 

[Wildcard]

Geht es hier um Accessibility? Wenn ja, warum verwendest du nicht die built-in Accessibiltiy?

 

[Wolfgang Lenhard]

Was meinst Du genau?

 

[Wildcard]

Na für mich hört sich das nach Support für Menschen mit zB Sehbehinderung an und da würde ich nicht das Rad neu erfinden.

 

[Wolfgang Lenhard]

Ach so. Ja, das wäre ein gutes Beispiel. Im konkretenb Fall geht es um Software für Kinder in der Schuleingangsphase und für leistungsschwache Kinder in der Grundschule, die noch nicht unbedingt lesen können. Es ist ein Programm zur Therapie von Dyskalkulie.

 

[Wildcard]

Nun, ich weiß nicht ob da ganz spezielle Anforderungen gegeben sind, aber durch Java Accessibility besteht eben schon die Integration an den Accessibility Layer des Betriebssystems (Screenreader und der Gleichen).