java-gnome version 4.0.19

org.gnome.glade
Class Glade

Object
  extended by org.gnome.glib.Glib
      extended by org.gnome.glade.Glade

public final class Glade
extends Glib

This class is a hyper-thin wrapping of libglade, a library that allows you to transform the XML interface definition files generated by the GNOME User Interface Designers (of which Glade is the original and best known) into live Widgets in your application.

Using libglade is pretty easy. You prepare your user interface in Glade, write some code to load it in, and then extract the particular Widgets that you care about further manipulating.

Since we're stuck with the somewhat stupid name that the underlying library used for the tree of instantiated widgets, we recommend you use a variable name like glade or processedTree for the XML object you get back, perhaps as follows:

 final XML glade;
 final Window top;
 final Button confirm;
 
 glade = Glade.parse("HelpWindow.glade", "window1");
 
 top = (Window) glade.getWidget("window1");
 confirm = (Button) glade.getWidget("button4");
 
If you're wonder where "window1" and "button4" came from, they are the style of names that the Glade designer generates for its Widgets by default. To improve maintainability, you are highly encouraged to change these automatically generated names to ones which corresponds to the variable names being used in your Java code! In other words, something like:
 confirm = (Button) glade.getWidget("confirmButton");
 
These examples do, however, expose the two major structural weaknesses of using Glade: All that said, libglade provides a rapid application development capability par excellence, and is a significant part of almost every GNOME application.

Warning: There has been considerable discussion within GNOME about the state of libglade and it is widely expected that it will be replaced by GtkBuilder within GTK in the very near future. If that occurs before java-gnome 4.2 we will not release Glade to stable. Indeed, that event may well be the trigger to bump to 4.1

Since:
4.0.2
Author:
Andrew Cowie

Method Summary
static XML parse(String filename, String root)
          Parse a Glade interface definition file and create a tree of live instantiated Widgets ready for use.
 
Methods inherited from class org.gnome.glib.Glib
formatSizeForDisplay, getRealName, getSystemConfigDirs, getSystemDataDirs, getUserCacheDir, getUserConfigDir, getUserDataDir, getUserName, getUserSpecialDir, markupEscapeText, reloadUserSpecialDirsCache, setProgramName
 
Methods inherited from class Object
equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Method Detail

parse

public static XML parse(String filename,
                        String root)
                 throws FileNotFoundException
Parse a Glade interface definition file and create a tree of live instantiated Widgets ready for use.

Parameters:
filename - the path to the file containing the XML data generated by a Glade user interface designer. The path is relative to FIXME. A particularly effective Java solution is to put the .glade file on your CLASSPATH and then load the data as an InputStream with ClassLoader's getResourceAsStream(), passing the InputStream to the other form of parse().
root - the name of the Widget whose hierarchy you wish to load. It turns out you can have several Windows and Dialogs in a single .glade file; because of this you normally specify which Window you want to load. Hopefully you renamed it from window1 to something more sensible. You can also specify something lower down such as a ToolBar or VBox if that is all you need to instantiate. If you specify null all Widget hierarchies within the file will be loaded.
Throws:
FileNotFoundException - if the specified .glade file cannot be found or read. Unfortunately, this actually happens quite a lot due to people assuming that the XML data will be loaded from the location of the the source file which calls this method instead of relative to the FIXME place the program is executed from. The problem can certainly be solved using an absolute path for filename, but that isn't going to be portable at all.
Since:
4.0.2


java-gnome