| Developer(s) | The GNOME Project |
|---|---|
| Initial release | 11 March 2002; 23 years ago (2002-03-11) |
| Written in | C |
| Operating system | Cross-platform |
| Available in | Multilingual[which?] |
| Type | Software library |
| License | GNU LGPL |
| Website | developer |
TheGLib Object System, orGObject, is afreesoftware library providing a portableobject system and transparent cross-language interoperability. GObject is designed for use both directly inC programs to provide object-oriented C-based APIs and throughbindings to other languages to provide transparent cross-language interoperability, e.g.PyGObject.
Depending only onGLib andlibc, GObject is a cornerstone ofGNOME and is used throughoutGTK,Pango,ATK, and most higher-levelGNOME libraries likeGStreamer and applications. Prior to GTK+ 2.0, code similar to GObject was part of the GTK codebase. (The name “GObject” was not yet in use — the common baseclass was calledGtkObject.)
At the release of GTK+ 2.0, the object system was extracted into a separate library due to its general utility. In the process, most non-GUI-specific parts of theGtkObject class were moved up intoGObject, the new common baseclass. Having existed as a separate library since March 11, 2002 (the release date of GTK+ 2.0), the GObject library is now used by many non-GUI programs such ascommand-line andserver applications.
Though GObject has its own separate set of documentation[1] and is usually compiled into its ownshared library file, the source code for GObject resides in theGLib source tree and is distributed along with GLib. For this reason, GObject uses the GLib version numbers and is typically packaged together with GLib (for example,Debian puts GObject in itslibglib2.0 package family).
At the most basic level of the GObject framework lies a generic and dynamictype system called GType. The GType system holds a runtime description of all objects allowingglue code to facilitate multiple language bindings. The type system can handle anysingly inherited class structure, in addition tonon-classed types such asopaque pointers,strings, and variously sizedintegers andfloating point numbers.
The type system knows how to copy, assign, and destroy values belonging to any of the registered types. This is trivial for types like integers, but many complex objects arereference-counted, while some are complex but not reference-counted. When the type system “copies” a reference-counted object, it will typically just increase its reference count, whereas when copying a complex, non-reference-counted object (such as a string), it will typically create an actual copy byallocating memory.
This basic functionality is used for implementingGValue, a type of generic container that can hold values of any type known by the type system. Such containers are particularly useful when interacting with dynamically typed language environments in which all native values reside in suchtype-tagged containers.
Types that do not have any associatedclasses are callednon-classed. These types, together with all types that correspond to some form ofroot class, are known asfundamental types: the types from which all other types are derived. These make up a relatively closed set, but although the average user is not expected to create their own fundamental types, the possibility does exist and has been exploited to create customclass hierarchies — i.e., class hierarchies not based on theGObject class.
As of GLib 2.9.2,[2] thenon-classed built-in fundamental types are:
void (G_TYPE_NONE);char,int,long, and 64-bit integers (G_TYPE_CHAR,G_TYPE_UCHAR,G_TYPE_INT,G_TYPE_UINT,G_TYPE_LONG,G_TYPE_ULONG,G_TYPE_INT64, andG_TYPE_UINT64);G_TYPE_BOOLEAN);enum type, but differing in that the latter is only used forbit fields (G_TYPE_ENUM andG_TYPE_FLAGS);float anddouble (G_TYPE_FLOAT andG_TYPE_DOUBLE);char * (G_TYPE_STRING);void * (G_TYPE_POINTER).Theclassed built-in fundamental types are:
GObject, the root of the standard class inheritance tree (G_TYPE_OBJECT)G_TYPE_INTERFACE)G_TYPE_BOXED)G_TYPE_PARAM).Types that can be instantiated automatically by the type system are calledinstantiable. An important characteristic of these types is that the first bytes of any instance always contain a pointer to theclass structure (a form ofvirtual table) associated to the type of the instance. For this reason, any instantiable type must be classed. Contrapositively, any non-classed type (such asinteger orstring) must be non-instantiable. On the other hand, most classed types are instantiable, but some, such as interface types, are not.
The types that are derived from the built-in GObject fundamental types fallroughly into four categories:
enum type) that one wishes to use in some way that is related to the object system — for example, as the type of an object property — should be registered with the type system. Typically, the initialization code that takes care of registering these types is generated by an automated tool calledglib-mkenums[3] and stored in a separate file.background-color property, whose values should be instances of a structure that looks likestructcolor{intr,g,b;}. To avoid having to subclassGObject, we can create aboxed type to represent this structure, and provide functions for copying and freeing. GObject ships with a handful of boxed types wrapping simple GLib data types. Another use for boxed types is as a way to wrap foreign objects in a tagged container that the type system can identify and will know how to copy and free.G_TYPE_POINTER), it is often a good idea to create a derived pointer type, documenting the fact that the pointers should reference a particular kind of object, even though nothing else is said about it.GObject. There are also interfaces, which, unlike classicJava-styleinterfaces, can contain implemented methods. GObject interfaces can thus be described asmixins.The GObject messaging system consists of two complementary parts:closures andsignals.
Each GObject class is implemented by at least two structures: theclass structure and theinstance structure.
Defining a class in the GObject framework is complex, requiring large amounts ofboilerplate code, such as manual definitions of type casting macros and obscure type registration incantations. Also, since a C structure cannot have access modifiers like “public”, “protected”, or “private”, workarounds must be used to provideencapsulation. One approach is to include a pointer to the private data — conventionally called_priv — in the instance structure. Theprivate structure can be declared in the public header file, but defined only in the implementation file, with the effect that the private data is opaque to users, but transparent to the implementor. If the private structure is registered with GType, it will be automatically allocated by the object system. Indeed, it is not even necessary to include the_priv pointer, if one is willing to use the incantationG_TYPE_INSTANCE_GET_PRIVATE every time the private data is needed.
To address some of these complexities, several higher-level languages exist thatsource-to-source compiles to GObject in C. TheVala programming language uses aC#-style syntax and is pre-processed intovanilla C code. The GObject Builder, orGOB2, offers a template syntax reminiscent ofJava.
The combination of C and GObject is used in many successfulfree software projects, such as theGNOME desktop, theGTK toolkit and theGIMP image manipulation program.
Though many GObject applications are written entirely in C, the GObject system maps well into the native object systems of many other languages, likeC++,Java,Ruby,Python,Common Lisp, and.NET/Mono. As a result, it is usually relatively painless to createlanguage bindings for well-written libraries that use the GObject framework.
Writing GObject code in C in the first place, however, is relatively verbose. The library takes a good deal of time to learn, and programmers with experience inhigh-level object-oriented languages often find it somewhat tedious to work with GObject in C. For example, creating a subclass (even just a subclass ofGObject) can require writing and/or copying large amounts ofboilerplate code.[5] However, usingVala, a language that is designed primarily to work with GObject and which converts to C, is likely to make working with GObject or writing GObject based libraries nicer.
Although they are not reallyfirst-class objects (there are no actual metatypes in GType),metaobjects like classes and interfaces are created by GObject applications at runtime, and provide good support forintrospection. The introspective capabilities are used by language bindings and user interface design applications likeGlade to allow doing things like loading ashared library that provides a GObject class—usually some kind ofwidget, in the case of Glade—and then obtain a list of all properties of the class, complete with type information and documentationstrings.
 | This sectionpossibly containsoriginal research. Pleaseimprove it byverifying the claims made and addinginline citations. Statements consisting only of original research should be removed.(December 2011) (Learn how and when to remove this message) |
 | This sectiondoes notcite anysources. Please helpimprove this section byadding citations to reliable sources. Unsourced material may be challenged andremoved.(November 2018) (Learn how and when to remove this message) |
