3 .\" (C) 1999 George Lebl <jirka@5z.com>
5 .\" This manual page is covered by the terms of the GNU General
8 .TH GOB 1 "GOB @VERSION@"
10 GOB \- The GTK+ Object Builder
18 GTK+ Object Builder is a simple preprocessor for easily creating
19 GTK+ objects. It does not parse any C code and ignores any C errors. It
20 is in spirit similar to things like lex or yacc.
30 Display a simple help screen.
33 Display version information (note, --version was not added until 0.92.0)
38 Exit with an error code even when you encounter a warning.
41 Exit with an error only on errors, not on warnings, this is the default.
47 Never add the extern "C" to the header.
50 Never generate any code with GNU C extensions. However all the GNU C
51 extensions are always wrapped in #ifdef __GNUC__, so code using them compiles
52 correctly even on non-GNU compilers. This option is for purists only.
53 (using GNU extensions some warnings are eliminated, some ugly hacks and there
54 is better argument type safety, so it's good to use them)
57 Don't touch the generated header file unless it really changed, this avoids
58 spurious rebuilds, but can confuse some make systems (automake in particular),
59 so it is not enabled by default. Private header is still touched even if
62 .B --always-private-header
63 Always create a \fB<basename>-private.h\fR file, even if it would be empty.
64 Otherwise, it is only created when there are private data members in the class.
65 This option implicitly negates --no-private-header
67 .B --no-private-header
68 Never create a private header file. If we use any private data members,
69 define the private data structure at the point in the .c source where
70 the class definition begins. This option implicitly negates
71 --always-private-header
76 Do not write any output files, just check syntax of the input file.
80 Because we need to parse out different parts of the typename, sometimes you
81 need to specify the typename with some special syntax. Types are specified in
82 capitalized form and words are separated by ':'. The first word of the type
83 (which can be empty) is the "namespace". This fact is for example used for the
84 type checking macro and the type macro. For "Gtk:New:Button", the macros will
85 be GTK_IS_NEW_BUTTON and GTK_TYPE_NEW_BUTTON. This colon separated format of
86 typenames is used in the class declaration header and for method argument
91 The filenames are created from the typename. The words are
92 separated by '-' and all in lower case. For example for an object named
93 "Gtk:New:Button", the files are \fBgtk-new-button.c\fR and
94 \fBgtk-new-button.h\fR.
95 If you are using C++ mode, the output .c file will in fact be a .cc file.
96 If you have any private data members, a private header file will also
97 be created, called \fB<basename>-private.h\fR (for the example above it
98 would be gtk-new-button-private.h).
99 The public header file is created to be human readable and to be used as a
100 reference to the object. The .c source file is not created as a human
101 readable source and is littered with #line statements, which make the
102 compiler attempt to point you to the right line in your .gob file in
103 case of parsing errors. The output should not be edited by hand, and
104 you should only edit the .gob file.
106 .SH INCLUDING NORMAL C CODE IN THE OUTPUT FILES
108 To include some code directly in the output C file begin with '%{'
109 on an empty line and end the code with a '%}' on an empty line. These
110 sections will appear in the output files in the order they are given.
111 There are several other \fIsections\fR to which you can put code. You can
112 put it in the 'header' section (which can be abbreviated 'h') and it will
113 go into the public header file. You can also put it in the 'privateheader'
114 section (abbreviated 'ph') which will make the code go into the private
115 header file. Sometimes you want some code (other includes) to appear before
116 the extern "C" and the protecting define. To do this you can put them
117 into the 'headertop' (or 'ht') section. You may wish to include code or
118 comments in all the files, which you can do by putting them into the 'all'
119 (or 'a') section. Similarly, code you wish to appear at the top of all
120 files go in the 'alltop' (or 'at') section. For example:
124 /* this will be on top of all output files */
128 /* this will be on top of the public header */
132 /* this will go into the private header file */
136 /* will be included in the header */
137 void somefunc(int i);
141 /* will be included in all files */
145 /* will be included in the C file */
156 Gob will automatically include the class header file at the top of the .c
157 source file. If you wish to include it somewhere else, put the include
158 into some %{ %} section above the class definition, and gob will not include
159 it automatically. This way you can avoid circular includes and control
160 where in the file do you want to include the header.
162 If you made any data members private, gob will also create a source file
163 that will be called \fB<basename>-private.h\fR. Same rule as above applies
164 for this just as it does for the regular header file. If you do explicitly
165 include the regular header file, you should always include this private
166 header file below it. That is, if you use any private data members. If you
167 don't, the private header file automatically includes the public header file,
168 and thus the public header file will be indirectly included at the very top
171 .SH MAKING A NEW CLASS
175 There can be only one class per input file. Defining a class
176 is sort of like in Java, you define the class and write inline code
177 directly into the class definition. To define a class you need to specify
178 the new object name and the name of the object from which it is derived
179 from, such as this "class <new type> from <parent type> { <class code> }".
183 class Gtk:New:Button from Gtk:Button {
191 There are five types of data members. Three of them are normal data numbers,
192 one is class wide (global) in scope and one is a virtual one, usually linked to
193 a normal data member or a class wide data member. The three normal data
194 members are public, protected and private. Public and protected are basically
195 just entries in the object structure, while private has it's own dynamically
196 allocated private structure. Protected members are always put after the public
197 one in the structure and are marked protected in the header file. There is
198 only one identifier allowed per typename unlike in normal C. Example:
202 private GtkWidget *h;
207 Public and protected data members are accessed normally as members of
208 the object struct. Example where 'i' is as above a public data member:
215 The private data members are defined in a structure which is only available
216 inside the .c file, or by including a private header file. You must access
217 them using the structure _priv. Example
218 where 'h' is the private data member (as in the above example):
221 object->_priv->h = NULL;
224 The _priv structure is defined in the \fB<basename>-private.h\fR.
225 This file is automatically included if you don't include it yourself. You
226 should always explicitly include it if you explicitly also include the main
229 In case you use the \fB--no-private-header\fR option, no
230 private header file is created and you can only access the _priv pointer
231 below the class definition in the .gob file.
233 Classwide data members:
235 Sometimes you want a datamember to be shared by all objects. You then need
236 the "classwide" scope keyword. So for example the following adds a global
243 To access the member you do the standard voodoo of getting the class from the
244 object and casting it to your class pointer. Thus the following would work:
247 SELF_CLASS(GTK_OBJECT(object)->klass)->foo = 20;
251 Automatic Initialization (0.93.0 and higher only):
253 You can automatically initialize the public private and protected data members
254 without having to add an init method. The advantage here is that
255 initialization is kept close to the definition of the data member and thus
256 it's easier to check. To do this, just add a '=' followed by a number or
257 a token. It is also possible to include arbitrary C code for more elaborate
258 initializations by putting it all in curly braces. Note that the curly braces
259 will not be printed into the output, but since gob does not C parsing it needs
260 them to figure out where the C code ends. The code will be inserted into the
261 init method, above the user defined body. So for example the following
262 will initialize an integer to -1 and a string with a newly allocated string
267 private char *bar = {g_strdup("hello")};
271 Automatic Destruction (0.93.0 and higher only):
273 Most data stored as pointers needs to have a function called when the object
274 is destroyed, to either free it or give up a reference. Gob will let you
275 define a function to be called on the data the object is destroyed. This is
276 achieved by putting 'destroywith' followed by a function name after the
277 variable definition. It is only called if the data you defined this on
278 is not NULL, so you cans specify functions which do not handle NULL. It
279 is very much like the GDestroyNotify function used in GTK+ and glib in many
280 places. Unlike many other places, gob will not enforce any kind of type
281 safety here so be a little bit more careful. Any function you give it will
282 be called as a "void function(void *)". It will in fact be cast into such
283 a form before called. This is to avoid spurious warnings for gtk calls to
284 subclass methods. The function needs not be of that form, it just has to
285 take one argument which is the pointer to the data. You should also not
286 define this on any non-pointer data as the results may be undefined.
290 public Gtk:Widget *window = NULL
291 destroywith gtk_widget_destroy;
292 public char *foo = {g_strdup("bar")}
296 Note that the function name you give must be a real function and not macro.
297 Also note that this is always called in the "finalize" method of GtkObject.
299 Sometimes you may want to run arbitrary code on destruction. While this can
300 be perfectly well done in the destroy handler. Depending on the style you
301 may want to include all destruction/initialization code together with the
302 definition of the data member. Thus you may want to put arbitrary code which
303 will then be inserted into the "finalize" method of GtkObject. This can be
304 done with the "destroy" keyword followed by arbitrary code in curly braces.
305 Inside this code a macro called VAR will be define which refers to your
306 variable. So for example destroying a GString can be either done with
307 a helper routine or the following code:
310 public GString *string = {g_string_new(NULL)}
312 if(VAR) g_string_free(VAR, TRUE);
316 The thing to remember with these is that there are many ways to do this
317 and you'd better be consistent in your code in how you use the above things.
318 Also defining a helper routine that will do the destruction will be a nicer
319 thing to do if that's a possibility. The "destroy" keyword with code does
320 take up more space in the file and it may become more cluttered.
324 The fourth type of a data member an argument type. It is a named data member
325 which is one of the features of the GTK+ object system. You need to define a
326 get and a set handler. They are fragments of C code that will be used to get
327 the value or set the value of the argument. Inside them you can use the define
328 ARG to which you assign the data or get the data. You can also use the
329 identifier "self" as pointer to the object instance. The type is defined as
330 one of the gtk type enums, but without the GTK_TYPE_ prefix. For example:
334 argument INT height set { self->height = ARG; } get { ARG = self->height; };
338 If you don't define a set or a get handler it will be a read-only
339 or a write-only argument. If you want to add extra argument flags, add
340 them into parenthesis after the argument keyword, separated by '|' and
341 without the GTK_ARG_ prefix. For example:
345 argument (CONSTRUCT) INT height get { ARG = self->height; };
348 This makes the argument settable even before the object is constructed, so
349 that people can pass it to gtk_object_new function. Useful is also
350 CONSTRUCT_ONLY flag which makes the argument only available during
351 construction of the object.
353 Since 0.92.1, gob creates macros which can be used for type safe access to
354 gtk arguments. The macros are called <type>_ARG_<argument name>(x) and
355 <type>_GET_ARG_<argument name>(x). They define both the string and the
356 value part of the argument. So for setting an argument of height, one would
357 use (for object type My:Object):
360 gtk_object_set(GTK_OBJECT(object),
361 MY_OBJECT_ARG_HEIGHT(7),
365 And for getting, you would use:
369 gtk_object_set(GTK_OBJECT(object),
370 MY_OBJECT_GET_ARG_HEIGHT(&height),
374 Note however that the type safety only works completely on GNU C compilers.
375 The code will compile on other compilers but with minimal type safety.
377 To get good type safety on POINTER types however, you should specify
378 an optional C type that gob should use. For other then POINTER types
379 this is redundant but possible. To do this, place '(type <c type>)'
380 right after the GTK+ type. Example:
383 argument POINTER (type char *) foo set { /* foo */ } get { /* bar */ };
387 Sometimes it can become tiresome to type in the set and get handlers if
388 they are trivial. So gob since version 0.93.0 provides automatic argument
389 linking to data members. There are three different cases it handles, direct
390 link (keyword 'link'), string linking (keyword 'stringlink') and object
391 linking (keyword 'objectlink'). You just place the keyword after the argument
392 name instead of the get/set handlers. It will link to a data member of the
393 same name that was defined earlier in the input file. Best is to see examples:
397 argument INT foo link;
404 argument INT (type int) foo
405 get { ARG = self->foo; }
406 set { self->foo = ARG; };
413 argument POINTER foo stringlink;
420 argument POINTER (type char *) foo
422 ARG = self->_priv->foo;
424 g_free(self->_priv->foo);
425 self->_priv->foo = g_strdup(ARG);
429 And for the objectlink we would have:
432 public Gtk:Object * foo;
433 argument POINTER foo objectlink;
439 protected Gtk:Object * foo;
440 argument POINTER (type Gtk:Object *) foo
445 gtk_object_unref(self->foo);
448 gtk_object_ref(self->foo);
453 As you see it will handle NULLs correctly (for the string, g_free and g_strdup
454 handle NULLs). And it will also handle private, protected and public members.
455 Also you should notice that when the get is used, only a pointer is always
456 returned for both objectlink and strinklink. So you should treat the returned
457 value with care and never free it (and notice that it will only be around
458 until you set the argument to something else or destroy the object).
462 There is a whole array of possible methods. The three normal,
463 "familiar" method types are private, protected and public. Public are
464 defined as normal functions with a prototype in the header file.
465 Protected methods are defined as normal methods (which you can call from other
466 files), but their prototype is placed in the private header file. Private
468 are defined as static functions with prototypes at the top of the .c
469 file. Then there are signal, virtual and override methods. More on those
471 define init and class_init methods with a special definition if you want
472 to add code to the constructors or you can just leave them out.
473 You can also not define a body for a method, by just using ';' instead of a
474 body. This will define an empty function. You can't do this for non-void
475 regular public, private or protected methods, however it is acceptable for
476 non-void virtual, signal and override methods.
478 Function argument lists:
480 For all but the init and class_init methods, you use the
481 following syntax for arguments. The first argument can be just "self",
482 which gob will translate into a pointer to the object instance. The rest
483 of the arguments are very similar to normal C arguments. If the
484 typename is an object pointer you should use the syntax defined above
485 with the words separated by ':'
489 <type> <argument id> (check <list of checks>)
492 The checks are glib type preconditions, and can be the following:
493 "null", which tests pointers for being NULL, "type" which checks GTK+
494 object pointers for being the right type, "<test> <number>" which tests
495 numeric arguments for being a certain value. The test can be a <,>,<=,>=
499 public int foo(self, int h (check > 0 < 11), Gtk:Widget *w (check null type))
503 This will be the prototype of a function which has a self pointer
504 as the first argument, an integer argument which will be checked and has
505 to be more then 0 and less then 11, and a pointer to a GtkWidget object
506 instance and it is checked for being null and the type will also be
511 Methods which have a return value, there also has to be something
512 returned if there is an error, such as if a precondition is not met. The
513 default is 0, casted to the type of the method. If you need to return
514 something else then you can specify an "onerror" keyword after the
515 prototype and after that a number, a token (an identifier) or a bit of C
516 code enclosed in braces {}. The braces will not be printed into the
517 output, they just delimit the string. For example:
520 public void * get_something(self, int i (check >= 0)) onerror NULL {
525 The onerror value is also used in overrides that have a return value, in
526 case there isn't a parent method, PARENT_HANDLER will return it. More about
531 Some signal and virtual methods have a return type. But what happens if
532 there is no default handler and no one connects to a signal. GOB will
533 normally have the wrappers return whatever you specify with onerror or '0'
534 if you haven't specified anything. But since 0.93.2 you can specify a default
535 return value with the keyword 'defreturn'. It's use is identical to the
536 use of onerror, and you can in fact use both at the same time. Example
539 virtual int get_some_int(self) onerror -1 defreturn 10 ;
542 That is an empty virtual method (in C++ terms a pure virtual). If you never
543 specify any handler for it in the derived children it will just return 10.
547 There are two methods that handle the construction of an object, init and
548 class_init. You define them by just using the init or class_init keyword
549 with an untyped argument in the argument list. The argument will be
550 usable in your function as a pointer to your object or class depending if
551 it's init or class_init.
556 /* initialize the object here */
562 /* initialize the class, this is rarely needed */
567 The class_init function is very rarely needed as all standard class
568 initialization is taken care of for you by gob itself. The init function
569 should on the other hand be used whenever you need to construct or initialize
570 anything in the object to put it into a sane state. Sometimes you need
571 some arguments, for this you should either use a construct method and a
572 new function like many GTK+ widgets, and/or a CONSTRUCT or CONSTRUCT_ONLY
577 Virtual methods are basically pointers in the class structure,
578 so that one can override the method in derived methods. They can be empty
579 (if you put ';' instead of the C code). A wrapper will also be defined
580 which makes calling the methods he same as public methods. This type of
581 method is just a little bit "slower" then normal functions, but not as
582 slow as signals. You define them by using "virtual" keyword before the
583 prototype. If you put the keyword "private" right after the "virtual"
584 keyword, the wrapper will not be a public method, but a private one.
585 You can do the same with "protected" to make a protected wrapper.
589 Signals are methods to which the user can bind other handlers
590 and override the default handler. The default handler is basically the
591 method body. This is the most versatile and flexible type of a method
592 and also the slowest. You need to specify a whole bunch of things when
593 you define a signal. One thing is when the default handler will be run,
594 first or last. You specify that by "first" or "last" right after the
595 "signal" keyword. Then you need to define the gtk enum types (again
596 without the GTK_TYPE_ prefix). For that you define the return types
597 and the types of arguments after the "self" pointer (not including the
598 "self" pointer). You put it in the following syntax "<return type> (<list
599 of arguments>)". If the return type is void, the type should be "NONE",
600 the same should be for the argument list. The rest of the prototype is
601 the same as for other method types. The body can also be empty, and
602 also there is a public method wrapper which you can use for calling the
603 signal just like a public method. Example:
606 signal first INT(POINTER,INT)
607 int do_something(self, Gtk:Widget *w (check null type), int length)
614 signal last NONE(NONE) void foo(self);
618 If you don't want the wrapper that emits the signal to be public, you can
619 include the keyword "private" after the "signal" keyword. This will make
620 the wrapper a normal private method. You can also make a protected wrapper
621 by using "protected" instead of "private".
623 If you don't define a "first" or a "last", the default will be taken as
626 You can also add additional flags. You do this just like with the argument
627 flags, although this is probably very rare. These are the GTK_RUN_* flags,
628 and you can add them without the GTK_RUN_ prefix into a parenthesis, just
629 after the "signal" keyword. By default all public signals are GTK_RUN_ACTION.
633 If you need to override some method (a signal or a virtual method
634 of some class in the parent tree of the new object), you can define and
635 override method. After the "override" keyword, you should put the
636 typename of the class you are overriding a method from. Other then that
637 it is the same as for other methods. The "self" pointer in this case
638 should be the type of the method you are overriding so that you don't
639 get warnings during compilation. Also to call the method of the parent
640 class, you can use the PARENT_HANDLER macro with your arguments. Example:
643 override (Gtk:Container) void
644 add (Gtk:Container *self (check null type), Gtk:Widget *wid (check null type))
647 PARENT_HANDLER(self, wid);
651 If the function has a return value, then PARENT_HANDLER is an expression that
652 you can use. It will return whatever the parent handler returned, or the
653 "onerror" expression if there was no parent handler.
657 Inside the code, pointers are set for the methods, so that you don't
658 have to type the class name before each call, just the name of the method.
671 return foo(self) + i;
678 You should define a new method which should be a normal public method. Inside
679 this method, you can use the GET_NEW macro that is defined for you and that
680 will fetch a new object, so a fairly standard new method would look like:
686 ret = GTK_OBJECT (GET_NEW);
694 There are some standard casts defined for you. Instead of using the full
695 macros inside the .c file, you can use SELF, IS_SELF and SELF_CLASS. Using
696 these makes it easier to for example change classnames around. There is
697 however no self type, so if you're declaring a pointer to your object, you
698 still have to use the full type.
700 .SH DEALING WITH DIFFERENT GOB VERSIONS
704 In your generated C file, you can use the defines GOB_VERSION_MAJOR
705 GOB_VERSION_MINOR and GOB_VERSION_PATCHLEVEL if you wish to for example
706 use a feature that is only available in some newer gob version. Note however
707 that you can only use these defines in the C code portions of your .gob file,
708 and #ifdef's cannot span multiple functions. Check the BUGS section
709 for more on using the C preprocessor and gob. Also note that these
710 have only been available since the 0.92.1 version of gob.
712 Minimum version requires:
714 You can also make your .gob file require at least certain version of gob. You
715 do this by putting 'requires x.y.z' (where x.y.z is the version number) outside
716 of any C block, comment or class, usually you should make this the first line
717 in the file or close to the top. If gob finds this and the version of gob used
718 to compile the code is lower then that listed in the require, gob will generate
719 an error and exit. For example to require that gob version 0.92.1 or higher
720 be used to compile a file, put this at the top of that file:
726 It should be noted however that this feature was not added until 0.92.1, and
727 so if the file gets compiled by a lower version, gob would generate a
728 syntax error. Thus by putting in a requires line, you are implicitly
729 requiring at least 0.92.1.
733 There is a C++ mode so that gob creates C++ compiler friendly files. You need
734 to use the --for-cpp argument to gob. This will make the generated file have
735 a .cc instead of a .c extension, and several things will be adjusted to
736 make it all work for a C++ compiler. One thing that will be missing is an
737 alias to the new method, as that clashes with C++, so instead you'll have to
738 use the full name of the method inside your code. Also note that gob does
739 not use any C++ features, this option will just make the generated code
740 compile with a C++ compiler.
742 .SH IDENTIFIER CONFLICTS
744 Gob will need to define some local varibles and functions in the generated
745 files, so you need to take some precaution not to conflict with these. The
746 general rule of thumb is that all of these start with three underscores. There
747 is one, "parent_class" which doesn't because it's intended for use in your
748 code. For virtuals or signals, you cannot use the identifier __parent__
749 which is used for the parent of the object. You should actually never access
750 __parent__ either as it not guaranteed that it will stay named this way.
751 Data members cannot be named __parent__ nor _priv. For methods, you cannot
752 use the identifiers "init" or "class_init" unless you mean the constructor
753 methods. You shouldn't generally use 3 underscores even in override method
754 argument lists and virtual and signal method names as it might confuse the
755 PARENT_HANDLER macro. In fact avoiding all names with three underscores is
756 the best policy when working with gob.
758 There are a couple of defines which you shouldn't be redefining in the code
759 or other headers. These are SELF, IS_SELF, SELF_CLASS, ARG, VAR,
760 PARENT_HANDLER, GET_NEW, GOB_VERSION_MAJOR, GOB_VERSION_MINOR and
761 GOB_VERSION_PATCHLEVEL.
763 .SH USING GTK-DOC STYLE INLINE DOCUMENTATION
765 If you want to use gtk-doc style inline documentation for your objects, you
766 can do one of two things. First, you could include the inline documentation
767 comments in your %{ %} section which will then be put verbatim into the
768 output source file. This is the way you should use for functions you define
769 outside of the class.
771 For class methods, you should use a gtk+ style comment, however it can be
772 indented any number of tabs or spaces and you can use the short method name
773 without the type prefix. Gob will automatically try to extract these and
774 translate to full names and put them in the output source file. An example
778 class Gtk:Button:Example from Gtk:Button {
782 * Makes a new #GtkButtonExample widget
784 * Returns: a new widget
790 return GTK_WIDGET(GET_NEW);
795 If the function you are documenting is a signal or a virtual then it will
796 be documentating the wrapper that starts that virtual function or emits
799 .SH DEALING WITH CIRCULAR HEADERS
801 Sometimes you may need to use an object of type MyObjectA in the MyObjectB
802 class and vice versa. Obviously you can't include headers for both. So you
803 need to just declare the typedef in the header of A for B, and the other way
804 around as well. The headers generated since v0.92.2 include a protecting
805 define before it declares the typedef. This define is the
806 __TYPEDEF_<upper case object name>__. So inside my-object-a.h there will be
810 #ifndef __TYPEDEF_MY_OBJECT_A__
811 #define __TYPEDEF_MY_OBJECT_A__
812 typedef struct _MyObjectA MyObjectA;
816 Now instead of including my-object-a.h in the header section of
817 my-object-b.gob, just copy the above code there and you're set for using
818 MyObjectA as a type in the method parameters and public types.
820 Another way to get out of this problem is if you can use those types only
821 in the private members, in which case they won't be in the generated public
826 Also the lexer does not actually parse the C code, so I'm sure that some corner
827 cases or maybe even some not so corner cases of C syntax might confuse gob
828 completely. If you find any, send me the source that makes it go gaga and I'll
829 try to make the lexer try to handle it properly, but no promises.
831 Another thing is that gob ignores preprocessor macros. Since gob counts
832 braces, the following code won't work:
844 To make this work, you'd have to do this:
857 There is no real good way we can handle this without parsing C code, so we
858 probably never will. In the future, I might add #if 0 as a comment but
859 that's about as far as I can really take it and even that is problematic.
860 Basically, if you use gob, just don't use the C preprocessor too extensively.
862 Comments will not get through to the generated files unless inside C code.
863 This makes using something like gtk-doc harder. However I'm planning to
868 George Lebl <jirka@5z.com>