Jadice Viewer - Fokus Reihenfolge der Bedienelemente
Inhaltsverzeichnis
Einleitung & Motivation
Dieser Artikel zum jadice viewer® gibt ein Überblick, wie die Fokus Reihenfolge der Viewer Bedienelemente bestimmt werden kann.
Der Artikel richtet sich an Integratoren, die aufgefordert sind, bestehende wie auch neue Anwendungen zugänglich zu gestalten.
Das hier beschriebene Konzept ermöglicht die Umsetzung von tastaturbedienbaren jadice viewer Integrationen. Sowohl die reine Tastaturbedienung als auch, die Verwendung von assistiven Technologien, wie Screenreader können dadurch ermöglicht werden. Nach unserer Erfahrung ist es wichtig und nachhaltig keine Unterscheidung der Anwendergruppen in der Umsetzung zu realisieren. Wir empfehlen, eine einheitliche Lösung für alle Anwendergruppen anzustreben. So profitieren sowohl Personen mit motorischer Einschränkung, teilweiser oder vollständiger Sehbeeinträchtigung, als auch Power-User von den hieraus abgeleiteten Lösungen.
Nachfolgend werden dafür erforderliche Konzepte und Code Beispiele erklärt.
Focus Traversal Policy
In Swing gibt es die Möglichkeit, mittels der Tastatur mit einzelnen Bedienelementen zu interagieren. Voraussetzung für die Interaktion mit einem gewünschten Bedienelement ist, dass dieses Element den Fokus hat. Dabei kann immer nur ein Bedienelement der GUI den Fokus erhalten.
Eine Focus Traversal Policy bestimmt die Reihenfolge, in welcher die Bedienelemente den Fokus erhalten. Jede Swing-Komponente besitzt eine Default Focus Traversal Policy. Je nach Lokation der Swing Komponente in der Swing-Komponenten-Hierarchie ergibt sich daraus die Fokus Reihenfolge der Anwendung. Dieses Standardverhalten kann durch das Implementieren einer eigenen FocusTraversalPolicy
verändert werden.
Eine FocusTraversalPolicy berücksichtigt nur Bedienelemente, die einen Fokus erhalten können. Das heißt, zunächst muss sichergestellt werden, dass die gewünschten Bedienelemente fokussierbar sind.
Swing sieht für Komponenten die .setFocusable(true)
Methode vor.
jadice® bietet mittels des Action & Command Framework die Möglichkeit, alle Menubar-Komponenten fokussierbar zu machen. Dazu muss in der verwendeten menucomponents.properties, bzw. dessen internationalisierte Variante, folgende boolsche Einstellung gesetzt werden:
enable.focussability.for.nonfocussable.components=true
Nachfolgend finden Sie eine kleine Beispielanwendung für eine eigene FocusTraversalPolicy
(siehe Abschnitt „Beispielimplementierung für eine FocusTraversalPolicy“).
Weitere Informationen zum Thema FocusTraversalPolicy finden Sie hier: https://docs.oracle.com/javase/tutorial/uiswing/misc/focus.html#customFocusTraversal
Focus Traversal Policy in jadice®
Es gibt grundsätzlich zwei Vorgehensweisen, über die der Zugriff auf die Swing-Komponenten erfolgen kann.
- Zum einen kann die Referenz für die Komponenten vorgehalten werden, wie es auch in der „Beispielimplementierung für eine FocusTraversalPolicy“ der Fall ist. Hierbei müssen die einzelnen Komponenten für externe Zugriffe via API aufrufbar sein.
- Zum anderen gibt es die Möglichkeit über das Traversieren der Swing Komponenten Hierarchie mittels Identifier auf die Komponenten zuzugreifen.
In den nachfolgenden Abschnitten wird die zweite Vorgehensweise näher erläutert.
Identifizierung der Swing-Komponenten
Ist der externe Zugriff auf Swing-Komponenten aufgrund ihrer Sichtbarkeit via API nicht möglich, machen wir uns eine Eigenschaft der jadice® Implementation zunutze. Wir verwenden Informationen, die uns über den AccessibleContext der jeweiligen Komponente bereitgestellt werden. Im Besonderen nutzen wir die über die jadice Implementation bereitgestellte Eindeutigkeit des AccessibleName
(In Sonderfällen kann der Accessible Context auch integrationsseitig überschrieben werden, die Eindeutigkeit des gewählten Namens obliegt in diesem Falle dem Integrator). Zu beachten ist dabei, dass der AccessibleName
abhängig vom verwendeten Locale ist.
AccessibleName aus den Action & Command Framework Dateien
Für die nachfolgend beschriebene Identifizierung der Swing-Komponenten, wird der verwendete AccessibleName aus den Property Dateien des Action & Command Framework genutzt. In der actions.properties
Datei wird der Name einer Action spezifiziert. Der dort verwendete Name der Action wird über die jadice implementation zu einem AccessibleName überführt. Anhand des Action Name bzw. des AccessibleName kann bei der Traversierung der Swing-Komponenten-Hierarchie die gesuchte Komponente identifiziert werden. (Siehe Abschnitt "Erstellung der Policy anhand der Action Names")
Nachfolgend ein Auschnitt einer actions.properties
Datei, bei der der Action Name "Document drucken"(Zeile: 2) ausgelesen werden kann.
Der Action Name, bzw. Accessible Name kann wiederum im nachfolgend dargestellten "Erstellung der Policy anhand der Action Names" verwendet werden.
Im Beispiel "Erstellung der Policy anhand der Action Names" wird gezeigt, wie durch das Hinzufügen der Accessible Names in das String Array die Fokusreihenfolge definiert werden kann. Die dort definierte Reihenfolge entspricht der Reihenfolge, mit der die Swing-Komponenten den Fokus erhalten.
AccessibleName aus dem Annotation Profil
Im Falle der AnnotationsToolbar, die dynamisch anhand des verwendeten Annotationsprofil erstellt wird, kann der AccessibleName aus dem Annotationsprofil ausgelesen werden (siehe Codebock "Auszug aus dem default-annotation-profile.xml"). Hierfür muss der Wert des attributes name (@name="Line") als AccessibleName verwendet werden (siehe Zeile 1).
Swing Komponenten Hierarchie Traversal
In Swing sind die einzelnen Komponenten in einer Hierarchie, die einer Baumstruktur entspricht, enthalten. Wenn man beispielsweise angefangen beim Wurzelelement der Swing Hierarchie beginnt, durch die Elemente zu traversieren, kann man mittels des zuvor erwähnten AccessibleNames alle Elemente in dieser Baumstruktur wiederfinden. Ein Beispiel, wie so etwas angegangen werden kann, wird im Abschnitt "Beispiele" gezeigt. Wir verwenden im Beispiel dabei AtomicReferences (siehe https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicReference.html), um später Zugriff auf das Originalobjekt zu erhalten.
Integrationsmöglichkeit der eigenen Focus Traversal Policy
Nachfolgend wird beschrieben wie die erstellte Focus Traversal Policy Integriert werden kann. Es wird auch auf das Verändern des Standard FocusTraversalKey eingegangen.
Setzen einer Focus Traversal Policy
Um eine FocusTraversalPolicy zu setzen, muss man nur die Policy auf der gewünschten Komponente setzen. Werden in der selben Hierarchie mehrere Komponenten mit einer Policy besetzt, so werden bei einem FocusTraversal diese Policies zunächst ignoriert. Wenn man die Beachtung dieser Policies wünscht, so kann man wie in dem gezeigten Beispiel es als PolicyProvider markieren. Dann wird bei einer Suche dessen Policy ebenfalls zur Anwendung kommen, falls diese Komponente zurückgegeben wird bei einer Suche (Next/First/Last Component).
Eigene FocusTraversalKeys verwenden
Standardmäßig wird TAB
verwendet, um bei der Komponente einen Fokuswechsel zur nächsten zu bewirken. Dies kann man durch das Setzen eigener Keys überschreiben. Über ein Boolean kann dabei gesteuert werden, ob die Komponente die Events des gesetzten Keys normal verarbeiten soll oder nur einen Fokuswechsel bewirken soll.
Möglichkeiten und Grenzen
Zuvor wurde die Vorgehensweise beschrieben, bei der Anhand des AccessibleNames Komponenten während der Traversierung der Swing-Komponenten-Hierarchie aufgefunden und für eine FocusTraversalPolicy verwendet werden können. Diese Vorgehensweise ist nicht in allen Fällen anwendbar, weshalb nachfolgen Besonderheiten und Grenzen aufgezeigt werden.
Dynamische Komponenten
Bei der Konstruktion einer Focus Traversal Policy muss man bestimmten dynamischen Komponenten besondere Beachtung schenken. Mit dynamischen Komponenten sind hier Komponenten gemeint, die dynamisch anhand von äußeren Faktoren wie beispielsweise einem gesetztem Annotationsprofil erzeugt werden. Ebenfalls können bestimmte Eigenschaften von Komponenten wie beispielsweise visuelle Sichtbarkeit oder ob die Komponente deaktiviert ist, eine Relevanz bei der Reihenfolge des Fokus haben. Diese müssen bei einer Policy je nach gewünschtem Verhalten gesondert beachtet werden.
Overlays
Zum Beispiel die Annotationseditoren, das GalleryNavigationTool und die RolloutSearch unterstützen die in diesem Artikel Konzepte für die Tastaturbedienbarkeit momentan nicht. Wenn Sie diese dennoch in Ihrer Integration mit dem hier beschriebenen Konzept Verwenden wollen, stehen wir Ihnen gerne beratend zur Seite.
Fehlende AccessibleNames
Wenn eine Swing/AWT Komponente keinen AccesibleContext oder AccessibleName vergeben hat, kann dies die Identifizierung eines entsprechenden Elements in dem Ansatz mit der Traversierung, erschweren. In diesem Fall müssen wahlweise andere Eigenschaften (AccessibleContext) einer Komponente vergeben werden, die diese in dem Hierarchiebaum eindeutig identifizierbar machen oder aber auf den Ansatz mit dem Halten von Referenzen auf die Objekte ohne Traversierung ausgewichen werden.
Externe Frames
Bei einer komplexen Anwendung kommt es häufig dazu, dass ein sekundärer Dialog oder Frame zum Einsatz kommt. Da dieses Frame oder dieser Dialog nicht Teil der Hierarche des Hauptfensters ist, muss dieses ebenfalls eine eigene Policy mitbringen, die den Fokus steuert. Wichtig ist dabei auch den Übergang zwischen den Frames zu beachten. Soll beispielsweise dem neuen Fenster Fokus gegeben werden, muss man mit requestFocus()
und gegebenenfalls toFront()
im Voraus das Fenster in den Vordergrund rücken. Ob ein Fenster den Fokus letztendlich bekommt, kann jedoch je nach Betriebssystem anders gehandhabt werden und die Priorität des Fensters spielt ebenfalls eine Rolle.
Hierarchie Listener
Bei manchen Swing/AWT basierten Anwendungen kann es zu einer Änderung der Swing-Hierarchie kommen. Wird eine FocusTraversalPolicy verwendet, muss diese auf derartige Änderungen eventuell reagieren müssen, je nach Anwendungsfall. Diesem Effekt kann mit einem HierarchyListener (siehe https://docs.oracle.com/javase/8/docs/api/java/awt/event/HierarchyListener.html) begegnet werden.