dog.gui is a lightweight, high-performance Java GUI toolkit. It is designed to replace the standard AWT user interface components such as buttons, textfields, and lists.


This page shows an example applet using some of the dog.gui classes.


You can download the jarfile from the link below. If you just get a screenful of text in your browser, try the Save As function (your browser may not understand what a jar is).

dog.gui, version 1.0.1

dog.gui API documentation

Note: this software may contain bugs, and may not be strictly compatible with future development on the package. It is provided in the hope that it may be of some use, and for the purposes of discussion and testing. Please read the API documentation (see link below) and read the notes for a fuller understanding of what I'm trying to achieve here. Also please refer to the licence for redistribution terms.


Toolkit API documentation


My main reason for creating this package was speed and useability. Heavyweight AWT components are slow and require a great deal of native operating system resources. In addition, they provide very limited functionality. Javasoft's alternative, the Swing toolkit, is extremely flexible but still slow and often requires many lines of code to control effectively.


Many of the simpler components, such as buttons, checkboxes, and textfields, are pretty straightforward in their functionality, since they represent simple values (booleans, integers, strings). Other components, specifically lists and choices, represent multiple values. These components are subject to scaleability problems and the need to understand what the values represent.

Swing's standard answer to the latter problem has been to use a model-controller metaphor. While theoretically sound, this has often forced the burden of overcoming the scaleability issues onto the developer, who may not be familiar with toolkit programming. Most Java toolkits use lists in the same way as arrays, where you have indexed values.

In a departure from this tradition, dog.gui uses the concept of an item to represent values in lists, choices, menus, and so forth. The DItem class encapsulates the notion of an object that may have a text label, an icon, and an arbitrary number of named fields. In addition, and possibly most usefully, it has a reference, which is an arbitrary object that can be tagged to the item. This object can be a reference to the actual application object that the item represents in the interface, and is a straightforward and simple way to associated interface elements with application functionality. Items are not components in themselves; they are rendered into component contexts such as lists. This allows the list to become much more scaleable, as it doesn't have the overhead of maintaining components.


I have run several fairly thorough tests on the dog.gui componentry, comparing it against Swing, normal AWT components, and Marimba's Bongo. It has proved to be 2-5 times faster than Swing to construct components, marginally faster to lay them out, and approximately 2 times faster to paint them. AWT components take a longer time to construct and lay out but paint faster. Bongo widgets take longer to construct and lay out but paint at about the same speed. Obviously your own requirements may differ - I welcome you to run your own tests. Note that as new functionality is added to the toolkit (which is constantly) performance statistics may vary.

Look and feel

My goal is to achieve an interface that, if not completely flexible, is blitzingly fast and incredibly simple to use. Most of the components in the toolkit have a look very similar to Swing's default "Java-native" look, in order to conform to these new standards and aid new users in learning to navigate the interface. however, these components don't have a pluggable look or feel, since this introduces an unacceptable performance overhead.

In a few cases, the look differs from the standard Java-native. The two main components are:

  1. DFolder - this looks like a Windows tabbed folder. In my experience no users found the Java-native tabbed folder at all intuitive, and found its colour scheme distracting. If anyone has any comments, i look forward to hearing them.
  2. DScrollbar - this doesn't have the Java-native bumps on the thumb, as i find them visually noisy. Instead I have opted for a small NeXt-like dimple, which can be removed if necessary.
  3. Arrows in various places (scrollbars, choices, etc) are not filled. They fill with a primary control colour when pressed.

Toolkit elements

All components and containers allow you to associate an arbitrary object reference with them.

A theme (DTheme) is used to control the colours and fonts used by an application. I can think of relatively few instances where it is desirable to have different colour schemes for different windows in an application, so this provides a clean focus for a central scheme. You can subclass DTheme to create your own colour and font schemes.

The basic top-level container is the DRootPane - this is an interface implemented by the windows (DFrame, DDialog, DWindow), and the applet (DApplet) that are the only heavyweight components in the interface. All these containers manage the double-buffering required for the contained lightweight components, so you don't need intermediary rendering panes. You can set a background image on the root pane which can be rendered in various ways (tiled, centered, etc). All DRootPanes have a getFrame() method that can be used to return the nearest parent frame for the purpose of constructing dialogs and windows.

You can now associate a tooltip with a component or container. If you do so, and you set the TooltipManager to be enabled, tooltips will be popped up after a specified delay (this defaults to 4 seconds). This means you can globally enable and disable tooltips in your application.

The simple components are:

Checkboxes, buttons, and labels can all be given multiline labels.

There are several text editing components:

The list components:

There are also a number of miscellaneous components:

Known bugs and issues

  1. Popups always use lightweight mode at the moment as there were too many bugs with native windows.
  2. DMenu still doesn't automatically pop up the submenu. I'll get round to it eventually.

knife home page questions, etc