Glib::Object::Introspection - Dynamically create Perl language bindings
Contents
Abstract
Glib::Object::Introspection uses the gobject-introspection and libffi projects to dynamically create Perl
bindings for a wide variety of libraries. Examples include Gtk, webkit, libsoup and many more.
Description For Library Users
To allow Glib::Object::Introspection to create bindings for a library, the library must have installed a
typelib file, for example "$prefix/lib/girepository-1.0/Gtk-3.0.typelib". In your code you then simply
call "Glib::Object::Introspection->setup" with the following key-value pairs to set everything up:
basename => $basename
The basename of the library that should be wrapped. If your typelib is called "Gtk-3.0.typelib",
then the basename is 'Gtk'.
version => $version
The particular version of the library that should be wrapped, in string form. For "Gtk-3.0.typelib",
it is '3.0'.
package => $package
The name of the Perl package where every class and method of the library should be rooted. If a
library with basename 'Gtk' contains an class 'GtkWindow', and you pick as the package 'Gtk3', then
that class will be available as 'Gtk3::Window'.
The Perl wrappers created by "Glib::Object::Introspection" follow the conventions of the Glib module and
old hand-written bindings like Gtk2. You can use the included tool "perli11ndoc" to view the
documentation of all installed libraries organized and displayed in accordance with these conventions.
The guiding principles underlying the conventions are described in the following.
NamespacesandObjects
The namespaces of the C libraries are mapped to Perl packages according to the "package" option
specified, for example:
gtk_ => Gtk3
gdk_ => Gtk3::Gdk
gdk_pixbuf_ => Gtk3::Gdk::Pixbuf
pango_ => Pango
Classes, interfaces and boxed and fundamental types get their own namespaces, in a way, as the concept of
the GType is completely replaced in the Perl bindings by the Perl package name.
GtkButton => Gtk3::Button
GdkPixbuf => Gtk3::Gdk::Pixbuf
GtkScrolledWindow => Gtk3::ScrolledWindow
PangoFontDescription => Pango::FontDescription
With this package mapping and Perl's built-in method lookup, the bindings can do object casting for you.
This gives us a rather comfortably object-oriented syntax, using normal Perl object semantics:
in C:
GtkWidget * b;
b = gtk_check_button_new_with_mnemonic ("_Something");
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (b), TRUE);
gtk_widget_show (b);
in Perl:
my $b = Gtk3::CheckButton->new_with_mnemonic ('_Something');
$b->set_active (1);
$b->show;
You see from this that cast macros are not necessary and that you don't need to type namespace prefixes
quite so often, so your code is a lot shorter.
FlagsandEnums
Flags and enum values are handled as strings, because it's much more readable than numbers, and because
it's automagical thanks to the GType system. Values are referred to by their nicknames; basically, strip
the common prefix, lower-case it, and optionally convert '_' to '-':
GTK_WINDOW_TOPLEVEL => 'toplevel'
GTK_BUTTONS_OK_CANCEL => 'ok-cancel' (or 'ok_cancel')
Flags are a special case. You can't (sensibly) bitwise-or these string-constants, so you provide a
reference to an array of them instead. Anonymous arrays are useful here, and an empty anonymous array is
a simple way to say 'no flags'.
FOO_BAR_BAZ | FOO_BAR_QUU | FOO_BAR_QUUX => [qw/baz quu qux/]
0 => []
In some cases you need to see if a bit is set in a bitfield; methods returning flags therefore return an
overloaded object. See Glib for more details on which operations are allowed on these flag objects, but
here is a quick example:
in C:
/* event->state is a bitfield */
if (event->state & GDK_CONTROL_MASK) g_printerr ("control was down\n");
in Perl:
# $event->state is a special object
warn "control was down\n" if $event->state & "control-mask";
But this also works:
warn "control was down\n" if $event->state * "control-mask";
warn "control was down\n" if $event->state >= "control-mask";
warn "control and shift were down\n"
if $event->state >= ["control-mask", "shift-mask"];
MemoryHandling
The functions for ref'ing and unref'ing objects and free'ing boxed structures are not even mapped to
Perl, because it's all handled automagically by the bindings. Objects will be kept alive so long as you
have a Perl scalar pointing to it or the object is referenced in another way, e.g. from a container.
The only thing you have to be careful about is the lifespan of non reference counted structures, which
means most things derived from "Glib::Boxed". If it comes from a signal callback it might be good only
until you return, or if it's the insides of another object then it might be good only while that object
lives. If in doubt you can "copy". Structs from "copy" or "new" are yours and live as long as referred
to from Perl.
Callbacks
Use normal Perl callback/closure tricks with callbacks. The most common use you'll have for callbacks is
with the Glib "signal_connect" method:
$widget->signal_connect (event => \&event_handler, $user_data);
$button->signal_connect (clicked => sub { warn "hi!\n" });
$user_data is optional, and with Perl closures you don't often need it (see "Persistent variables with
closures" in perlsub).
The userdata is held in a scalar, initialized from what you give in "signal_connect" etc. It's passed to
the callback in usual Perl "call by reference" style which means the callback can modify its last
argument, ie. $_[-1], to modify the held userdata. This is a little subtle, but you can use it for some
"state" associated with the connection.
$widget->signal_connect (activate => \&my_func, 1);
sub my_func {
print "activation count: $_[-1]\n";
$_[-1] ++;
}
Because the held userdata is a new scalar there's no change to the variable (etc.) you originally passed
to "signal_connect".
If you have a parent object in the userdata (or closure) you have to be careful about circular references
preventing parent and child being destroyed. See "Two-Phased Garbage Collection" in perlobj about this
generally. Toplevel widgets like "Gtk3::Window" always need an explicit "$widget->destroy" so their
"destroy" signal is a good place to break circular references. But for other widgets it's usually
friendliest to avoid circularities in the first place, either by using weak references in the userdata,
or possibly locating a parent dynamically with "$widget->get_ancestor".
Exceptionhandling
Anything that uses GError in C will "croak" on failure, setting $@ to a magical exception object, which
is overloaded to print as the returned error message. The ideology here is that GError is to be used for
runtime exceptions, and "croak" is how you do that in Perl. You can catch a croak very easily by
wrapping the function in an eval:
eval {
my $pixbuf = Gtk3::Gdk::Pixbuf->new_from_file ($filename);
$image->set_from_pixbuf ($pixbuf);
};
if ($@) {
print "$@\n"; # prints the possibly-localized error message
if (Glib::Error::matches ($@, 'Gtk3::Gdk::Pixbuf::Error',
'unknown-format')) {
change_format_and_try_again ();
} elsif (Glib::Error::matches ($@, 'Glib::File::Error', 'noent')) {
change_source_dir_and_try_again ();
} else {
# don't know how to handle this
die $@;
}
}
This has the added advantage of letting you bunch things together as you would with a try/throw/catch
block in C++ -- you get cleaner code. By using Glib::Error exception objects, you don't have to rely on
string matching on a possibly localized error message; you can match errors by explicit and predictable
conditions. See Glib::Error for more information.
Outputarguments,lists,hashes
In C you can only return one value from a function, and it is a common practice to modify pointers passed
in to simulate returning multiple values. In Perl, you can return lists; any functions which modify
arguments are changed to return them instead.
Arguments and return values that have the types GList or GSList or which are C arrays of values will be
converted to and from references to normal Perl arrays. The same holds for GHashTable and references to
normal Perl hashes.
Objectclassfunctions
Object class functions like "Gtk3::WidgetClass::find_style_propery" can be called either with a package
name or with an instance of the package. For example:
Gtk3::WidgetClass::find_style_property ('Gtk3::Button', 'image-spacing')
my $button = Gtk3::Button->new;
Gtk3::WidgetClass::find_style_property ($button, 'image-spacing')
Overridingvirtualfunctions
When subclassing a gtk+ class or when implementing a gtk+ interface with Glib::Object::Subclass, you can
override any virtual functions that the class has by simply defining sub routines with names obtained by
capitalizing the original names of the virtual functions. So, for example, if you implement a custom
subclass of "Gtk3::CellRenderer" and want to override its virtual function "render", you provide a sub
routine with the name "RENDER" in your package.
sub RENDER {
my ($cell, $cr, $widget, $background_area, $cell_area, $flags) = @_;
# do something
}
License
This library is free software; you can redistribute it and/or modify it under the terms of the Lesser
General Public License (LGPL). For more information, see http://www.fsf.org/licenses/lgpl.txt
perl v5.40.0 2024-10-20 Glib::Object::Introspection(3pm)
Name
Glib::Object::Introspection - Dynamically create Perl language bindings
See Also
perl-Glib: Glib
gobject-introspection: <https://gi.readthedocs.io/en/latest/>
libffi: <http://sourceware.org/libffi/>
Synopsis
use Glib::Object::Introspection;
Glib::Object::Introspection->setup(
basename => 'Gtk',
version => '3.0',
package => 'Gtk3');
# now GtkWindow, to mention just one example, is available as
# Gtk3::Window, and you can call gtk_window_new as Gtk3::Window->new
