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
+.B gob
+[ option ] ...
+file
.SH DESCRIPTION
.PP
GTK+ Object Builder is a simple preprocessor for easily creating
.B --for-cpp
Generate C++ code.
.TP
+.B --no-extern-c
+Never add the extern "C" to the header.
+.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
define the private data structure at the point in the .c source where
the class definition begins. This option implicitly negates
--always-private-header
+.TP
+.B -n
+.TP
+.B --no-write
+Do not write any output files, just check syntax of the input file.
.SH TYPENAMES
.PP
.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:
+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 \fIsections\fR 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. For example:
.nf
+ %alltop{
+ /* this will be on top of all output files */
+ %}
+
+ %headertop{
+ /* this will be on top of the public header */
+ %}
+
+ %privateheader{
+ /* this will go into the private header file */
+ %}
+
%h{
/* will be included in the header */
void somefunc(int i);
%}
+ %a{
+ /* will be included in all files */
+ %}
+
%{
/* will be included in the C file */
void somefunc(int i)
.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:
+There are five types of data members. Three of them are normal data numbers,
+one is class wide (global) in scope and one is a virtual one, usually linked to
+a normal data member or a class wide data member. The three normal data
+members are public, protected and private. Public and protected are basically
+just entries in the object 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 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:
+Classwide data members:
+.PP
+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:
+.nf
+
+ classwide int foo;
+
+.fi
+To access the member you do the standard voodoo of getting the class from the
+object and casting it to your class pointer. Thus the following would work:
+.nf
+
+ SELF_CLASS(GTK_OBJECT(object)->klass)->foo = 20;
+
+.fi
+.PP
+Automatic Initialization (0.93.0 and higher only):
+.PP
+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".
+.nf
+
+ public int foo = -1;
+ private char *bar = {g_strdup("hello")};
+
+.fi
+.PP
+Automatic Destruction (0.93.0 and higher only):
+.PP
+Most data stored as pointers needs to have a function called when the object
+is destroyed, to either free it or give up a reference. Gob will let you
+define a function to be called on the data the object is destroyed. This is
+achieved by putting 'destroywith' followed by a function name after the
+variable definition. It is only called if the data you defined this on
+is not NULL, so you cans specify functions which do not handle NULL. It
+is very much like the GDestroyNotify function used in GTK+ and glib in many
+places. Unlike many other places, gob will not enforce any kind of type
+safety here so be a little bit more careful. Any function you give it will
+be called as a "void function(void *)". It will in fact be cast into such
+a form before called. This is to avoid spurious warnings for gtk calls to
+subclass methods. The function needs not be of that form, 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:
+.nf
+
+ public Gtk:Widget *window = NULL
+ destroywith gtk_widget_destroy;
+ public char *foo = {g_strdup("bar")}
+ destroywith g_free;
+
+.fi
+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 GtkObject.
+.PP
+Sometimes you may want to run arbitrary code on destruction. While this can
+be perfectly well done in the destroy handler. Depending on the style you
+may want to include all destruction/initialization code together with the
+definition of the data member. Thus you may want to put arbitrary code which
+will then be inserted into the "finalize" method of GtkObject. This can be
+done with the "destroy" keyword followed by arbitrary code in curly braces.
+Inside this code a macro called VAR will be define which refers to your
+variable. So for example destroying a GString can be either done with
+a helper routine or the following code:
+.nf
+
+ public GString *string = {g_string_new(NULL)}
+ destroy {
+ if(VAR) g_string_free(VAR, TRUE);
+ };
+
+.fi
+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.
+.PP
+GTK+ Arguments:
+.PP
+The fourth type of a data member an argument type. It is a named data member
+which is one of the features of the GTK+ object system. You need to define a
+get and a set handler. They are fragments of C code that will be used to get
+the value or set the value of the argument. Inside them you can use the define
+ARG to which you assign the data or get the data. You can also use the
+identifier "self" as pointer to the object instance. The type is defined as
+one of the gtk type enums, but without the GTK_TYPE_ prefix. For example:
.nf
public int height;
.fi
.PP
+Sometimes it can become tiresome to type in the set and get handlers if
+they are trivial. So gob since version 0.93.0 provides automatic argument
+linking to data members. There are three different cases it handles, direct
+link (keyword 'link'), string linking (keyword 'stringlink') and object
+linking (keyword 'objectlink'). You just place the keyword after the argument
+name instead of the get/set handlers. It will link to a data member of the
+same name that was defined earlier in the input file. Best is to see examples:
+.nf
+
+ public int foo;
+ argument INT foo link;
+
+.fi
+is just like
+.nf
+
+ public int foo;
+ argument INT (type int) foo
+ get { ARG = self->foo; }
+ set { self->foo = ARG; };
+
+.fi
+Similiarly,
+.nf
+
+ private char * foo;
+ argument POINTER foo stringlink;
+
+.fi
+is just like
+.nf
+
+ private char * foo;
+ argument POINTER (type char *) foo
+ get {
+ ARG = self->_priv->foo;
+ } set {
+ g_free(self->_priv->foo);
+ self->_priv->foo = g_strdup(ARG);
+ }
+
+.fi
+And for the objectlink we would have:
+.nf
+
+ public Gtk:Object * foo;
+ argument POINTER foo objectlink;
+
+.fi
+is just like
+.nf
+
+ protected Gtk:Object * foo;
+ argument POINTER (type Gtk:Object *) foo
+ get {
+ ARG = self->foo;
+ } set {
+ if(self->foo)
+ gtk_object_unref(self->foo);
+ self->foo = ARG;
+ if(self->foo)
+ gtk_object_ref(self->foo);
+ }
+
+.fi
+.PP
+As you see it will handle NULLs correctly (for the string, g_free and g_strdup
+handle NULLs). And it will also handle private, protected and public members.
+Also you should notice that when the get is used, only a pointer is always
+returned for both objectlink and strinklink. So you should treat the returned
+value with care and never free it (and notice that it will only be around
+until you set the argument to something else or destroy the object).
+.PP
Methods:
.PP
There is a whole array of possible methods. The three normal,
regular public, private or protected methods, however it is acceptable for
non-void virtual, signal and override methods.
.PP
-Argument lists:
+Function 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",
case there isn't a parent method, PARENT_HANDLER will return it. More about
this later.
.PP
+Default return:
+.PP
+Some signal and virtual methods have a return type. But what happens if
+there is no default handler and no one connects to a signal. GOB will
+normally have the wrappers return whatever you specify with onerror or '0'
+if you haven't specified anything. But since 0.93.2 you can specify a default
+return value with the keyword 'defreturn'. It's use is identical to the
+use of onerror, and you can in fact use both at the same time. Example
+.nf
+
+ virtual int get_some_int(self) onerror -1 defreturn 10 ;
+
+.fi
+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.
+.PP
Constructor methods:
.PP
There are two methods that handle the construction of an object, init and
For example:
.nf
- init(object) {
+ init(self) {
/* initialize the object here */
- object->a = 9;
- object->b = 9;
+ self->a = 9;
+ self->b = 9;
}
class_init(class) {
If you don't define a "first" or a "last", the default will be taken as
"last".
.PP
+You can also add additional flags. You do this just like with the argument
+flags, although this is probably very rare. These are the GTK_RUN_* flags,
+and you can add them without the GTK_RUN_ prefix into a parenthesis, just
+after the "signal" keyword. By default all public signals are GTK_RUN_ACTION.
+.PP
Override methods:
.PP
If you need to override some method (a signal or a virtual method
.fi
.PP
+Casts:
+.PP
+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 classnames around. There is
+however no self type, so if you're declaring a pointer to your object, you
+still have to use the full type.
.SH DEALING WITH DIFFERENT GOB VERSIONS
.PP
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.
+.PP
+There are a couple of defines which you shouldn't be redefining in the code
+or other headers. These are SELF, IS_SELF, SELF_CLASS, ARG, VAR,
+PARENT_HANDLER, GET_NEW, GOB_VERSION_MAJOR, GOB_VERSION_MINOR and
+GOB_VERSION_PATCHLEVEL.
+
+.SH USING GTK-DOC STYLE INLINE DOCUMENTATION
+.PP
+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.
+.PP
+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:
+.fi
+
+ class Gtk:Button:Example from Gtk:Button {
+ /**
+ * new:
+ *
+ * Makes a new #GtkButtonExample widget
+ *
+ * Returns: a new widget
+ **/
+ public
+ GtkWidget *
+ new(void)
+ {
+ return GTK_WIDGET(GET_NEW);
+ }
+ }
+
+.fi
+If the function you are documenting is a signal or a virtual then it will
+be documentating the wrapper that starts that virtual function or emits
+that signal.
+
+.SH DEALING WITH CIRCULAR HEADERS
+.PP
+Sometimes you may need to use an object of type MyObjectA in the MyObjectB
+class and vice versa. Obviously you can't include headers for both. So you
+need to just declare the typedef in the header of A for B, and the other way
+around as well. The headers generated since v0.92.2 include a protecting
+define before it declares the typedef. This define is the
+__TYPEDEF_<upper case object name>__. So inside my-object-a.h there will be
+this:
+.nf
+
+ #ifndef __TYPEDEF_MY_OBJECT_A__
+ #define __TYPEDEF_MY_OBJECT_A__
+ typedef struct _MyObjectA MyObjectA;
+ #endif
+
+.fi
+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.
+.PP
+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.
.SH BUGS
.PP
projects / gob-dx.git / blobdiff