NAME

SYNOPSIS

DESCRIPTION

OPTIONS

-? -h --help

Display a simple help screen.

--version

Display version information

-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

Don´t touch output files unless they really changed (implies --no-touch-headers). Be careful with automake, see section PREVENTING SPURIOUS BUILDS.

--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 particular), 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 it would be empty.

--ondemand-private-header

Create the private header only if it would have something in it, that is, if there are some private data members or protected methods. This is the default.

--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.

--m4

Preprocess source with m4. Following args will be passed to m4.

--m4-dir

Print directory that will be searched for m4 files.

-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.

-o --output-dir

The directory into which output should be placed.

--file-sep[=c]

Replace default ´-´ file name separator. If no separator character is given then none is used. Only one character can be used.

TYPENAMES

OUTPUT FILES

INCLUDING NORMAL C CODE IN THE OUTPUT FILES

  %alltop{
        /* this will be at the very top of all output files */
  %}
  %ctop{
        /* this will be at the very top of the C file */
        /* Requires 2.0.18 */
  %}
  %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 */
  %}
  %afterdecls{
        /* between the declarations and the method implementations */
        /* Requires gob version 2.0.16 */
  %}
  %{
        /* will be included in the C file */
        void somefunc(int i)
        {
              /* some code */
        }
  %}

INCLUDE FILES

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 private header file below it. That is, if you use any private 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.

THE CLASS HEADER

  class Gtk:New:Button from Gtk:Button {
	  <class code>
  }

To make an abstract class (to pass G_TYPE_FLAG_ABSTRACT) add ´(abstract)´ before the curly braces above. This works since version 2.0.13.

DATA MEMBERS

  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;

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;

  SELF_GET_CLASS(object)->foo = 20;

Automatic Initialization:

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 arbitrary 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 initialize an integer to -1 and a string with a newly allocated string of "hello".

  public int foo = -1;
  private char *bar = {g_strdup("hello")};

Automatic Destruction:

Most data stored as pointers needs to have a function called when the object is finalized to either free the data. Gob will let you define a function to be called on the data the object is finalized. 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 char *foo = {g_strdup("bar")}
          destroywith g_free;

Sometimes you may want to run arbitrary code on destruction. While this can be perfectly well done in the finalize 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 "finalize" method of GObject. 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 routine or the following code:

  public GString *string = {g_string_new(NULL)}
          destroy {
	          if(VAR) g_string_free(VAR, TRUE);
	  };

The data is zeroed out after being destroyed. This is to make debugging easier in case your code might try to access an already finalized object. In case you have overridden the finalize 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 finalize override function.

Automatic Unreffing:

This is very much like the automatic destruction, but is instead run in the dispose method (it is among other places called from the "destroy" method of GtkObject). All data and other objects that you need to unref should be done here, and not at finalize time. The semantics are otherwise the same as for the "destroywith" and "destroy" keywords, except that you use "unrefwith" and "unref".

  public G:Object *foo = NULL
          unrefwith g_object_unref;
  public G:Object *bar = NULL
          unref {
		g_object_unref (VAR);
	  };

GOBJECT PROPERTIES

  private int height;
  property INT height
         (nick = _("Short nickname"),
          blurb = _("Long description"),
          minimum = 10,
          maximum = 200,
          default_value = 100)
        set { self->_priv->height = g_value_get_int (VAL); }
        get { g_value_set_int (VAL, self->_priv->height); };

The attributes are really optional though you should at least set some of them. All property types have a ´nick´ and a ´blurb´ attribute and you should set those accordingly. This will make runtime querying the object nicer as things such as gui editors and class browsers can be more verbose about the class itself. You can use the ´_("string")´ notation instead of just "string", and that will mark the string for translation.

Almost all types also have a ´default_value´ attribute which sets the initial value of this property (on object initialization, the set handler will be run automatically with this value). This value will be overridden if the user sets a value of this property on the call to g_object_new.

All the numeric types (including CHAR) have ´minimum´ and ´maximum´ attributes which can restrict the range. If you do not specify these the range will be the full range that the data type can handle.

Types such as UNICHAR and BOOLEAN only have the ´nick´, ´blurb´ and ´default_value´ attributes.

The ENUM type has an ´enum_type´ attribute which is the exact type of the enum. This is so that the property knows which exact type you can set, rather then just knowing it is an enum. You should always create an enum type specific for the enum itself (see section on the enum types)

Similarly FLAGS type has a ´flags_type´ which again you should set to the specific type of this flags data member.

