|
java-gnome version 4.0.15 | ||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | ||||
Objectorg.gnome.glib.Glib
org.gnome.glade.Glade
public final class Glade
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:
ClassCastException (or worse a segmentation fault) if you get
it wrong.
parse() and
getWidget() calls are tightly coupled to the textual names
created in the Glade program. If you refactor your Java code,
sooner or later you will forget to change the corresponding names in the
.glade files, which will inevitably lead to confusion down the
road.
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
| 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 |
|---|
getRealName, getSystemConfigDirs, getSystemDataDirs, getUserCacheDir, getUserConfigDir, getUserDataDir, getUserName, getUserSpecialDir, reloadUserSpecialDirsCache, setProgramName |
| Methods inherited from class Object |
|---|
equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Method Detail |
|---|
public static XML parse(String filename,
String root)
throws FileNotFoundException
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.
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.
|
![]() java-gnome |
||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | ||||