.TP
.B --no-kill-underscores
Do not remove the initial underscore from method names.
+.TP
+.B --always-private-struct
+Always include the private pointer in the public header file. This is useful for
+files which are part of a library and you want to reserve the right to add some
+private data members without breaking binary compatibility.
.SH TYPENAMES
.PP
use (for object type My:Object):
.nf
- gtk_object_set(GTK_OBJECT(object),
- MY_OBJECT_ARG_HEIGHT(7),
- NULL);
+ 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);
+ 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.
private char * foo;
argument POINTER (type char *) foo
get {
- ARG = self->_priv->foo;
+ ARG = g_strdup(self->_priv->foo);
} set {
g_free(self->_priv->foo);
self->_priv->foo = g_strdup(ARG);
.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).
+For objectlink, just a pointer is returned on get, if you wish to keep it around,
+you should call gtk_object_ref on it. For stringlink, get makes a copy of
+the string which you should free after use. This is the behaviour since 1.0.2.
.PP
Methods:
.PP
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
+Since 1.0.6, gob creates wrapper signal macros for signal connection
+typesafety, at least on gnu compilers. These macros are named
+<type>_SIGNAL_<signal name>(func), where func is the function pointer. This
+pointer must be of the correct type, or you will get an initialization from
+wrong pointer type warning. This macro, much like the argument macros, wraps
+both the name and the function pointer parameters. For example to connect a
+signal "changed" to a function "foo", you would do:
+.nf
+
+ gtk_signal_connect (GTK_OBJECT (object),
+ MY_OBJECT_SIGNAL_CHANGED (foo),
+ NULL);
+
+.fi
+.PP
Override methods:
.PP
If you need to override some method (a signal or a virtual method
public GtkObject *
new(void) {
- GtkObject *ret;
- ret = GTK_OBJECT (GET_NEW);
- return ret;
+ GtkObject *ret = GET_NEW;
+ return GTK_OBJECT (ret);
}
.fi
.PP
+You should not a subtle peculiarity of the GTK+ object system here. If there is any
+code inside the GTK_OBJECT macro argument, it will get executed multiple times. This
+means that things such as GTK_OBJECT(GET_NEW) would actually create 4 objects, leaking
+3 of them. A good rule is to be careful with all macros.
+.PP
Self alias casts:
.PP
There are some standard casts defined for you. Instead of using the full
not use any C++ features, this option will just make the generated code
compile with a C++ compiler.
+.SH OVERRIDING THE GET_TYPE METHOD
+.PP
+The get_type is not really a method, but a function which initializes your
+object. Recently objects appeared which require you to make a custom
+get_type function (BonoboXObject currently). So in 1.0.7 it is now possible
+to override this function. To do so, just define a new public method called
+get_type, with no arguments. Example:
+.nf
+
+ public GtkType
+ get_type (void)
+ {
+ /* code goes here */
+ return some_type;
+ }
+
+.fi
+
.SH IDENTIFIER CONFLICTS
.PP
Gob will need to define some local variables and functions in the generated
have to include both the .gob and the .c and .h files in the SOURCES for your
program.
+.SH DEBUGGING
+.PP
+GOB does several things to make debugging the code easier. First it adds
+preprocessor commands into the output c file that point to the correct places
+in your .gob input file. However sometimes there might be some bigger
+confusion and this is just not helpful. In this case you will probably want
+to have gcc point you directly at the generated files. For this use
+the --no-lines command line option. You should also note that these commands
+are not generated for the public header file at all. If there is an error which
+points you to the public header file, make sure you fix this error in the .gob
+file, otherwise your changes will not have any effect after gob recompiles the
+sources again.
+.PP
+Sometimes you might want to know which method you are in for some debugging
+output. GOB will define __GOB_FUNCTION__ macro, which is just a string constant
+with a pretty name of the method.
+
.SH BUGS
.PP
The lexer does not actually parse the C code, so I'm sure that some corner
projects / gob-dx.git / blobdiff