Provided by: gob2_2.0.20-1_amd64 bug

NAME

       GOB2 - The GObject Builder

SYNOPSIS

       gob2 [ option ] ...  file

DESCRIPTION

       GObject Builder is a simple preprocessor for easily creating GObject objects.  It does not
       parse any C code and ignores any C errors.  It is in spirit similar to things like lex  or
       yacc.   In  some ways it also resembles java.  But it is really just a simple preprocessor
       for creating GObjects for use in C or C++ and it is not a programming language.

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.

       --gtk3 Use gtk3.

TYPENAMES

       Because we need to parse out different parts  of  the  typename,  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
       declaration header and for method argument types.

OUTPUT FILES

       The filenames are created from the typename.  The words are separated by ´-´ (this can  be
       changed  with  --file-sep  option) 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++  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.  Sometimes 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.   When you want code to appear as in alltop but only in the
       cfile you use the ´ctop´ (or ´ct´) section.  Note that ctop  requires  2.0.18.    Finally,
       ´afterdecls´  includes  code  between the declarations and the method implementations, but
       note that ´afterdecls´ requires version 2.0.16.  For example:

         %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

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

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

       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

       There are five types of data members.  Three of them are normal data members, 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 structure, while
       private has it´s own dynamically  allocated  private  structure.   Protected  members  are
       always  put  after  the public one in the structure and are marked protected 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>-private.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 protected 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;

       To access the member you can use the SELF_GET_CLASS macro (or  YOUR_OBJECT_NAME_GET_CLASS)
       to get at the class.  Thus the following would work:

         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;

       Note that the function name you give must be a real function and  not  macro.   Also  note
       that this is always called in the "finalize" method of GObject.  It is always called after
       any user defined body of the finalize handler.

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

       The fourth type of a data member a property type.  It is a named data member which is  one
       of  the  features  of the GObject system.  It just defines a way to get and set some data,
       but you have to take care of storing that data somewhere.  So it is normal to also have  a
       normal  private  (or public) data member where you store the real data.  You normally 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 VAL to
       which you assign the data or get the data.  You should treat this VAL as  a  GValue  which
       stores the data of the correct type.  You can also use the identifier "self" as pointer to
       the object instance.  The type is defined as one of the GObject type  enums,  but  without
       the  G_TYPE_ prefix.  There are also some attributes of a property which you can set.  For
       example the following is a definition of  an  integer  property  ´height´  which  will  be
       synchronized with a private integer data member also of the name ´height´.

         private int height;
         property INT height
                (
                 name = "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.

       The ´name´ property is canonical name of property. It is useful when you try to  implement
       properties with no C names like ´vertical-scroll´. The ´name´ property can be omitted.

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

       And for getting, you would use:

         int height;
         g_object_get (G_OBJECT (object),
                 MY_OBJECT_GET_PROP_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.  For complete type safety it is
       useful to use the get/set methods that are defined by using the ´export´ attribute.

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

       Overriding is supported since gob 2.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 functions 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 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 {
              ...
         }

       The onerror value is also used in overrides that have a return value, in case there  isn´t
       a parent method, PARENT_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.  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 ;

       That  is  an empty virtual method (in C++ terms a pure virtual).  If you never specify any
       handler for it in the derived children it will just return 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;
         }

       The  class_init  function  is  very  rarely needed as all standard 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.

       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 */
         }

       You can also just override those methods as usual, but the above is much easier and nearly
       as flexible.

       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)
         {
              ...
         }

       or

         signal last NONE (NONE) void foo (self);

       You can include name of signal, if this name is not a C variable name. Example:

         signal first INT "do-something" (POINTER, INT)
         int do_something (self, Gtk:Widget *w (check null type), int length)
         {
              ...
         }

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

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

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

       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:

       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

       Defines:

       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  can  create  new GObject ENUM, FLAGS and GError types for use in your classes easily.
       Glib includes some utilities for handling these, however it may  be  cleaner  to  use  the
       below  specified  way  in  your classes.  It also then doesn´t require any Makefile setup.
       Make sure this is defined in the same section as the class, that is  not  in  any  of  the
       ´%?{´ ´%}´ sections.

       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

       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 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.  So it  is
       possible  to  override  this  function.   To do so, just define a new public method called
       get_type, with no arguments.  Example:

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

INTERFACES

       Currently gob will only allow you to implement interfaces (that  is,  define  new  classes
       which  implement an interface) and doesn´t yet have support for making new interfaces, but
       this will be coming at some point in the future.

       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

       If you want to build a BonoboObject class gob2 has direct support for these.  Just  create
       a  new  object that derives from Bonobo:Object.  Then use a "BonoboObject" class flag with
       the interface name as an argument.  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  BonoboObject
       keyword.  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: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 */
         }

       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 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 prototypes 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 function to get the actual object pointer.

DIRECT LIBGLADE SUPPORT

       Gob can simplify writing a libglade class.  Just create a new object that derives  from  a
       GtkContainer  widget.   Then  use  a  "GladeXML" class flag with the glade file name, root
       widget and optional domain  as arguments between double quotes.  For example:

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

       Note however that then "gob-libglade.glade" would have to be  in  the  current  directory.
       You  could  specify  a path, but that may not work for all installations.  You can replace
       the glade filename with a token to be used in the generated .c file and you can then  have
       a macro with the filename, as follows:

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

       And somewhere in your header files you would have

       #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;

       This will automatically set the "button1" from the GladeXML file.

       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

       Gob will need to define some local variables and functions in the generated files, so  you
       need  to  take  some  precaution 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 __parent__ nor _priv.  For methods, you cannot use  the
       identifiers "init" or "class_init" unless you mean the constructor 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.

       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

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

       If the function you are documenting is a signal or a virtual 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
       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 section 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 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 ´gob2´ is a tab, not spaces):

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

BUILDING WITH AUTOCONF and AUTOMAKE

       This is a little bit more involved.  Basically the first thing to do is to check for  GOB2
       in  your  configure.in  file.  You can use the supplied m4 macro which will also check the
       version of gob.  Basically you include this:

         GOB2_CHECK([2.0.0])

       This will replace @GOB2@ in your makefiles with the full path of gob2.  Thus  when  adding
       the generic rule to your Makefile.am file, it should look like:

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

       When  nothing has changed you might not really want to rebuild everything and gob provides
       options --no-touch (since 2.0.13) and --no-touch-headers to avoid this.  When working with
       build systems such as automake you have to be more careful as just using those options can
       cause automake to get confused and you will need to use something like the following:

         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

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

       It is possible to have your .gob file also preprocessed by m4.  This is useful if you have
       a lot of files and you´d like to have some preprocessor put in some common features.   All
       you  have  to do is add --m4 to the command line of gob2 and gob2 will first run your file
       through m4.  You can print the directory that is searched for m4 files  by  running  "gob2
       --m4-dir"

       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

       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 parsing 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.  Basically, if you use gob,  just  don´t  use
       the C preprocessor too extensively.  And if you use it make sure that you do not cross the
       boundaries of the C code segments.

       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

       George Lebl <jirka@5z.com>

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

                                           GOB2 2.0.20                                    GOB2(1)