Improving i18n Support in FEST-Swing

DZone 's Guide to

Improving i18n Support in FEST-Swing

· Java Zone ·
Free Resource

FEST-Swing is a Java library, released under Apache 2.0 license, that provides a fluent interface for functional Swing GUI testing. Under the covers it uses the AWT Robot to generate native input events, which is the most reliable way to simulate a user interacting with an application (IMHO.) For example, the following code:


will enter the text “hsolo” in the text field with name “username” in a login dialog. FEST-Swing will actually generate native key presses when entering such text. In order to achieve this, we need a mapping between the character to enter and the code of the key to press, as well as any modifiers (e.g. shift key.) These mappings are specified as implementations of the interface KeyStrokeMappingProvider. For example, KeyStrokeMappingProvider_en specifies the following mappings for the English language:

mappings.add(mapping('a', VK_A, NO_MASK));
mappings.add(mapping('A', VK_A, SHIFT_MASK));

These mappings indicate that the character ‘a’ is mapped to the key ‘A’ (VK_A) with no modifiers, while the character ‘A’ is mapped to the keys ‘A’ and ‘Shift.’

In versions 1.1 and 1.2-alpha3, FEST-Swing tries to pick up the correct KeyStrokeMappingProvider based on the language of the default locale (e.g. KeyStrokeMappingProvider_en for German.) If one cannot be found, it will fall back to KeyStrokeMappingProvider_en.

Users can also specify their own KeyStrokeMappingProvider as follows:


The Problem

This feature, even though is pretty flexible, has raised some issues:

  1. Character mappings not only depend on language, but also on operating system
  2. It’s not easy for users to create their own KeyStrokeMappingProvider for languages not supported in FEST-Swing

Since I don’t have enough resources to support multiple languages and operating systems, it is very difficult for me to provide more implementations of KeyStrokeMappingProvider.

The Solution

Olivier DOREMIEUX, a FEST-Swing user, found a brilliant solution for the problems mentioned above (to be included in the next release, FEST-Swing 1.2rc – by the end of April.)

He found that character mappings also depend on operating system, not only on locale. Now FEST-Swing will try to find the correct KeyStrokeMappingProvider based on operating system and the default locale. For example, if the operating system is Windows and the locale is DE, FEST-Swing will try the following, one by one, until it succeeds:

  1. use the OS family, country and language: KeyStrokeProvider_win_de_de
  2. use the OS family and language: KeyStrokeProvider_win_de
  3. use the language only: KeyStrokeProvider_de
  4. use the default one: KeyStrokeProvider_en

For the second problem, Olivier proposed two solutions:

  1. Allow users to specify a text file containing the character mappings
  2. Provide a tool for creating such file

For the next release (by end of April,) FEST-Swing will allow users to parse text files containing character mappings in the format [CHARACTER, KEY_CODE, MODIFIER_MAPPING], one mapping per line. For example:


(please note that the key code does not need to use the prefix “VK_”)

To use a mapping file, users will simply need to do the following:

KeyStrokeMappingsParser parser = new KeyStrokeMappingsParser();
KeyStrokeProvider provider = parser.parse("myMappings.txt"); // there is also an overloaded version that takes a File

To make creation of mapping files easier, I put together a little application that records all the entered keystrokes and saves them in a text file:

This application is currently available via Java Web Start. It requires access to the file system to save mappings files.

I expect to have an installer by the time of the release.

Thanks Olivier!

Feedback is always welcome :)

From http://alexruiz.developerblogs.com/?p=1102


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}