Free gobject software for linux

pygobject archive contains bindings for the GObject, to be used in Python.

It is a fairly complete set of bindings, its already rather useful, and is usable to write moderately complex programs. (see the examples directory for some examples of the simpler programs you could write).

GOB (GOB2 anyway) project is a preprocessor for making GObjects with inline C code so that generated files are not edited. Syntax is inspired by Java and Yacc or Lex. The implementation is intentionally kept simple, and no C actual code parsing is done.
Main features:
- C is a perfect (well mostly) language, no need for another language
- Writing a fully featured GObject is a hassle
- GObject has little type safety, GOB improves on it.
- Need for a generator that doesnt require changes to generated code
- I like how Java writes method code directly into the class definition.

GuiLoader is a high-performance and compact GuiXml loader library. This library allows GTK+ applications to create GUI widgets and objects at run-time from GuiXml resource files.

GuiLoader is written in C language as a GObject subclass and has a trivial language-independent API. GuiLoader was designed to be easily wrapped for any language that has GTK+ bindings.

Glib are Perl wrappers for the GLib utility and Object libraries.

SYNOPSIS

use Glib;

ABSTRACT

This module provides perl access to GLib and GLibs GObject libraries. GLib is a portability and utility library; GObject provides a generic type system with inheritance and a powerful signal system. Together these libraries are used as the foundation for many of the libraries that make up the Gnome environment, and are used in many unrelated projects.

This wrapper attempts to provide a perlish interface while remaining as true as possible to the underlying C API, so that any reference materials you can find on using GLib may still apply to using the libraries from perl. This module also provides facilities for creating wrappers for other GObject-based libraries. The "SEE ALSO" section contains pointers to all sorts of good information.

PERL VERSUS C

GLib provides to C programs many of the same facilities Perl offers natively. Where GLibs functionality overlaps Perls, Perls is favored. Some concepts have been eliminated entirely, as Perl is a higher-level language than C. In other instances weve had to add or change APIs to make sense in Perl. Heres a quick run-down:

Perl Already Does That

The GLib types GList (a doubly-linked list), GSList (singly-linked list), GHashTable, GArray, etc have all been replaced by native Perl datatypes. In fact, many functions which take GLists or arrays simply accept lists on the Perl stack. For the most part, GIOChannels are no more functional than Perl file handles, so you wont see any GIOChannels. GClosures are not visible at the Perl level, because Perl code references do the same thing. Just about any function taking either a C function pointer or a GClosure will accept a code reference in Perl. (In fact, you can probably get away with just a subroutine name in many spots, provided you arent using strict subs.)

Dont Worry About That

Some concepts have been eliminated; you need never worry about reference-counting on GObjects or having to free GBoxed structures. Perl is a garbage-collected language, and weve put a lot of work into making the bindings take care of memory for you in a way that feels natural to a Perl developer. You wont see GValues in Perl (thats just a C structure with Perl scalar envy, anyway).

Glib::CodeGen is a code generation utilities for Glib-based bindings.

SYNOPSIS

# usually in Makefile.PL
use Glib::CodeGen;

# most common, use all defaults
Glib::CodeGen->parse_maps (myprefix);
Glib::CodeGen->write_boot;

# more exotic, change everything
Glib::CodeGen->parse_maps (foo,
input => foo.maps,
header => foo-autogen.h,
typemap => foo.typemap,
register => register-foo.xsh);
Glib::CodeGen->write_boot (filename => bootfoo.xsh,
glob => Foo*.xs,
ignore => ^(Foo|Foo::Bar)$);

# add a custom type handler (rarely necessary)
Glib::CodeGen->add_type_handler (FooType => ≥n_foo_stuff);
# (see the section EXTENDING TYPE SUPPORT for more info.)

This module packages some of the boilerplate code needed for performing code generation typically used by perl bindings for gobject-based libraries, using the Glib module as a base.

The default output filenames are in the subdirectory build, which usually will be present if you are using ExtUtils::Depends (as most Glib-based extensions probably should).

libexo is the extension library to Xfce developed by os-cillation. While Xfce ships with quite a few libraries that are primarly targeted at desktop development, libexo is targeted at application development, with a focus on applications for Xfce.
libexo library is already used by three Xfce applications - Terminal, Xfmedia and Thunar - and is expected to be used by other Xfce applications as well, once more application developers start to write applications for and with Xfce.
libexo contains a bunch of additional widgets (e.g. an icon bar and widgets that can automatically ellipsize text), provides a framework for editable toolbars (an improved version of the framework present in GNOME), light-weight session management support, functions to automatically synchronize object properties (based on GObject Binding Properties) and several miscelleanous utility and helper functions for application developers.
Installation:
Before we go into the details of how to install libexo from source, we should mention that binary packages prebuilt for your operating system will be available, either from your operating system vendor or from independent sources. Check the download locations mentioned above to see whether binary packages are available for your operating system.
The source package is distributed as bzip2ed tarball (.tar.bz2) and as a gziped tarball (.tar.gz). It is highly recommended to install libexo to the same location that you installed Xfce to. For example, if you installed Xfce into /usr/local, you would perform the following steps to build and install libexo:
# bunzip2 exo-X.Y.Z.tar.bz2
# tar xf exo-X.Y.Z.tar
# cd exo-X.Y.Z
# export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
# ./configure --prefix=/usr/local
# make
# make install
Replace X.Y.Z in the above lines with the version of the tarball you downloaded (e.g. 0.2.0).
Enhancements:
- This release adds a new ExoIconChooserDialog widget to pick an icon from either the current icon theme or an image file.
- It adds exo_gtk_file_chooser_add_thumbnail_preview(), which adds a thumbnail preview widget to a GtkFileChooser.
- It adds ExoCellRendererIcon as the default icon renderer for the ExoIconView.
- ExoTreeView has been updated to add support for rubberband selection.
- A layout problem in ExoIconView where the appearance of a scrollbar caused the icons to be laid out again and again has been fixed.
- The GSlice allocator is used where possible to further reduce memory overhead.

GTK-Doc is used to document C code. It is typically used to document the public API of libraries, such as the GTK+ and GNOME libraries, but it can also be used to document application code.

Note that GTK-Doc wasnt originally intended to be a general-purpose documentation tool, so it can be a bit awkward to setup and use. For a more polished general-purpose documentation tool you may want to look at Doxygen (http://www.doxygen.org/). However GTK-Doc has some special code to document the signals and properties of GTK+ widgets and GObject classes which other tools may not have.

GTK-Doc allows your documentation to be written in 2 ways:

a) Embedded inside the source code in specially-formatted comments.

or

b) Added to the template files which gtk-doc outputs after scanning all the header files and parsing the declarations.

From these source code comments and template files GTK-Doc generates a Docbook XML (or SGML) document, which is then transformed into HTML. The generated HTML documentation can be browsed in an ordinary web browser or by using the special Devhelp API browser (see http://developer.imendio.com/wiki/Devhelp).

Gtk-sharp is a .Net language bindings for Gtk+ and selected Gnome libraries.

Gtk# provides tools to bind GObject based libraries for use by Mono/.Net applications in addition to a set of assemblies that binds the Gtk+ libraries and several Gnome libraries.