Since GObject provides a mostly complete object system for C[citation needed], it can be seen as an alternative to C-derived languages such asC++ andObjective-C. (Though both also offer many other features beyond just their respective object systems.) An easily observed difference between C++ and GObject is that GObject (like Java) does not supportmultiple inheritance.[6]
GObject's use ofGLib's g_malloc() memory allocation function will cause the program to exit unconditionally upon memory exhaustion, unlike the C library'smalloc(), C++'snew, and other common memory allocators which allow a program to cope with or even fully recover from out-of-memory situations without simply crashing.[7] This tends to work against including GObject in software where resilience in the face of limited memory is important, or where very many or very large objects are commonly handled. The g_try_new() can be used when a memory allocation is more likely to fail (for a large object for example), but this cannot grant that the allocation will not fail elsewhere in the code.[8]
Another important difference is that while C++ and Objective-C are separate languages, GObject is strictly a library and as such does not introduce any new syntax or compiler intelligence. For example, when writing GObject-based C code, it is frequently necessary to perform explicitupcasting.[citation needed] Hence, “C with GObject”, also called "glib-flavored C", considered as a language separate from plain C, is a strict superset of plain C — like Objective C, but unlike C++.
On platforms where there is no standardABI that works across all C++ compilers (which is not usually the case, since either the Itanium ABI or the Microsoft ABI are usually followed), a library compiled with one C++ compiler is not always able to call a library compiled with a different one.[citation needed] If such compatibility is required, the C++ methods must be exported as plain C functions, partly defeating the purpose of the C++ object system.[citation needed] The problem occurs in part because different C++ compilers use different kinds ofname mangling to ensure the uniqueness of all exported symbols. (This is necessary because, for example, two different classes may have identically named member functions, one function name may beoverloaded multiple times, or identically named functions may appear in differentnamespaces, but inobject code these overlaps are not allowed.)[citation needed] In contrast, since C does not support any form of overloading or namespacing, authors of C libraries will typically use explicit prefixes to ensure the global uniqueness of their exported names.[citation needed] Hence, despite being object-oriented, a GObject-based library written in C will always use the same external symbol names regardless of which compiler is used.
Perhaps the most profound difference is GObject's emphasis onsignals (calledevents in other languages).[citation needed] This emphasis derives from the fact that GObject was specifically designed to meet the needs of a GUI toolkit. Whilst there are signal libraries for most object-oriented languages out there, in the case of GObject it is built into the object system. Because of this, a typical GObject application will tend to use signals to a much larger extent than a non-GObject application would, making GObjectcomponents much moreencapsulated and reusable than the ones using plain C++ or Java.[citation needed][according to whom?] If usingglibmm/gtkmm, the official C++ wrappers to Glib/GTK respectively, the sibling projectlibsigc++ allows easy use of underlying GObject signals using standard C++. Of course, other implementations of signals are available on almost all platforms, although sometimes an extra library is needed, such as Boost.Signals2 for C++.
| Platform |
| ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| GNOME | |||||||||||||||
| Cinnamon | |||||||||||||||
| Xfce | |||||||||||||||
| LXDE | |||||||||||||||
| Graphical shells | |||||||||||||||
| 3rd-party applications |
| ||||||||||||||
