X-Git-Url: https://git.draconx.ca/gitweb/gob-dx.git/blobdiff_plain/5d4e3f65125a1e67702b7fbd4096d5e2fd3ec798..6bec711e14babb0d6388754f41834036f22a3ef1:/doc/gob2.1.in diff --git a/doc/gob2.1.in b/doc/gob2.1.in index 904691e..31f7bfb 100644 --- a/doc/gob2.1.in +++ b/doc/gob2.1.in @@ -1,6 +1,6 @@ .\" .\" gob manual page -.\" (C) 1999,2000,2001,2002,2005 George Lebl +.\" (C) 1999-2011 Jiri (George) Lebl .\" .\" This manual page is covered by the terms of the GNU General .\" Public License. @@ -26,92 +26,92 @@ language. .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 +.B \-\-no\-touch Don\'t touch output files unless they really -changed (implies --no-touch-headers). Be careful with automake, see section +changed (implies \-\-no\-touch\-headers). Be careful with automake, see section PREVENTING SPURIOUS BUILDS. .TP -.B --no-touch-headers +.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. .TP -.B --always-private-header +.B \-\-always\-private\-header Always create a \fB-private.h\fR file, even if it would be empty. .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 +.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 +.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 +.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. .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 +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 @@ -121,14 +121,14 @@ types. .SH OUTPUT FILES .PP The filenames are created from the typename. The words are -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. +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-private.h\fR (for the example above it -would be gtk-new-button-private.h). +be created, called \fB\-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 @@ -150,14 +150,21 @@ the extern "C" and the protecting define. To do this you can put them 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. Finally, +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{ @@ -201,7 +208,7 @@ 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-private.h\fR. Same rule as above applies +that will be called \fB\-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 @@ -250,7 +257,7 @@ Public and protected data members are accessed normally as members of the object struct. Example where \'i\' is as above a public data member: .nf - object->i = 1; + object\->i = 1; .fi .PP @@ -260,10 +267,10 @@ them using the structure _priv. Example 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-private.h\fR. +The _priv structure is defined in the \fB\-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 @@ -272,7 +279,7 @@ 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 +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 @@ -295,7 +302,7 @@ YOUR_OBJECT_NAME_GET_CLASS) to get at the class. Thus the following would work: .nf - SELF_GET_CLASS(object)->foo = 20; + SELF_GET_CLASS(object)\->foo = 20; .fi .PP @@ -310,11 +317,11 @@ initializations by putting it all in curly braces. Note that the curly braces 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 @@ -423,8 +430,8 @@ be synchronized with a private integer data member also of the name \'height\'. 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 @@ -438,7 +445,7 @@ 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\' @@ -555,8 +562,8 @@ had a \'height\' property then you could override it by 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); }; + 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. @@ -671,7 +678,7 @@ 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 ; + 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 @@ -689,13 +696,13 @@ For example: 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 @@ -860,7 +867,7 @@ Example: private int foo (self) { - return self->len; + return self\->len; } private int @@ -909,7 +916,7 @@ 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 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. +macros and the self type aliases by passing \-\-no\-self\-alias to gob. .SH DEALING WITH DIFFERENT GOB VERSIONS .PP @@ -987,7 +994,7 @@ C code: .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 @@ -1097,7 +1104,7 @@ Note that the implementation method can be private, in fact that\'s probably 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. @@ -1110,13 +1117,13 @@ 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") +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 +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, @@ -1187,9 +1194,9 @@ 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 +.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 @@ -1230,7 +1237,7 @@ class and vice versa. Obviously you can\'t include headers for both. So you 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___. So inside my-object-a.h there will be +__TYPEDEF___. So inside my\-object\-a.h there will be this: .nf @@ -1240,8 +1247,8 @@ this: #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 @@ -1256,7 +1263,7 @@ and then just use the .c and .h files as usual (make sure the space before the \'gob2\' is a tab, not spaces): .nf - %.c %.h %-private.h: %.gob + %.c %.h %\-private.h: %.gob gob2 $< .fi @@ -1275,7 +1282,7 @@ 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 @@ -1288,18 +1295,18 @@ 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 +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 + 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 $< + @GOB2@ \-\-no\-touch $< @touch $@ .fi @@ -1311,7 +1318,7 @@ 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 +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 @@ -1325,11 +1332,11 @@ with a pretty name of the method. .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. @@ -1374,7 +1381,7 @@ And if you use it make sure that you do not cross the boundaries of the C 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