.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
.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
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
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
projects / gob-dx.git / blobdiff