.TP
.B --no-write
Do not write any output files, just check syntax of the input file.
+.TP
+.B --no-lines
+Do not print out the '#line' statements into the output. Useful for debugging
+the autogenerated generated code.
+.TP
+.B --no-self-alias
+Do not create the Self and SelfClass type aliases and the SELF, IS_SELF
+and SELF_CLASS macros.
+.TP
+.B --no-kill-underscores
+Do not remove the initial underscore from method names.
.SH TYPENAMES
.PP
.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;
.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.
+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.
.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
+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.
+.PP
+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
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
+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:
.nf
.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.
+Also note that this is always called in the "destroy" method of GtkObject.
+It is always called after any user defined body of the destroy handler.
.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
+will then be inserted into the "destroy" 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
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
+The data is zeroed out after being destroyed. This is to make debugging easier
+in case your code might try to access an already destroyed object. In case
+you have overriden the destroy 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 destroy override function.
+.PP
GTK+ Arguments:
.PP
The fourth type of a data member an argument type. It is a named data member
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
you can use. It will return whatever the parent handler returned, or the
"onerror" expression if there was no parent handler.
.PP
-Calling methods:
+Method names:
.PP
-Inside the code, pointers are set for the methods, so that you don't
+Inside the code, aliases 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
.fi
.PP
+Underscore removal (0.93.5+):
+.PP
+Sometimes this causes conflicts with other libraries. For example a library
+might have already used the identifier foo. You can prepend an underscore to
+the name in the .gob file. This will make the local short alias have an
+initial underscore, but it will not change the name of the actual name of the
+function. For example:
+.nf
+ class My:Object from Gtk:Object {
+ public void
+ _foo(self) {
+ /* foo body */
+ }
+ public void
+ bar(self) {
+ /* short calling convention */
+ _foo(self);
+ /* long calling convention */
+ my_object_foo(self);
+ }
+ }
+.fi
+Thus you see that the "_foo" method still generates the method "my_object_foo"
+just as "foo" would generate. You can turn off this behaviour if you depend
+on the old (pre 0.93.5) behaviour with the --no-kill-underscores option. This
+also means that if both "_foo" and "foo" are defined, it is treated as a
+conflict.
+.PP
+This does not apply to override methods. Override methods are special beasts
+and this is not neccessary and would make the code behave in weird ways.
+.PP
Making new objects:
.PP
You should define a new method which should be a normal public method. Inside
.fi
.PP
-Casts:
+Self alias 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.
+these makes it easier to for example change classnames around.
+.PP
+Self alias types:
+.PP
+Since 0.93.5, there have also been defined 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 you
+.c file. You can disable both the self casting macros and the self type
+aliases by passing --no-self-alias to
.SH DEALING WITH DIFFERENT GOB VERSIONS
.PP
PARENT_HANDLER macro. In fact avoiding all names with three underscores is
the best policy when working with gob.
.PP
+Also note that starting with version 0.93.5, method names that start with a
+an underscore are eqivalent to the names without the initial underscore. This
+is done to avoid conflicts with the aliases. Thus you can define the method
+as "_name", if "name" happens to be some standard library function. This is
+the same as defining it as "name" except that the local alias will be "_name"
+rather then "name".
+.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.
+.PP
+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.
.SH USING GTK-DOC STYLE INLINE DOCUMENTATION
.PP
in the private members, in which case they won't be in the generated public
header.
+.SH BUILDING WITH MAKE
+.PP
+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 'gob' is a tab, not spaces):
+.nf
+
+ %.c %.h %-private.h: %.gob
+ gob $<
+
+.fi
+
+.SH BUILDING WITH AUTOCONF and AUTOMAKE
+.PP
+This is a little bit more involved. Basically the first thing to do is to
+check for GOB in your configure.in file. You can use the supplied m4 macro
+which will also check the version of gob. Basically you include this:
+.nf
+
+ GOB_CHECK(0.93.4)
+
+.fi
+This will replace @GOB@ in your makefiles with the full path of gob. Thus
+when adding the generic rule to your Makefile.am file, it should look like:
+.nf
+
+ %.c %.h %-private.h: %.gob
+ @GOB@ $<
+
+.fi
+.PP
+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.
+
.SH BUGS
.PP
Also the lexer does not actually parse the C code, so I'm sure that some corner
projects / gob-dx.git / blobdiff