[gob-dx.git] / doc / gob.1.in

.\"
.\" gob manual page
.\" (C) 1999 George Lebl <jirka@5z.com>
.\" 
.\" This manual page is covered by the terms of the GNU General
.\" Public License.  
.\"
.TH GOB 1 "GOB @VERSION@" 
.SH NAME
GOB \- The GTK+ Object Builder
.SH SYNOPSIS
.PP
.B gob [-?] [-h] [--help] [--version] [-w] [--exit-on-warn]
[--no-exit-on-warn] [--for-cpp] [--no-gnu] [--always-private-header]
[--no-private-header] [--no-touch-headers] file
.SH DESCRIPTION
.PP
GTK+ Object Builder is a simple preprocessor for easily creating
GTK+ objects.  It does not parse any C code and ignores any C errors.  It
is in spirit similar to things like lex or yacc.

.SH OPTIONS
.PP
.TP
.B -?
.TP
.B -h
.TP
.B --help
Display a simple help screen.
.TP
.B --version
Display version information (note, --version was not added until 0.92.0)
.TP
.B -w
.TP
.B --exit-on-warn
Exit with an error code even when you encounter a warning.
.TP
.B --no-exit-on-warn
Exit with an error only on errors, not on warnings, this is the default.
.TP
.B --for-cpp
Generate C++ code.
.TP
.B --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)
.TP
.B --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.
.TP
.B --always-private-header
Always create a \fB<basename>-private.h\fR file, even if it would be empty.
Otherwise, it is only created when there are private data members in the class.
This option implicitly negates --no-private-header
.TP
.B --no-private-header
Never create a private header file.  If we use any private data members,
define the private data structure at the point in the .c source where
the class definition begins.  This option implicitly negates
--always-private-header

.SH TYPENAMES
.PP
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.

.SH OUTPUT FILES
.PP
The filenames are created from the typename.  The words are
separated by '-' and all in lower case.  For example for an object named
"Gtk:New:Button", the files are \fBgtk-new-button.c\fR and
\fBgtk-new-button.h\fR.
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 \fB<basename>-private.h\fR (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.

.SH INCLUDING NORMAL C CODE IN THE OUTPUT FILES
.PP
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.  To
put the code in the output header file, start the code with a '%h{'.
For example:
.nf

  %h{
  /* will be included in the header */
  void somefunc(int i);
  %}

  %{
  /* will be included in the C file */
  void somefunc(int i)
  {
        /* some code */
  }
  %}

.fi

.SH INCLUDE FILES
.PP
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.
.PP
If you made any data members private, gob will also create a source file
that will be called \fB<basename>-private.h\fR.  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.

.SH MAKING A NEW CLASS
.PP
The class header:
.PP
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:
.nf

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

.fi
.PP
Data members:
.PP
There are four types of data members.  Three of them are normal
data numbers, and one is a virtual one, usually linked to a normal
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:
.nf

  public int i;
  private GtkWidget *h;
  protected long k;

.fi
.PP
Public and protected data members are accessed normally as members of
the object struct.  Example where 'i' is as above a public data member:
.nf

  object->i = 1;

.fi
.PP
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):
.nf

  object->_priv->h = NULL;

.fi
The _priv structure is defined in the \fB<basename>-private.h\fR.
This file is automatically included if you don't include it yourself.  You
should always explicitly include it if you explicitly also include the main
header file.
.PP
In case you use the \fB--no-private-header\fR option, no
private header file is created and you can only access the _priv pointer
below the class definition in the .gob file.
.PP
The fourth type is an argument type.  It is a named data member which
is one of the features of the GTK+ object system.  You need to define a get
and a set handler.  They are fragments of C code that will be used to 
get the value or set the value of the argument.  Inside them you can use the
define ARG to which you assign the data or get the data.  You can also use
the identifier "self" as pointer to the object instance.  The type is
defined as one of the gtk type enums, but without the GTK_TYPE_ prefix.
For example:
.nf

  public int height;
  argument INT height set { self->height = ARG; } get { ARG = self->height; };

.fi
.PP
If you don't define a set or a get handler it will be a read-only
or a write-only argument.  If you want to add extra argument flags, add
them into parenthesis after the argument keyword, separated by '|' and
without the GTK_ARG_ prefix.  For example:
.nf

  public int height;
  argument (CONSTRUCT) INT height get { ARG = self->height; };

