3 .\" (C) 1999-2011 Jiri (George) Lebl <jirka@5z.com>
5 .\" This manual page is covered by the terms of the GNU General
8 .TH GOB2 1 "GOB2 @VERSION@"
10 GOB2 \- The GObject Builder
19 GObject Builder is a simple preprocessor for easily creating
20 GObject objects. It does not parse any C code and ignores any C errors. It
21 is in spirit similar to things like lex or yacc. In some ways it
22 also resembles java. But it is really just a simple preprocessor
23 for creating GObjects for use in C or C++ and it is not a programming
30 Display a simple help screen.
33 Display version information
35 .B \-w \-\-exit\-on\-warn
36 Exit with an error code even when you encounter a warning.
38 .B \-\-no\-exit\-on\-warn
39 Exit with an error only on errors, not on warnings, this is the default.
45 Never add the extern "C" to the header.
48 Never generate any code with GNU C extensions. However all the GNU C
49 extensions are always wrapped in #ifdef __GNUC__, so code using them compiles
50 correctly even on non-GNU compilers. This option is for purists only.
51 (using GNU extensions some warnings are eliminated, some ugly hacks and there
52 is better argument type safety, so it\'s good to use them)
55 Don\'t touch output files unless they really
56 changed (implies \-\-no\-touch\-headers). Be careful with automake, see section
57 PREVENTING SPURIOUS BUILDS.
59 .B \-\-no\-touch\-headers
60 Don\'t touch the generated header file unless it really changed, this avoids
61 spurious rebuilds, but can confuse some make systems (automake in particular),
62 so it is not enabled by default. Private header is still touched even if
65 .B \-\-always\-private\-header
66 Always create a \fB<basename>-private.h\fR file, even if it would be empty.
68 .B \-\-ondemand\-private\-header
69 Create the private header only if it would have something in it, that is,
70 if there are some private data members or protected methods.
73 .B \-\-no\-private\-header
74 Never create a private header file. If we use any private data members,
75 define the private data structure at the point in the .c source where
76 the class definition begins.
79 Preprocess source with m4. Following args will be passed to m4.
82 Print directory that will be searched for m4 files.
85 Do not write any output files, just check syntax of the input file.
88 Do not print out the \'#line\' statements into the output. Useful for debugging
89 the auto-generated generated code.
91 .B \-\-no\-self\-alias
92 Do not create the Self and SelfClass type aliases and the SELF, IS_SELF
93 and SELF_CLASS macros.
95 .B \-\-no\-kill\-underscores
96 Do not remove the initial underscore from method names.
98 .B \-\-always\-private\-struct
99 Always include the private pointer in the public header file. This is useful
100 for files which are part of a library and you want to reserve the right to add
101 some private data members without breaking binary compatibility.
103 .B \-o \-\-output\-dir
104 The directory into which output should be placed.
107 Replace default \'\-\' file name separator. If no separator character
108 is given then none is used. Only one character can be used.
115 Because we need to parse out different parts of the typename, sometimes you
116 need to specify the typename with some special syntax. Types are specified in
117 capitalized form and words are separated by \':\'. The first word of the type
118 (which can be empty) is the "namespace". This fact is for example used for the
119 type checking macro and the type macro. For "Gtk:New:Button", the macros will
120 be GTK_IS_NEW_BUTTON and GTK_TYPE_NEW_BUTTON. This colon separated format of
121 typenames is used in the class declaration header and for method argument
126 The filenames are created from the typename. The words are
127 separated by \'\-\' (this can be changed with
128 \fB\-\-file\-sep\fR option) and all in lower case. For example for an object named
129 "Gtk:New:Button", the files are \fBgtk\-new\-button.c\fR and
130 \fBgtk\-new\-button.h\fR.
131 If you are using C++ mode, the output .c file will in fact be a .cc file.
132 If you have any private data members, a private header file will also
133 be created, called \fB<basename>\-private.h\fR (for the example above it
134 would be gtk\-new\-button\-private.h).
135 The public header file is created to be human readable and to be used as a
136 reference to the object. The .c source file is not created as a human
137 readable source and is littered with #line statements, which make the
138 compiler attempt to point you to the right line in your .gob file in
139 case of parsing errors. The output should not be edited by hand, and
140 you should only edit the .gob file.
142 .SH INCLUDING NORMAL C CODE IN THE OUTPUT FILES
144 To include some code directly in the output C file begin with \'%{\'
145 on an empty line and end the code with a \'%}\' on an empty line. These
146 sections will appear in the output files in the order they are given.
147 There are several other \fIsections\fR to which you can put code. You can
148 put it in the \'header\' section (which can be abbreviated \'h\') and it will
149 go into the public header file. You can also put it in the \'privateheader\'
150 section (abbreviated \'ph\') which will make the code go into the private
151 header file. Sometimes you want some code (other includes) to appear before
152 the extern "C" and the protecting define. To do this you can put them
153 into the \'headertop\' (or \'ht\') section. You may wish to include code or
154 comments in all the files, which you can do by putting them into the \'all\'
155 (or \'a\') section. Similarly, code you wish to appear at the top of all
156 files go in the \'alltop\' (or \'at\') section. When you want code
157 to appear as in alltop but only in the cfile you use the \'ctop\' (or \'ct\')
158 section. Note that ctop requires 2.0.18. Finally,
159 \'afterdecls\' includes code between the declarations and the method
160 implementations, but note that \'afterdecls\' requires version 2.0.16.
165 /* this will be at the very top of all output files */
169 /* this will be at the very top of the C file */
170 /* Requires 2.0.18 */
174 /* this will be on top of the public header */
178 /* this will go into the private header file */
182 /* will be included in the header */
183 void somefunc(int i);
187 /* will be included in all files */
191 /* between the declarations and the method implementations */
192 /* Requires gob version 2.0.16 */
196 /* will be included in the C file */
207 Gob will automatically include the class header file at the top of the .c
208 source file. If you wish to include it somewhere else, put the include
209 into some %{ %} section above the class definition, and gob will not include
210 it automatically. This way you can avoid circular includes and control
211 where in the file do you want to include the header.
213 If you made any data members private, gob will also create a source file
214 that will be called \fB<basename>\-private.h\fR. Same rule as above applies
215 for this just as it does for the regular header file. If you do explicitly
216 include the regular header file, you should always include this private
217 header file below it. That is, if you use any private data members. If you
218 don\'t, the private header file automatically includes the public header file,
219 and thus the public header file will be indirectly included at the very top
224 There can be only one class per input file. Defining a class
225 is sort of like in Java, you define the class and write inline code
226 directly into the class definition. To define a class you need to specify
227 the new object name and the name of the object from which it is derived
228 from, such as this "class <new type> from <parent type> { <class code> }".
232 class Gtk:New:Button from Gtk:Button {
238 To make an abstract class (to pass G_TYPE_FLAG_ABSTRACT) add \'(abstract)\'
239 before the curly braces above. This works since version 2.0.13.
242 To make a simple dynamic class which can be registered with a GTypeModule,
243 add \`(dynamic)\' to the class header.
244 This will cause a type registration method to be defined, which you would
245 normally call from the load method of a GTypeModule.
246 In the above example, the registration function will look like
249 void gtk_new_button_register_type(GTypeModule *type_module)
254 There are five types of data members. Three of them are normal data members,
255 one is class wide (global) in scope and one is a virtual one, usually linked to
256 a normal data member or a class wide data member. The three normal data
257 members are public, protected and private. Public and protected are basically
258 just entries in the object structure, while private has it\'s own dynamically
259 allocated private structure. Protected members are always put after the public
260 one in the structure and are marked protected in the header file. There is
261 only one identifier allowed per typename unlike in normal C. Example:
265 private GtkWidget *h;
270 Public and protected data members are accessed normally as members of
271 the object struct. Example where \'i\' is as above a public data member:
278 The private data members are defined in a structure which is only available
279 inside the .c file, or by including a private header file. You must access
280 them using the structure _priv. Example
281 where \'h\' is the private data member (as in the above example):
284 object\->_priv\->h = NULL;
287 The _priv structure is defined in the \fB<basename>\-private.h\fR.
288 This file is automatically included if you don\'t include it yourself. You
289 should always explicitly include it in your .gob file if you explicitly also
290 include the main header file. The reason it is a separate header file is
291 that you can also include it in other places that need to access this objects
292 private data, such as if you have the majority of functionality of an object
293 in a separate .c file. Or if a derived object needs to access the protected
296 In case you use the \fB\-\-no\-private\-header\fR option, no
297 private header file is created and you can only access the _priv pointer
298 below the class definition in the .gob file.
300 Also note that this structure is dynamically allocated, and is freed in the
301 finalize handler. If you override the finalized handler, your code will be
302 run first and only then will the _priv structure be freed.
304 .B "Classwide data members:"
306 Sometimes you want a datamember to be shared by all objects. You then need
307 the "classwide" scope keyword. So for example the following adds a global
314 To access the member you can use the SELF_GET_CLASS macro (or
315 YOUR_OBJECT_NAME_GET_CLASS) to get at the class.
316 Thus the following would work:
319 SELF_GET_CLASS(object)\->foo = 20;
323 .B "Automatic Initialization:"
325 You can automatically initialize the public private and protected data members
326 without having to add an init method. The advantage here is that
327 initialization is kept close to the definition of the data member and thus
328 it\'s easier to check. To do this, just add a \'=\' followed by a number or
329 a token. It is also possible to include arbitrary C code for more elaborate
330 initializations by putting it all in curly braces. Note that the curly braces
331 will not be printed into the output, but since gob does not C parsing it needs
332 them to figure out where the C code ends. The code will be inserted into the
333 init method, above the user defined body. So for example the following
334 will initialize an integer to \-1 and a string with a newly allocated string
338 public int foo = \-1;
339 private char *bar = {g_strdup("hello")};
343 .B "Automatic Destruction:"
345 Most data stored as pointers needs to have a function called when the object
346 is finalized to either free the data. Gob will let you
347 define a function to be called on the data the object is finalized. This is
348 achieved by putting \'destroywith\' followed by a function name after the
349 variable definition. It is only called if the data you defined this on
350 is not NULL, so you cans specify functions which do not handle NULL. It
351 is very much like the GDestroyNotify function used in GTK+ and glib in many
352 places. Unlike many other places, gob will not enforce any kind of type
353 safety here so be a little bit more careful. Any function you give it will
354 be called as a "void function(void *)". It will in fact be cast into such
355 a form before called. This is to avoid spurious warnings for gtk calls to
356 subclass methods. The function needs not be of that form exactly, it just has
357 to take one argument which is the pointer to the data. You should also not
358 define this on any non-pointer data as the results may be undefined.
362 public char *foo = {g_strdup("bar")}
366 Note that the function name you give must be a real function and not macro.
367 Also note that this is always called in the "finalize" method of GObject.
368 It is always called after any user defined body of the finalize handler.
370 Sometimes you may want to run arbitrary code on destruction. While this can
371 be perfectly well done in the finalize handler. Depending on the style you
372 may want to include all destruction/initialization code together with the
373 definition of the data member. Thus you may want to put arbitrary code which
374 will then be inserted into the "finalize" method of GObject. This can be
375 done with the "destroy" keyword followed by arbitrary code in curly braces.
376 Inside this code a macro called VAR will be define which refers to your
377 variable. So for example destroying a GString can be either done with
378 a helper routine or the following code:
381 public GString *string = {g_string_new(NULL)}
383 if(VAR) g_string_free(VAR, TRUE);
387 The thing to remember with these is that there are many ways to do this
388 and you\'d better be consistent in your code in how you use the above things.
389 Also defining a helper routine that will do the destruction will be a nicer
390 thing to do if that\'s a possibility. The "destroy" keyword with code does
391 take up more space in the file and it may become more cluttered.
393 The data is zeroed out after being destroyed. This is to make debugging easier
394 in case your code might try to access an already finalized object. In case
395 you have overridden the finalize method, your code will be run first and
396 only then will the destructors be called. You should not however make any
397 assumptions about the order at which the destructors are called. If you have
398 interdependencies between destructors for different data members, you will
399 have to do this in your own finalize override function.
401 .B "Automatic Unreffing:"
403 This is very much like the automatic destruction, but is instead run in the
404 dispose method (it is among other places called from the "destroy" method of
405 GtkObject). All data and other objects that you need to unref should be
406 done here, and not at finalize time. The semantics are otherwise the same
407 as for the "destroywith" and "destroy" keywords, except that you use
408 "unrefwith" and "unref".
411 public G:Object *foo = NULL
412 unrefwith g_object_unref;
413 public G:Object *bar = NULL
415 g_object_unref (VAR);
420 .SH GOBJECT PROPERTIES
422 The fourth type of a data member a property type. It is a named data member
423 which is one of the features of the GObject system. It just defines a way to
424 get and set some data, but you have to take care of storing that data
425 somewhere. So it is normal to also have a normal private (or public)
426 data member where you store the real data.
427 You normally need to define a
428 get and a set handler. They are fragments of C code that will be used to get
429 the value or set the value of the argument. Inside them you can use the define
430 VAL to which you assign the data or get the data. You should treat this VAL
431 as a GValue which stores the data of the correct type.
433 identifier "self" as pointer to the object instance. The type is defined as
434 one of the GObject type enums, but without the G_TYPE_ prefix. There are
435 also some attributes of a property which you can set. For example the
436 following is a definition of an integer property \'height\' which will
437 be synchronized with a private integer data member also of the name \'height\'.
444 nick = _("Short nickname"),
445 blurb = _("Long description"),
449 set { self\->_priv\->height = g_value_get_int (VAL); }
450 get { g_value_set_int (VAL, self\->_priv\->height); };
454 The attributes are really optional though you should at least set some
456 All property types have a \'nick\' and a \'blurb\' attribute and you should
457 set those accordingly. This will make runtime querying the object
458 nicer as things such as gui editors and class browsers can be more
459 verbose about the class itself.
461 The \'name\' property is canonical name of property. It is useful when you try to
462 implement properties with no C names like \'vertical-scroll\'. The \'name\'
463 property can be omitted.
465 You can use the \'_("string")\' notation
466 instead of just "string", and that will mark the string for translation.
468 Almost all types also have a \'default_value\' attribute which sets the initial
469 value of this property (on object initialization, the set handler will be run
470 automatically with this value). This value will be overridden if the user
471 sets a value of this property on the call to g_object_new.
473 All the numeric types (including CHAR) have \'minimum\' and \'maximum\'
474 attributes which can restrict the range. If you do not specify these
475 the range will be the full range that the data type can handle.
477 Types such as UNICHAR and BOOLEAN only have the \'nick\', \'blurb\' and
478 \'default_value\' attributes.
480 The ENUM type has an \'enum_type\' attribute which is the exact
481 type of the enum. This is so that the property knows which exact
482 type you can set, rather then just knowing it is an enum. You should
483 always create an enum type specific for the enum itself (see section
486 Similarly FLAGS type has a \'flags_type\' which again you should set to
487 the specific type of this flags data member.
489 There is a STRING type which has only the extra \'default_value\' attribute.
491 The OBJECT type is one of the types that doesn\'t have a \'default_value\' and it
492 only has an \'object_type\' attribute (in addition to nick and blurb of course)
493 that is the exact object type that this property accepts. The object_type
494 should be as a type, that is for example \'Gtk:Button\'.
496 There is a BOXED type which is a pointer which has a boxed type defined
497 (such that GObject knows how to copy and destroy this pointer). Here
498 you will need to specify the \'boxed_type\' attribute with the specific
499 type of the boxed pointer.
501 There is also a POINTER type, which has only the \'nick\' and \'blurb\'
502 attributes. This is for storing arbitrary pointers. You should be
503 careful with this one, as GObject knows nothing about the data
504 stored at this pointer. It is somewhat like a \'void *\' type.
506 There is also the PARAM type for storing parameters with a \'param_type\'
509 You should notice that this list is pretty much like the list of g_param_spec_*
510 functions from gobject/gparamspecs.h, and the attributes are like the
511 arguments of those functions. Note however that value array is NOT supported
514 You can also specify extra flags, such as CONSTRUCT or CONSTRUCT_ONLY using the
515 \'flags\' attribute. You can specify multiple flags by oring them together with
516 \'|\'. These flags correspond to the GParamFlags enumeration except do not
517 include the G_PARAM_ prefix. So for example to define an enumeration property,
518 which is a CONSTRUCT_ONLY property, we could do the following:
521 private SomeEnumerationType foo;
523 (nick = _("Short nickname"),
524 blurb = _("Long description"),
525 enum_type = Some:Enumeration:Type
526 default_value = SOME_ENUMERATION_VALUE,
527 flags = CONSTRUCT_ONLY,
532 The above example also gives an example of automatic linking to a standard data
533 memember. By including the attribute \'link\' a get and set handlers will be
534 automatically added without having to type them by hand. This is useful for a
535 vast majority data types that are just linked to some standard data member and
536 do not need to do anything extra on get or set.
538 Another extra feature of properties is the possibility of automatically
539 exporing methods to get and set the property. That is without having to
540 use g_object_set and g_object_get. This is achieved by adding an
541 \'export\' attribute to the list of property attributes.
543 If you do not define a set or get handler, the property will automatically
544 be only readable or writable as appropriate.
546 Gob2 also creates macros which can be used for type safe access to
547 properties through g_object_set and g_object_get.
548 The macros are called <type>_PROP_<argument name>(x) and
549 <type>_GET_PROP_<argument name>(x). They define both the string and the
550 value part of the argument. So for setting an argument of height, one would
551 use (for object type My:Object):
554 g_object_set (G_OBJECT (object),
555 MY_OBJECT_PROP_HEIGHT (7),
559 And for getting, you would use:
563 g_object_get (G_OBJECT (object),
564 MY_OBJECT_GET_PROP_HEIGHT (&height),
568 Note however that the type safety only works completely on GNU C compilers.
569 The code will compile on other compilers but with minimal type safety.
570 For complete type safety it is useful to use the get/set methods that
571 are defined by using the \'export\' attribute.
573 To get bettery type safety on some of the property types, you can specify
574 the \'type\' attribute which will add casts where appropriate in code dealing
575 with this property. This is especially useful for POINTER and OBJECT types.
578 You can also override properties from parent objects (that is override their
579 implementation, not their attributes). Do this by adding the
580 special \'override\' attribute. For example if the parent object
581 had a \'height\' property then you could override it by
587 set { self\->_priv\->height = g_value_get_int (VAL); }
588 get { g_value_set_int (VAL, self\->_priv\->height); };
591 Overriding is supported since gob 2.0.10.
595 There is a whole array of possible methods. The three normal,
596 "familiar" method types are private, protected and public. Public are
597 defined as normal functions with a prototype in the header file.
598 Protected methods are defined as normal methods (which you can call from other
599 files), but their prototype is placed in the private header file. Private
601 are defined as static functions with prototypes at the top of the .c
602 file. Then there are signal, virtual and override methods. More on those
604 define init and class_init methods with a special definition if you want
605 to add code to the constructors or you can just leave them out.
606 You can also not define a body for a method, by just using \';\' instead of a
607 body. This will define an empty function. You can\'t do this for non-void
608 regular public, private or protected methods, however it is acceptable for
609 non-void virtual, signal and override methods.
611 .B "Function argument lists:"
613 For all but the init and class_init methods, you use the
614 following syntax for arguments. The first argument can be just "self",
615 which gob will translate into a pointer to the object instance. The rest
616 of the arguments are very similar to normal C arguments. If the
617 typename is an object pointer you should use the syntax defined above
618 with the words separated by \':\'
622 <type> <argument id> (check <list of checks>)
625 The checks are glib type preconditions, and can be the following:
626 "null", which tests pointers for being NULL, "type" which checks GTK+
627 object pointers for being the right type, "<test> <number>" which tests
628 numeric arguments for being a certain value. The test can be a <,>,<=,>=
634 int h (check > 0 < 11),
635 Gtk:Widget *w (check null type))
639 This will be the prototype of a function which has a self pointer
640 as the first argument, an integer argument which will be checked and has
641 to be more then 0 and less then 11, and a pointer to a GtkWidget object
642 instance and it is checked for being null and the type will also be
645 .B "Function attributes:"
647 For method that aren't virtual, signal or override methods, and aren't
648 init or class_init, GLib function attribute macros G_GNUC_PRINTF,
649 G_GNUC_SCANF, and G_GNUC_FORMAT can optionally be included after the
650 argument list. Simply include an \'attr\' keyword and the C code to include
651 in the file. You have to include braces and anything inside the braces
652 will be printed into the header file after the function declaration and
653 before the trailing semicolon. The braces themselves are not printed.
658 print (self, const char *format (check null), ...)
659 attr {G_GNUC_PRINTF(2, 3)}
663 This will produce a prototype which will generate a warning at compile
664 time if the contents of the format argument (argument number 2) aren't
665 consistent with the types and number of the subsequent variadic
666 arguments (the first of which is argument number 3). Only one \'attr\'
667 keyword per method is allowed.
668 If you have more than one attribute to include, you should
669 put them all within the braces.
670 Note that function attributes were aded in version 2.0.16.
674 Methods which have a return value, there also has to be something
675 returned if there is an error, such as if a precondition is not met.
676 The default is 0, casted to the type of the method. If you need to
677 return something else then you can specify an \'onerror\' keyword after
678 the prototype and any optional function attribute macros, and after
679 that a number, a token (an identifier) or a bit of C code enclosed in
680 braces {}. The braces will not be printed into the output, they just
681 delimit the string. For example:
684 public void * get_something (self, int i (check >= 0)) onerror NULL {
689 The onerror value is also used in overrides that have a return value, in
690 case there isn\'t a parent method, PARENT_HANDLER will return it. More about
695 Some signal and virtual methods have a return type. But what happens if
696 there is no default handler and no one connects to a signal. GOB2 will
697 normally have the wrappers return whatever you specify with onerror or \'0\'
698 if you haven\'t specified anything. You can also specify a default
699 return value with the keyword \'defreturn\'. It\'s use is identical to the
700 use of onerror, and you can in fact use both at the same time. Example
703 virtual int get_some_int (self) onerror \-1 defreturn 10 ;
706 That is an empty virtual method (in C++ terms a pure virtual). If you never
707 specify any handler for it in the derived children it will just return 10.
709 .B "Constructor methods:"
711 There are two methods that handle the construction of an object, init and
712 class_init. You define them by just using the init or class_init keyword
713 with an untyped argument in the argument list. The argument will be
714 usable in your function as a pointer to your object or class depending if
715 it\'s init or class_init.
720 /* initialize the object here */
726 /* initialize the class, this is rarely needed */
731 The class_init function is very rarely needed as all standard class
732 initialization is taken care of for you by gob itself. The init function
733 should on the other hand be used whenever you need to construct or initialize
734 anything in the object to put it into a sane state.
736 .B "Constructor, dispose, finalize methods:"
738 Since 2.0.16, you can also easily add code to the object's constructor,
739 dispose, and finalize methods. See GObject documentation on how these are
740 run. The code you add will be run before calling the parents function
741 for dispose and finalize, and after the parent function for constructor.
742 The syntax is just like init and class_init.
747 /* constructor method */
755 /* finalize method */
759 You can also just override those methods as usual, but the above is much easier and nearly as flexible.
761 .B "Virtual methods:"
763 Virtual methods are basically pointers in the class structure,
764 so that one can override the method in derived methods. That is to implement
765 the method in a derived class, you must then use an override method (more
768 (if you put \';\' instead of the C code). A wrapper will also be defined
769 which makes calling the methods he same as public methods. This type of
770 method is just a little bit "slower" then normal functions, but not as
771 slow as signals. You define them by using "virtual" keyword before the
772 prototype. If you put the keyword "private" right after the "virtual"
773 keyword, the wrapper will not be a public method, but a private one.
774 You can do the same with "protected" to make a protected wrapper.
778 Signals are methods to which the user can bind other handlers
779 and override the default handler. The default handler is basically the
780 method body. This is the most versatile and flexible type of a method
781 and also the slowest. You need to specify a whole bunch of things when
782 you define a signal. One thing is when the default handler will be run,
783 first or last. You specify that by "first" or "last" right after the
784 "signal" keyword. Then you need to define the GObject enum types (again
785 without the G_TYPE_ prefix). For that you define the return types
786 and the types of arguments after the "self" pointer (not including the
787 "self" pointer). You put it in the following syntax "<return type> (<list
788 of arguments>)". If the return type is void, the type should be "NONE",
789 the same should be for the argument list. The rest of the prototype is
790 the same as for other method types. The body can also be empty, and
791 also there is a public method wrapper which you can use for calling the
792 signal just like a public method. Example:
795 signal first INT (POINTER, INT)
796 int do_something (self, Gtk:Widget *w (check null type), int length)
805 signal last NONE (NONE) void foo (self);
809 You can include name of signal, if this name is not a C variable name. Example:
812 signal first INT "do-something" (POINTER, INT)
813 int do_something (self, Gtk:Widget *w (check null type), int length)
820 If you don\'t want the wrapper that emits the signal to be public, you can
821 include the keyword "private" after the "signal" keyword. This will make
822 the wrapper a normal private method. You can also make a protected wrapper
823 by using "protected" instead of "private".
825 If you don\'t define a "first" or a "last", the default will be taken as
828 You can also add additional flags. You do this just like with the argument
829 flags, although this is probably very rare. These are the G_SIGNAL_* flags,
830 and you can add them without the G_SIGNAL_ prefix into a parenthesis, just
831 after the "signal" keyword. By default all public signals are G_SIGNAL_ACTION.
833 Also gob2 creates a wrapper macros for typesafe signal connection. That is
834 you will be warned by the compiler if you pass a callback that is not the
835 correct prototype. This will again only warn you on gcc, but it will
836 compile without warning on another compiler. So as with all the typesafety
837 hacks in gob, it is better to test your objects under gcc to get any warnings
838 even if you are using a different compiler in the end.
840 The methods that are created for you are:
843 <class_name>_connect__<signal_name> (<object>, <callback>, <data>)
844 <class_name>_connect_after__<signal_name> (<object>, <callback>, <data>)
845 <class_name>_connect_data__<signal_name> (<object>, <callback>, <data>,
846 <destroy_notify>, <flags>)
850 These three functions correspond to the g_signal_connect,
851 g_signal_connect_after and g_signal_connect_data functions that you would
852 normally use, except they are for a specific signal. Also do note
853 the two underscores between the method name and the signal name. For
854 example to connect the signal "foo" on the object "Test:Object" you
858 test_object_connect__foo (object, callback, data);
862 To use BOXED in the signal arguments you need to tell gob which type of boxed
863 argument you want to use. For this you can just add BOXED_GTK_TYPE_STRING
864 instead of BOXED. For example BOXED_GTK_TYPE_TREE_ITER for GtkTreeIter.
865 This works since version 2.0.13.
867 .B "Override methods:"
869 If you need to override some method (a signal or a virtual method
870 of some class in the parent tree of the new object), you can define and
871 override method. After the "override" keyword, you should put the
872 typename of the class you are overriding a method from. Other then that
873 it is the same as for other methods. The "self" pointer in this case
874 should be the type of the method you are overriding so that you don\'t
875 get warnings during compilation. Also to call the method of the parent
876 class, you can use the PARENT_HANDLER macro with your arguments. Example:
879 override (Gtk:Container) void
880 add (Gtk:Container *self (check null type), Gtk:Widget *wid (check null type))
883 PARENT_HANDLER(self, wid);
887 If the function has a return value, then PARENT_HANDLER is an expression that
888 you can use. It will return whatever the parent handler returned, or the
889 "onerror" expression if there was no parent handler.
893 Inside the code, aliases are set for the methods, so that you don\'t
894 have to type the class name before each call, just type \fBself_\fR instead
895 of the name of the class. So to call a method called \fBblah\fR, you
896 would use the name \fBself_blah\fR.
909 return self_foo (self) + i;
914 .SH MAKING NEW OBJECTS
916 You should define a new method which should be a normal public method. Inside
917 this method, you can use the GET_NEW macro that is defined for you and that
918 will fetch a new object, so a fairly standard new method would look like:
923 GObject *ret = GET_NEW;
924 return G_OBJECT (ret);
929 You should not a subtle peculiarity of the GObject system here. If there is
930 any code inside the G_OBJECT macro argument, it will get executed multiple
931 times. This means that things such as G_OBJECT(GET_NEW) would actually create
932 4 objects, leaking 3 of them. A good rule (as with anywhere in C) is to be
933 careful with all macros.
937 .B "Self alias casts:"
939 There are some standard casts defined for you. Instead of using the full
940 macros inside the .c file, you can use SELF, IS_SELF and SELF_CLASS. Using
941 these makes it easier to for example change class names around.
943 .B "Self alias types:"
945 There are also the Self and SelfClass types inside
946 your .c file. These serve the same function as the above, they make it easier
947 to type and easier to change typenames around which can help a lot during
948 prototyping stage. However you should note that the Self type should not be
949 used in function prototypes as one of the arguments or as a return value type.
950 This is because this is a simple C typedef which is only available inside your
951 \&.c file and not in the header files. You can disable both the self casting
952 macros and the self type aliases by passing \-\-no\-self\-alias to gob.
954 .SH DEALING WITH DIFFERENT GOB VERSIONS
958 In your generated C file, you can use the defines GOB_VERSION_MAJOR
959 GOB_VERSION_MINOR and GOB_VERSION_PATCHLEVEL if you wish to for example
960 use a feature that is only available in some newer gob version. Note however
961 that you can only use these defines in the C code portions of your .gob file,
962 and #ifdef\'s cannot span multiple functions. Check the BUGS section
963 for more on using the C preprocessor and gob.
965 .B "Minimum version requires:"
967 You can also make your .gob file require at least certain version of gob. You
968 do this by putting \'requires x.y.z\' (where x.y.z is the version number)
969 outside of any C block, comment or class, usually you should make this the
970 first line in the file or close to the top. If gob finds this and the version
971 of gob used to compile the code is lower then that listed in the require, gob
972 will generate an error and exit. For example to require that gob2 version
973 2.0.0 or higher be used to compile a file, put this at the top of that file:
980 .SH CREATING NEW ENUM, FLAGS and ERROR TYPES
982 You can create new GObject ENUM, FLAGS and GError types for use in your
983 classes easily. Glib includes some utilities for handling these, however
984 it may be cleaner to use the below specified way in your classes. It also
985 then doesn\'t require any Makefile setup. Make sure this is defined in the
986 same section as the class, that is not in any of the \'%?{\' \'%}\' sections.
988 You use the keywords \'enum\' \'flags\' and \'error\' as you would use the
989 \'class\' keyword. Then you give a prefix for the values in the enumeration.
990 Then you define a list of values just like in C. For \'enum\' types you can
991 also specify the values assigned to each string. Then you specify the type in
992 the standard gob style of specifying types. Here are a few examples
1008 error TEST_OBJECT_ERROR {
1011 } Test:Object:Error;
1015 This will for example define an enum that is equivalent to the following
1020 LAME_CLIENT_IS_CONNECTED,
1021 LAME_CLIENT_NONE = 9,
1029 There is a C++ mode so that gob creates C++ compiler friendly files. You need
1030 to use the \-\-for\-cpp argument to gob. This will make the generated file have
1031 a .cc instead of a .c extension, and several things will be adjusted to
1032 make it all work for a C++ compiler. One thing that will be missing is an
1033 alias to the new method, as that clashes with C++, so instead you\'ll have to
1034 use the full name of the method inside your code. Also note that gob does
1035 not use any C++ features, this option will just make the generated code
1036 compile with a C++ compiler.
1038 .SH OVERRIDING THE GET_TYPE METHOD
1040 The get_type is not really a method, but a function which initializes your
1041 object. Recently objects appeared which require you to make a custom
1042 get_type function. So it is possible
1043 to override this function. To do so, just define a new public method called
1044 get_type, with no arguments. Example:
1050 /* code goes here */
1058 Currently gob will only allow you to implement interfaces (that is, define new
1059 classes which implement an interface) and doesn\'t yet have support for making
1060 new interfaces, but this will be coming at some point in the future.
1062 To define a class that implements an interface add a class flag \'interface\'
1063 with the type name of the interface as an argument. Then to implement
1064 a specific method of the interface, just add \'interface <typename>\'
1065 before the method definition. The method can, and probably should be,
1068 Interface methods behave very similarly to virtual/override methods.
1069 As with override methods, you can use PARENT_HANDLER in the definition of an
1070 interface method to call the implementation of the same interface method in
1073 The NAME_parent_iface variable may be used to access the complete interface
1074 structure from a parent class, where NAME is the implemented interface (with
1075 colons replaced by underscores).
1076 This enables access to the full parent implementation of an interface.
1077 For example, if a class implements the Gtk:Tree:Model interface then the
1078 implementation of the same interface in the parent class is available via
1079 the Gtk_Tree_Model_parent_iface pointer.
1080 If an interface is not implemented in the parent class, then the corresponding
1081 parent_iface value will be a null pointer.
1083 The following example implements a new object, that implements the
1084 Gtk:Tree:Model interface and implements the get_flags method of that
1085 interface. Do note that except for standard (GTK+ and glib) specific
1086 interfaces which seem
1087 to have a non-standard name for the interface structure, the structure
1088 should end with and Iface, if you are implementing an interface. That
1089 is for example for the Gtk:Tree:Model, the structure containing the
1090 table of methods should be named GtkTreeModelIface.
1092 class Some:Object from G:Object
1093 (interface Gtk:Tree:Model)
1095 /* function implemented for the Gtk:Tree:Model interface */
1096 interface Gtk:Tree:Model
1097 private GtkTreeModelFlags
1098 get_flags (Gtk:Tree:Model *self (check null type))
1100 /* Here would be the implementation */
1101 return (GtkTreeModelFlags)0;
1107 If you want to implement multiple interfaces just list more class flag lines
1111 class Some:Object from G:Object
1112 (interface Gtk:Tree:Model)
1113 (interface Gtk:Editable)
1120 .SH DIRECT BonoboObject SUPPORT
1122 If you want to build a BonoboObject class gob2 has direct support for these.
1123 Just create a new object that derives from
1125 Then use a "BonoboObject" class flag with the interface name as an
1126 argument. The interface name should be as you would type it in C, that is with
1127 underscores as namespace separators. Then you add the methods (using exact
1128 same names as in the idl file) and prepend those methods with a BonoboObject
1129 keyword. For example imagine you have an interface GNOME/Foo/SomeInterface,
1130 with a method fooBar that takes a single string:
1133 class Foo:Some:Interface from Bonobo:Object
1134 (BonoboObject GNOME_Foo_SomeInterface) {
1138 fooBar (PortableServer_Servant servant,
1139 const CORBA_char *string,
1140 CORBA_Environment *ev)
1142 Self *self = SELF (bonobo_object_from_servant (servant));
1144 /* your code here */
1151 Note that the implementation method can be private, in fact that\'s probably
1152 a good idea to do. It won\'t work to make this a signal, it can however
1153 be a virtual. Note that the method prototype must match the one from the
1154 interface header file, or you will get a bad assignment warning. You should
1155 check the header file generated by orbit\-idl and see the epv structure
1156 for the correct prototypes if you can\'t figure them out from the idl itself.
1157 Also note that the first argument is not "self", but the servant and you must
1158 use bonobo_object_from_servant function to get the actual object pointer.
1160 .SH DIRECT LIBGLADE SUPPORT
1162 Gob can simplify writing a libglade class. Just create a new object that
1163 derives from a GtkContainer widget. Then use a "GladeXML" class flag
1164 with the glade file name, root widget and optional domain as arguments
1165 between double quotes. For example:
1168 class My:Glade from Gtk:Window (GladeXML "gob\-libglade.glade" "root")
1174 Note however that then "gob\-libglade.glade" would have to be in the current
1175 directory. You could specify a path, but that may not work for all
1176 installations. You can replace the glade filename with a token to be used
1177 in the generated .c file and you can then have a macro with the filename,
1181 class My:Glade from Gtk:Window (GladeXML GLADE_FILE "root")
1187 And somewhere in your header files you would have
1190 #define GLADE_FILE "/path/to/file.glade"
1194 You can declare widgets as data members by adding a 'GladeXML' to
1198 private Gtk:Button * button1 GladeXML;
1201 This will automatically set the "button1" from the GladeXML file.
1203 All signals created with glade are automatically connected if you defined
1204 those class methods in your class. For example suppose in glade that
1205 we set the "connect" signal on button1 to go to on_button1_clicked, then
1206 in our gob file we can just write:
1210 on_button1_clicked(self, GtkButton * button)
1216 See the examples directory for a full example. Note that this feature
1217 requires version at least 2.0.12.
1220 .SH IDENTIFIER CONFLICTS
1222 Gob will need to define some local variables and functions in the generated
1223 files, so you need to take some precaution not to conflict with these. The
1224 general rule of thumb is that all of these start with three underscores. There
1225 is one, "parent_class" which doesn\'t because it\'s intended for use in your
1226 code. For virtuals or signals, you cannot use the identifier __parent__
1227 which is used for the parent of the object. You should actually never access
1228 __parent__ either as it not guaranteed that it will stay named this way.
1229 Data members cannot be named __parent__ nor _priv. For methods, you cannot
1230 use the identifiers "init" or "class_init" unless you mean the constructor
1231 methods. You shouldn\'t generally use 3 underscores even in override method
1232 argument lists and virtual and signal method names as it might confuse the
1233 PARENT_HANDLER macro. In fact avoiding all names with three underscores is
1234 the best policy when working with gob.
1236 There are a couple of defines which you shouldn\'t be redefining in the code
1237 or other headers. These are SELF, IS_SELF, SELF_CLASS, SELF_TYPE, ARG, VAR,
1238 PARENT_HANDLER, GET_NEW, GOB_VERSION_MAJOR, GOB_VERSION_MINOR and
1239 GOB_VERSION_PATCHLEVEL.
1241 As for types, there are Self and SelfClass types which are only defined in your
1242 source files. Their generation (just like the generation of the SELF macros)
1243 can be turned off, see command line options.
1245 .SH USING GTK\-DOC STYLE INLINE DOCUMENTATION
1247 If you want to use gtk\-doc style inline documentation for your objects, you
1248 can do one of two things. First, you could include the inline documentation
1249 comments in your %{ %} section which will then be put verbatim into the
1250 output source file. This is the way you should use for functions you define
1251 outside of the class.
1253 For class methods, you should use a gtk+ style comment, however it can be
1254 indented any number of tabs or spaces and you can use the short method name
1255 without the type prefix. Gob will automatically try to extract these and
1256 translate to full names and put them in the output source file. An example
1260 class Gtk:Button:Example from Gtk:Button {
1264 * Makes a new #GtkButtonExample widget
1266 * Returns: a new widget
1272 return (GtkWidget *)GET_NEW;
1277 If the function you are documenting is a signal or a virtual then it will
1278 be documenting the wrapper that starts that virtual function or emits
1281 .SH DEALING WITH CIRCULAR HEADERS
1283 Sometimes you may need to use an object of type MyObjectA in the MyObjectB
1284 class and vice versa. Obviously you can\'t include headers for both. So you
1285 need to just declare the typedef in the header of A for B, and the other way
1286 around as well. The headers generated include a protecting
1287 define before it declares the typedef. This define is the
1288 __TYPEDEF_<upper case object name>__. So inside my\-object\-a.h there will be
1292 #ifndef __TYPEDEF_MY_OBJECT_A__
1293 #define __TYPEDEF_MY_OBJECT_A__
1294 typedef struct _MyObjectA MyObjectA;
1298 Now instead of including my\-object\-a.h in the header section of
1299 my\-object\-b.gob, just copy the above code there and you\'re set for using
1300 MyObjectA as a type in the method parameters and public types.
1302 Another way to get out of this problem is if you can use those types only
1303 in the private members, in which case they won\'t be in the generated public
1306 .SH BUILDING WITH MAKE
1308 If you are using normal makefiles, what you need to do is to add a generic
1309 rule for .gob files. So you would include the following in the Makefile
1310 and then just use the .c and .h files as usual (make sure the space
1311 before the \'gob2\' is a tab, not spaces):
1314 %.c %.h %\-private.h: %.gob
1319 .SH BUILDING WITH AUTOCONF and AUTOMAKE
1321 This is a little bit more involved. Basically the first thing to do is to
1322 check for GOB2 in your configure.in file. You can use the supplied m4 macro
1323 which will also check the version of gob. Basically you include this:
1329 This will replace @GOB2@ in your makefiles with the full path of gob2. Thus
1330 when adding the generic rule to your Makefile.am file, it should look like:
1333 %.c %.h %\-private.h: %.gob
1338 For Makefile.am you have to set up a couple more things. First you have to
1339 include the generated .c and .h files into BUILT_SOURCES variable. You
1340 have to include both the .gob and the .c and .h files in the SOURCES for your
1343 .SH PREVENTING SPURIOUS BUILDS
1345 When nothing has changed you might not really want to rebuild everything and
1346 gob provides options \-\-no\-touch (since 2.0.13) and \-\-no\-touch\-headers to avoid
1347 this. When working with build systems such as automake you have to be more
1348 careful as just using those options can cause automake to get confused and you
1349 will need to use something like the following:
1352 foo_SOURCES = foo.gob foo.gob.stamp foo.c foo.h foo\-private.h
1353 BUILT_SOURCES = foo.gob.stamp
1354 MAINTAINERCLEANFILES = foo.gob.stamp
1357 @GOB2@ \-\-no\-touch $<
1364 GOB does several things to make debugging the code easier. First it adds
1365 preprocessor commands into the output c file that point to the correct places
1366 in your .gob input file. However sometimes there might be some bigger
1367 confusion and this is just not helpful. In this case you will probably want
1368 to have gcc point you directly at the generated files. For this use
1369 the \-\-no\-lines command line option. You should also note that these commands
1370 are not generated for the public header file at all. If there is an error which
1371 points you to the public header file, make sure you fix this error in the .gob
1372 file, otherwise your changes will not have any effect after gob recompiles the
1375 Sometimes you might want to know which method you are in for some debugging
1376 output. GOB will define __GOB_FUNCTION__ macro, which is just a string constant
1377 with a pretty name of the method.
1381 It is possible to have your .gob file also preprocessed by m4. This is useful
1382 if you have a lot of files and you\'d like to have some preprocessor put in
1383 some common features. All you have to do is add \-\-m4 to the command line
1384 of gob2 and gob2 will first run your file through m4. You can print the
1385 directory that is searched for m4 files by running "gob2 \-\-m4\-dir"
1387 All the arguments after \-\-m4 will be passed to m4 itself, so it has to be the
1388 last gob2 argument on the command line. This way you can specify arbitrary
1389 options to pass to m4.
1393 The lexer does not actually parse the C code, so I\'m sure that some corner
1394 cases or maybe even some not so corner cases of C syntax might confuse gob
1395 completely. If you find any, send me the source that makes it go gaga and
1396 I\'ll try to make the lexer try to handle it properly, but no promises.
1398 Another thing is that gob ignores preprocessor macros. Since gob counts
1399 braces, the following code won\'t work:
1411 To make this work, you\'d have to do this:
1424 There is no real good way we can handle this without parsing C code, so we
1425 probably never will. In the future, I might add #if 0 as a comment but
1426 that\'s about as far as I can really take it and even that is problematic.
1427 Basically, if you use gob, just don\'t use the C preprocessor too extensively.
1428 And if you use it make sure that you do not cross the boundaries of the C
1431 Comments will not get through to the generated files unless inside C code.
1432 This is not the case for gtk\-doc style comments which are supported.
1434 The short name aliases are actually implemented as pointers to functions. Thus
1435 if you want to get the pointer of a function using the short name alias you
1436 can\'t use the \'&\'. Thus:
1439 void (*foo)(Self *);
1441 /* this will NOT work */
1442 foo = &self_short_name;
1444 /* this will work */
1445 foo = self_short_name;
1447 /* Both of these will work */
1448 foo = &my_class_long_name;
1449 foo = my_class_long_name;
1455 George Lebl <jirka@5z.com>
1457 GOB2 Homepage: http://www.jirka.org/gob.html