.\"
.\" gob manual page
-.\" (C) 1999,2000,2001,2002 George Lebl <jirka@5z.com>
+.\" (C) 1999-2011 Jiri (George) Lebl <jirka@5z.com>
.\"
.\" This manual page is covered by the terms of the GNU General
.\" Public License.
.SH OPTIONS
.PP
.TP
-.B -? -h --help
+.B \-? \-h \-\-help
Display a simple help screen.
.TP
-.B --version
+.B \-\-version
Display version information
.TP
-.B -w --exit-on-warn
+.B \-w \-\-exit\-on\-warn
Exit with an error code even when you encounter a warning.
.TP
-.B --no-exit-on-warn
+.B \-\-no\-exit\-on\-warn
Exit with an error only on errors, not on warnings, this is the default.
.TP
-.B --for-cpp
+.B \-\-for\-cpp
Generate C++ code.
.TP
-.B --no-extern-c
+.B \-\-no\-extern\-c
Never add the extern "C" to the header.
.TP
-.B --no-gnu
+.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
correctly even on non-GNU compilers. This option is for purists only.
(using GNU extensions some warnings are eliminated, some ugly hacks and there
is better argument type safety, so it\'s good to use them)
.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. Private header is still touched even if
-unchanged however.
+.B \-\-no\-touch
+Don\'t touch output files unless they really
+changed (implies \-\-no\-touch\-headers). Be careful with automake, see section
+PREVENTING SPURIOUS BUILDS.
.TP
-.B --always-private-header
+.B \-\-no\-touch\-headers
+Don\'t touch any generated header file unless that file really changed.
+This avoids spurious rebuilds, but can confuse some make systems 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.
-This is the default.
.TP
-.B --ondemand-private-header
+.B \-\-ondemand\-private\-header
Create the private header only if it would have something in it, that is,
if there are some private data members or protected methods.
+This is the default.
.TP
-.B --no-private-header
+.B \-\-no\-private\-header
Never create a private header file. If we use any private data members,
define the private data structure at the point in the .c source where
the class definition begins.
.TP
-.B --m4
+.B \-\-m4
Preprocess source with m4. Following args will be passed to m4.
.TP
-.B --m4-dir
+.B \-\-m4\-dir
Print directory that will be searched for m4 files.
.TP
-.B -n --no-write
+.B \-n \-\-no\-write
Do not write any output files, just check syntax of the input file.
.TP
-.B --no-lines
+.B \-\-no\-lines
Do not print out the \'#line\' statements into the output. Useful for debugging
the auto-generated generated code.
.TP
-.B --no-self-alias
+.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
+.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.
+.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.
+.TP
+.B \-o \-\-output\-dir
+The directory into which output should be placed.
+.TP
+.B \-\-file\-sep[=c]
+Replace default \'\-\' file name separator. If no separator character
+is given then none is used. Only one character can be used.
+.TP
+.B \-\-gtk3
+Use gtk3.
.SH TYPENAMES
.PP
.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 \fBgtk-new-button.c\fR and
-\fBgtk-new-button.h\fR.
+separated by \'\-\' (this can be changed with
+\fB\-\-file\-sep\fR option) and all in lower case. For example for an object named
+"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).
+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
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:
+files go in the \'alltop\' (or \'at\') section. When you want code
+to appear as in alltop but only in the cfile you use the \'ctop\' (or \'ct\')
+section. Note that ctop requires 2.0.18. Finally,
+\'afterdecls\' includes code between the declarations and the method
+implementations, but note that \'afterdecls\' requires version 2.0.16.
+For example:
.nf
%alltop{
- /* this will be on top of all output files */
+ /* this will be at the very top of all output files */
+ %}
+
+ %ctop{
+ /* this will be at the very top of the C file */
+ /* Requires 2.0.18 */
%}
%headertop{
- /* this will be on top of the public header */
+ /* this will be on top of the public header */
%}
%privateheader{
- /* this will go into the private header file */
+ /* this will go into the private header file */
%}
%h{
- /* will be included in the header */
- void somefunc(int i);
+ /* will be included in the header */
+ void somefunc(int i);
%}
%a{
- /* will be included in all files */
+ /* will be included in all files */
+ %}
+
+ %afterdecls{
+ /* between the declarations and the method implementations */
+ /* Requires gob version 2.0.16 */
%}
%{
- /* will be included in the C file */
- void somefunc(int i)
- {
- /* some code */
- }
+ /* will be included in the C file */
+ void somefunc(int i)
+ {
+ /* some code */
+ }
%}
.fi
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
+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
}
.fi
+.PP
+To make an abstract class (to pass G_TYPE_FLAG_ABSTRACT) add \'(abstract)\'
+before the curly braces above. This works since version 2.0.13.
+
+.PP
+To make a simple dynamic class which can be registered with a GTypeModule,
+add \`(dynamic)\' to the class header.
+This will cause a type registration method to be defined, which you would
+normally call from the load method of a GTypeModule.
+In the above example, the registration function will look like
+.nf
+
+ void gtk_new_button_register_type(GTypeModule *type_module)
+.fi
.SH DATA MEMBERS
.PP
-There are five types of data members. Three of them are normal data numbers,
+There are five types of data members. Three of them are normal data members,
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
the object struct. Example where \'i\' is as above a public data member:
.nf
- object->i = 1;
+ object\->i = 1;
.fi
.PP
where \'h\' is the private data member (as in the above example):
.nf
- object->_priv->h = NULL;
+ object\->_priv\->h = NULL;
.fi
-The _priv structure is defined in the \fB<basename>-private.h\fR.
+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 in your .gob file if you explicitly also
include the main header file. The reason it is a separate header file is
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
+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
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:
+To access the member you can use the SELF_GET_CLASS macro (or
+YOUR_OBJECT_NAME_GET_CLASS) to get at the class.
+Thus the following would work:
.nf
- SELF_CLASS(GTK_OBJECT(object)->klass)->foo = 20;
+ SELF_GET_CLASS(object)\->foo = 20;
.fi
.PP
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
+will initialize an integer to \-1 and a string with a newly allocated string
of "hello".
.nf
- public int foo = -1;
+ public int foo = \-1;
private char *bar = {g_strdup("hello")};
.fi
private int height;
property INT height
- (nick = _("Short nickname"),
+ (
+ name = "height",
+ nick = _("Short nickname"),
blurb = _("Long description"),
minimum = 10,
maximum = 200,
default_value = 100)
- set { self->_priv->height = g_value_get_int (VAL); }
- get { g_value_set_int (VAL, self->_priv->height); };
+ set { self\->_priv\->height = g_value_get_int (VAL); }
+ get { g_value_set_int (VAL, self\->_priv\->height); };
.fi
.PP
All property types have a \'nick\' and a \'blurb\' attribute and you should
set those accordingly. This will make runtime querying the object
nicer as things such as gui editors and class browsers can be more
-verbose about the class itself. You can use the \'_("string")\' notation
+verbose about the class itself.
+.PP
+The \'name\' property is canonical name of property. It is useful when you try to
+implement properties with no C names like \'vertical-scroll\'. The \'name\'
+property can be omitted.
+.PP
+You can use the \'_("string")\' notation
instead of just "string", and that will mark the string for translation.
.PP
Almost all types also have a \'default_value\' attribute which sets the initial
value of this property (on object initialization, the set handler will be run
-automatically with this value). This value will be overriden if the user
+automatically with this value). This value will be overridden if the user
sets a value of this property on the call to g_object_new.
.PP
All the numeric types (including CHAR) have \'minimum\' and \'maximum\'
.PP
The OBJECT type is one of the types that doesn\'t have a \'default_value\' and it
only has an \'object_type\' attribute (in addition to nick and blurb of course)
-that is the exact object type that this property accepts.
+that is the exact object type that this property accepts. The object_type
+should be as a type, that is for example \'Gtk:Button\'.
.PP
There is a BOXED type which is a pointer which has a boxed type defined
(such that GObject knows how to copy and destroy this pointer). Here
.PP
To get bettery type safety on some of the property types, you can specify
the \'type\' attribute which will add casts where appropriate in code dealing
-with this property. This is especially useful for POINTER types. But
-even for others.
+with this property. This is especially useful for POINTER and OBJECT types.
+But even for others.
+.PP
+You can also override properties from parent objects (that is override their
+implementation, not their attributes). Do this by adding the
+special \'override\' attribute. For example if the parent object
+had a \'height\' property then you could override it by
+.nf
+
+ private int height;
+ property INT height
+ (override)
+ set { self\->_priv\->height = g_value_get_int (VAL); }
+ get { g_value_set_int (VAL, self\->_priv\->height); };
+
+.fi
+Overriding is supported since gob 2.0.10.
.SH METHODS
.PP
instance and it is checked for being null and the type will also be
checked.
.PP
+.B "Function attributes:"
+.PP
+For method that aren't virtual, signal or override methods, and aren't
+init or class_init, GLib function attribute macros G_GNUC_PRINTF,
+G_GNUC_SCANF, and G_GNUC_FORMAT can optionally be included after the
+argument list. Simply include an \'attr\' keyword and the C code to include
+in the file. You have to include braces and anything inside the braces
+will be printed into the header file after the function declaration and
+before the trailing semicolon. The braces themselves are not printed.
+For example:
+.nf
+
+ public void
+ print (self, const char *format (check null), ...)
+ attr {G_GNUC_PRINTF(2, 3)}
+
+.fi
+.PP
+This will produce a prototype which will generate a warning at compile
+time if the contents of the format argument (argument number 2) aren't
+consistent with the types and number of the subsequent variadic
+arguments (the first of which is argument number 3). Only one \'attr\'
+keyword per method is allowed.
+If you have more than one attribute to include, you should
+put them all within the braces.
+Note that function attributes were aded in version 2.0.16.
+.PP
.B "Error return:"
.PP
Methods which have a return value, there also has to be something
-returned if there is an error, such as if a precondition is not met. The
-default is 0, casted to the type of the method. If you need to return
-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:
+returned if there is an error, such as if a precondition is not met.
+The default is 0, casted to the type of the method. If you need to
+return something else then you can specify an \'onerror\' keyword after
+the prototype and any optional function attribute macros, 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:
.nf
public void * get_something (self, int i (check >= 0)) onerror NULL {
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 ;
+ 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
init (self) {
/* initialize the object here */
- self->a = 9;
- self->b = 9;
+ self\->a = 9;
+ self\->b = 9;
}
class_init (class) {
/* initialize the class, this is rarely needed */
- class->blah = NULL;
+ class\->blah = NULL;
}
.fi
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.
.PP
+.B "Constructor, dispose, finalize methods:"
+.PP
+Since 2.0.16, you can also easily add code to the object's constructor,
+dispose, and finalize methods. See GObject documentation on how these are
+run. The code you add will be run before calling the parents function
+for dispose and finalize, and after the parent function for constructor.
+The syntax is just like init and class_init.
+For example:
+.nf
+
+ constructor (self) {
+ /* constructor method */
+ }
+
+ dispose (self) {
+ /* dispose method */
+ }
+
+ finalize (self) {
+ /* finalize method */
+ }
+
+.fi
+You can also just override those methods as usual, but the above is much easier and nearly as flexible.
+.PP
.B "Virtual methods:"
.PP
Virtual methods are basically pointers in the class structure,
signal last NONE (NONE) void foo (self);
+.fi
+.PP
+You can include name of signal, if this name is not a C variable name. Example:
+.nf
+
+ signal first INT "do-something" (POINTER, INT)
+ int do_something (self, Gtk:Widget *w (check null type), int length)
+ {
+ ...
+ }
+
.fi
.PP
If you don\'t want the wrapper that emits the signal to be public, you can
.fi
.PP
+To use BOXED in the signal arguments you need to tell gob which type of boxed
+argument you want to use. For this you can just add BOXED_GTK_TYPE_STRING
+instead of BOXED. For example BOXED_GTK_TYPE_TREE_ITER for GtkTreeIter.
+This works since version 2.0.13.
+.PP
.B "Override methods:"
.PP
If you need to override some method (a signal or a virtual method
private int
foo (self)
{
- return self->len;
+ return self\->len;
}
private int
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
+This is because this is a simple C typedef which is only available inside your
+\&.c file and not in the header files. You can disable both the self casting
+macros and the self type aliases by passing \-\-no\-self\-alias to gob.
.SH DEALING WITH DIFFERENT GOB VERSIONS
.PP
.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
+to use the \-\-for\-cpp argument to gob. This will make the generated file have
a .cc instead of a .c extension, 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
before the method definition. The method can, and probably should be,
private.
.PP
+Interface methods behave very similarly to virtual/override methods.
+As with override methods, you can use PARENT_HANDLER in the definition of an
+interface method to call the implementation of the same interface method in
+a parent class.
+.PP
+The NAME_parent_iface variable may be used to access the complete interface
+structure from a parent class, where NAME is the implemented interface (with
+colons replaced by underscores).
+This enables access to the full parent implementation of an interface.
+For example, if a class implements the Gtk:Tree:Model interface then the
+implementation of the same interface in the parent class is available via
+the Gtk_Tree_Model_parent_iface pointer.
+If an interface is not implemented in the parent class, then the corresponding
+parent_iface value will be a null pointer.
+.PP
The following example implements a new object, that implements the
Gtk:Tree:Model interface and implements the get_flags method of that
interface. Do note that except for standard (GTK+ and glib) specific
a good idea to do. It won\'t work to make this a signal, it can however
be a virtual. Note that the method prototype must match the one from the
interface header file, or you will get a bad assignment warning. You should
-check the header file generated by orbit-idl and see the epv structure
+check the header file generated by orbit\-idl and see the epv structure
for the correct prototypes if you can\'t figure them out from the idl itself.
Also note that the first argument is not "self", but the servant and you must
use bonobo_object_from_servant function to get the actual object pointer.
+.SH DIRECT LIBGLADE SUPPORT
+.PP
+Gob can simplify writing a libglade class. Just create a new object that
+derives from a GtkContainer widget. Then use a "GladeXML" class flag
+with the glade file name, root widget and optional domain as arguments
+between double quotes. For example:
+.nf
+
+class My:Glade from Gtk:Window (GladeXML "gob\-libglade.glade" "root")
+{
+ ....
+}
+
+.fi
+Note however that then "gob\-libglade.glade" would have to be in the current
+directory. You could specify a path, but that may not work for all
+installations. You can replace the glade filename with a token to be used
+in the generated .c file and you can then have a macro with the filename,
+as follows:
+.nf
+
+class My:Glade from Gtk:Window (GladeXML GLADE_FILE "root")
+{
+ ....
+}
+
+.fi
+And somewhere in your header files you would have
+.nf
+
+#define GLADE_FILE "/path/to/file.glade"
+
+.fi
+
+You can declare widgets as data members by adding a 'GladeXML' to
+the definition.
+.nf
+
+private Gtk:Button * button1 GladeXML;
+
+.fi
+This will automatically set the "button1" from the GladeXML file.
+
+All signals created with glade are automatically connected if you defined
+those class methods in your class. For example suppose in glade that
+we set the "connect" signal on button1 to go to on_button1_clicked, then
+in our gob file we can just write:
+.nf
+
+public void
+on_button1_clicked(self, GtkButton * button)
+{
+}
+
+.fi
+
+See the examples directory for a full example. Note that this feature
+requires version at least 2.0.12.
+
+
.SH IDENTIFIER CONFLICTS
.PP
Gob will need to define some local variables and functions in the generated
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
+.SH USING GTK\-DOC STYLE INLINE DOCUMENTATION
.PP
-If you want to use gtk-doc style inline documentation for your objects, you
+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
need to just declare the typedef in the header of A for B, and the other way
around as well. The headers generated 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
+__TYPEDEF_<upper case object name>__. So inside my\-object\-a.h there will be
this:
.nf
#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
+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
before the \'gob2\' is a tab, not spaces):
.nf
- %.c %.h %-private.h: %.gob
+ %.c %.h %\-private.h: %.gob
gob2 $<
.fi
which will also check the version of gob. Basically you include this:
.nf
- GOB2_CHECK(2.0.0)
+ GOB2_CHECK([2.0.0])
.fi
This will replace @GOB2@ in your makefiles with the full path of gob2. Thus
when adding the generic rule to your Makefile.am file, it should look like:
.nf
- %.c %.h %-private.h: %.gob
+ %.c %.h %\-private.h: %.gob
@GOB2@ $<
.fi
have to include both the .gob and the .c and .h files in the SOURCES for your
program.
+.SH PREVENTING SPURIOUS BUILDS
+.PP
+When nothing has changed you might not really want to rebuild everything and
+gob provides options \-\-no\-touch (since 2.0.13) and \-\-no\-touch\-headers to avoid
+this. When working with build systems such as automake you have to be more
+careful as just using those options can cause automake to get confused and you
+will need to use something like the following:
+.nf
+
+ foo_SOURCES = foo.gob foo.gob.stamp foo.c foo.h foo\-private.h
+ BUILT_SOURCES = foo.gob.stamp
+ MAINTAINERCLEANFILES = foo.gob.stamp
+
+ %.gob.stamp: %.gob
+ @GOB2@ \-\-no\-touch $<
+ @touch $@
+
+.fi
+
.SH DEBUGGING
.PP
GOB does several things to make debugging the code easier. First it adds
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
+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
.PP
It is possible to have your .gob file also preprocessed by m4. This is useful
if you have a lot of files and you\'d like to have some preprocessor put in
-some common features. All you have to do is add --m4 to the command line
+some common features. All you have to do is add \-\-m4 to the command line
of gob2 and gob2 will first run your file through m4. You can print the
-directory that is searched for m4 files by running "gob2 --m4-dir"
+directory that is searched for m4 files by running "gob2 \-\-m4\-dir"
.PP
-All the arguments after --m4 will be passed to m4 itself, so it has to be the
+All the arguments after \-\-m4 will be passed to m4 itself, so it has to be the
last gob2 argument on the command line. This way you can specify arbitrary
options to pass to m4.
code segments.
.PP
Comments will not get through to the generated files unless inside C code.
-This is not the case for gtk-doc style comments which are supported.
+This is not the case for gtk\-doc style comments which are supported.
.PP
The short name aliases are actually implemented as pointers to functions. Thus
if you want to get the pointer of a function using the short name alias you
projects / gob-dx.git / blobdiff