]> git.draconx.ca Git - gob-dx.git/blob - doc/gob.1.in
Release 0.90.4
[gob-dx.git] / doc / gob.1.in
1 .\"
2 .\" gob manual page
3 .\" (C) 1999 George Lebl <jirka@5z.com>
4 .\" 
5 .\" This manual page is covered by the terms of the GNU General
6 .\" Public License.  
7 .\"
8 .TH GOB 1 "GOB @VERSION@" 
9 .SH NAME
10 GOB \- The GTK+ Object Builder
11 .SH SYNOPSIS
12 .PP
13 .B gob [-?] [-h] [-w] [--exit-on-warn] [--no-exit-on-warn] [--for-cpp]
14 [--no-touch-headers] file
15 .SH DESCRIPTION
16 .PP
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.
20
21 .SH OPTIONS
22 .PP
23 .TP
24 .B -?
25 .TP
26 .B -h
27 Display a simple help screen.
28 .TP
29 .B -w
30 .TP
31 .B --exit-on-warn
32 Exit with an errorcode even when you encounter a warning.
33 .TP
34 .B --no-exit-on-warn
35 Exit with an error only on errors, not on warnings, this is the default.
36 .TP
37 .B --for-cpp
38 Generate C++ code.
39 .TP
40 .B --no-touch-headers
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.
44
45
46 .SH TYPENAMES
47 .PP
48 Because we need to parse out different parts of the typename, 
49 sometimes you need to specify the typename with some special syntax.
50 Types are specified in capitalized form and words are separated by ':'.
51 The first word of the type (which can be empty) is the "namespace".  This
52 fact is for example used for the type checking macro.  For "Gtk:New:Button",
53 the macro will be GTK_IS_NEW_BUTTON.  This format of typenames is used in
54 the class declaration header and for method argument types.
55
56 .SH OUTPUT FILE NAMES
57 .PP
58 The filenames are created from the typename.  The words are
59 separated by '-' and all in lower case.  For example for an object named
60 "Gtk:New:Button", the files are gtk-new-button.c and gtk-new-button.h.
61
62 .SH INCLUDING NORMAL C CODE IN THE OUTPUT FILES
63 .PP
64 To include some code directly in the output C file begin with '%{'
65 on an empty line and end the code with a '%}' on an empty line.  To
66 put the code in the output header file, start the code with a '%h{'.
67 For example:
68 .nf
69
70   %h{
71   /* will be included in the header */
72   void somefunc(int i);
73   %}
74
75   %{
76   /* will be included in the C file */
77   void somefunc(int i)
78   {
79         /* some code */
80   }
81   %}
82
83 .fi
84
85 .SH MAKING A NEW CLASS
86 .PP
87 The class header:
88 .PP
89 There can be only one class per input file.  Defining a class
90 is sort of like in Java, you define the class and write inline code
91 directly into the class definition.  To define a class you need to specify
92 the new object name and the name of the object from which it is derived
93 from, such as this "class <new type> from <parent type> { <class code> }".
94 For example:
95 .nf
96
97   class Gtk:New:Button from Gtk:Button {
98           <class code>
99   }
100
101 .fi
102 .PP
103 Data members:
104 .PP
105 There are three types of data members.  Two of them are normal
106 data numbers, and one is a virtual one, usually linked to a normal public
107 data member.  The two normal data members are public or private. They are
108 basically just copied into the object directly.  There is only one
109 identifier allowed per typename unlike in normal C.  Example:
110 .nf
111
112   public int i;
113   private GtkWidget *h;
114
115 .fi
116 .PP
117 The private members are not currently protected from outside use,
118 they are just marked by a comment in the header file, this will most likely
119 be somehow solved in some future version.
120 .PP
121 The third type is an argument type.  It is a named datamember which
122 is one of the features of the GTK+ object system.  You need to define a get
123 and a set handler.  They are fragments of C code that will be used to 
124 get the value or set the value of the argument.  Inside them you can use the
125 define ARG to which you assign the data or get the data.  You can also use
126 the identifier "self" as pointer to the object instance.  The type is
127 defined as one of the gtk type enums, but without the GTK_TYPE_ prefix.
128 For example:
129 .nf
130
131   public int height;
132   argument INT height set { self->height = ARG; } get { ARG = self->height; };
133
134 .fi
135 .PP
136 If you don't define a set or a get handler it will be a readonly
137 or a writeonly argument.  If you want to add extra argument flags, add
138 them into parenthesis after the argument keyword, separated by '|' and
139 without the GTK_ARG_ prefix.  For example:
140 .nf
141
142   public int height;
143   argument (CONSTRUCT) INT height get { ARG = self->height; };
144
145 .fi
146 .PP
147 Methods:
148 .PP
149 There is a whole array of possible methods.  The two normal,
150 "familiar" method types are private and public.  Public are defined as
151 normal functions with a prototype in the header file.  Private methods
152 are defined as static functions with prototypes at the top of the .c
153 file.  Then there are signal, virtual and override methods.  You can also
154 define init and init_class methods with a special definition if you want
155 to add code to the constructors or you can just leave them out.
156 .PP
157 Argument lists:
158 .PP
159 For all but the init and init_class methods, you use the
160 following syntax for arguments.  The first argument can be just "self",
161 which gob will translate into a pointer to the object instance.  The rest
162 of the arguments are very similar to normal C arguments.  If the
163 typename is an object pointer you should use the syntax defined above
164 with the words separated by ':'
165 .nf
166 <type> <argument id>
167 or
168 <type> <argument id> (check <list of checks>)
169 .fi
170 .PP
171 The checks are glib type preconditions, and can be the following:
172 "null", which tests pointers for being NULL, "type" which checks GTK+
173 object pointers for being the right type, "<test> <number>" which tests
174 numeric arguments for being a certain value.  The test can be a <,>,<=,>=
175 != or ==.  Example:
176 .nf
177   
178   public int foo(self, int h (check > 0 < 11), Gtk:Widget *w (check null type))
179
180 .fi
181 .PP
182 This will be the prototype of a function which has a self pointer
183 as the first argument, an integer argument which will be checked and has
184 to be more then 0 and less then 11, and a pointer to a GtkWidget object
185 instance and it is checked for being null and the type will also be
186 checked.
187 .PP
188 Error return:
189 .PP
190 Methods which have a return value, there also has to be something
191 returned if there is an error, such as if a precondition is not met.  The
192 default is 0, casted to the type of the method.  If you need to return
193 something else then you can specify an "onerror" keyword after the
194 prototype and after that a number, a token (an identifier) or a bit of C
195 code enclosed in braces {}.  The braces will not be printed into the
196 output, they just delimit the string.  For example
197 .nf
198
199   public void * get_something(self, int i (check >= 0)) onerror NULL {
200           ...
201   }
202
203 .fi
204 .PP
205 Virtual methods:
206 .PP
207 Virtual methods are basically pointers in the class structure,
208 so that one can override the method in derived methods.  They can be empty
209 (if you put ';' instead of the C code).  A wrapper will also be defined
210 which makes calling the methods he same as public methods.  This type of
211 method is just a little bit "slower" then normal functions, but not as
212 slow as signals.  You define them by using "virtual" keyword before the
213 prototype. If you put the keyword "private" right after the "virtual"
214 keyword, the wrapper will not be a public method, but a private one.
215 .PP
216 Signals:
217 .PP
218 Signals are methods to which the user can bind other handlers
219 and override the default handler.  The default handler is basically the
220 method body.  This is the most versatile and flexible type of a method
221 and also the slowest.  You need to specify a whole bunch of things when
222 you define a signal.  One thing is when the default handler will be run,
223 first or last.  You specify that by "first" or "last" right after the
224 "signal" keyword.  Then you need to define the gtk enum types (again
225 without the GTK_TYPE_ prefix).  For that you define the return types
226 and the types of arguments after the "self" pointer (not including the
227 "self" pointer).  You put it in the following syntax "<return type> (<list
228 of arguments>)".  If the return type is void, the type should be "NONE",
229 the same should be for the argument list.  The rest of the prototype is
230 the same as for other method types.  The body can also be empty, and
231 also there is a public method wrapper which you can use for calling the
232 signal just like a public method.  Example:
233 .nf
234
235   signal first INT(POINTER,INT)
236   int do_something(self, Gtk:Widget *w (check null type), int length)
237   {
238           ...
239   }
240   
241 or
242
243   signal last NONE(NONE) void foo(self);
244
245 .fi
246 .PP
247 If you don't want the wrapper that emits the signal to be public, you can
248 include the keyword "private" after the "signal" keyword. This will make
249 the wrapper a normal private method.
250 .PP
251 If you don't define a "first" or a "last", the default will be taken as
252 "last".
253 .PP
254 Override methods:
255 .PP
256 If you need to override some method (a signal or a virtual method
257 of some class in the parent tree of the new object), you can define and
258 override method.  After the "override" keyword, you should put the
259 typename of the class you are overriding a method from.  Other then that
260 it is the same as for other methods.  The "self" pointer in this case
261 should be the type of the method you are overriding so that you don't
262 get warnings during compilation.  Example:
263 .nf
264
265   override (Gtk:Container) void
266   add (Gtk:Container *self (check null type), Gtk:Widget *wid (check null type))
267   {
268           ...
269   }
270 .fi
271 .PP
272 Calling methods:
273 .PP
274 Inside the code, pointers are set for the methods, so that you don't
275 have to type the class name before each call, just the name of the method.
276 Example:
277 .nf
278
279   private int
280   foo(self)
281   {
282           return self->len;
283   }
284   
285   private int
286   bar(self,int i)
287   {
288           return foo(self) + i;
289   }
290
291 .fi
292 .PP
293 Making new objects:
294 .PP
295 You should define a new method which should be a normal public method.  Inside
296 this method, you can use the GET_NEW macro that is defined for you and that
297 will fetch a new object, so a fairly standard new method would look like:
298 .nf
299
300   public GtkWidget *
301   new(void) {
302           GtkObject *ret;
303           ret = GTK_OBJECT (GET_NEW);
304           return ret;
305   }
306
307 .fi
308
309 .SH C++ MODE
310 .PP
311 There is a C++ mode so that gob creates C++ compiler friendly files.  You need
312 to use the --for-cpp argument to gob.  This will make the generated file have
313 a .cc instead of a .c extention, and several things will be adjusted to
314 make it all work for a C++ compiler.  One thing that will be missing is an
315 alias to the new method, as that clashes with C++, so instead you'll have to
316 use the full name of the method inside your code.  Also note that gob does
317 not use any C++ features, this option will just make the generated code
318 compile with a C++ compiler.
319
320 .SH BUGS
321 .PP
322 The generated header file is included as the first file in the .c file, no
323 matter what. This means that you will have to put things that need to be
324 included before that, into an %h{ } section.
325 .PP
326 Also the lexer does not actually parse the C code, so I'm sure that some corner
327 cases or maybe even some not so corner cases of C syntax might confuse gob
328 completely.  If you find any, send me the source that makes it go gaga and I'll
329 try to make the lexer try to handle it properly, but no promises.
330 .PP
331 Another thing is that gob ignores preprocessor macros.  Since gob counts
332 braces, the following code won't work:
333 .nf
334
335   #ifdef SOME_DEFINE
336   if(foo) {
337   #else
338   if(bar) {
339   #endif
340           blah();
341   }
342
343 .fi
344 To make this work, you'd have to do this:
345 .nf
346
347   #ifdef SOME_DEFINE
348   if(foo)
349   #else
350   if(bar)
351   #endif
352   {
353           blah();
354   }
355
356 .fi
357 There is no real good way we can handle this without parsing C code, so we
358 probably never will.  In the future, I might add #if 0 as a comment but
359 that's about as far as I can really take it and even that is problematic.
360 Basically, if you use gob, just don't use the C preprocessor too extensively.
361
362 .SH AUTHOR
363 .PP
364 George Lebl <jirka@5z.com>