SwingAppKit is a complete swing framework for building desktop applications. It includes dialog management, preferences, XML application descriptor for menus, popups, toolbars..., various prefedefined dialogs (about, help, tip of the day...), some swing utilities.
The following applications are based on this framework : EditiX (an XML Editor and XSLT Debugger), XFlows (an XML workflow), UniMailer (a mail client)
1. Dialog Management
2. Preferences
3. Wizard
4. Application Descriptor
5.
Application Model
6.
Tools
The main part is the DialogManager class. With the DialogManager you can show easily your dialog in a modern style
The main method is the showDialog, with this method, it will display your content pane inside a modal dialog. As any dialogs, various actions like Ok, Cancel are available, you can know the last pressed action with the returned value of the showDialog method. For sample for detecting the Ok action, the value is equals to DialogManager.OK_ID.
In the following sample, we display a button in a dialog content for a size of 500 x 500, we force the screen center location using the setAutoCenter method.
package dialogs; |

Automatically the user interface content takes all the space in dialog, this is due to an hidden usage of a BorderLayout. Note that most of the time, you will not put directly your component (like a button) but rather you will put a complete panel.
A dialog box is divided in three parts :
- The header (Main title in bold, comment and one icon)
- The UI part (this is your interface)
- A footer (with the action part : Ok, Cancel...)
You can manage (add,remove...) the dialog actions (ok, cancel...) using a DialogActionModel. When it is not specified, the DialogManager includes a default model with the Ok and Cancel actions. An action is a standard class implementing the swing javax.swing.Action interface.
In the following sample, we add a custom action with the class CustomDialogAction :
package dialogs; |

Our action is stored inside the default action model. Note that putting it inside the default model will make it visible for all the next dialogs, that's why we remove it at the end. The interface ClosingAction is for helping the dialog manager to know if the dialog must be closed or not with this action, if you don't implement this empty interface, the dialog will not be closed.
We can also build our own action model, but we must add too the Ok or Cancel actions if required. Here a sample :
package dialogs; |
We build an action model using the DialogActionModel class and we report it to the DialogManager inside the showDialog method.
Using the DialogManager you can replace :
- The default dialog header, you must in this case implement the DialogHeader interface and call the setDefaultDialogHeader(java.lang.Class) method
- The default dialog footer, you must in this case implement the DialogFooter interface and call the setDefaultDialogFooter(java.lang.Class) method.
- The default action model, you must in this case called the setDefaultDialogActionModel(com.japisoft.framework.dialog.actions.DialogActionModel) method.
- The default icon, you must in this case call the setDefaultDialogIcon(javax.swing.Icon) method.
You can work without the DialogManager creating another dialog class. Here a sample, this dialog has one Ok button.
package dialogs; |

In this sample, we inherit from the BasicOkDialogComponent class. This class is a complete dialog box with an Ok dialog action. We use the setUI method for setting the user interface. Note that you musn't use the getContentPane() or the add method as for a traditional JDialog usage.
When making visible such dialog, the method getLastAction give the last dialog action called (like Ok, Cancel...)
If you wish to have both the Ok and Cancel dialog actions, you must inherit from the BasicOkCancelDialogComponent.
If you wish to use other actions, you can also modify the actions model by overriding the method prepareActionModel (from the BasicOkDialogComponent...) or by using the DialogManager and its default action models.
/** Defining the dialog actions */ |
A preference is a way to let the user changing a part of the configuration. When building your code, you need to know the user choice, for colors, font, int... values, all is available from the Preferences class. This class contains a lot of static methods for getting a value that the user may have changed.
A preference is divided in two parts :
- The group : this is a collection of preferences
- A preference name
All the preferences are stored inside the home directory/.The application config name. The application name is defined by the ApplicationModel.SHORT_APPNAME value. For instance if the name is "simple" the user choices will be stored in his personal account home/.Simple.
Here a sample
package preferences; |
In this sample there're two preferences : pref1 and pref2 from the test1 group, so each value can be changed by the user with the preferences dialog box.
The preferences are loaded automatically for the first usage, if you change a value, you need to save it at the end of your application by calling the savePreferences method because all is managed in memory.
For displaying the preferences dialog box, you can use such code sample :
package preferences; |

