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.
26 Display a simple help screen.
29 Display version information (note, --version was not added until 0.92.0)
32 Exit with an error code even when you encounter a warning.
35 Exit with an error only on errors, not on warnings, this is the default.
41 Never add the extern "C" to the header.
44 Never generate any code with GNU C extensions. However all the GNU C
45 extensions are always wrapped in #ifdef __GNUC__, so code using them compiles
46 correctly even on non-GNU compilers. This option is for purists only.
47 (using GNU extensions some warnings are eliminated, some ugly hacks and there
48 is better argument type safety, so it's good to use them)
51 Don't touch the generated header file unless it really changed, this avoids
52 spurious rebuilds, but can confuse some make systems (automake in particular),
53 so it is not enabled by default. Private header is still touched even if
56 .B --always-private-header
57 Always create a \fB<basename>-private.h\fR file, even if it would be empty.
58 Otherwise, it is only created when there are private data members in the class.
59 This option implicitly negates --no-private-header
61 .B --no-private-header
62 Never create a private header file. If we use any private data members,
63 define the private data structure at the point in the .c source where
64 the class definition begins. This option implicitly negates
65 --always-private-header
68 Do not write any output files, just check syntax of the input file.
71 Do not print out the '#line' statements into the output. Useful for debugging
72 the auto-generated generated code.
75 Do not create the Self and SelfClass type aliases and the SELF, IS_SELF
76 and SELF_CLASS macros.
78 .B --no-kill-underscores
79 Do not remove the initial underscore from method names.
81 .B --always-private-struct
82 Always include the private pointer in the public header file. This is useful for
83 files which are part of a library and you want to reserve the right to add some
84 private data members without breaking binary compatibility.
88 Because we need to parse out different parts of the typename, sometimes you
89 need to specify the typename with some special syntax. Types are specified in
90 capitalized form and words are separated by ':'. The first word of the type
91 (which can be empty) is the "namespace". This fact is for example used for the
92 type checking macro and the type macro. For "Gtk:New:Button", the macros will
93 be GTK_IS_NEW_BUTTON and GTK_TYPE_NEW_BUTTON. This colon separated format of
94 typenames is used in the class declaration header and for method argument
99 The filenames are created from the typename. The words are
100 separated by '-' and all in lower case. For example for an object named
101 "Gtk:New:Button", the files are \fBgtk-new-button.c\fR and
102 \fBgtk-new-button.h\fR.
103 If you are using C++ mode, the output .c file will in fact be a .cc file.
104 If you have any private data members, a private header file will also
105 be created, called \fB<basename>-private.h\fR (for the example above it
106 would be gtk-new-button-private.h).
107 The public header file is created to be human readable and to be used as a
108 reference to the object. The .c source file is not created as a human
109 readable source and is littered with #line statements, which make the
110 compiler attempt to point you to the right line in your .gob file in
111 case of parsing errors. The output should not be edited by hand, and
112 you should only edit the .gob file.
114 .SH INCLUDING NORMAL C CODE IN THE OUTPUT FILES
116 To include some code directly in the output C file begin with '%{'
117 on an empty line and end the code with a '%}' on an empty line. These
118 sections will appear in the output files in the order they are given.
119 There are several other \fIsections\fR to which you can put code. You can
120 put it in the 'header' section (which can be abbreviated 'h') and it will
121 go into the public header file. You can also put it in the 'privateheader'
122 section (abbreviated 'ph') which will make the code go into the private
123 header file. Sometimes you want some code (other includes) to appear before
124 the extern "C" and the protecting define. To do this you can put them
125 into the 'headertop' (or 'ht') section. You may wish to include code or
126 comments in all the files, which you can do by putting them into the 'all'
127 (or 'a') section. Similarly, code you wish to appear at the top of all
128 files go in the 'alltop' (or 'at') section. For example:
132 /* this will be on top of all output files */
136 /* this will be on top of the public header */
140 /* this will go into the private header file */
144 /* will be included in the header */
145 void somefunc(int i);
149 /* will be included in all files */
153 /* will be included in the C file */
164 Gob will automatically include the class header file at the top of the .c
165 source file. If you wish to include it somewhere else, put the include
166 into some %{ %} section above the class definition, and gob will not include
167 it automatically. This way you can avoid circular includes and control
168 where in the file do you want to include the header.
170 If you made any data members private, gob will also create a source file
171 that will be called \fB<basename>-private.h\fR. Same rule as above applies
172 for this just as it does for the regular header file. If you do explicitly
173 include the regular header file, you should always include this private
174 header file below it. That is, if you use any private data members. If you
175 don't, the private header file automatically includes the public header file,
176 and thus the public header file will be indirectly included at the very top
179 .SH MAKING A NEW CLASS
183 There can be only one class per input file. Defining a class
184 is sort of like in Java, you define the class and write inline code
185 directly into the class definition. To define a class you need to specify
186 the new object name and the name of the object from which it is derived
187 from, such as this "class <new type> from <parent type> { <class code> }".
191 class Gtk:New:Button from Gtk:Button {
199 There are five types of data members. Three of them are normal data numbers,
200 one is class wide (global) in scope and one is a virtual one, usually linked to
201 a normal data member or a class wide data member. The three normal data
202 members are public, protected and private. Public and protected are basically
203 just entries in the object structure, while private has it's own dynamically
204 allocated private structure. Protected members are always put after the public
205 one in the structure and are marked protected in the header file. There is
206 only one identifier allowed per typename unlike in normal C. Example:
210 private GtkWidget *h;
215 Public and protected data members are accessed normally as members of
216 the object struct. Example where 'i' is as above a public data member:
223 The private data members are defined in a structure which is only available
224 inside the .c file, or by including a private header file. You must access
225 them using the structure _priv. Example
226 where 'h' is the private data member (as in the above example):
229 object->_priv->h = NULL;
232 The _priv structure is defined in the \fB<basename>-private.h\fR.
233 This file is automatically included if you don't include it yourself. You
234 should always explicitly include it in your .gob file if you explicitly also
235 include the main header file. The reason it is a separate header file is
236 that you can also include it in other places that need to access this objects
237 private data, such as if you have the majority of functionality of an object
238 in a separate .c file. Or if a derived object needs to access the protected
241 In case you use the \fB--no-private-header\fR option, no
242 private header file is created and you can only access the _priv pointer
243 below the class definition in the .gob file.
245 Also note that this structure is dynamically allocated, and is freed in the
246 finalize handler. If you override the finalized handler, your code will be
247 run first and only then will the _priv structure be freed.
249 Classwide data members:
251 Sometimes you want a datamember to be shared by all objects. You then need
252 the "classwide" scope keyword. So for example the following adds a global
259 To access the member you do the standard voodoo of getting the class from the
260 object and casting it to your class pointer. Thus the following would work:
263 SELF_CLASS(GTK_OBJECT(object)->klass)->foo = 20;
267 Automatic Initialization (0.93.0 and higher only):
269 You can automatically initialize the public private and protected data members
270 without having to add an init method. The advantage here is that
271 initialization is kept close to the definition of the data member and thus
272 it's easier to check. To do this, just add a '=' followed by a number or
273 a token. It is also possible to include arbitrary C code for more elaborate
274 initializations by putting it all in curly braces. Note that the curly braces
275 will not be printed into the output, but since gob does not C parsing it needs
276 them to figure out where the C code ends. The code will be inserted into the
277 init method, above the user defined body. So for example the following
278 will initialize an integer to -1 and a string with a newly allocated string
283 private char *bar = {g_strdup("hello")};
287 Automatic Destruction (0.93.0 and higher only):
289 Most data stored as pointers needs to have a function called when the object
290 is destroyed, to either free it or give up a reference. Gob will let you
291 define a function to be called on the data the object is destroyed. This is
292 achieved by putting 'destroywith' followed by a function name after the
293 variable definition. It is only called if the data you defined this on
294 is not NULL, so you cans specify functions which do not handle NULL. It
295 is very much like the GDestroyNotify function used in GTK+ and glib in many
296 places. Unlike many other places, gob will not enforce any kind of type
297 safety here so be a little bit more careful. Any function you give it will
298 be called as a "void function(void *)". It will in fact be cast into such
299 a form before called. This is to avoid spurious warnings for gtk calls to
300 subclass methods. The function needs not be of that form exactly, it just has
301 to take one argument which is the pointer to the data. You should also not
302 define this on any non-pointer data as the results may be undefined.
306 public Gtk:Widget *window = NULL
307 destroywith gtk_widget_destroy;
308 public char *foo = {g_strdup("bar")}
312 Note that the function name you give must be a real function and not macro.
313 Also note that this is always called in the "destroy" method of GtkObject.
314 It is always called after any user defined body of the destroy handler.
316 Sometimes you may want to run arbitrary code on destruction. While this can
317 be perfectly well done in the destroy handler. Depending on the style you
318 may want to include all destruction/initialization code together with the
319 definition of the data member. Thus you may want to put arbitrary code which
320 will then be inserted into the "destroy" method of GtkObject. This can be
321 done with the "destroy" keyword followed by arbitrary code in curly braces.
322 Inside this code a macro called VAR will be define which refers to your
323 variable. So for example destroying a GString can be either done with
324 a helper routine or the following code:
327 public GString *string = {g_string_new(NULL)}
329 if(VAR) g_string_free(VAR, TRUE);
333 The thing to remember with these is that there are many ways to do this
334 and you'd better be consistent in your code in how you use the above things.
335 Also defining a helper routine that will do the destruction will be a nicer
336 thing to do if that's a possibility. The "destroy" keyword with code does
337 take up more space in the file and it may become more cluttered.
339 The data is zeroed out after being destroyed. This is to make debugging easier
340 in case your code might try to access an already destroyed object. In case
341 you have overridden the destroy method, your code will be run first and
342 only then will the destructors be called. You should not however make any
343 assumptions about the order at which the destructors are called. If you have
344 interdependencies between destructors for different data members, you will
345 have to do this in your own destroy override function.
349 The fourth type of a data member an argument type. It is a named data member
350 which is one of the features of the GTK+ object system. You need to define a
351 get and a set handler. They are fragments of C code that will be used to get
352 the value or set the value of the argument. Inside them you can use the define
353 ARG to which you assign the data or get the data. You can also use the
354 identifier "self" as pointer to the object instance. The type is defined as
355 one of the gtk type enums, but without the GTK_TYPE_ prefix. For example:
359 argument INT height set { self->height = ARG; } get { ARG = self->height; };
363 If you don't define a set or a get handler it will be a read-only
364 or a write-only argument. If you want to add extra argument flags, add
365 them into parenthesis after the argument keyword, separated by '|' and
366 without the GTK_ARG_ prefix. For example:
370 argument (CONSTRUCT) INT height get { ARG = self->height; };
373 This makes the argument settable even before the object is constructed, so
374 that people can pass it to gtk_object_new function. Useful is also
375 CONSTRUCT_ONLY flag which makes the argument only available during
376 construction of the object.
378 Since 0.92.1, gob creates macros which can be used for type safe access to
379 gtk arguments. The macros are called <type>_ARG_<argument name>(x) and
380 <type>_GET_ARG_<argument name>(x). They define both the string and the
381 value part of the argument. So for setting an argument of height, one would
382 use (for object type My:Object):
385 gtk_object_set (GTK_OBJECT (object),
386 MY_OBJECT_ARG_HEIGHT (7),
390 And for getting, you would use:
394 gtk_object_get (GTK_OBJECT (object),
395 MY_OBJECT_GET_ARG_HEIGHT (&height),
399 Note however that the type safety only works completely on GNU C compilers.
400 The code will compile on other compilers but with minimal type safety.
402 To get good type safety on POINTER types however, you should specify
403 an optional C type that gob should use. For other then POINTER types
404 this is redundant but possible. To do this, place '(type <c type>)'
405 right after the GTK+ type. Example:
408 argument POINTER (type char *) foo set { /* foo */ } get { /* bar */ };
412 Sometimes it can become tiresome to type in the set and get handlers if
413 they are trivial. So gob since version 0.93.0 provides automatic argument
414 linking to data members. There are three different cases it handles, direct
415 link (keyword 'link'), string linking (keyword 'stringlink') and object
416 linking (keyword 'objectlink'). You just place the keyword after the argument
417 name instead of the get/set handlers. It will link to a data member of the
418 same name that was defined earlier in the input file. Best is to see examples:
422 argument INT foo link;
429 argument INT (type int) foo
430 get { ARG = self->foo; }
431 set { self->foo = ARG; };
438 argument POINTER foo stringlink;
445 argument POINTER (type char *) foo
447 ARG = g_strdup(self->_priv->foo);
449 g_free(self->_priv->foo);
450 self->_priv->foo = g_strdup(ARG);
454 And for the objectlink we would have:
457 public Gtk:Object * foo;
458 argument POINTER foo objectlink;
464 protected Gtk:Object * foo;
465 argument POINTER (type Gtk:Object *) foo
471 if(self->foo != NULL)
472 gtk_object_unref(self->foo);
478 As you see it will handle NULLs correctly (for the string, g_free and g_strdup
479 handle NULLs). And it will also handle private, protected and public members.
480 For objectlink, just a pointer is returned on get, if you wish to keep it around,
481 you should call gtk_object_ref on it. For stringlink, get makes a copy of
482 the string which you should free after use. This is the behaviour since 1.0.2.
484 You can also automatically export get and set methods for each of the arguments
485 by appending '(export)' flag before the get and set statements. For example:
489 argument INT (type int) foo (export)
490 get { ARG = self->foo; }
491 set { self->foo = ARG; };
494 Will export public methods get_foo(self) and set_foo(self, int foo) for you
495 automatically. Note that this behaviour is new in 1.0.10.
499 There is a whole array of possible methods. The three normal,
500 "familiar" method types are private, protected and public. Public are
501 defined as normal functions with a prototype in the header file.
502 Protected methods are defined as normal methods (which you can call from other
503 files), but their prototype is placed in the private header file. Private
505 are defined as static functions with prototypes at the top of the .c
506 file. Then there are signal, virtual and override methods. More on those
508 define init and class_init methods with a special definition if you want
509 to add code to the constructors or you can just leave them out.
510 You can also not define a body for a method, by just using ';' instead of a
511 body. This will define an empty function. You can't do this for non-void
512 regular public, private or protected methods, however it is acceptable for
513 non-void virtual, signal and override methods.
515 Function argument lists:
517 For all but the init and class_init methods, you use the
518 following syntax for arguments. The first argument can be just "self",
519 which gob will translate into a pointer to the object instance. The rest
520 of the arguments are very similar to normal C arguments. If the
521 typename is an object pointer you should use the syntax defined above
522 with the words separated by ':'
526 <type> <argument id> (check <list of checks>)
529 The checks are glib type preconditions, and can be the following:
530 "null", which tests pointers for being NULL, "type" which checks GTK+
531 object pointers for being the right type, "<test> <number>" which tests
532 numeric arguments for being a certain value. The test can be a <,>,<=,>=
536 public int foo(self, int h (check > 0 < 11), Gtk:Widget *w (check null type))
540 This will be the prototype of a function which has a self pointer
541 as the first argument, an integer argument which will be checked and has
542 to be more then 0 and less then 11, and a pointer to a GtkWidget object
543 instance and it is checked for being null and the type will also be
548 Methods which have a return value, there also has to be something
549 returned if there is an error, such as if a precondition is not met. The
550 default is 0, casted to the type of the method. If you need to return
551 something else then you can specify an "onerror" keyword after the
552 prototype and after that a number, a token (an identifier) or a bit of C
553 code enclosed in braces {}. The braces will not be printed into the
554 output, they just delimit the string. For example:
557 public void * get_something(self, int i (check >= 0)) onerror NULL {
562 The onerror value is also used in overrides that have a return value, in
563 case there isn't a parent method, PARENT_HANDLER will return it. More about
568 Some signal and virtual methods have a return type. But what happens if
569 there is no default handler and no one connects to a signal. GOB will
570 normally have the wrappers return whatever you specify with onerror or '0'
571 if you haven't specified anything. But since 0.93.2 you can specify a default
572 return value with the keyword 'defreturn'. It's use is identical to the
573 use of onerror, and you can in fact use both at the same time. Example
576 virtual int get_some_int(self) onerror -1 defreturn 10 ;
579 That is an empty virtual method (in C++ terms a pure virtual). If you never
580 specify any handler for it in the derived children it will just return 10.
584 There are two methods that handle the construction of an object, init and
585 class_init. You define them by just using the init or class_init keyword
586 with an untyped argument in the argument list. The argument will be
587 usable in your function as a pointer to your object or class depending if
588 it's init or class_init.
593 /* initialize the object here */
599 /* initialize the class, this is rarely needed */
604 The class_init function is very rarely needed as all standard class
605 initialization is taken care of for you by gob itself. The init function
606 should on the other hand be used whenever you need to construct or initialize
607 anything in the object to put it into a sane state. Sometimes you need
608 some arguments, for this you should either use a construct method and a
609 new function like many GTK+ widgets, and/or a CONSTRUCT or CONSTRUCT_ONLY
614 Virtual methods are basically pointers in the class structure,
615 so that one can override the method in derived methods. They can be empty
616 (if you put ';' instead of the C code). A wrapper will also be defined
617 which makes calling the methods he same as public methods. This type of
618 method is just a little bit "slower" then normal functions, but not as
619 slow as signals. You define them by using "virtual" keyword before the
620 prototype. If you put the keyword "private" right after the "virtual"
621 keyword, the wrapper will not be a public method, but a private one.
622 You can do the same with "protected" to make a protected wrapper.
626 Signals are methods to which the user can bind other handlers
627 and override the default handler. The default handler is basically the
628 method body. This is the most versatile and flexible type of a method
629 and also the slowest. You need to specify a whole bunch of things when
630 you define a signal. One thing is when the default handler will be run,
631 first or last. You specify that by "first" or "last" right after the
632 "signal" keyword. Then you need to define the gtk enum types (again
633 without the GTK_TYPE_ prefix). For that you define the return types
634 and the types of arguments after the "self" pointer (not including the
635 "self" pointer). You put it in the following syntax "<return type> (<list
636 of arguments>)". If the return type is void, the type should be "NONE",
637 the same should be for the argument list. The rest of the prototype is
638 the same as for other method types. The body can also be empty, and
639 also there is a public method wrapper which you can use for calling the
640 signal just like a public method. Example:
643 signal first INT(POINTER,INT)
644 int do_something(self, Gtk:Widget *w (check null type), int length)
653 signal last NONE(NONE) void foo(self);
657 If you don't want the wrapper that emits the signal to be public, you can
658 include the keyword "private" after the "signal" keyword. This will make
659 the wrapper a normal private method. You can also make a protected wrapper
660 by using "protected" instead of "private".
662 If you don't define a "first" or a "last", the default will be taken as
665 You can also add additional flags. You do this just like with the argument
666 flags, although this is probably very rare. These are the GTK_RUN_* flags,
667 and you can add them without the GTK_RUN_ prefix into a parenthesis, just
668 after the "signal" keyword. By default all public signals are GTK_RUN_ACTION.
670 Since 1.0.6, gob creates wrapper signal macros for signal connection
671 typesafety, at least on gnu compilers. These macros are named
672 <type>_SIGNAL_<signal name>(func), where func is the function pointer. This
673 pointer must be of the correct type, or you will get an initialization from
674 wrong pointer type warning. This macro, much like the argument macros, wraps
675 both the name and the function pointer parameters. For example to connect a
676 signal "changed" to a function "foo", you would do:
679 gtk_signal_connect (GTK_OBJECT (object),
680 MY_OBJECT_SIGNAL_CHANGED (foo),
687 If you need to override some method (a signal or a virtual method
688 of some class in the parent tree of the new object), you can define and
689 override method. After the "override" keyword, you should put the
690 typename of the class you are overriding a method from. Other then that
691 it is the same as for other methods. The "self" pointer in this case
692 should be the type of the method you are overriding so that you don't
693 get warnings during compilation. Also to call the method of the parent
694 class, you can use the PARENT_HANDLER macro with your arguments. Example:
697 override (Gtk:Container) void
698 add (Gtk:Container *self (check null type), Gtk:Widget *wid (check null type))
701 PARENT_HANDLER(self, wid);
705 If the function has a return value, then PARENT_HANDLER is an expression that
706 you can use. It will return whatever the parent handler returned, or the
707 "onerror" expression if there was no parent handler.
711 Inside the code, aliases are set for the methods, so that you don't
712 have to type the class name before each call, just the name of the method.
725 return foo(self) + i;
730 Underscore removal (0.93.5+):
732 Sometimes this causes conflicts with other libraries. For example a library
733 might have already used the identifier foo. You can prepend an underscore to
734 the name in the .gob file. This will make the local short alias have an
735 initial underscore, but it will not change the name of the actual name of the
736 function. For example:
738 class My:Object from Gtk:Object {
745 /* short calling convention */
747 /* long calling convention */
752 Thus you see that the "_foo" method still generates the method "my_object_foo"
753 just as "foo" would generate. You can turn off this behavior if you depend
754 on the old (pre 0.93.5) behavior with the --no-kill-underscores option. This
755 also means that if both "_foo" and "foo" are defined, it is treated as a
758 This does not apply to override methods. Override methods are special beasts
759 and this is not necessary and would make the code behave in weird ways.
763 You should define a new method which should be a normal public method. Inside
764 this method, you can use the GET_NEW macro that is defined for you and that
765 will fetch a new object, so a fairly standard new method would look like:
770 GtkObject *ret = GET_NEW;
771 return GTK_OBJECT (ret);
776 You should not a subtle peculiarity of the GTK+ object system here. If there is any
777 code inside the GTK_OBJECT macro argument, it will get executed multiple times. This
778 means that things such as GTK_OBJECT(GET_NEW) would actually create 4 objects, leaking
779 3 of them. A good rule is to be careful with all macros.
783 There are some standard casts defined for you. Instead of using the full
784 macros inside the .c file, you can use SELF, IS_SELF and SELF_CLASS. Using
785 these makes it easier to for example change class names around.
789 Since 0.93.5, there have also been defined the Self and SelfClass types inside
790 your .c file. These serve the same function as the above, they make it easier
791 to type and easier to change typenames around which can help a lot during
792 prototyping stage. However you should note that the Self type should not be
793 used in function prototypes as one of the arguments or as a return value type.
794 This is because this is a simple C typedef which is only available inside you
795 .c file. You can disable both the self casting macros and the self type
796 aliases by passing --no-self-alias to
798 .SH DEALING WITH DIFFERENT GOB VERSIONS
802 In your generated C file, you can use the defines GOB_VERSION_MAJOR
803 GOB_VERSION_MINOR and GOB_VERSION_PATCHLEVEL if you wish to for example
804 use a feature that is only available in some newer gob version. Note however
805 that you can only use these defines in the C code portions of your .gob file,
806 and #ifdef's cannot span multiple functions. Check the BUGS section
807 for more on using the C preprocessor and gob. Also note that these
808 have only been available since the 0.92.1 version of gob.
810 Minimum version requires:
812 You can also make your .gob file require at least certain version of gob. You
813 do this by putting 'requires x.y.z' (where x.y.z is the version number) outside
814 of any C block, comment or class, usually you should make this the first line
815 in the file or close to the top. If gob finds this and the version of gob used
816 to compile the code is lower then that listed in the require, gob will generate
817 an error and exit. For example to require that gob version 0.92.1 or higher
818 be used to compile a file, put this at the top of that file:
824 It should be noted however that this feature was not added until 0.92.1, and
825 so if the file gets compiled by a lower version, gob would generate a
826 syntax error. Thus by putting in a requires line, you are implicitly
827 requiring at least 0.92.1.
831 There is a C++ mode so that gob creates C++ compiler friendly files. You need
832 to use the --for-cpp argument to gob. This will make the generated file have
833 a .cc instead of a .c extension, and several things will be adjusted to
834 make it all work for a C++ compiler. One thing that will be missing is an
835 alias to the new method, as that clashes with C++, so instead you'll have to
836 use the full name of the method inside your code. Also note that gob does
837 not use any C++ features, this option will just make the generated code
838 compile with a C++ compiler.
840 .SH OVERRIDING THE GET_TYPE METHOD
842 The get_type is not really a method, but a function which initializes your
843 object. Recently objects appeared which require you to make a custom
844 get_type function (BonoboXObject currently, see next section for direct
845 BonoboXObject support). So in 1.0.7 it is now possible
846 to override this function. To do so, just define a new public method called
847 get_type, with no arguments. Example:
859 .SH DIRECT BonoboXObject SUPPORT
861 If you want to build a BonoboXObject class gob has direct support for these
862 classes since 1.0.9. Just create a new object that derives from
863 Bonobo:X:Object. Then use a "BonoboX" class flag with the interface name as an
864 argument. The interface name should be as you would type it in C, that is with
865 underscores as namespace separators. Then you add the methods (using exact
866 same names as in the idl file) and prepend those methods with a BonoboX
867 keyword. For example imagine you have an interface GNOME/Foo/SomeInterface,
868 with a method fooBar that takes a single string:
871 class Foo:Some:Interface from Bonobo:X:Object
872 (BonoboX GNOME_Foo_SomeInterface) {
876 fooBar (PortableServer_Servant servant,
877 const CORBA_char *string,
878 CORBA_Environment *ev)
880 Self *self = SELF (bonobo_object_from_servant (servant));
889 Note that the implementation method can be private, in fact that's probably
890 a good idea to do. It won't work to make this a signal, it can however
891 be a virtual. Note that the method prototype must match the one from the
892 interface header file, or you will get a bad assignment warning. You should
893 check the header file generated by orbit-idl and see the epv structure
894 for the correct prototypes if you can't figure them out from the idl itself.
895 Also note that the first argument is not "self", but the servant and you must
896 use bonobo_object_from_servant function to get the actual object pointer.
898 .SH IDENTIFIER CONFLICTS
900 Gob will need to define some local variables and functions in the generated
901 files, so you need to take some precaution not to conflict with these. The
902 general rule of thumb is that all of these start with three underscores. There
903 is one, "parent_class" which doesn't because it's intended for use in your
904 code. For virtuals or signals, you cannot use the identifier __parent__
905 which is used for the parent of the object. You should actually never access
906 __parent__ either as it not guaranteed that it will stay named this way.
907 Data members cannot be named __parent__ nor _priv. For methods, you cannot
908 use the identifiers "init" or "class_init" unless you mean the constructor
909 methods. You shouldn't generally use 3 underscores even in override method
910 argument lists and virtual and signal method names as it might confuse the
911 PARENT_HANDLER macro. In fact avoiding all names with three underscores is
912 the best policy when working with gob.
914 Also note that starting with version 0.93.5, method names that start with a
915 an underscore are equivalent to the names without the initial underscore. This
916 is done to avoid conflicts with the aliases. Thus you can define the method
917 as "_name", if "name" happens to be some standard library function. This is
918 the same as defining it as "name" except that the local alias will be "_name"
921 There are a couple of defines which you shouldn't be redefining in the code
922 or other headers. These are SELF, IS_SELF, SELF_CLASS, ARG, VAR,
923 PARENT_HANDLER, GET_NEW, GOB_VERSION_MAJOR, GOB_VERSION_MINOR and
924 GOB_VERSION_PATCHLEVEL.
926 As for types, there are Self and SelfClass types which are only defined in your
927 source files. Their generation (just like the generation of the SELF macros)
928 can be turned off, see command line options.
930 .SH USING GTK-DOC STYLE INLINE DOCUMENTATION
932 If you want to use gtk-doc style inline documentation for your objects, you
933 can do one of two things. First, you could include the inline documentation
934 comments in your %{ %} section which will then be put verbatim into the
935 output source file. This is the way you should use for functions you define
936 outside of the class.
938 For class methods, you should use a gtk+ style comment, however it can be
939 indented any number of tabs or spaces and you can use the short method name
940 without the type prefix. Gob will automatically try to extract these and
941 translate to full names and put them in the output source file. An example
945 class Gtk:Button:Example from Gtk:Button {
949 * Makes a new #GtkButtonExample widget
951 * Returns: a new widget
957 return GTK_WIDGET(GET_NEW);
962 If the function you are documenting is a signal or a virtual then it will
963 be documenting the wrapper that starts that virtual function or emits
966 .SH DEALING WITH CIRCULAR HEADERS
968 Sometimes you may need to use an object of type MyObjectA in the MyObjectB
969 class and vice versa. Obviously you can't include headers for both. So you
970 need to just declare the typedef in the header of A for B, and the other way
971 around as well. The headers generated since v0.92.2 include a protecting
972 define before it declares the typedef. This define is the
973 __TYPEDEF_<upper case object name>__. So inside my-object-a.h there will be
977 #ifndef __TYPEDEF_MY_OBJECT_A__
978 #define __TYPEDEF_MY_OBJECT_A__
979 typedef struct _MyObjectA MyObjectA;
983 Now instead of including my-object-a.h in the header section of
984 my-object-b.gob, just copy the above code there and you're set for using
985 MyObjectA as a type in the method parameters and public types.
987 Another way to get out of this problem is if you can use those types only
988 in the private members, in which case they won't be in the generated public
991 .SH BUILDING WITH MAKE
993 If you are using normal makefiles, what you need to do is to add a generic
994 rule for .gob files. So you would include the following in the Makefile
995 and then just use the .c and .h files as usual (make sure the space
996 before the 'gob' is a tab, not spaces):
999 %.c %.h %-private.h: %.gob
1004 .SH BUILDING WITH AUTOCONF and AUTOMAKE
1006 This is a little bit more involved. Basically the first thing to do is to
1007 check for GOB in your configure.in file. You can use the supplied m4 macro
1008 which will also check the version of gob. Basically you include this:
1014 This will replace @GOB@ in your makefiles with the full path of gob. Thus
1015 when adding the generic rule to your Makefile.am file, it should look like:
1018 %.c %.h %-private.h: %.gob
1023 For Makefile.am you have to set up a couple more things. First you have to
1024 include the generated .c and .h files into BUILT_SOURCES variable. You
1025 have to include both the .gob and the .c and .h files in the SOURCES for your
1030 GOB does several things to make debugging the code easier. First it adds
1031 preprocessor commands into the output c file that point to the correct places
1032 in your .gob input file. However sometimes there might be some bigger
1033 confusion and this is just not helpful. In this case you will probably want
1034 to have gcc point you directly at the generated files. For this use
1035 the --no-lines command line option. You should also note that these commands
1036 are not generated for the public header file at all. If there is an error which
1037 points you to the public header file, make sure you fix this error in the .gob
1038 file, otherwise your changes will not have any effect after gob recompiles the
1041 Sometimes you might want to know which method you are in for some debugging
1042 output. GOB will define __GOB_FUNCTION__ macro, which is just a string constant
1043 with a pretty name of the method.
1047 The lexer does not actually parse the C code, so I'm sure that some corner
1048 cases or maybe even some not so corner cases of C syntax might confuse gob
1049 completely. If you find any, send me the source that makes it go gaga and I'll
1050 try to make the lexer try to handle it properly, but no promises.
1052 Another thing is that gob ignores preprocessor macros. Since gob counts
1053 braces, the following code won't work:
1065 To make this work, you'd have to do this:
1078 There is no real good way we can handle this without parsing C code, so we
1079 probably never will. In the future, I might add #if 0 as a comment but
1080 that's about as far as I can really take it and even that is problematic.
1081 Basically, if you use gob, just don't use the C preprocessor too extensively.
1083 Comments will not get through to the generated files unless inside C code.
1084 This is not the case for gtk-doc style comments which are supported.
1086 The short name aliases are actually implemented as pointers to functions. Thus
1087 if you want to get the pointer of a function using the short name alias you
1088 can't use the '&'. Thus:
1091 void (*foo)(Self *);
1093 /* this will NOT work */
1096 /* this will work */
1099 /* Both of these will work */
1100 foo = &my_class_long_name;
1101 foo = my_class_long_name;
1107 George Lebl <jirka@5z.com>
projects / gob-dx.git / blob