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
13 .B gob [-?] [-h] [-w] [--exit-on-warn] [--no-exit-on-warn] [--for-cpp]
14 [--no-touch-headers] file
17 GTK+ Object Builder is a simple preprocessor for easily creating
18 GTK+ objects. It does not parse any C code and ignores any C errors. It
19 is in spirit similar to things like lex or yacc.
27 Display a simple help screen.
32 Exit with an errorcode even when you encounter a warning.
35 Exit with an error only on errors, not on warnings, this is the default.
41 Don't touch the generated header file unless it really changed, this avoids
42 spurious rebuilds, but can confuse some make systems (automake in particular),
43 so it is not enabled by default.
45 .B --always-private-header
46 Always create a \fB<basename>-private.h\fR file, even if it would be empty.
47 Otherwise, it is only created when there are private data members in the class.
48 This option implicitly negates --no-private-header
50 .B --no-private-header
51 Never create a private header file. If we use any private datamembers,
52 define the private data structure at the point in the .c source where
53 the class definition begins. This option implicitly negates
54 --always-private-header
58 Because we need to parse out different parts of the typename, sometimes you
59 need to specify the typename with some special syntax. Types are specified in
60 capitalized form and words are separated by ':'. The first word of the type
61 (which can be empty) is the "namespace". This fact is for example used for the
62 type checking macro and the type macro. For "Gtk:New:Button", the macros will
63 be GTK_IS_NEW_BUTTON and GTK_TYPE_NEW_BUTTON. This colon separated format of
64 typenames is used in the class declaration header and for method argument
69 The filenames are created from the typename. The words are
70 separated by '-' and all in lower case. For example for an object named
71 "Gtk:New:Button", the files are \fBgtk-new-button.c\fR and
72 \fBgtk-new-button.h\fR.
73 If you are using C++ mode, the output .c file will in fact be a .cc file.
74 If you have any private data members, a private header file will also
75 be created, called \fB<basename>-private.h\fR (for the example above it
76 would be gtk-new-button-private.h).
77 The public header file is created to be human readable and to be used as a
78 reference to the object. The .c source file is not created as a human
79 readable source and is littered with #line statements, which make the
80 compiler attempt to point you to the right line in your .gob file in
81 case of parsing errors. The output should not be editted by hand, and
82 you should only edit the .gob file.
84 .SH INCLUDING NORMAL C CODE IN THE OUTPUT FILES
86 To include some code directly in the output C file begin with '%{'
87 on an empty line and end the code with a '%}' on an empty line. To
88 put the code in the output header file, start the code with a '%h{'.
93 /* will be included in the header */
98 /* will be included in the C file */
109 Gob will automatically include the class header file at the top of the .c
110 source file. If you wish to include it somewhere else, put the include
111 into some %{ %} section above the class definition, and gob will not include
112 it automatically. This way you can avoid circular includes and control
113 where in the file do you want to include the header.
115 If you made any data members private, gob will also create a source file
116 that will be called \fB<basename>-private.h\fR. Same rule as above applies
117 for this just as it does for the regular header file. If you do explicitly
118 include the regular header file, you should always include this private
119 header file below it. That is, if you use any private data members. If you
120 don't, the private header file automatically includes the public header file,
121 and thus the public header file will be indirectly included at the very top
124 .SH MAKING A NEW CLASS
128 There can be only one class per input file. Defining a class
129 is sort of like in Java, you define the class and write inline code
130 directly into the class definition. To define a class you need to specify
131 the new object name and the name of the object from which it is derived
132 from, such as this "class <new type> from <parent type> { <class code> }".
136 class Gtk:New:Button from Gtk:Button {
144 There are three types of data members. Two of them are normal
145 data numbers, and one is a virtual one, usually linked to a normal public
146 data member. The two normal data members are public or private. They are
147 basically just copied into the object directly. There is only one
148 identifier allowed per typename unlike in normal C. Example:
152 private GtkWidget *h;
156 Public datamembers are accessed normally as members of the object struct.
157 Example where 'i' is as above a public data member:
164 The private data members are defined in a structure which is only available
165 inside the .c file. You must access them using the structure _priv. Example
166 where 'h' is the private data member (as in the above example):
169 object->_priv->h = NULL;
172 Note that the _priv structure is defined in the \fB<basename>-private.h\fR.
173 This file is automatically included if you don't include it yourself. You
174 should always explicitly include it if you explicitly also include the main
175 header file. In case you use the \fB--no-private-header\fR option, no
176 private header file is created and you can only access the _priv pointer
177 below the class definition in the .gob file.
179 The third type is an argument type. It is a named datamember which
180 is one of the features of the GTK+ object system. You need to define a get
181 and a set handler. They are fragments of C code that will be used to
182 get the value or set the value of the argument. Inside them you can use the
183 define ARG to which you assign the data or get the data. You can also use
184 the identifier "self" as pointer to the object instance. The type is
185 defined as one of the gtk type enums, but without the GTK_TYPE_ prefix.
190 argument INT height set { self->height = ARG; } get { ARG = self->height; };
194 If you don't define a set or a get handler it will be a readonly
195 or a writeonly argument. If you want to add extra argument flags, add
196 them into parenthesis after the argument keyword, separated by '|' and
197 without the GTK_ARG_ prefix. For example:
201 argument (CONSTRUCT) INT height get { ARG = self->height; };
207 There is a whole array of possible methods. The two normal,
208 "familiar" method types are private and public. Public are defined as
209 normal functions with a prototype in the header file. Private methods
210 are defined as static functions with prototypes at the top of the .c
211 file. Then there are signal, virtual and override methods. You can also
212 define init and init_class methods with a special definition if you want
213 to add code to the constructors or you can just leave them out.
217 For all but the init and init_class methods, you use the
218 following syntax for arguments. The first argument can be just "self",
219 which gob will translate into a pointer to the object instance. The rest
220 of the arguments are very similar to normal C arguments. If the
221 typename is an object pointer you should use the syntax defined above
222 with the words separated by ':'
226 <type> <argument id> (check <list of checks>)
229 The checks are glib type preconditions, and can be the following:
230 "null", which tests pointers for being NULL, "type" which checks GTK+
231 object pointers for being the right type, "<test> <number>" which tests
232 numeric arguments for being a certain value. The test can be a <,>,<=,>=
236 public int foo(self, int h (check > 0 < 11), Gtk:Widget *w (check null type))
240 This will be the prototype of a function which has a self pointer
241 as the first argument, an integer argument which will be checked and has
242 to be more then 0 and less then 11, and a pointer to a GtkWidget object
243 instance and it is checked for being null and the type will also be
248 Methods which have a return value, there also has to be something
249 returned if there is an error, such as if a precondition is not met. The
250 default is 0, casted to the type of the method. If you need to return
251 something else then you can specify an "onerror" keyword after the
252 prototype and after that a number, a token (an identifier) or a bit of C
253 code enclosed in braces {}. The braces will not be printed into the
254 output, they just delimit the string. For example
257 public void * get_something(self, int i (check >= 0)) onerror NULL {
265 Virtual methods are basically pointers in the class structure,
266 so that one can override the method in derived methods. They can be empty
267 (if you put ';' instead of the C code). A wrapper will also be defined
268 which makes calling the methods he same as public methods. This type of
269 method is just a little bit "slower" then normal functions, but not as
270 slow as signals. You define them by using "virtual" keyword before the
271 prototype. If you put the keyword "private" right after the "virtual"
272 keyword, the wrapper will not be a public method, but a private one.
276 Signals are methods to which the user can bind other handlers
277 and override the default handler. The default handler is basically the
278 method body. This is the most versatile and flexible type of a method
279 and also the slowest. You need to specify a whole bunch of things when
280 you define a signal. One thing is when the default handler will be run,
281 first or last. You specify that by "first" or "last" right after the
282 "signal" keyword. Then you need to define the gtk enum types (again
283 without the GTK_TYPE_ prefix). For that you define the return types
284 and the types of arguments after the "self" pointer (not including the
285 "self" pointer). You put it in the following syntax "<return type> (<list
286 of arguments>)". If the return type is void, the type should be "NONE",
287 the same should be for the argument list. The rest of the prototype is
288 the same as for other method types. The body can also be empty, and
289 also there is a public method wrapper which you can use for calling the
290 signal just like a public method. Example:
293 signal first INT(POINTER,INT)
294 int do_something(self, Gtk:Widget *w (check null type), int length)
301 signal last NONE(NONE) void foo(self);
305 If you don't want the wrapper that emits the signal to be public, you can
306 include the keyword "private" after the "signal" keyword. This will make
307 the wrapper a normal private method.
309 If you don't define a "first" or a "last", the default will be taken as
314 If you need to override some method (a signal or a virtual method
315 of some class in the parent tree of the new object), you can define and
316 override method. After the "override" keyword, you should put the
317 typename of the class you are overriding a method from. Other then that
318 it is the same as for other methods. The "self" pointer in this case
319 should be the type of the method you are overriding so that you don't
320 get warnings during compilation. Also to call the method of the parent
321 class, you can use the PARENT_HANDLER macro with your arguments. Example:
324 override (Gtk:Container) void
325 add (Gtk:Container *self (check null type), Gtk:Widget *wid (check null type))
328 PARENT_HANDLER(self, wid);
335 Inside the code, pointers are set for the methods, so that you don't
336 have to type the class name before each call, just the name of the method.
349 return foo(self) + i;
356 You should define a new method which should be a normal public method. Inside
357 this method, you can use the GET_NEW macro that is defined for you and that
358 will fetch a new object, so a fairly standard new method would look like:
364 ret = GTK_OBJECT (GET_NEW);
372 There is a C++ mode so that gob creates C++ compiler friendly files. You need
373 to use the --for-cpp argument to gob. This will make the generated file have
374 a .cc instead of a .c extention, and several things will be adjusted to
375 make it all work for a C++ compiler. One thing that will be missing is an
376 alias to the new method, as that clashes with C++, so instead you'll have to
377 use the full name of the method inside your code. Also note that gob does
378 not use any C++ features, this option will just make the generated code
379 compile with a C++ compiler.
383 Also the lexer does not actually parse the C code, so I'm sure that some corner
384 cases or maybe even some not so corner cases of C syntax might confuse gob
385 completely. If you find any, send me the source that makes it go gaga and I'll
386 try to make the lexer try to handle it properly, but no promises.
388 Another thing is that gob ignores preprocessor macros. Since gob counts
389 braces, the following code won't work:
401 To make this work, you'd have to do this:
414 There is no real good way we can handle this without parsing C code, so we
415 probably never will. In the future, I might add #if 0 as a comment but
416 that's about as far as I can really take it and even that is problematic.
417 Basically, if you use gob, just don't use the C preprocessor too extensively.
421 George Lebl <jirka@5z.com>