|
java-gnome version 4.0.19 | ||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
Object org.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 |
---|
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 |
---|
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 |