The wizard is a way to propose to the user several steps for building an application element.
All is managed from the JWizard class. This class contains a set of wizard step. A step is the interface part that will evolve during the wizard usage. All the steps are stored inside a WizardStepModel. In a step you must specify a title, a short title, a long title and comment and the user interface component like a JPanel instance. You can use a basic step with the BasicWizardStep class.
Here a sample of usage :
package wizard; |

The application descriptor is an XML document for building menus, popups, toolbars and set of actions. All is managed by the InterfaceBuilder class. This class builds all the required elements from an XML descriptor.
The XML descriptor has the following elements :
- a <root element> (can be any names) :
Attributes :
icon : application icon path from the classpath
- <menuBar> : set of menus
- <menu> : part of the <menuBar>
Attributes :
id : required, the menu identification
- <item> : part of the <menu>, <toolBar>, <model> or <popup> elements.
Attributes :
id : required, a unique id
group : a group name
- <itemRef> : can replace the <item> element
Attributes :
ref : A reference to an existing id.
- <ui> : part of the <menu> or <item> element
Attributes :
label : label of the item
mnemonic : character mnemonic for underline the good label part
help : A tooltip
icon : An icon path from the classpath
shortcut : An item shortcut, note you needn't to include a control key, it is added automatically
enabeld : true or false
- <action> : Part of the <item> element
Attributes :
class : Required, a java action class (compatible with the javax.swing.Action interface)
- <toolBar>
Attributes :
id : Required, a toolBar id.
floatable : false or true
- <separator/> : Part of a <menu> or <toolBar> or a <popup>
- <popup>
Attributes :
id : Required, a popup id
- <model>
Attributes :
id : Required, a model id
Here a sample of descriptor :
<!-- Here a simple application descriptor with one menubar, one toolbar and one popup -->
<test icon="descriptor/images/app.png">
<!-- Test of simple menu bar -->
<menuBar>
<!-- Simple menu content -->
<menu id="file">
<ui label="File" mnemonic="F"/>
<item id="openFile">
<ui help="Open a file" label="Open..." icon="descriptor/images/open.png"/>
<action class="descriptor.actions.OpenAction"/>
</item>
<separator/>
<item id="quit">
<ui help="Quit all" label="Quit" shortcut="Q" icon="descriptor/images/quit.png"/>
<action class="descriptor.actions.QuitAction"/>
</item>
</menu>
<!-- Simple menu content -->
<menu id="other">
<ui label="Other" mnemonic="O"/>
<item id="openFile2">
<ui help="Open a file" label="Open..." icon="descriptor/images/open.png" enabled="false"/>
<action class="descriptor.actions.OpenAction" enabled="false"/>
</item>
<!-- sub menu -->
<menu id="other2">
<ui label="Other2"/>
<item id="quit2">
<ui help="Quit all" label="Quit" shortcut="Q" icon="descriptor/images/quit.png"/>
<action class="descriptor.actions.QuitAction"/>
</item>
</menu>
</menu>
</menuBar>
<!-- Test of a simple toolBar -->
<toolBar id="mainToolBar">
<itemRef ref="openFile"/>
<separator/>
<itemRef ref="quit"/>
</toolBar>
<!-- Test of a simple popup -->
<popup id="mainPopup">
<itemRef ref="openFile"/>
<separator/>
<itemRef ref="quit"/>
</popup>
<!-- Test of a simple action model -->
<model id="mainModel">
<itemRef ref="openFile"/>
</model>
</test>