There is a STRING type which has only the extra ´default_value´ attribute.

The OBJECT type is one of the types that doesn´t have a ´default_value´ and it only has an ´object_type´ attribute (in addition to nick and blurb of course) that is the exact object type that this property accepts. The object_type should be as a type, that is for example ´Gtk:Button´.

There is a BOXED type which is a pointer which has a boxed type defined (such that GObject knows how to copy and destroy this pointer). Here you will need to specify the ´boxed_type´ attribute with the specific type of the boxed pointer.

There is also a POINTER type, which has only the ´nick´ and ´blurb´ attributes. This is for storing arbitrary pointers. You should be careful with this one, as GObject knows nothing about the data stored at this pointer. It is somewhat like a ´void *´ type.

There is also the PARAM type for storing parameters with a ´param_type´ attribute.

You should notice that this list is pretty much like the list of g_param_spec_* functions from gobject/gparamspecs.h, and the attributes are like the arguments of those functions. Note however that value array is NOT supported yet.

You can also specify extra flags, such as CONSTRUCT or CONSTRUCT_ONLY using the ´flags´ attribute. You can specify multiple flags by oring them together with ´|´. These flags correspond to the GParamFlags enumeration except do not include the G_PARAM_ prefix. So for example to define an enumeration property, which is a CONSTRUCT_ONLY property, we could do the following:

  private SomeEnumerationType foo;
  property ENUM foo
         (nick = _("Short nickname"),
          blurb = _("Long description"),
          enum_type = Some:Enumeration:Type
          default_value = SOME_ENUMERATION_VALUE,
          flags = CONSTRUCT_ONLY,
          link);

The above example also gives an example of automatic linking to a standard data memember. By including the attribute ´link´ a get and set handlers will be automatically added without having to type them by hand. This is useful for a vast majority data types that are just linked to some standard data member and do not need to do anything extra on get or set.

Another extra feature of properties is the possibility of automatically exporing methods to get and set the property. That is without having to use g_object_set and g_object_get. This is achieved by adding an ´export´ attribute to the list of property attributes.

If you do not define a set or get handler, the property will automatically be only readable or writable as appropriate.

Gob2 also creates macros which can be used for type safe access to properties through g_object_set and g_object_get. The macros are called <type>_PROP_<argument name>(x) and <type>_GET_PROP_<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):

  g_object_set (G_OBJECT (object),
		MY_OBJECT_PROP_HEIGHT (7),
		NULL);

  int height;
  g_object_get (G_OBJECT (object),
		MY_OBJECT_GET_PROP_HEIGHT (&height),
		NULL);

To get bettery type safety on some of the property types, you can specify the ´type´ attribute which will add casts where appropriate in code dealing with this property. This is especially useful for POINTER and OBJECT types. But even for others.

You can also override properties from parent objects (that is override their implementation, not their attributes). Do this by adding the special ´override´ attribute. For example if the parent object had a ´height´ property then you could override it by

  private int height;
  property INT height
         (override)
        set { self->_priv->height = g_value_get_int (VAL); }
        get { g_value_set_int (VAL, self->_priv->height); };

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 following: "null", which tests pointers for being NULL, "type" which checks GTK+ object pointers for being the right type, "<test> <number>" which tests numeric arguments 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.

Function attributes:

For method that aren't virtual, signal or override methods, and aren't init or class_init, GLib function attribute macros G_GNUC_PRINTF, G_GNUC_SCANF, and G_GNUC_FORMAT can optionally be included after the argument list. Simply include an ´attr´ keyword and the C code to include in the file. You have to include braces and anything inside the braces will be printed into the header file after the function declaration and before the trailing semicolon. The braces themselves are not printed. For example:

  public void
  print (self, const char *format (check null), ...)
    attr {G_GNUC_PRINTF(2, 3)}

This will produce a prototype which will generate a warning at compile time if the contents of the format argument (argument number 2) aren't consistent with the types and number of the subsequent variadic arguments (the first of which is argument number 3). Only one ´attr´ keyword per method is allowed. If you have more than one attribute to include, you should put them all within the braces. Note that function attributes were aded in version 2.0.16.

Error return:

Methods which have a return value, there also has to be something returned if there is an error, such as if a precondition 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 prototype and any optional function attribute macros, 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 {
	  ...
  }

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. GOB2 will normally have the wrappers return whatever you specify with onerror or ´0´ if you haven´t specified anything. You can also specify a default return value with the keyword ´defreturn´. 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 ;

Constructor methods:

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 argument in the argument list. The argument will be usable in your function as a pointer to your object or class depending 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;
  }

