GOB(1)GOB(1)NAMEGOB - The GTK+ Object Builder
SYNOPSIS
gob [ option ] ... file
DESCRIPTION
GTK+ Object Builder is a simple preprocessor for easily
creating GTK+ objects. It does not parse any C code and
ignores any C errors. It is in spirit similar to things
like lex or yacc.
OPTIONS
-? -h --help
Display a simple help screen.
--version
Display version information (note, --version was
not added until 0.92.0)
-w --exit-on-warn
Exit with an error code even when you encounter a
warning.
--no-exit-on-warn
Exit with an error only on errors, not on warnings,
this is the default.
--for-cpp
Generate C++ code.
--no-extern-c
Never add the extern "C" to the header.
--no-gnu
Never generate any code with GNU C extensions.
However all the GNU C extensions are always wrapped
in #ifdef __GNUC__, so code using them compiles
correctly even on non-GNU compilers. This option
is for purists only. (using GNU extensions some
warnings are eliminated, some ugly hacks and there
is better argument type safety, so it's good to use
them)
--no-touch-headers
Don't touch the generated header file unless it
really changed, this avoids spurious rebuilds, but
can confuse some make systems (automake in particu
lar), so it is not enabled by default. Private
header is still touched even if unchanged however.
--always-private-header
Always create a <basename>-private.h file, even if
GOB 1.0.10 1
GOB(1)GOB(1)
it would be empty. Otherwise, it is only created
when there are private data members in the class.
This option implicitly negates --no-private-header
--no-private-header
Never create a private header file. If we use any
private data members, define the private data
structure at the point in the .c source where the
class definition begins. This option implicitly
negates --always-private-header
-n --no-write
Do not write any output files, just check syntax of
the input file.
--no-lines
Do not print out the '#line' statements into the
output. Useful for debugging the auto-generated
generated code.
--no-self-alias
Do not create the Self and SelfClass type aliases
and the SELF, IS_SELF and SELF_CLASS macros.
--no-kill-underscores
Do not remove the initial underscore from method
names.
--always-private-struct
Always include the private pointer in the public
header file. This is useful for files which are
part of a library and you want to reserve the right
to add some private data members without breaking
binary compatibility.
TYPENAMES
Because we need to parse out different parts of the type
name, sometimes you need to specify the typename with some
special syntax. Types are specified in capitalized form
and words are separated by ':'. The first word of the
type (which can be empty) is the "namespace". This fact
is for example used for the type checking macro and the
type macro. For "Gtk:New:Button", the macros will be
GTK_IS_NEW_BUTTON and GTK_TYPE_NEW_BUTTON. This colon
separated format of typenames is used in the class decla
ration header and for method argument types.
OUTPUT FILES
The filenames are created from the typename. The words
are separated by '-' and all in lower case. For example
for an object named "Gtk:New:Button", the files are gtk-
new-button.c and gtk-new-button.h. If you are using C++
GOB 1.0.10 2
GOB(1)GOB(1)
mode, the output .c file will in fact be a .cc file. If
you have any private data members, a private header file
will also be created, called <basename>-private.h (for the
example above it would be gtk-new-button-private.h). The
public header file is created to be human readable and to
be used as a reference to the object. The .c source file
is not created as a human readable source and is littered
with #line statements, which make the compiler attempt to
point you to the right line in your .gob file in case of
parsing errors. The output should not be edited by hand,
and you should only edit the .gob file.
INCLUDING NORMAL C CODE IN THE OUTPUT FILES
To include some code directly in the output C file begin
with '%{' on an empty line and end the code with a '%}' on
an empty line. These sections will appear in the output
files in the order they are given. There are several
other sections to which you can put code. You can put it
in the 'header' section (which can be abbreviated 'h') and
it will go into the public header file. You can also put
it in the 'privateheader' section (abbreviated 'ph') which
will make the code go into the private header file. Some
times you want some code (other includes) to appear before
the extern "C" and the protecting define. To do this you
can put them into the 'headertop' (or 'ht') section. You
may wish to include code or comments in all the files,
which you can do by putting them into the 'all' (or 'a')
section. Similarly, code you wish to appear at the top of
all files go in the 'alltop' (or 'at') section. For exam
ple:
%alltop{
/* this will be on top of all output files */
%}
%headertop{
/* this will be on top of the public header */
%}
%privateheader{
/* this will go into the private header file */
%}
%h{
/* will be included in the header */
void somefunc(int i);
%}
%a{
/* will be included in all files */
%}
%{
GOB 1.0.10 3
GOB(1)GOB(1)
/* will be included in the C file */
void somefunc(int i)
{
/* some code */
}
%}
INCLUDE FILES
Gob will automatically include the class header file at
the top of the .c source file. If you wish to include it
somewhere else, put the include into some %{ %} section
above the class definition, and gob will not include it
automatically. This way you can avoid circular includes
and control where in the file do you want to include the
header.
If you made any data members private, gob will also create
a source file that will be called <basename>-private.h.
Same rule as above applies for this just as it does for
the regular header file. If you do explicitly include the
regular header file, you should always include this pri
vate header file below it. That is, if you use any pri
vate data members. If you don't, the private header file
automatically includes the public header file, and thus
the public header file will be indirectly included at the
very top of the file.
MAKING A NEW CLASS
The class header:
There can be only one class per input file. Defining a
class is sort of like in Java, you define the class and
write inline code directly into the class definition. To
define a class you need to specify the new object name and
the name of the object from which it is derived from, such
as this "class <new type> from <parent type> { <class
code> }". For example:
class Gtk:New:Button from Gtk:Button {
<class code>
}
Data members:
There are five types of data members. Three of them are
normal data numbers, one is class wide (global) in scope
and one is a virtual one, usually linked to a normal data
member or a class wide data member. The three normal data
members are public, protected and private. Public and
protected are basically just entries in the object
GOB 1.0.10 4
GOB(1)GOB(1)
structure, while private has it's own dynamically allo
cated private structure. Protected members are always put
after the public one in the structure and are marked pro
tected in the header file. There is only one identifier
allowed per typename unlike in normal C. Example:
public int i;
private GtkWidget *h;
protected long k;
Public and protected data members are accessed normally as
members of the object struct. Example where 'i' is as
above a public data member:
object->i = 1;
The private data members are defined in a structure which
is only available inside the .c file, or by including a
private header file. You must access them using the
structure _priv. Example where 'h' is the private data
member (as in the above example):
object->_priv->h = NULL;
The _priv structure is defined in the <basename>-pri
vate.h. This file is automatically included if you don't
include it yourself. You should always explicitly include
it in your .gob file if you explicitly also include the
main header file. The reason it is a separate header file
is that you can also include it in other places that need
to access this objects private data, such as if you have
the majority of functionality of an object in a separate
.c file. Or if a derived object needs to access the pro
tected methods.
In case you use the --no-private-header option, no private
header file is created and you can only access the _priv
pointer below the class definition in the .gob file.
Also note that this structure is dynamically allocated,
and is freed in the finalize handler. If you override the
finalized handler, your code will be run first and only
then will the _priv structure be freed.
Classwide data members:
Sometimes you want a datamember to be shared by all
objects. You then need the "classwide" scope keyword. So
for example the following adds a global member foo:
classwide int foo;
GOB 1.0.10 5
GOB(1)GOB(1)
To access the member you do the standard voodoo of getting
the class from the object and casting it to your class
pointer. Thus the following would work:
SELF_CLASS(GTK_OBJECT(object)->klass)->foo = 20;
Automatic Initialization (0.93.0 and higher only):
You can automatically initialize the public private and
protected data members without having to add an init
method. The advantage here is that initialization is kept
close to the definition of the data member and thus it's
easier to check. To do this, just add a '=' followed by a
number or a token. It is also possible to include arbi
trary C code for more elaborate initializations by putting
it all in curly braces. Note that the curly braces will
not be printed into the output, but since gob does not C
parsing it needs them to figure out where the C code ends.
The code will be inserted into the init method, above the
user defined body. So for example the following will ini
tialize an integer to -1 and a string with a newly allo
cated string of "hello".
public int foo = -1;
private char *bar = {g_strdup("hello")};
Automatic Destruction (0.93.0 and higher only):
Most data stored as pointers needs to have a function
called when the object is destroyed, to either free it or
give up a reference. Gob will let you define a function
to be called on the data the object is destroyed. This is
achieved by putting 'destroywith' followed by a function
name after the variable definition. It is only called if
the data you defined this on is not NULL, so you cans
specify functions which do not handle NULL. It is very
much like the GDestroyNotify function used in GTK+ and
glib in many places. Unlike many other places, gob will
not enforce any kind of type safety here so be a little
bit more careful. Any function you give it will be called
as a "void function(void *)". It will in fact be cast
into such a form before called. This is to avoid spurious
warnings for gtk calls to subclass methods. The function
needs not be of that form exactly, it just has to take one
argument which is the pointer to the data. You should
also not define this on any non-pointer data as the
results may be undefined. Example:
public Gtk:Widget *window = NULL
destroywith gtk_widget_destroy;
public char *foo = {g_strdup("bar")}
destroywith g_free;
GOB 1.0.10 6
GOB(1)GOB(1)
Note that the function name you give must be a real func
tion and not macro. Also note that this is always called
in the "destroy" method of GtkObject. It is always called
after any user defined body of the destroy handler.
Sometimes you may want to run arbitrary code on destruc
tion. While this can be perfectly well done in the
destroy handler. Depending on the style you may want to
include all destruction/initialization code together with
the definition of the data member. Thus you may want to
put arbitrary code which will then be inserted into the
"destroy" method of GtkObject. This can be done with the
"destroy" keyword followed by arbitrary code in curly
braces. Inside this code a macro called VAR will be
define which refers to your variable. So for example
destroying a GString can be either done with a helper rou
tine or the following code:
public GString *string = {g_string_new(NULL)}
destroy {
if(VAR) g_string_free(VAR, TRUE);
};
The thing to remember with these is that there are many
ways to do this and you'd better be consistent in your
code in how you use the above things. Also defining a
helper routine that will do the destruction will be a
nicer thing to do if that's a possibility. The "destroy"
keyword with code does take up more space in the file and
it may become more cluttered.
The data is zeroed out after being destroyed. This is to
make debugging easier in case your code might try to
access an already destroyed object. In case you have
overridden the destroy method, your code will be run first
and only then will the destructors be called. You should
not however make any assumptions about the order at which
the destructors are called. If you have interdependencies
between destructors for different data members, you will
have to do this in your own destroy override function.
GTK+ Arguments:
The fourth type of a data member an argument type. It is
a named data member which is one of the features of the
GTK+ object system. You need to define a get and a set
handler. They are fragments of C code that will be used
to get the value or set the value of the argument. Inside
them you can use the define ARG to which you assign the
data or get the data. You can also use the identifier
"self" as pointer to the object instance. The type is
defined as one of the gtk type enums, but without the
GTK_TYPE_ prefix. For example:
GOB 1.0.10 7
GOB(1)GOB(1)
public int height;
argument INT height set { self->height = ARG; } get { ARG = self->height; };
If you don't define a set or a get handler it will be a
read-only or a write-only argument. If you want to add
extra argument flags, add them into parenthesis after the
argument keyword, separated by '|' and without the
GTK_ARG_ prefix. For example:
public int height;
argument (CONSTRUCT) INT height get { ARG = self->height; };
This makes the argument settable even before the object is
constructed, so that people can pass it to gtk_object_new
function. Useful is also CONSTRUCT_ONLY flag which makes
the argument only available during construction of the
object.
Since 0.92.1, gob creates macros which can be used for
type safe access to gtk arguments. The macros are called
<type>_ARG_<argument name>(x) and <type>_GET_ARG_<argument
name>(x). They define both the string and the value part
of the argument. So for setting an argument of height,
one would use (for object type My:Object):
gtk_object_set (GTK_OBJECT (object),
MY_OBJECT_ARG_HEIGHT (7),
NULL);
And for getting, you would use:
int height;
gtk_object_get (GTK_OBJECT (object),
MY_OBJECT_GET_ARG_HEIGHT (&height),
NULL);
Note however that the type safety only works completely on
GNU C compilers. The code will compile on other compilers
but with minimal type safety.
To get good type safety on POINTER types however, you
should specify an optional C type that gob should use.
For other then POINTER types this is redundant but possi
ble. To do this, place '(type <c type>)' right after the
GTK+ type. Example:
argument POINTER (type char *) foo set { /* foo */ } get { /* bar */ };
Sometimes it can become tiresome to type in the set and
get handlers if they are trivial. So gob since version
0.93.0 provides automatic argument linking to data mem
bers. There are three different cases it handles, direct
GOB 1.0.10 8
GOB(1)GOB(1)
link (keyword 'link'), string linking (keyword
'stringlink') and object linking (keyword 'objectlink').
You just place the keyword after the argument name instead
of the get/set handlers. It will link to a data member of
the same name that was defined earlier in the input file.
Best is to see examples:
public int foo;
argument INT foo link;
is just like
public int foo;
argument INT (type int) foo
get { ARG = self->foo; }
set { self->foo = ARG; };
Similarly,
private char * foo;
argument POINTER foo stringlink;
is just like
private char * foo;
argument POINTER (type char *) foo
get {
ARG = g_strdup(self->_priv->foo);
} set {
g_free(self->_priv->foo);
self->_priv->foo = g_strdup(ARG);
}
And for the objectlink we would have:
public Gtk:Object * foo;
argument POINTER foo objectlink;
is just like
protected Gtk:Object * foo;
argument POINTER (type Gtk:Object *) foo
get {
ARG = self->foo;
} set {
if(ARG != NULL)
gtk_object_ref(ARG);
if(self->foo != NULL)
gtk_object_unref(self->foo);
self->foo = ARG;
}
As you see it will handle NULLs correctly (for the string,
GOB 1.0.10 9
GOB(1)GOB(1)
g_free and g_strdup handle NULLs). And it will also han
dle private, protected and public members. For
objectlink, just a pointer is returned on get, if you wish
to keep it around, you should call gtk_object_ref on it.
For stringlink, get makes a copy of the string which you
should free after use. This is the behaviour since 1.0.2.
You can also automatically export get and set methods for
each of the arguments by appending '(export)' flag before
the get and set statements. For example:
public int foo;
argument INT (type int) foo (export)
get { ARG = self->foo; }
set { self->foo = ARG; };
Will export public methods get_foo(self) and set_foo(self,
int foo) for you automatically. Note that this behaviour
is new in 1.0.10.
Methods:
There is a whole array of possible methods. The three
normal, "familiar" method types are private, protected and
public. Public are defined as normal functions with a
prototype in the header file. Protected methods are
defined as normal methods (which you can call from other
files), but their prototype is placed in the private
header file. Private methods are defined as static func
tions with prototypes at the top of the .c file. Then
there are signal, virtual and override methods. More on
those later. You can also define init and class_init
methods with a special definition if you want to add code
to the constructors or you can just leave them out. You
can also not define a body for a method, by just using ';'
instead of a body. This will define an empty function.
You can't do this for non-void regular public, private or
protected methods, however it is acceptable for non-void
virtual, signal and override methods.
Function argument lists:
For all but the init and class_init methods, you use the
following syntax for arguments. The first argument can be
just "self", which gob will translate into a pointer to
the object instance. The rest of the arguments are very
similar to normal C arguments. If the typename is an
object pointer you should use the syntax defined above
with the words separated by ':'
<type> <argument id>
or
<type> <argument id> (check <list of checks>)
The checks are glib type preconditions, and can be the
GOB 1.0.10 10
GOB(1)GOB(1)
following: "null", which tests pointers for being NULL,
"type" which checks GTK+ object pointers for being the
right type, "<test> <number>" which tests numeric argu
ments for being a certain value. The test can be a
<,>,<=,>= != or ==. Example:
public int foo(self, int h (check > 0 < 11), Gtk:Widget *w (check null type))
This will be the prototype of a function which has a self
pointer as the first argument, an integer argument which
will be checked and has to be more then 0 and less then
11, and a pointer to a GtkWidget object instance and it is
checked for being null and the type will also be checked.
Error return:
Methods which have a return value, there also has to be
something returned if there is an error, such as if a pre
condition is not met. The default is 0, casted to the
type of the method. If you need to return something else
then you can specify an "onerror" keyword after the proto
type and after that a number, a token (an identifier) or a
bit of C code enclosed in braces {}. The braces will not
be printed into the output, they just delimit the string.
For example:
public void * get_something(self, int i (check >= 0)) onerror NULL {
...
}
The onerror value is also used in overrides that have a
return value, in case there isn't a parent method, PAR
ENT_HANDLER will return it. More about this later.
Default return:
Some signal and virtual methods have a return type. But
what happens if there is no default handler and no one
connects to a signal. GOB will normally have the wrappers
return whatever you specify with onerror or '0' if you
haven't specified anything. But since 0.93.2 you can
specify a default return value with the keyword 'defre
turn'. It's use is identical to the use of onerror, and
you can in fact use both at the same time. Example
virtual int get_some_int(self) onerror -1 defreturn 10 ;
That is an empty virtual method (in C++ terms a pure vir
tual). If you never specify any handler for it in the
derived children it will just return 10.
Constructor methods:
GOB 1.0.10 11
GOB(1)GOB(1)
There are two methods that handle the construction of an
object, init and class_init. You define them by just
using the init or class_init keyword with an untyped argu
ment in the argument list. The argument will be usable in
your function as a pointer to your object or class depend
ing if it's init or class_init. For example:
init(self) {
/* initialize the object here */
self->a = 9;
self->b = 9;
}
class_init(class) {
/* initialize the class, this is rarely needed */
class->blah = NULL;
}
The class_init function is very rarely needed as all stan
dard class initialization is taken care of for you by gob
itself. The init function should on the other hand be
used whenever you need to construct or initialize anything
in the object to put it into a sane state. Sometimes you
need some arguments, for this you should either use a con
struct method and a new function like many GTK+ widgets,
and/or a CONSTRUCT or CONSTRUCT_ONLY type of an argument.
Virtual methods:
Virtual methods are basically pointers in the class struc
ture, so that one can override the method in derived meth
ods. They can be empty (if you put ';' instead of the C
code). A wrapper will also be defined which makes calling
the methods he same as public methods. This type of
method is just a little bit "slower" then normal func
tions, but not as slow as signals. You define them by
using "virtual" keyword before the prototype. If you put
the keyword "private" right after the "virtual" keyword,
the wrapper will not be a public method, but a private
one. You can do the same with "protected" to make a pro
tected wrapper.
Signals:
Signals are methods to which the user can bind other han
dlers and override the default handler. The default han
dler is basically the method body. This is the most ver
satile and flexible type of a method and also the slowest.
You need to specify a whole bunch of things when you
define a signal. One thing is when the default handler
will be run, first or last. You specify that by "first"
or "last" right after the "signal" keyword. Then you need
to define the gtk enum types (again without the GTK_TYPE_
prefix). For that you define the return types and the
GOB 1.0.10 12
GOB(1)GOB(1)
types of arguments after the "self" pointer (not including
the "self" pointer). You put it in the following syntax
"<return type> (<list of arguments>)". If the return type
is void, the type should be "NONE", the same should be for
the argument list. The rest of the prototype is the same
as for other method types. The body can also be empty,
and also there is a public method wrapper which you can
use for calling the signal just like a public method.
Example:
signal first INT(POINTER,INT)
int do_something(self, Gtk:Widget *w (check null type), int length)
{
...
}
or
signal last NONE(NONE) void foo(self);
If you don't want the wrapper that emits the signal to be
public, you can include the keyword "private" after the
"signal" keyword. This will make the wrapper a normal
private method. You can also make a protected wrapper by
using "protected" instead of "private".
If you don't define a "first" or a "last", the default
will be taken as "last".
You can also add additional flags. You do this just like
with the argument flags, although this is probably very
rare. These are the GTK_RUN_* flags, and you can add them
without the GTK_RUN_ prefix into a parenthesis, just after
the "signal" keyword. By default all public signals are
GTK_RUN_ACTION.
Since 1.0.6, gob creates wrapper signal macros for signal
connection typesafety, at least on gnu compilers. These
macros are named <type>_SIGNAL_<signal name>(func), where
func is the function pointer. This pointer must be of the
correct type, or you will get an initialization from wrong
pointer type warning. This macro, much like the argument
macros, wraps both the name and the function pointer
parameters. For example to connect a signal "changed" to
a function "foo", you would do:
gtk_signal_connect (GTK_OBJECT (object),
MY_OBJECT_SIGNAL_CHANGED (foo),
NULL);
Override methods:
GOB 1.0.10 13
GOB(1)GOB(1)
If you need to override some method (a signal or a virtual
method of some class in the parent tree of the new
object), you can define and override method. After the
"override" keyword, you should put the typename of the
class you are overriding a method from. Other then that
it is the same as for other methods. The "self" pointer
in this case should be the type of the method you are
overriding so that you don't get warnings during compila
tion. Also to call the method of the parent class, you
can use the PARENT_HANDLER macro with your arguments.
Example:
override (Gtk:Container) void
add (Gtk:Container *self (check null type), Gtk:Widget *wid (check null type))
{
/* some code here */
PARENT_HANDLER(self, wid);
}
If the function has a return value, then PARENT_HANDLER is
an expression that you can use. It will return whatever
the parent handler returned, or the "onerror" expression
if there was no parent handler.
Method names:
Inside the code, aliases are set for the methods, so that
you don't have to type the class name before each call,
just the name of the method. Example:
private int
foo(self)
{
return self->len;
}
private int
bar(self,int i)
{
return foo(self) + i;
}
Underscore removal (0.93.5+):
Sometimes this causes conflicts with other libraries. For
example a library might have already used the identifier
foo. You can prepend an underscore to the name in the
.gob file. This will make the local short alias have an
initial underscore, but it will not change the name of the
actual name of the function. For example:
class My:Object from Gtk:Object {
public void
_foo(self) {
GOB 1.0.10 14
GOB(1)GOB(1)
/* foo body */
}
public void
bar(self) {
/* short calling convention */
_foo(self);
/* long calling convention */
my_object_foo(self);
}
}
Thus you see that the "_foo" method still generates the
method "my_object_foo" just as "foo" would generate. You
can turn off this behavior if you depend on the old (pre
0.93.5) behavior with the --no-kill-underscores option.
This also means that if both "_foo" and "foo" are defined,
it is treated as a conflict.
This does not apply to override methods. Override methods
are special beasts and this is not necessary and would
make the code behave in weird ways.
Making new objects:
You should define a new method which should be a normal
public method. Inside this method, you can use the
GET_NEW macro that is defined for you and that will fetch
a new object, so a fairly standard new method would look
like:
public GtkObject *
new(void) {
GtkObject *ret = GET_NEW;
return GTK_OBJECT (ret);
}
You should not a subtle peculiarity of the GTK+ object
system here. If there is any code inside the GTK_OBJECT
macro argument, it will get executed multiple times. This
means that things such as GTK_OBJECT(GET_NEW) would actu
ally create 4 objects, leaking 3 of them. A good rule is
to be careful with all macros.
Self alias casts:
There are some standard casts defined for you. Instead of
using the full macros inside the .c file, you can use
SELF, IS_SELF and SELF_CLASS. Using these makes it easier
to for example change class names around.
Self alias types:
Since 0.93.5, there have also been defined the Self and
SelfClass types inside your .c file. These serve the same
GOB 1.0.10 15
GOB(1)GOB(1)
function as the above, they make it easier to type and
easier to change typenames around which can help a lot
during prototyping stage. However you should note that
the Self type should not be used in function prototypes as
one of the arguments or as a return value type. This is
because this is a simple C typedef which is only available
inside you aliases by passing --no-self-alias to
DEALING WITH DIFFERENT GOB VERSIONS
Defines:
In your generated C file, you can use the defines GOB_VER
SION_MAJOR GOB_VERSION_MINOR and GOB_VERSION_PATCHLEVEL if
you wish to for example use a feature that is only avail
able in some newer gob version. Note however that you can
only use these defines in the C code portions of your .gob
file, and #ifdef's cannot span multiple functions. Check
the BUGS section for more on using the C preprocessor and
gob. Also note that these have only been available since
the 0.92.1 version of gob.
Minimum version requires:
You can also make your .gob file require at least certain
version of gob. You do this by putting 'requires x.y.z'
(where x.y.z is the version number) outside of any C
block, comment or class, usually you should make this the
first line in the file or close to the top. If gob finds
this and the version of gob used to compile the code is
lower then that listed in the require, gob will generate
an error and exit. For example to require that gob ver
sion 0.92.1 or higher be used to compile a file, put this
at the top of that file:
requires 0.92.1
It should be noted however that this feature was not added
until 0.92.1, and so if the file gets compiled by a lower
version, gob would generate a syntax error. Thus by
putting in a requires line, you are implicitly requiring
at least 0.92.1.
C++ MODE
There is a C++ mode so that gob creates C++ compiler
friendly files. You need to use the --for-cpp argument to
gob. This will make the generated file have a .cc instead
of a .c extension, and several things will be adjusted to
make it all work for a C++ compiler. One thing that will
be missing is an alias to the new method, as that clashes
with C++, so instead you'll have to use the full name of
the method inside your code. Also note that gob does not
use any C++ features, this option will just make the
GOB 1.0.10 16
GOB(1)GOB(1)
generated code compile with a C++ compiler.
OVERRIDING THE GET_TYPE METHOD
The get_type is not really a method, but a function which
initializes your object. Recently objects appeared which
require you to make a custom get_type function (BonoboXOb
ject currently, see next section for direct BonoboXObject
support). So in 1.0.7 it is now possible to override this
function. To do so, just define a new public method
called get_type, with no arguments. Example:
public GtkType
get_type (void)
{
/* code goes here */
return some_type;
}
DIRECT BonoboXObject SUPPORT
If you want to build a BonoboXObject class gob has direct
support for these classes since 1.0.9. Just create a new
object that derives from Bonobo:X:Object. Then use a
"BonoboX" class flag with the interface name as an argu
ment. The interface name should be as you would type it
in C, that is with underscores as namespace separators.
Then you add the methods (using exact same names as in the
idl file) and prepend those methods with a BonoboX key
word. For example imagine you have an interface
GNOME/Foo/SomeInterface, with a method fooBar that takes a
single string:
class Foo:Some:Interface from Bonobo:X:Object
(BonoboX GNOME_Foo_SomeInterface) {
BonoboX
private void
fooBar (PortableServer_Servant servant,
const CORBA_char *string,
CORBA_Environment *ev)
{
Self *self = SELF (bonobo_object_from_servant (servant));
/* your code here */
}
/* rest of class */
}
Note that the implementation method can be private, in
fact that's probably a good idea to do. It won't work to
make this a signal, it can however be a virtual. Note
GOB 1.0.10 17
GOB(1)GOB(1)
that the method prototype must match the one from the
interface header file, or you will get a bad assignment
warning. You should check the header file generated by
orbit-idl and see the epv structure for the correct proto
types if you can't figure them out from the idl itself.
Also note that the first argument is not "self", but the
servant and you must use bonobo_object_from_servant func
tion to get the actual object pointer.
IDENTIFIER CONFLICTS
Gob will need to define some local variables and functions
in the generated files, so you need to take some precau
tion not to conflict with these. The general rule of
thumb is that all of these start with three underscores.
There is one, "parent_class" which doesn't because it's
intended for use in your code. For virtuals or signals,
you cannot use the identifier __parent__ which is used for
the parent of the object. You should actually never
access __parent__ either as it not guaranteed that it will
stay named this way. Data members cannot be named __par
ent__ nor _priv. For methods, you cannot use the identi
fiers "init" or "class_init" unless you mean the construc
tor methods. You shouldn't generally use 3 underscores
even in override method argument lists and virtual and
signal method names as it might confuse the PARENT_HANDLER
macro. In fact avoiding all names with three underscores
is the best policy when working with gob.
Also note that starting with version 0.93.5, method names
that start with a an underscore are equivalent to the
names without the initial underscore. This is done to
avoid conflicts with the aliases. Thus you can define the
method as "_name", if "name" happens to be some standard
library function. This is the same as defining it as
"name" except that the local alias will be "_name" rather
then "name".
There are a couple of defines which you shouldn't be
redefining in the code or other headers. These are SELF,
IS_SELF, SELF_CLASS, ARG, VAR, PARENT_HANDLER, GET_NEW,
GOB_VERSION_MAJOR, GOB_VERSION_MINOR and GOB_VER
SION_PATCHLEVEL.
As for types, there are Self and SelfClass types which are
only defined in your source files. Their generation (just
like the generation of the SELF macros) can be turned off,
see command line options.
USING GTK-DOC STYLE INLINE DOCUMENTATION
If you want to use gtk-doc style inline documentation for
your objects, you can do one of two things. First, you
could include the inline documentation comments in your %{
GOB 1.0.10 18
GOB(1)GOB(1)
%} section which will then be put verbatim into the output
source file. This is the way you should use for functions
you define outside of the class.
For class methods, you should use a gtk+ style comment,
however it can be indented any number of tabs or spaces
and you can use the short method name without the type
prefix. Gob will automatically try to extract these and
translate to full names and put them in the output source
file. An example would be:
class Gtk:Button:Example from Gtk:Button {
/**
* new:
*
* Makes a new #GtkButtonExample widget
*
* Returns: a new widget
**/
public
GtkWidget *
new(void)
{
return GTK_WIDGET(GET_NEW);
}
}
If the function you are documenting is a signal or a vir
tual then it will be documenting the wrapper that starts
that virtual function or emits that signal.
DEALING WITH CIRCULAR HEADERS
Sometimes you may need to use an object of type MyObjectA
in the MyObjectB class and vice versa. Obviously you
can't include headers for both. So you need to just
declare the typedef in the header of A for B, and the
other way around as well. The headers generated since
v0.92.2 include a protecting define before it declares the
typedef. This define is the __TYPEDEF_<upper case object
name>__. So inside my-object-a.h there will be this:
#ifndef __TYPEDEF_MY_OBJECT_A__
#define __TYPEDEF_MY_OBJECT_A__
typedef struct _MyObjectA MyObjectA;
#endif
Now instead of including my-object-a.h in the header sec
tion of my-object-b.gob, just copy the above code there
and you're set for using MyObjectA as a type in the method
parameters and public types.
Another way to get out of this problem is if you can use
those types only in the private members, in which case
GOB 1.0.10 19
GOB(1)GOB(1)
they won't be in the generated public header.
BUILDING WITH MAKE
If you are using normal makefiles, what you need to do is
to add a generic rule for .gob files. So you would
include the following in the Makefile and then just use
the .c and .h files as usual (make sure the space before
the 'gob' is a tab, not spaces):
%.c %.h %-private.h: %.gob
gob $<
BUILDING WITH AUTOCONF and AUTOMAKE
This is a little bit more involved. Basically the first
thing to do is to check for GOB in your configure.in file.
You can use the supplied m4 macro which will also check
the version of gob. Basically you include this:
GOB_CHECK(0.93.4)
This will replace @GOB@ in your makefiles with the full
path of gob. Thus when adding the generic rule to your
Makefile.am file, it should look like:
%.c %.h %-private.h: %.gob
@GOB@ $<
For Makefile.am you have to set up a couple more things.
First you have to include the generated .c and .h files
into BUILT_SOURCES variable. You have to include both the
.gob and the .c and .h files in the SOURCES for your pro
gram.
DEBUGGINGGOB does several things to make debugging the code easier.
First it adds preprocessor commands into the output c file
that point to the correct places in your .gob input file.
However sometimes there might be some bigger confusion and
this is just not helpful. In this case you will probably
want to have gcc point you directly at the generated
files. For this use the --no-lines command line option.
You should also note that these commands are not generated
for the public header file at all. If there is an error
which points you to the public header file, make sure you
fix this error in the .gob file, otherwise your changes
will not have any effect after gob recompiles the sources
again.
Sometimes you might want to know which method you are in
GOB 1.0.10 20
GOB(1)GOB(1)
for some debugging output. GOB will define __GOB_FUNC
TION__ macro, which is just a string constant with a
pretty name of the method.
BUGS
The lexer does not actually parse the C code, so I'm sure
that some corner cases or maybe even some not so corner
cases of C syntax might confuse gob completely. If you
find any, send me the source that makes it go gaga and
I'll try to make the lexer try to handle it properly, but
no promises.
Another thing is that gob ignores preprocessor macros.
Since gob counts braces, the following code won't work:
#ifdef SOME_DEFINE
if(foo) {
#else
if(bar) {
#endif
blah();
}
To make this work, you'd have to do this:
#ifdef SOME_DEFINE
if(foo)
#else
if(bar)
#endif
{
blah();
}
There is no real good way we can handle this without pars
ing C code, so we probably never will. In the future, I
might add #if 0 as a comment but that's about as far as I
can really take it and even that is problematic. Basi
cally, if you use gob, just don't use the C preprocessor
too extensively.
Comments will not get through to the generated files
unless inside C code. This is not the case for gtk-doc
style comments which are supported.
The short name aliases are actually implemented as point
ers to functions. Thus if you want to get the pointer of
a function using the short name alias you can't use the
'&'. Thus:
void (*foo)(Self *);
/* this will NOT work */
GOB 1.0.10 21
GOB(1)GOB(1)
foo = &short_name;
/* this will work */
foo = short_name;
/* Both of these will work */
foo = &my_class_long_name;
foo = my_class_long_name;
AUTHOR
George Lebl <jirka@5z.com>
GOB 1.0.10 22