Here a code sample for using this descriptor :
package descriptor; |
Note that your application must have a short name with the
ApplicationModel.SHORT_APPNAME value.
For finding the application descriptor we use the application classpath, here the URL of the application descriptor is accessed relativly to our application location using the getResource method. Once the descriptor is read, we can access to the menu bar by calling the getMenuBar method, this is similar for the toolbar with the getToolBarById method and for the popup and the bound getPopup method.
As the application descriptor works with standard swing actions, you may also create your own code for creating action, supposing your actions are stored in a database etc.. You must in this case implement the ActionBuilder interface. Your class will be a kind of delegate for building each action instance and must be provided inside the constructor of the InterfaceBuilder class.
Here a code sample :
package descriptor; |
All the action instances are available inside the ActionModel class. You can for instance retrieve an action, activate it and disable/enable. You have also various methos for popup, toolbar and model access from the InterfaceBuilder.
The SwingAppKit includes too an application framework that can be use outside the scope of a swing application. This is a mecanism for building in a clean way your application. For the concept, your application starting is divided in a set of steps. Each step is managed by the ApplicationMain class. A step is stored inside the ApplicationModel. A step is a task that must be runned when starting the application, it can be anything, like showing a splashscreen, setting the current lookAndFeel, defining the application interface content... Once the model is full of steps, you only have to call the start method of the ApplicationMain, when terminating your application, you must call the stop method from the ApplicationMain class, then each step that needs it, will dispose its resource.
Here a sample of code working work various steps
// Add a splashscreen |
The following steps are predefined :
com.japisoft.framework.step.InterfaceBuilderStep : Use an XML descriptor for building the menubar, toolbar...
com.japisoft.framework.step.LookAndFeelStep : Set the application lookAndFeel. By default use the system one.
com.japisoft.framework.step.SplashScreenApplicationStep : Add a splash screen, if the application logo is not specified it is loaded from the ApplicationModel.APP_IMG_PATH property.
com.japisoft.framework.step.ClassInstanceStep : Create an instance for a particular class.
There're also some properties inside the ApplicationModel class you should defined for your application, some properties are used by some predefined dialog box.
/** The application full name */
LONG_APPNAME = null;
/** A short application name. This is used for the user home directory name */
SHORT_APPNAME = null;
/** A build version */
BUILD = "010105";
/** A major version number */
MAJOR_VERSION = 1;
/** A Minor version number */
MINOR_VERSION = 0;
/** A Sub minor version number */
SUBMINOR_VERSION = 0;
/** A Beta version number */
BETA_VERSION = 0;
/** Main contact for email support */
MAIN_SUPPORT_EMAIL = null;
/** Registered file name */
REGISTERED_FILE = null;
/** URL for reporting a problem */
REPORTING_URL = null;
/** Main application descriptor */
USERINTERFACE_FILE = null;
/** File for generating a documentation */
AUTODOC_FILE = "autodoc.xsl";
/** Path (classpath) for an application logo image */
APP_IMG_PATH = null;
Here a code sample :
// Short name, required for saving preferences |
Note that most path are working from the classpath, thus you can deploy your application with one jar very easily.
There's some predefined dialogs :
The about dialog : You can invoke it with the AboutAction class (this is a swing action, you can put it in an XML descriptor) or using the AboutDialog.
The tip of the day dialog : You can invoke it with the TipOfTheDayAction class (this is a standard swing action) or using the dialog TipOfTheDayDialog. All the tips must be stored in a tips path available from your classpath. Each tip is available in an HTML file call tip1.html, tip2.html ... The first line of each tip file is the tip name.

The manual is available with the ManualAction class or using the ManualDialog dialog box. The manual is an HTML document located with an URL inside the ApplicationModel.DEF_MANUAL_PATH property.

You have also accessed to various components like a Gradient panel or a TextField for choosing a file :
Here a code sample for usage :
package tools; |
© 2006 JAPISoft - http://www.japisoft.com 17/05/06