6. Swing Client GUI development

6.1. Introduction

Having written new devices in Java and created instances of them on the server, they can now be examined and controlled from the interactive Jython interpreter. However, the GDA also allows developers to build custom graphical components for direct interaction with the server-side devices. These custom GUI components can be added to the core GDA client. This mechanism allows for a much more flexible means of examining and controlling new devices.

The process of extending the GDA client in this way requires two development steps:

• Writing the GUI component (currently in Swing)
• Setting up the communication between the client-side GUI component and the server-side device

These processes will be illustrated using an example of a simple power supply device, which has two states: ‘On’ and ‘Off’.

6.2. Writing the Swing GUI component

All custom GDA GUI components must extend the GDA class AcqusitionPanel (in the uk.ac.gda.core plugin, package gda.gui). This enables correct behaviour of the new component in the GDA client, and enables some of the components of client-server communication.

The example power supply GUI component extending AcquisitionPanel is in the documentation src tree, org.myls.gda.gui.PowerSupplyPanel. It comprises two JButtons, ‘On’ and ‘Off’. Its behaviour is to toggle the state of the server-side power supply between the two states using the buttons. When the state of the underlying power supply is ‘Off’, the ‘Off’ button is disabled, and the ‘On’ button enabled. Clicking on the ‘On’ button changes the state of the server-side power supply to ‘On’ through CORBA-implemented client-server communication. The GUI component is registered as an observer of the power supply, and responds to any changes in state of the server-side device. In this example, the state of the server-side power supply has been changed by the user. The GUI component responds to the changed state by disabling the ‘On’ JButton, and enabling the ‘Off’ button.

This behaviour is implemented in GDA using the Observer and Observable interfaces. The PowerSupplyPanel registers itself as on Observer of the server-side power supply, which sends changes in state back to the PowerSupplyPanel.

A standalone application which wraps the PowerSupplyPanel component is org.myls.gda.gui.PowerSupplyTestFrame, and can be run from the command line or from within Eclipse.

Appearance of the PowerSupplyPanel when the power supply is in state ‘Off’:

Clicking the ‘On’ button changes the state of the remote power supply to ‘On’. This change is detected by the client-side panel, which updates to the stet below:

6.3. Adding the new component to the GDA client

The new GUI component is added to the GDA client by defining an instance of it the Spring beans configuration file ‘client_beans.xml’ in the documentation/xml directory. This configuration file is for including custom (non-core GDA) components to the GDA client. (Another client configuration file, ‘client.xml’, is used to define which of the predefined GDA graphical components to include in the client.)

The ‘client_beans.xml’ configuration file is a Spring beans container, and follows the Spring beans XML schema. The bean definition for the PowerSupplyPanel is:

<bean id='powerSupplyPanel' class='org.myls.gda.gui.PowerSupplyPanel'>
   <property name='name' value='gdaPowerSupplyPanel1'/>
   <property name='psuName' value='gdaPowerSupply1'/>
</bean>

The new view appears in the GDA client as the panel ‘gdaPowerSupplyPanel1’.

6.4. CORBAising the object

See the corba manual next to this file for more specifics.

6.4.1. Writing the CORBA classes for GUI–server communication

Several generic CORBA classes are provided which external developers can extend. These include CORBA adaptors, Impl classes, and base classes.

6.4.2. Creating CORBA proxies for client-server communication

The new device is now available on the server and can be controlled from the Jython interpreter in the Scripting Terminal view. For example, scannable objects can be scanned, and the result of the scan displayed automatically in plot window.

However, it may the case that specialised GUI panel needs to be developed to control and simply the new device. In that case, communication must be set up between the client (GUI) and the object on the server. In GDA, this communication is CORBA-based.

CORBA proxies for custom devices are built using the Ant target ‘make-corba-jar’. This target calls ‘compile-corba-classes’, which in turn calls ‘compile-idl-definitions’. This invokes a CORBA idl2java compiler, in this case org.jacorb.idl.parser’.

Therefore, for each custom device that has been written, it is also necessary to define an IDL for that class.

An example of an IDL for a simple power supply device is:

Module org {
Module myls {
Module gda {
Module device {
Module powersupply {
Module corba {

interface CorbaPowerSupply
{
    void setOn(in Boolean on);
    boolean getOn();
};};};};};};};

The name of the resulting CORBA proxy implementation is based on the name of the device class. The convention is new name = old name, lowercased apart from first letter + ‘Impl’. For example a device class called ‘PowerSupply’ has a CORBA proxy generated with name ‘PowersupplyImpl’.