Constructor, dispose, finalize methods:

Since 2.0.16, you can also easily add code to the object's constructor, dispose, and finalize methods. See GObject documentation on how these are run. The code you add will be run before calling the parents function for dispose and finalize, and after the parent function for constructor. The syntax is just like init and class_init. For example:

  constructor (self) {
	/* constructor method */
  }
  dispose (self) {
	/* dispose method */
  }
  finalize (self) {
	/* finalize method */
  }

Virtual methods:

Virtual methods are basically pointers in the class structure, so that one can override the method in derived methods. That is to implement the method in a derived class, you must then use an override method (more on those later). 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 functions, 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 protected wrapper.

Signals:

Signals are methods to which the user can bind other handlers and override the default handler. The default handler is basically the method body. This is the most versatile 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 GObject enum types (again without the G_TYPE_ prefix). For that you define the return types and the 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)
  {
	  ...
  }
  

  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 G_SIGNAL_* flags, and you can add them without the G_SIGNAL_ prefix into a parenthesis, just after the "signal" keyword. By default all public signals are G_SIGNAL_ACTION.

Also gob2 creates a wrapper macros for typesafe signal connection. That is you will be warned by the compiler if you pass a callback that is not the correct prototype. This will again only warn you on gcc, but it will compile without warning on another compiler. So as with all the typesafety hacks in gob, it is better to test your objects under gcc to get any warnings even if you are using a different compiler in the end.

The methods that are created for you are:

  <class_name>_connect__<signal_name> (<object>, <callback>, <data>)
  <class_name>_connect_after__<signal_name> (<object>, <callback>, <data>)
  <class_name>_connect_data__<signal_name> (<object>, <callback>, <data>,
                                            <destroy_notify>, <flags>)

These three functions correspond to the g_signal_connect, g_signal_connect_after and g_signal_connect_data functions that you would normally use, except they are for a specific signal. Also do note the two underscores between the method name and the signal name. For example to connect the signal "foo" on the object "Test:Object" you would do:

  test_object_connect__foo (object, callback, data);

To use BOXED in the signal arguments you need to tell gob which type of boxed argument you want to use. For this you can just add BOXED_GTK_TYPE_STRING instead of BOXED. For example BOXED_GTK_TYPE_TREE_ITER for GtkTreeIter. This works since version 2.0.13.

Override methods:

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 compilation. 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);
  }

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 type self_ instead of the name of the class. So to call a method called blah, you would use the name self_blah. Example:

  private int
  foo (self)
  {
	  return self->len;
  }
  
  private int
  bar (self, int i)
  {
	  return self_foo (self) + i;
  }

MAKING NEW OBJECTS

  public GObject *
  new (void) {
	  GObject *ret = GET_NEW;
	  return G_OBJECT (ret);
  }

You should not a subtle peculiarity of the GObject system here. If there is any code inside the G_OBJECT macro argument, it will get executed multiple times. This means that things such as G_OBJECT(GET_NEW) would actually create 4 objects, leaking 3 of them. A good rule (as with anywhere in C) is to be careful with all macros.

SELF REFERENCES

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:

There are also the Self and SelfClass types inside your .c file. These serve the same 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 your .c file and not in the header files. You can disable both the self casting macros and the self type aliases by passing --no-self-alias to gob.

DEALING WITH DIFFERENT GOB VERSIONS

In your generated C file, you can use the defines GOB_VERSION_MAJOR GOB_VERSION_MINOR and GOB_VERSION_PATCHLEVEL if you wish to for example use a feature that is only available 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.

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 gob2 version 2.0.0 or higher be used to compile a file, put this at the top of that file:

  requires 2.0.0

CREATING NEW ENUM, FLAGS and ERROR TYPES

You use the keywords ´enum´ ´flags´ and ´error´ as you would use the ´class´ keyword. Then you give a prefix for the values in the enumeration. Then you define a list of values just like in C. For ´enum´ types you can also specify the values assigned to each string. Then you specify the type in the standard gob style of specifying types. Here are a few examples of all of these:

  enum LAME_CLIENT {
        IS_CONNECTED,
        NONE = 9,
        LAST
  } Test:Enum;
  flags BUGA_BUGA {
        ONE,
        TWO,
        MANY,
  } Some:Flags;
  error TEST_OBJECT_ERROR {
        BAD_THIS,
        BAD_THAT
  } Test:Object:Error;

