A special data type is the object, which is often a widget, i.e. an
area on screen which is part of a GUI, e.g. a label, button etc.
In Glib-based libraries, all objects are derived from the base class
GObject. These are handled specially in following ways:
- Method Invocation
- When you call a method on an object, e.g. win:set_title(), then
a function name is constructed from the object's type and the method
name, in this case gtk_window_set_title().
- Reference Counting
- GObjects have reference counts, which are generally managed automatically
by LuaGnome so you don't have to worry about them. In some corner cases
you may have to think about it, mostly that you keep a Lua proxy object
around until the referenced object isn't required anymore.
- Additional Methods
- Some operations on objects are handled through C macros, which are not
available - only functions are. Therefore, a few extra methods are
defined:
- lg_get_type(): returns the name of the object's class. It is not
named get_type(), because this would hide other functions
by this name, e.g. cairo.surface_get_type().
- Data Storage
- Each Lua proxy object (a userdata) can store arbitrary key/value pairs
in its environment, which is a regular Lua table attached to such proxy
objects. As long as you keep the proxy object, this data is retained, even
if this is an argument to a callback - the same proxy object will be
reused, and retains the data.
- Access to structure fields
- Any GObject and derived objects have an underlying C structure; all the
fields can be read and written by simply accessing them just as you would
for a Lua table.
- Type casting
- It is possible to cast a type to another by using the function
gnome.cast, e.g. when you have a GdkEvent e and know by inspecting
e.type that this is a key event, you can call e = gnome.cast(e, "GdkEventKey")
to get access to key specific fields.