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.