This will for example define an enum that is equivalent to the following C code:

  typedef enum {
        LAME_CLIENT_IS_CONNECTED,
        LAME_CLIENT_NONE = 9,
        LAME_CLIENT_LAST
  } TestEnum;

C++ MODE

OVERRIDING THE GET_TYPE METHOD

  public GType
  get_type (void)
  {
	/* code goes here */
	return some_type;
  }

INTERFACES

To define a class that implements an interface add a class flag ´interface´ with the type name of the interface as an argument. Then to implement a specific method of the interface, just add ´interface <typename>´ before the method definition. The method can, and probably should be, private.

The following example implements a new object, that implements the Gtk:Tree:Model interface and implements the get_flags method of that interface. Do note that except for standard (GTK+ and glib) specific interfaces which seem to have a non-standard name for the interface structure, the structure should end with and Iface, if you are implementing an interface. That is for example for the Gtk:Tree:Model, the structure containing the table of methods should be named GtkTreeModelIface.

  class Some:Object from G:Object
          (interface Gtk:Tree:Model)
  {
          /* function implemented for the Gtk:Tree:Model interface */
          interface Gtk:Tree:Model
          private GtkTreeModelFlags
          get_flags (Gtk:Tree:Model *self (check null type))
          {
          	/* Here would be the implementation */
          	return (GtkTreeModelFlags)0;
          }
  }

If you want to implement multiple interfaces just list more class flag lines as follows:

  class Some:Object from G:Object
          (interface Gtk:Tree:Model)
          (interface Gtk:Editable)
  {
          /* ... */
  }

DIRECT BonoboObject SUPPORT

  class Foo:Some:Interface from Bonobo:Object
    (BonoboObject GNOME_Foo_SomeInterface) {
          BonoboObject
          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 */
  }

DIRECT LIBGLADE SUPPORT

class My:Glade from Gtk:Window (GladeXML "gob-libglade.glade" "root")
{
  ....
}

class My:Glade from Gtk:Window (GladeXML GLADE_FILE "root")
{
  ....
}

#define GLADE_FILE "/path/to/file.glade"

You can declare widgets as data members by adding a 'GladeXML' to the definition.

private Gtk:Button * button1 GladeXML;

All signals created with glade are automatically connected if you defined those class methods in your class. For example suppose in glade that we set the "connect" signal on button1 to go to on_button1_clicked, then in our gob file we can just write:

public void
on_button1_clicked(self, GtkButton * button)
{
}

See the examples directory for a full example. Note that this feature requires version at least 2.0.12.

IDENTIFIER CONFLICTS

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, SELF_TYPE, ARG, VAR, PARENT_HANDLER, GET_NEW, GOB_VERSION_MAJOR, GOB_VERSION_MINOR and GOB_VERSION_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

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 (GtkWidget *)GET_NEW;
          }
  } 

DEALING WITH CIRCULAR HEADERS

  #ifndef __TYPEDEF_MY_OBJECT_A__
  #define __TYPEDEF_MY_OBJECT_A__
  typedef struct _MyObjectA MyObjectA;
  #endif

Another way to get out of this problem is if you can use those types only in the private members, in which case they won´t be in the generated public header.

BUILDING WITH MAKE

  %.c %.h %-private.h: %.gob
          gob2 $<

BUILDING WITH AUTOCONF and AUTOMAKE

  GOB2_CHECK([2.0.0])

  %.c %.h %-private.h: %.gob
          @GOB2@ $<

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 program.

PREVENTING SPURIOUS BUILDS

  foo_SOURCES = foo.gob foo.gob.stamp foo.c foo.h foo-private.h
  BUILT_SOURCES = foo.gob.stamp
  MAINTAINERCLEANFILES = foo.gob.stamp
  %.gob.stamp: %.gob
          @GOB2@ --no-touch $<
          @touch $@

DEBUGGING

Sometimes you might want to know which method you are in for some debugging output. GOB will define __GOB_FUNCTION__ macro, which is just a string constant with a pretty name of the method.

M4 SUPPORT

All the arguments after --m4 will be passed to m4 itself, so it has to be the last gob2 argument on the command line. This way you can specify arbitrary options to pass to m4.

BUGS

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();
  }

  #ifdef SOME_DEFINE
  if(foo)
  #else
  if(bar)
  #endif
  {
          blah();
  }

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 pointers 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 */
  foo = &self_short_name;
  /* this will work */
  foo = self_short_name;
  /* Both of these will work */
  foo = &my_class_long_name;
  foo = my_class_long_name;

AUTHOR

GOB2 Homepage: http://www.jirka.org/gob.html