.fi
This makes the argument settable even before the object is constructed, so
that people can pass it to gtk_object_new function.  Useful is also
CONSTRUCT_ONLY flag which makes the argument only available during
construction of the object.
.PP
Since 0.92.1, gob creates macros which can be used for type safe access to
gtk arguments.  The macros are called <type>_ARG_<argument name>(x) and
<type>_GET_ARG_<argument name>(x).  They define both the string and the
value part of the argument.  So for setting an argument of height, one would
use (for object type My:Object):
.nf

  gtk_object_set(GTK_OBJECT(object),
                 MY_OBJECT_ARG_HEIGHT(7),
                 NULL);

.fi
And for getting, you would use:
.nf

  int height;
  gtk_object_set(GTK_OBJECT(object),
                 MY_OBJECT_GET_ARG_HEIGHT(&height),
                 NULL);

.fi
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.
.PP
To get good type safety on POINTER types however, you should specify
an optional C type that gob should use.  For other then POINTER types
this is redundant but possible.  To do this, place '(type <c type>)'
right after the GTK+ type.  Example:
.nf

  argument POINTER (type char *) foo set { /* foo */ } get { /* bar */ };

.fi
.PP
Methods:
.PP
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.
.PP
Argument lists:
.PP
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 ':'
.nf
<type> <argument id>
or
<type> <argument id> (check <list of checks>)
.fi
.PP
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:
.nf
  
  public int foo(self, int h (check > 0 < 11), Gtk:Widget *w (check null type))

.fi
.PP
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.
.PP
Error return:
.PP
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 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:
.nf

  public void * get_something(self, int i (check >= 0)) onerror NULL {
          ...
  }

.fi
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.
.PP
Constructor methods:
.PP
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:
.nf

  init(object) {
          /* initialize the object here */
          object->a = 9;
          object->b = 9;
  }

  class_init(class) {
          /* initialize the class, this is rarely needed */
          class->blah = NULL;
  }

.fi
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.  Sometimes you need
some arguments, for this you should either use a construct method and a
new function like many GTK+ widgets, and/or a CONSTRUCT or CONSTRUCT_ONLY
type of an argument.
.PP
Virtual methods:
.PP
Virtual methods are basically pointers in the class structure,
so that one can override the method in derived methods.  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.
.PP
Signals:
.PP
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 gtk enum types (again
without the GTK_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:
.nf

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

.fi
.PP
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".
.PP
If you don't define a "first" or a "last", the default will be taken as
"last".
.PP
Override methods:
.PP
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:
.nf

  override (Gtk:Container) void
  add (Gtk:Container *self (check null type), Gtk:Widget *wid (check null type))
  {
          /* some code here */
          PARENT_HANDLER(self, wid);
  }

.fi
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.
.PP
Calling methods:
.PP
Inside the code, pointers are set for the methods, so that you don't
have to type the class name before each call, just the name of the method.
Example:
.nf

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

.fi
.PP
Making new objects:
.PP
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:
.nf

  public GtkObject *
  new(void) {
          GtkObject *ret;
          ret = GTK_OBJECT (GET_NEW);
          return ret;
  }

.fi
.PP

.SH DEALING WITH DIFFERENT GOB VERSIONS
.PP
Defines:
.PP
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.  Also note that these
have only been available since the 0.92.1 version of gob.
.PP
Minimum version requires:
.PP
You can also make your .gob file require at least certain version of gob.  You
do this by putting 'requires x.y.z' (where x.y.z is the version number) outside
of any C block, comment or class, usually you should make this the first line
in the file or close to the top.  If gob finds this and the version of gob used
to compile the code is lower then that listed in the require, gob will generate
an error and exit.  For example to require that gob version 0.92.1 or higher
be used to compile a file, put this at the top of that file:
.nf

  requires 0.92.1

.fi
It should be noted however that this feature was not added until 0.92.1, and
so if the file gets compiled by a lower version, gob would generate a 
syntax error.  Thus by putting in a requires line, you are implicitly
requiring at least 0.92.1.

.SH C++ MODE
.PP
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.

.SH IDENTIFIER CONFLICTS
.PP
Gob will need to define some local varibles 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.

.SH BUGS
.PP
Also 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.
.PP
Another thing is that gob ignores preprocessor macros.  Since gob counts
braces, the following code won't work:
.nf

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

.fi
To make this work, you'd have to do this:
.nf

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

.fi
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.
.PP
Comments will not get through to the generated files unless inside C code.
This makes using something like gtk-doc harder.  However I'm planning to
fix this somehow.

.SH AUTHOR
.PP
George Lebl <jirka@5z.com>