GOB \- The GTK+ Object Builder
.SH SYNOPSIS
.PP
-.B gob
+.B gob [-?] [-h] [-w] [--exit-on-warn] [--no-exit-on-warn] [--for-cpp]
+[--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
+Display a simple help screen.
+.TP
+.B -w
+.TP
+.B --exit-on-warn
+Exit with an errorcode 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-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.
+.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 datamembers,
+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. For "Gtk:New:Button",
-the macro will be GTK_IS_NEW_BUTTON. This format of typenames is used in
-the class declaration header and for method argument types.
+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 FILE NAMES
+.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 gtk-new-button.c and gtk-new-button.h.
+"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 editted 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
+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 */
+ /* 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:
.fi
.PP
-The private members are not currently protected from outside use,
-they are just marked by a comment in the header file, this will most likely
-be somehow solved in some future version.
+Public datamembers 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. 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
+Note that 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. 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 third type is an argument type. It is a named datamember which
is one of the features of the GTK+ object system. You need to define a get
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.
.PP
Methods:
.PP
normal functions with a prototype in the 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. You can also
-define init and init_class methods with a special definition if you want
+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.
.PP
Argument lists:
.PP
-For all but the init and init_class methods, you use the
+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
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
+output, they just delimit the string. For example:
.nf
public void * get_something(self, int i (check >= 0)) onerror NULL {
.fi
.PP
+Constructor methods:
+.PP
+There are two methods that handle the cosntruction 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,
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.
+prototype. If you put the keyword "private" right after the "virtual"
+keyword, the wrapper will not be a public method, but a private one.
.PP
Signals:
.PP
.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.
+.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
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. Example:
+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, defines are set for the methods, so that you don't
-have to type the class name before each call. Example:
+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
will fetch a new object, so a fairly standard new method would look like:
.nf
- public GtkWidget *
+ public GtkObject *
new(void) {
GtkObject *ret;
ret = GTK_OBJECT (GET_NEW);
.fi
+.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 extention, 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 BUGS
.PP
-The generated header file is included as the first file in the .c file, no
-matter what. This means that you will have to put things that need to be included
-before that, into an %h{ } section.
+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.
.SH AUTHOR
.PP
projects / gob-dx.git / blobdiff