From 69c350c69e70bddb040dfc5d90b0368376a6389e Mon Sep 17 00:00:00 2001 From: George Lebl Date: Mon, 15 Jul 2002 22:18:00 -0800 Subject: [PATCH] Release 2.0.0 --- ChangeLog | 19 + NEWS | 3 + TODO | 4 - configure | 2 +- configure.in | 2 +- doc/Makefile.am | 2 +- doc/Makefile.in | 2 +- doc/gob2.1.in | 625 +++++++++++++++++++------------- doc/makehtml.pl | 4 + examples/Makefile.am | 3 +- examples/Makefile.in | 4 +- examples/README | 11 +- examples/foo-some-interface.gob | 2 +- examples/gtk-button-count.gob | 45 ++- examples/my-person.gob | 113 +++--- examples/my-person2.gob | 79 ---- gob2.spec | 2 +- src/Makefile.am | 2 +- src/Makefile.in | 2 +- 19 files changed, 508 insertions(+), 418 deletions(-) delete mode 100644 examples/my-person2.gob diff --git a/ChangeLog b/ChangeLog index 15551ed..e6c85fe 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,22 @@ +Mon Jul 15 13:05:18 2002 George Lebl + + * Release 2.0.0 + + * */Makefile.am: add '.' to SUBDIRS to silence a stupid version + of bash + +Mon Jul 15 12:54:30 2002 George Lebl + + * configure.in: raise version to 2.0.0 + + * examples/*: update examples and readme. Remove old, bad examples + + * doc/gob2.1.in: update for gob2 + +Wed Jul 10 11:10:37 2002 George Lebl + + * doc/gob2.1.in: update the docs a bit. Still not finished. + Tue May 28 12:09:56 2002 George Lebl * Release 1.99.3 diff --git a/NEWS b/NEWS index 8fd6853..e5f0a54 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,6 @@ +2.0.0: + * Update examples and documentation + 1.99.3: * Fix signal default value * Special case the interface code to allow implementing diff --git a/TODO b/TODO index 24bf3e0..99f0ab3 100644 --- a/TODO +++ b/TODO @@ -4,7 +4,3 @@ Allow math expressions in array definition test out the possibility of doing the static typesafe downcasts, at least for gob objects. - -override geT_type - -Support BonoboXObject directly diff --git a/configure b/configure index db8797d..64fec14 100755 --- a/configure +++ b/configure @@ -1119,7 +1119,7 @@ fi PACKAGE=gob2 -VERSION=1.99.3 +VERSION=2.0.0 if test "`cd $srcdir && pwd`" != "`pwd`" && test -f $srcdir/config.status; then { { echo "$as_me:1125: error: source directory already configured; run \"make distclean\" there first" >&5 diff --git a/configure.in b/configure.in index f57f83e..6847592 100644 --- a/configure.in +++ b/configure.in @@ -2,7 +2,7 @@ dnl Process this file with autoconf to produce a configure script. AC_PREREQ(2.2) AC_INIT(src/treefuncs.h) AM_CONFIG_HEADER(config.h) -AM_INIT_AUTOMAKE(gob2,1.99.3) +AM_INIT_AUTOMAKE(gob2,2.0.0) AM_MAINTAINER_MODE GLIB_REQUIRED=1.3.12 diff --git a/doc/Makefile.am b/doc/Makefile.am index 4654781..6d63081 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -1,5 +1,5 @@ man_MANS = gob2.1 -SUBDIRS = +SUBDIRS = . EXTRA_DIST = gob2.1.in makehtml.pl diff --git a/doc/Makefile.in b/doc/Makefile.in index 46de52b..4f28fd1 100644 --- a/doc/Makefile.in +++ b/doc/Makefile.in @@ -79,7 +79,7 @@ YACC = @YACC@ YFLAGS = @YFLAGS@ man_MANS = gob2.1 -SUBDIRS = +SUBDIRS = . EXTRA_DIST = gob2.1.in makehtml.pl mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs diff --git a/doc/gob2.1.in b/doc/gob2.1.in index adf08b0..c51e7e6 100644 --- a/doc/gob2.1.in +++ b/doc/gob2.1.in @@ -1,6 +1,6 @@ .\" .\" gob manual page -.\" (C) 1999,2000,2001 George Lebl +.\" (C) 1999,2000,2001,2002 George Lebl .\" .\" This manual page is covered by the terms of the GNU General .\" Public License. @@ -10,21 +10,18 @@ GOB2 \- The GObject Builder .SH SYNOPSIS .PP -.B gob +.B gob2 [ option ] ... file -.SH OUT OF DATE -.PP -This manual is out of date. I will be updating it when I can but it -mostly covers the GOB 1.0.x versions and not GOB2 yet. There ARE wrong -things in this manual for now. Keep that in mind. However most things -still apply. Just not all. .SH DESCRIPTION .PP GObject Builder is a simple preprocessor for easily creating GObject objects. It does not parse any C code and ignores any C errors. It -is in spirit similar to things like lex or yacc. +is in spirit similar to things like lex or yacc. In some ways it +also resembles java. But it is really just a simple preprocessor +for creating GObjects for use in C or C++ and it is not a programming +language. .SH OPTIONS .PP @@ -62,14 +59,22 @@ unchanged however. .TP .B --always-private-header Always create a \fB-private.h\fR file, even if it would be empty. -Otherwise, it is only created when there are private data members in the class. -This option implicitly negates --no-private-header +This is the default. +.TP +.B --ondemand-private-header +Create the private header only if it would have something in it, that is, +if there are some private data members or protected methods. .TP .B --no-private-header Never create a private header file. If we use any private data members, define the private data structure at the point in the .c source where -the class definition begins. This option implicitly negates ---always-private-header +the class definition begins. +.TP +.B --m4 +Preprocess source with m4. Following args will be passed to m4. +.TP +.B --m4-dir +Print directory that will be searched for m4 files. .TP .B -n --no-write Do not write any output files, just check syntax of the input file. @@ -183,9 +188,7 @@ don't, the private header file automatically includes the public header file, and thus the public header file will be indirectly included at the very top of the file. -.SH MAKING A NEW CLASS -.PP -The class header: +.SH THE CLASS HEADER .PP There can be only one class per input file. Defining a class is sort of like in Java, you define the class and write inline code @@ -200,8 +203,8 @@ For example: } .fi -.PP -Data members: + +.SH DATA MEMBERS .PP There are five types of data members. Three of them are normal data numbers, one is class wide (global) in scope and one is a virtual one, usually linked to @@ -253,7 +256,7 @@ Also note that this structure is dynamically allocated, and is freed in the finalize handler. If you override the finalized handler, your code will be run first and only then will the _priv structure be freed. .PP -Classwide data members: +.B "Classwide data members:" .PP Sometimes you want a datamember to be shared by all objects. You then need the "classwide" scope keyword. So for example the following adds a global @@ -271,7 +274,7 @@ object and casting it to your class pointer. Thus the following would work: .fi .PP -Automatic Initialization (0.93.0 and higher only): +.B "Automatic Initialization:" .PP You can automatically initialize the public private and protected data members without having to add an init method. The advantage here is that @@ -291,11 +294,11 @@ of "hello". .fi .PP -Automatic Destruction (0.93.0 and higher only): +.B "Automatic Destruction:" .PP Most data stored as pointers needs to have a function called when the object -is destroyed, to either free it or give up a reference. Gob will let you -define a function to be called on the data the object is destroyed. This is +is finalized to either free the data. Gob will let you +define a function to be called on the data the object is finalized. This is achieved by putting 'destroywith' followed by a function name after the variable definition. It is only called if the data you defined this on is not NULL, so you cans specify functions which do not handle NULL. It @@ -310,21 +313,19 @@ define this on any non-pointer data as the results may be undefined. Example: .nf - public Gtk:Widget *window = NULL - destroywith gtk_widget_destroy; public char *foo = {g_strdup("bar")} destroywith g_free; .fi Note that the function name you give must be a real function and not macro. -Also note that this is always called in the "destroy" method of GtkObject. -It is always called after any user defined body of the destroy handler. +Also note that this is always called in the "finalize" method of GObject. +It is always called after any user defined body of the finalize handler. .PP Sometimes you may want to run arbitrary code on destruction. While this can -be perfectly well done in the destroy handler. Depending on the style you +be perfectly well done in the finalize handler. Depending on the style you may want to include all destruction/initialization code together with the definition of the data member. Thus you may want to put arbitrary code which -will then be inserted into the "destroy" method of GtkObject. This can be +will then be inserted into the "finalize" method of GObject. This can be done with the "destroy" keyword followed by arbitrary code in curly braces. Inside this code a macro called VAR will be define which refers to your variable. So for example destroying a GString can be either done with @@ -344,164 +345,180 @@ thing to do if that's a possibility. The "destroy" keyword with code does take up more space in the file and it may become more cluttered. .PP The data is zeroed out after being destroyed. This is to make debugging easier -in case your code might try to access an already destroyed object. In case -you have overridden the destroy method, your code will be run first and +in case your code might try to access an already finalized object. In case +you have overridden the finalize method, your code will be run first and only then will the destructors be called. You should not however make any assumptions about the order at which the destructors are called. If you have interdependencies between destructors for different data members, you will -have to do this in your own destroy override function. +have to do this in your own finalize override function. +.PP +.B "Automatic Unreffing:" .PP -GTK+ Arguments: +This is very much like the automatic destruction, but is instead run in the +shutdown method (which is called from the "destroy" method of GtkObject). +All data and other objects that you need to unref should be done here, and +not at finalize time. The semantics are otherwise the same as for the +"destroywith" and "destroy" keywords, except that you use "unrefwith" +and "unref". +.nf + + public G:Object *foo = NULL + unrefwith g_object_unref; + public G:Object *bar = NULL + unref { + g_object_unref (VAR); + }; + +.fi + +.SH GOBJECT PROPERTIES .PP -The fourth type of a data member an argument type. It is a named data member -which is one of the features of the GTK+ object system. You need to define a +The fourth type of a data member a property type. It is a named data member +which is one of the features of the GObject system. It just defines a way to +get and set some data, but you have to take care of storing that data +somewhere. So it is normal to also have a normal private (or public) +data member where you store the real data. +You normally need to define a get and a set handler. They are fragments of C code that will be used to get the value or set the value of the argument. Inside them you can use the define -ARG to which you assign the data or get the data. You can also use the +VAL to which you assign the data or get the data. You should treat this VAL +as a GValue which stores the data of the correct type. +You can also use the identifier "self" as pointer to the object instance. The type is defined as -one of the gtk type enums, but without the GTK_TYPE_ prefix. For example: +one of the GObject type enums, but without the G_TYPE_ prefix. There are +also some attributes of a property which you can set. For example the +following is a definition of an integer property 'height' which will +be synchronized with a private integer data member also of the name 'height'. .nf - public int height; - argument INT height set { self->height = ARG; } get { ARG = self->height; }; + private int height; + property INT height + (nick = _("Short nickname"), + blurb = _("Long description"), + minimum = 10, + maximum = 200, + default_value = 100) + set { self->_priv->height = g_value_get_int (VAL); } + get { g_value_set_int (VAL, self->_priv->height); }; .fi .PP -If you don't define a set or a get handler it will be a read-only -or a write-only argument. If you want to add extra argument flags, add -them into parenthesis after the argument keyword, separated by '|' and -without the GTK_ARG_ prefix. For example: +The attributes are really optional though you should at least set some +of them. +All property types have a 'nick' and a 'blurb' attribute and you should +set those accordingly. This will make runtime querying the object +nicer as things such as gui editors and class browsers can be more +verbose about the class itself. Almost all types also have a +'default_value' +attribute which sets the initial value of this property (on object +initialization, the set handler will be run automatically with this +value). +.PP +All the numeric types (including CHAR) have 'minimum' and 'maximum' +attributes which can restrict the range. If you do not specify these +the range will be the full range that the data type can handle. +.PP +Types such as UNICHAR and BOOLEAN only have the 'nick', 'blurb' and +'default_value' attributes. +.PP +The ENUM type has an 'enum_type' attribute which is the exact +type of the enum. This is so that the property knows which exact +type you can set, rather then just knowing it is an enum. You should +always create an enum type specific for the enum itself (see section +on the enum types) +.PP +Similarly FLAGS type has a 'flags_type' which again you should set to +the specific type of this flags data member. +.PP +There is a STRING type which has only the extra 'default_value' attribute. +.PP +The OBJECT type is one of the types that doesn't have a 'default_value' and it +only has an 'object_type' attribute (in addition to nick and blurb of course) +that is the exact object type that this property accepts. +.PP +There is a BOXED type which is a pointer which has a boxed type defined +(such that GObject knows how to copy and destroy this pointer). Here +you will need to specify the 'boxed_type' attribute with the specific +type of the boxed pointer. +.PP +There is also a POINTER type, which has only the nick and blurb +attributes. This is for storing arbitrary pointers. You should be +careful with this one, as GObject knows nothing about the data +stored at this pointer. It is somewhat like a 'void *' type. +.PP +There is also the PARAM type for storing parameters with a 'param_type' +attribute. +.PP +You should notice that this list is pretty much like the list of g_param_spec_* +functions from gobject/gparamspecs.h, and the attributes are like the +arguments of those functions. Note however that value array is NOT supported +yet. +.PP +You can also specify extra flags, such as CONSTRUCT or CONSTRUCT_ONLY using the +'flags' attribute. You can specify multiple flags by oring them together with +'|'. These flags correspond to the GParamFlags enumeration except do not +include the G_PARAM_ prefix. So for example to define an enumeration property, +which is a CONSTRUCT_ONLY property, we could do the following: .nf - public int height; - argument (CONSTRUCT) INT height get { ARG = self->height; }; + private SomeEnumerationType foo; + property ENUM foo + (nick = _("Short nickname"), + blurb = _("Long description"), + enum_type = Some:Enumeration:Type + default_value = SOME_ENUMERATION_VALUE, + flags = CONSTRUCT_ONLY, + link); .fi -This makes the argument settable even before the object is constructed, so -that people can pass it to gtk_object_new function. Useful is also -CONSTRUCT_ONLY flag which makes the argument only available during -construction of the object. -.PP -Since 0.92.1, gob creates macros which can be used for type safe access to -gtk arguments. The macros are called _ARG_(x) and -_GET_ARG_(x). They define both the string and the +.PP +The above example also gives an example of automatic linking to a standard data +memember. By including the attribute 'link' a get and set handlers will be +automatically added without having to type them by hand. This is useful for a +vast majority data types that are just linked to some standard data member and +do not need to do anything extra on get or set. +.PP +Another extra feature of properties is the possibility of automatically +exporing methods to get and set the property. That is without having to +use g_object_set and g_object_get. This is achieved by adding an +'export' attribute to the list of property attributes. +.PP +If you do not define a set or get handler, the property will automatically +be only readable or writable as appropriate. +.PP +Gob2 also creates macros which can be used for type safe access to +properties through g_object_set and g_object_get. +The macros are called _PROP_(x) and +_GET_PROP_(x). They define both the string and the value part of the argument. So for setting an argument of height, one would use (for object type My:Object): .nf - gtk_object_set (GTK_OBJECT (object), - MY_OBJECT_ARG_HEIGHT (7), - NULL); + g_object_set (G_OBJECT (object), + MY_OBJECT_PROP_HEIGHT (7), + NULL); .fi And for getting, you would use: .nf int height; - gtk_object_get (GTK_OBJECT (object), - MY_OBJECT_GET_ARG_HEIGHT (&height), - NULL); + g_object_get (G_OBJECT (object), + MY_OBJECT_GET_PROP_HEIGHT (&height), + NULL); .fi Note however that the type safety only works completely on GNU C compilers. The code will compile on other compilers but with minimal type safety. +For complete type safety it is useful to use the get/set methods that +are defined by using the 'export' attribute. .PP -To get good type safety on POINTER types however, you should specify -an optional C type that gob should use. For other then POINTER types -this is redundant but possible. To do this, place '(type )' -right after the GTK+ type. Example: -.nf - - argument POINTER (type char *) foo set { /* foo */ } get { /* bar */ }; - -.fi -.PP -Sometimes it can become tiresome to type in the set and get handlers if -they are trivial. So gob since version 0.93.0 provides automatic argument -linking to data members. There are three different cases it handles, direct -link (keyword 'link'), string linking (keyword 'stringlink') and object -linking (keyword 'objectlink'). You just place the keyword after the argument -name instead of the get/set handlers. It will link to a data member of the -same name that was defined earlier in the input file. Best is to see examples: -.nf - - public int foo; - argument INT foo link; - -.fi -is just like -.nf - - public int foo; - argument INT (type int) foo - get { ARG = self->foo; } - set { self->foo = ARG; }; - -.fi -Similarly, -.nf - - private char * foo; - argument POINTER foo stringlink; - -.fi -is just like -.nf - - private char * foo; - argument POINTER (type char *) foo - get { - ARG = g_strdup(self->_priv->foo); - } set { - g_free(self->_priv->foo); - self->_priv->foo = g_strdup(ARG); - } - -.fi -And for the objectlink we would have: -.nf - - public Gtk:Object * foo; - argument POINTER foo objectlink; - -.fi -is just like -.nf - - protected Gtk:Object * foo; - argument POINTER (type Gtk:Object *) foo - get { - ARG = self->foo; - } set { - if(ARG != NULL) - gtk_object_ref(ARG); - if(self->foo != NULL) - gtk_object_unref(self->foo); - self->foo = ARG; - } - -.fi -.PP -As you see it will handle NULLs correctly (for the string, g_free and g_strdup -handle NULLs). And it will also handle private, protected and public members. -For objectlink, just a pointer is returned on get, if you wish to keep it around, -you should call gtk_object_ref on it. For stringlink, get makes a copy of -the string which you should free after use. This is the behaviour since 1.0.2. -.PP -You can also automatically export get and set methods for each of the arguments -by appending '(export)' flag before the get and set statements. For example: -.nf - - public int foo; - argument INT (type int) foo (export) - get { ARG = self->foo; } - set { self->foo = ARG; }; +To get bettery type safety on some of the property types, you can specify +the 'type' attribute which will add casts where appropriate in code dealing +with this property. This is especially useful for POINTER types. But +even for others. -.fi -Will export public methods get_foo(self) and set_foo(self, int foo) for you -automatically. Note that this behaviour is new in 1.0.10. -.PP -Methods: +.SH METHODS .PP There is a whole array of possible methods. The three normal, "familiar" method types are private, protected and public. Public are @@ -519,7 +536,7 @@ body. This will define an empty function. You can't do this for non-void regular public, private or protected methods, however it is acceptable for non-void virtual, signal and override methods. .PP -Function argument lists: +.B "Function argument lists:" .PP For all but the init and class_init methods, you use the following syntax for arguments. The first argument can be just "self", @@ -540,7 +557,10 @@ numeric arguments for being a certain value. The test can be a <,>,<=,>= != or ==. Example: .nf - public int foo(self, int h (check > 0 < 11), Gtk:Widget *w (check null type)) + public int + foo (self, + int h (check > 0 < 11), + Gtk:Widget *w (check null type)) .fi .PP @@ -550,7 +570,7 @@ to be more then 0 and less then 11, and a pointer to a GtkWidget object instance and it is checked for being null and the type will also be checked. .PP -Error return: +.B "Error return:" .PP Methods which have a return value, there also has to be something returned if there is an error, such as if a precondition is not met. The @@ -561,7 +581,7 @@ code enclosed in braces {}. The braces will not be printed into the output, they just delimit the string. For example: .nf - public void * get_something(self, int i (check >= 0)) onerror NULL { + public void * get_something (self, int i (check >= 0)) onerror NULL { ... } @@ -570,23 +590,23 @@ The onerror value is also used in overrides that have a return value, in case there isn't a parent method, PARENT_HANDLER will return it. More about this later. .PP -Default return: +.B "Default return:" .PP Some signal and virtual methods have a return type. But what happens if -there is no default handler and no one connects to a signal. GOB will +there is no default handler and no one connects to a signal. GOB2 will normally have the wrappers return whatever you specify with onerror or '0' -if you haven't specified anything. But since 0.93.2 you can specify a default +if you haven't specified anything. You can also specify a default return value with the keyword 'defreturn'. It's use is identical to the use of onerror, and you can in fact use both at the same time. Example .nf - virtual int get_some_int(self) onerror -1 defreturn 10 ; + virtual int get_some_int (self) onerror -1 defreturn 10 ; .fi That is an empty virtual method (in C++ terms a pure virtual). If you never specify any handler for it in the derived children it will just return 10. .PP -Constructor methods: +.B "Constructor methods:" .PP There are two methods that handle the construction of an object, init and class_init. You define them by just using the init or class_init keyword @@ -596,13 +616,13 @@ it's init or class_init. For example: .nf - init(self) { + init (self) { /* initialize the object here */ self->a = 9; self->b = 9; } - class_init(class) { + class_init (class) { /* initialize the class, this is rarely needed */ class->blah = NULL; } @@ -611,15 +631,15 @@ For example: The class_init function is very rarely needed as all standard class initialization is taken care of for you by gob itself. The init function should on the other hand be used whenever you need to construct or initialize -anything in the object to put it into a sane state. Sometimes you need -some arguments, for this you should either use a construct method and a -new function like many GTK+ widgets, and/or a CONSTRUCT or CONSTRUCT_ONLY -type of an argument. +anything in the object to put it into a sane state. .PP -Virtual methods: +.B "Virtual methods:" .PP Virtual methods are basically pointers in the class structure, -so that one can override the method in derived methods. They can be empty +so that one can override the method in derived methods. That is to implement +the method in a derived class, you must then use an override method (more +on those later). +They can be empty (if you put ';' instead of the C code). A wrapper will also be defined which makes calling the methods he same as public methods. This type of method is just a little bit "slower" then normal functions, but not as @@ -628,7 +648,7 @@ prototype. If you put the keyword "private" right after the "virtual" keyword, the wrapper will not be a public method, but a private one. You can do the same with "protected" to make a protected wrapper. .PP -Signals: +.B "Signals:" .PP Signals are methods to which the user can bind other handlers and override the default handler. The default handler is basically the @@ -636,8 +656,8 @@ method body. This is the most versatile and flexible type of a method and also the slowest. You need to specify a whole bunch of things when you define a signal. One thing is when the default handler will be run, first or last. You specify that by "first" or "last" right after the -"signal" keyword. Then you need to define the gtk enum types (again -without the GTK_TYPE_ prefix). For that you define the return types +"signal" keyword. Then you need to define the GObject enum types (again +without the G_TYPE_ prefix). For that you define the return types and the types of arguments after the "self" pointer (not including the "self" pointer). You put it in the following syntax " ()". If the return type is void, the type should be "NONE", @@ -647,8 +667,8 @@ also there is a public method wrapper which you can use for calling the signal just like a public method. Example: .nf - signal first INT(POINTER,INT) - int do_something(self, Gtk:Widget *w (check null type), int length) + signal first INT (POINTER, INT) + int do_something (self, Gtk:Widget *w (check null type), int length) { ... } @@ -657,7 +677,7 @@ signal just like a public method. Example: or .nf - signal last NONE(NONE) void foo(self); + signal last NONE (NONE) void foo (self); .fi .PP @@ -670,26 +690,40 @@ If you don't define a "first" or a "last", the default will be taken as "last". .PP You can also add additional flags. You do this just like with the argument -flags, although this is probably very rare. These are the GTK_RUN_* flags, -and you can add them without the GTK_RUN_ prefix into a parenthesis, just -after the "signal" keyword. By default all public signals are GTK_RUN_ACTION. -.PP -Since 1.0.6, gob creates wrapper signal macros for signal connection -typesafety, at least on gnu compilers. These macros are named -_SIGNAL_(func), where func is the function pointer. This -pointer must be of the correct type, or you will get an initialization from -wrong pointer type warning. This macro, much like the argument macros, wraps -both the name and the function pointer parameters. For example to connect a -signal "changed" to a function "foo", you would do: +flags, although this is probably very rare. These are the G_SIGNAL_* flags, +and you can add them without the G_SIGNAL_ prefix into a parenthesis, just +after the "signal" keyword. By default all public signals are G_SIGNAL_ACTION. +.PP +Also gob2 creates a wrapper macros for typesafe signal connection. That is +you will be warned by the compiler if you pass a callback that is not the +correct prototype. This will again only warn you on gcc, but it will +compile without warning on another compiler. So as with all the typesafety +hacks in gob, it is better to test your objects under gcc to get any warnings +even if you are using a different compiler in the end. +.PP +The methods that are created for you are: +.nf + + _connect__ (, , ) + _connect_after__ (, , ) + _connect_data__ (, , , + , ) + +.fi +.PP +These three functions correspond to the g_signal_connect, +g_signal_connect_after and g_signal_connect_data functions that you would +normally use, except they are for a specific signal. Also do note +the two underscores between the method name and the signal name. For +example to connect the signal "foo" on the object "Test:Object" you +would do: .nf - gtk_signal_connect (GTK_OBJECT (object), - MY_OBJECT_SIGNAL_CHANGED (foo), - NULL); + test_object_connect__foo (object, callback, data); .fi .PP -Override methods: +.B "Override methods:" .PP If you need to override some method (a signal or a virtual method of some class in the parent tree of the new object), you can define and @@ -713,7 +747,7 @@ If the function has a return value, then PARENT_HANDLER is an expression that you can use. It will return whatever the parent handler returned, or the "onerror" expression if there was no parent handler. .PP -Method names: +.B "Method names:" .PP Inside the code, aliases are set for the methods, so that you don't have to type the class name before each call, just type \fBself_\fR instead @@ -729,42 +763,45 @@ Example: } private int - bar (self,int i) + bar (self, int i) { return self_foo (self) + i; } .fi -.PP -Making new objects: + +.SH MAKING NEW OBJECTS .PP You should define a new method which should be a normal public method. Inside this method, you can use the GET_NEW macro that is defined for you and that will fetch a new object, so a fairly standard new method would look like: .nf - public GtkObject * - new(void) { - GtkObject *ret = GET_NEW; - return GTK_OBJECT (ret); + public GObject * + new (void) { + GObject *ret = GET_NEW; + return G_OBJECT (ret); } .fi .PP -You should not a subtle peculiarity of the GTK+ object system here. If there is any -code inside the GTK_OBJECT macro argument, it will get executed multiple times. This -means that things such as GTK_OBJECT(GET_NEW) would actually create 4 objects, leaking -3 of them. A good rule is to be careful with all macros. +You should not a subtle peculiarity of the GObject system here. If there is +any code inside the G_OBJECT macro argument, it will get executed multiple +times. This means that things such as G_OBJECT(GET_NEW) would actually create +4 objects, leaking 3 of them. A good rule (as with anywhere in C) is to be +careful with all macros. + +.SH SELF REFERENCES .PP -Self alias casts: +.B "Self alias casts:" .PP There are some standard casts defined for you. Instead of using the full macros inside the .c file, you can use SELF, IS_SELF and SELF_CLASS. Using these makes it easier to for example change class names around. .PP -Self alias types: +.B "Self alias types:" .PP -Since 0.93.5, there have also been defined the Self and SelfClass types inside +There are also the Self and SelfClass types inside your .c file. These serve the same function as the above, they make it easier to type and easier to change typenames around which can help a lot during prototyping stage. However you should note that the Self type should not be @@ -775,34 +812,76 @@ aliases by passing --no-self-alias to .SH DEALING WITH DIFFERENT GOB VERSIONS .PP -Defines: +.B "Defines:" .PP In your generated C file, you can use the defines GOB_VERSION_MAJOR GOB_VERSION_MINOR and GOB_VERSION_PATCHLEVEL if you wish to for example use a feature that is only available in some newer gob version. Note however that you can only use these defines in the C code portions of your .gob file, and #ifdef's cannot span multiple functions. Check the BUGS section -for more on using the C preprocessor and gob. Also note that these -have only been available since the 0.92.1 version of gob. +for more on using the C preprocessor and gob. .PP -Minimum version requires: +.B "Minimum version requires:" .PP You can also make your .gob file require at least certain version of gob. You do this by putting 'requires x.y.z' (where x.y.z is the version number) outside of any C block, comment or class, usually you should make this the first line in the file or close to the top. If gob finds this and the version of gob used to compile the code is lower then that listed in the require, gob will generate -an error and exit. For example to require that gob version 0.92.1 or higher +an error and exit. For example to require that gob2 version 2.0.0 or higher be used to compile a file, put this at the top of that file: .nf - requires 0.92.1 + requires 2.0.0 + +.fi + +.SH CREATING NEW ENUM, FLAGS and ERROR TYPES +.PP +You can create new GObject ENUM, FLAGS and GError types for use in your +classes easily. Glib includes some utilities for handling these, however +it may be cleaner to use the below specified way in your classes. It also +then doesn't require any Makefile setup. Make sure this is defined in the same +section as the class, that is not in any of the '%?{' '%}' sections. +.PP +You use the keywords 'enum' 'flags' and 'error' as you would use the 'class' +keyword. Then you give a prefix for the values in the enumeration. Then +you define a list of values just like in C. For 'enum' types you can also +specify the values assigned to each string. Then you specify the type +in the standard gob style of specifying types. Here are a few examples +of all of these: +.nf + + enum LAME_CLIENT { + IS_CONNECTED, + NONE = 9, + LAST + } Test:Enum; + + flags BUGA_BUGA { + ONE, + TWO, + MANY, + } Some:Flags; + + error TEST_OBJECT_ERROR { + BAD_THIS, + BAD_THAT + } Test:Object:Error; + +.fi +.PP +This will for example define an enum that is equivalent to the following +C code: +.nf + + typedef enum { + LAME_CLIENT_IS_CONNECTED, + LAME_CLIENT_NONE = 9, + LAME_CLIENT_LAST + } TestEnum; .fi -It should be noted however that this feature was not added until 0.92.1, and -so if the file gets compiled by a lower version, gob would generate a -syntax error. Thus by putting in a requires line, you are implicitly -requiring at least 0.92.1. .SH C++ MODE .PP @@ -819,13 +898,12 @@ compile with a C++ compiler. .PP The get_type is not really a method, but a function which initializes your object. Recently objects appeared which require you to make a custom -get_type function (BonoboXObject currently, see next section for direct -BonoboXObject support). So in 1.0.7 it is now possible +get_type function. So it is possible to override this function. To do so, just define a new public method called get_type, with no arguments. Example: .nf - public GtkType + public GType get_type (void) { /* code goes here */ @@ -834,22 +912,72 @@ get_type, with no arguments. Example: .fi -.SH DIRECT BonoboXObject SUPPORT +.SH INTERFACES +.PP +Currently gob will only allow you to implement interfaces (that is, define new +classes which implement an interface) and doesn't yet have support for making +new interfaces, but this will be coming at some point in the future. +.PP +To define a class that implements an interface add a class flag 'interface' +with the type name of the interface as an argument. Then to implement +a specific method of the interface, just add 'interface ' +before the method definition. The method can, and probably should be, +private. +.PP +The following example implements a new object, that implements the +Gtk:Tree:Model interface and implements the get_flags method of that +interface. Do note that except for standard (GTK+ and glib) specific +interfaces which seem +to have a non-standard name for the interface structure, the structure +should end with and Iface, if you are implementing an interface. That +is for example for the Gtk:Tree:Model, the structure containing the +table of methods should be named GtkTreeModelIface. +.nf + class Some:Object from G:Object + (interface Gtk:Tree:Model) + { + /* function implemented for the Gtk:Tree:Model interface */ + interface Gtk:Tree:Model + private GtkTreeModelFlags + get_flags (Gtk:Tree:Model *self (check null type)) + { + /* Here would be the implementation */ + return (GtkTreeModelFlags)0; + } + } + +.fi +.PP +If you want to implement multiple interfaces just list more class flag lines +as follows: +.nf + + class Some:Object from G:Object + (interface Gtk:Tree:Model) + (interface Gtk:Editable) + { + /* ... */ + } + +.fi + +.SH DIRECT BonoboObject SUPPORT .PP -If you want to build a BonoboXObject class gob has direct support for these -classes since 1.0.9. Just create a new object that derives from -Bonobo:X:Object. Then use a "BonoboX" class flag with the interface name as an +If you want to build a BonoboObject class gob2 has direct support for these. +Just create a new object that derives from +Bonobo:Object. +Then use a "BonoboObject" class flag with the interface name as an argument. The interface name should be as you would type it in C, that is with underscores as namespace separators. Then you add the methods (using exact -same names as in the idl file) and prepend those methods with a BonoboX +same names as in the idl file) and prepend those methods with a BonoboObject keyword. For example imagine you have an interface GNOME/Foo/SomeInterface, with a method fooBar that takes a single string: .nf - class Foo:Some:Interface from Bonobo:X:Object - (BonoboX GNOME_Foo_SomeInterface) { + class Foo:Some:Interface from Bonobo:Object + (BonoboObject GNOME_Foo_SomeInterface) { - BonoboX + BonoboObject private void fooBar (PortableServer_Servant servant, const CORBA_char *string, @@ -889,13 +1017,6 @@ argument lists and virtual and signal method names as it might confuse the PARENT_HANDLER macro. In fact avoiding all names with three underscores is the best policy when working with gob. .PP -Also note that starting with version 0.93.5, method names that start with a -an underscore are equivalent to the names without the initial underscore. This -is done to avoid conflicts with the aliases. Thus you can define the method -as "_name", if "name" happens to be some standard library function. This is -the same as defining it as "name" except that the local alias will be "_name" -rather then "name". -.PP There are a couple of defines which you shouldn't be redefining in the code or other headers. These are SELF, IS_SELF, SELF_CLASS, SELF_TYPE, ARG, VAR, PARENT_HANDLER, GET_NEW, GOB_VERSION_MAJOR, GOB_VERSION_MINOR and @@ -932,7 +1053,7 @@ would be: GtkWidget * new(void) { - return GTK_WIDGET(GET_NEW); + return (GtkWidget *)GET_NEW; } } @@ -946,7 +1067,7 @@ that signal. Sometimes you may need to use an object of type MyObjectA in the MyObjectB class and vice versa. Obviously you can't include headers for both. So you need to just declare the typedef in the header of A for B, and the other way -around as well. The headers generated since v0.92.2 include a protecting +around as well. The headers generated include a protecting define before it declares the typedef. This define is the __TYPEDEF___. So inside my-object-a.h there will be this: @@ -971,30 +1092,30 @@ header. If you are using normal makefiles, what you need to do is to add a generic rule for .gob files. So you would include the following in the Makefile and then just use the .c and .h files as usual (make sure the space -before the 'gob' is a tab, not spaces): +before the 'gob2' is a tab, not spaces): .nf %.c %.h %-private.h: %.gob - gob $< + gob2 $< .fi .SH BUILDING WITH AUTOCONF and AUTOMAKE .PP This is a little bit more involved. Basically the first thing to do is to -check for GOB in your configure.in file. You can use the supplied m4 macro +check for GOB2 in your configure.in file. You can use the supplied m4 macro which will also check the version of gob. Basically you include this: .nf - GOB_CHECK(0.93.4) + GOB2_CHECK(2.0.0) .fi -This will replace @GOB@ in your makefiles with the full path of gob. Thus +This will replace @GOB2@ in your makefiles with the full path of gob2. Thus when adding the generic rule to your Makefile.am file, it should look like: .nf %.c %.h %-private.h: %.gob - @GOB@ $< + @GOB2@ $< .fi .PP @@ -1020,6 +1141,18 @@ Sometimes you might want to know which method you are in for some debugging output. GOB will define __GOB_FUNCTION__ macro, which is just a string constant with a pretty name of the method. +.SH M4 SUPPORT +.PP +It is possible to have your .gob file also preprocessed by m4. This is useful +if you have a lot of files and you'd like to have some preprocessor put in +some common features. All you have to do is add --m4 to the command line +of gob2 and gob2 will first run your file through m4. You can print the +directory that is searched for m4 files by running "gob2 --m4-dir" +.PP +All the arguments after --m4 will be passed to m4 itself, so it has to be the +last gob2 argument on the command line. This way you can specify arbitrary +options to pass to m4. + .SH BUGS .PP The lexer does not actually parse the C code, so I'm sure that some corner @@ -1057,6 +1190,8 @@ There is no real good way we can handle this without parsing C code, so we probably never will. In the future, I might add #if 0 as a comment but that's about as far as I can really take it and even that is problematic. Basically, if you use gob, just don't use the C preprocessor too extensively. +And if you use it make sure that you do not cross the boundaries of the C +code segments. .PP Comments will not get through to the generated files unless inside C code. This is not the case for gtk-doc style comments which are supported. @@ -1069,10 +1204,10 @@ can't use the '&'. Thus: void (*foo)(Self *); /* this will NOT work */ - foo = &short_name; + foo = &self_short_name; /* this will work */ - foo = short_name; + foo = self_short_name; /* Both of these will work */ foo = &my_class_long_name; diff --git a/doc/makehtml.pl b/doc/makehtml.pl index 8b14c5d..5b77ed2 100755 --- a/doc/makehtml.pl +++ b/doc/makehtml.pl @@ -38,8 +38,12 @@ while (<>) { print "\n"; } print "

\n"; + } elsif (/^\.B "(.*)"$/) { + print "$1\n"; } elsif (/^\.B (.*)$/) { print "$1\n"; + } elsif (/^\.I "(.*)"$/) { + print "$1\n"; } elsif (/^\.I (.*)$/) { print "$1\n"; } elsif (/^\.nf/) { diff --git a/examples/Makefile.am b/examples/Makefile.am index b92c413..42fe237 100644 --- a/examples/Makefile.am +++ b/examples/Makefile.am @@ -2,8 +2,7 @@ EXTRA_DIST = \ README \ gtk-button-count.gob \ my-person.gob \ - my-person2.gob \ GNOME_Foo_SomeInterface.idl \ foo-some-interface.gob -SUBDIRS = +SUBDIRS = . diff --git a/examples/Makefile.in b/examples/Makefile.in index efc4320..03db219 100644 --- a/examples/Makefile.in +++ b/examples/Makefile.in @@ -78,10 +78,10 @@ VERSION = @VERSION@ YACC = @YACC@ YFLAGS = @YFLAGS@ -EXTRA_DIST = README gtk-button-count.gob my-person.gob my-person2.gob GNOME_Foo_SomeInterface.idl foo-some-interface.gob +EXTRA_DIST = README gtk-button-count.gob my-person.gob GNOME_Foo_SomeInterface.idl foo-some-interface.gob -SUBDIRS = +SUBDIRS = . mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs CONFIG_HEADER = ../config.h CONFIG_CLEAN_FILES = diff --git a/examples/README b/examples/README index dba804d..228f420 100644 --- a/examples/README +++ b/examples/README @@ -3,20 +3,17 @@ These are some example .gob files gtk-button-count.gob An example showing how simple it is to derive objects and override methods, this one implements a "click counting" on a GtkButton. It defines - an argument for getting and setting the count + a property for getting and setting the count and it overrides the "clicked" default handler to count clicks. It also has inline documentation - in gtk-doc style which gob 0.92.3+ can translate + in gtk-doc style which gob can translate and stuff into the source file for you. my-person.gob A simple file which can store some identity - information about a person, it shows arguments, + information about a person, it shows properties, signals and others. -my-person2.gob The same as above but using automatic initialization, - destruction and argument linking features of 0.93.0+ - GNOME_Foo_SomeInterface.idl -foo-some-interface.gob Example idl and gob file for a BonoboXClass +foo-some-interface.gob Example idl and gob file for a BonoboClass implementation. It can be this easy to write Bonobo classes. diff --git a/examples/foo-some-interface.gob b/examples/foo-some-interface.gob index 40a9473..173f052 100644 --- a/examples/foo-some-interface.gob +++ b/examples/foo-some-interface.gob @@ -3,7 +3,7 @@ * * see GNOME_Foo_SomeInterface.idl */ -requires 1.99.0 +requires 2.0.0 %{ /* some standard includes */ diff --git a/examples/gtk-button-count.gob b/examples/gtk-button-count.gob index 9061c5c..2eee5f2 100644 --- a/examples/gtk-button-count.gob +++ b/examples/gtk-button-count.gob @@ -5,19 +5,26 @@ * which will be correctly translated and put into the resulting source * file */ -class Gtk:Button:Count from Gtk:Button { - public int count; +requires 2.0.0 - argument INT count - get { - ARG = self->count; - } - set { - self->count = ARG; - }; +class Gtk:Button:Count from Gtk:Button { + public int count = 0; + property INT count + (nick = _("Count of clicks"), + blurb = _("How many times was the button clicked"), + minimum = 0, + maximum = INT_MAX, + /* initially set to 0, even though we have already + * set the default above */ + default_value = 0, + /* links the count property to the count data member */ + link); - init(self) + init (self) { + /* Although we have specified the default in two places + * already, this is an example of where else you can put + * initialization */ self->count = 0; } @@ -30,7 +37,7 @@ class Gtk:Button:Count from Gtk:Button { **/ public GtkWidget * - new(void) + new (void) { /* It's ok to use a normal cast here, as we are sure that we * have gotten the right type */ @@ -47,23 +54,25 @@ class Gtk:Button:Count from Gtk:Button { **/ public GtkWidget * - new_with_label(char *label (check null)) onerror NULL + new_with_label (char *label (check null)) onerror NULL { /* It's ok to use a normal cast here, as we are sure that we * have gotten the right type */ GtkWidget *widget = (GtkWidget *)GET_NEW; - GtkWidget *label_widget = gtk_label_new(label); - gtk_container_add(GTK_CONTAINER(widget), label_widget); - gtk_widget_show(label_widget); + GtkWidget *label_widget = gtk_label_new (label); + gtk_container_add (GTK_CONTAINER (widget), label_widget); + gtk_widget_show (label_widget); return widget; } override (Gtk:Button) void - clicked(Gtk:Button *self (check null type)) + clicked (Gtk:Button *self (check null type)) { - GtkButtonCount *bc = GTK_BUTTON_COUNT(self); + GtkButtonCount *bc = GTK_BUTTON_COUNT (self); + /* increase count */ bc->count++; - PARENT_HANDLER(self); + /* runt he parent class handler for clicked */ + PARENT_HANDLER (self); } } diff --git a/examples/my-person.gob b/examples/my-person.gob index d895a62..7f4e9b3 100644 --- a/examples/my-person.gob +++ b/examples/my-person.gob @@ -1,8 +1,8 @@ -requires 0.92.1 - -/* This will work with an older version (0.92.1 specifically), if you want - * to see a version with automatic argument<->datamember linking, automatic - * initialization and destruction, look at my-person2.gob */ +/* + * This file is a basic example of how a .gob file would be constructed, + * how to add data members, properties and methods + */ +requires 2.0.0 %{ #include @@ -10,58 +10,74 @@ requires 0.92.1 #include "my-person-private.h" %} -class My:Person from Gtk:Object { - public char *name; - public long dob; /* date of birth as a time_t */ - public long dod; /* date of death as a time_t */ +class My:Person from G:Object { + /* the name of the person */ + private char *name = {g_strdup(_("Nobody"))} + destroywith g_free; + property STRING name + (nick = _("Name"), + blurb = _("Name of the person"), + default_value = _("Nobody"), + /* Export get/set functions for this property */ + export, + /* link to the data memeber 'name' */ + link); - private int rounds_in_shotgun; /* number of rounds in our shotgun */ - - argument POINTER (type char *) name - get { - /* note that g_strdup handles NULL correctly */ - ARG = g_strdup(self->name); - } - set { - /* note that g_free and g_strdup handles NULL correctly */ - g_free(self->name); - self->name = g_strdup(ARG); - }; + /* date of birth as a time_t */ + private long dob = 0; + property LONG dob + (nick = _("Date of birth"), + blurb = _("Date of birth of the person"), + minimum = 0, + maximum = LONG_MAX, + default_value = 0, + export) + /* We could use 'link' as above, but the code below + * shows how to do this without linking */ + set { + self->_priv->dob = g_value_get_long (VAL); + } + get { + g_value_set_long (VAL, self->_priv->dob); + }; - argument LONG dob get { ARG = self->dob; } set { self->dob = ARG; }; - argument LONG dod get { ARG = self->dod; } set { self->dod = ARG; }; + /* date of death as a time_t */ + private long dod = 0; + property LONG dod + (nick = _("Date of death"), + blurb = _("Date of death of the person"), + minimum = 0, + maximum = LONG_MAX, + default_value = 0, + export, + link); - init(self) - { - self->name = g_strdup("Nobody"); - self->dob = 0; - self->dod = 0; - - /* initially we have no rounds in the shotgun */ - self->_priv->rounds_in_shotgun = 0; - } + /* number of rounds in our shotgun */ + private int rounds_in_shotgun = 0; /* when the person gets born, sends out a signal, the caller of the signal should provide the date of birth */ signal last NONE (LONG) void - birth(self, long dob) + birth (self, long dob) { - self->dob = dob; + g_object_set (G_OBJECT (self), + "dob", dob); } /* when the person dies, sends out a signal, the caller of the signal should provide the date of death */ signal last NONE (LONG) void - death(self, long dod) + death (self, long dod) { - self->dod = dod; + g_object_set (G_OBJECT (self), + "dod", dod); } public void - load_shotgun(self) + load_shotgun (self) { /* add a round to our shotgun */ self->_priv->rounds_in_shotgun++; @@ -69,10 +85,10 @@ class My:Person from Gtk:Object { public void - shoot_oneself_in_the_head(self) + shoot_oneself_in_the_head (self) { - if(self->_priv->rounds_in_shotgun==0) { - g_warning("No rounds in the shotgun!"); + if (self->_priv->rounds_in_shotgun == 0) { + g_warning (_("No rounds in the shotgun!")); return; } @@ -80,21 +96,12 @@ class My:Person from Gtk:Object { self->_priv->rounds_in_shotgun--; /* death is imminent if we shoot oneself in the head */ - death(self, (long)time(NULL)); - } - - /* override the destroy signal where we destroy data we need to free */ - override (Gtk:Object) - void - destroy (Gtk:Object *self (check null type)) - { - g_free(MY_PERSON(self)->name); - PARENT_HANDLER(self); + death (self, (long)time (NULL)); } - public GtkObject * - new(void) + public GObject * + new (void) { - return (GtkObject *)GET_NEW; + return (GObject *)GET_NEW; } } diff --git a/examples/my-person2.gob b/examples/my-person2.gob deleted file mode 100644 index b7f23ed..0000000 --- a/examples/my-person2.gob +++ /dev/null @@ -1,79 +0,0 @@ -requires 0.93.0 - -/* this file requires 0.93.0 as it uses some of the new features to reduce - * typing and generally make it easier to read I think. Of course they're - * optional to use so use the my-person.gob as an example of not using them. - * These include data member initialization, automatic destructor calling - * and automatic argument<->data member linking */ - -%{ -#include -#include "my-person2.h" -#include "my-person2-private.h" -%} - -class My:Person2 from Gtk:Object { - /* the name of the person */ - public char *name = {g_strdup("Nobody")} - destroywith g_free; - argument POINTER name stringlink; - - /* date of birth as a time_t */ - public long dob = 0; - argument LONG dob link; - - /* date of death as a time_t */ - public long dod = 0; - argument LONG dod link; - - /* number of rounds in our shotgun */ - private int rounds_in_shotgun = 0; - - /* when the person gets born, sends out a signal, the caller - of the signal should provide the date of birth */ - signal last NONE (LONG) - void - birth(self, long dob) - { - self->dob = dob; - } - - /* when the person dies, sends out a signal, the caller - of the signal should provide the date of death */ - signal last NONE (LONG) - void - death(self, long dod) - { - self->dod = dod; - } - - public - void - load_shotgun(self) - { - /* add a round to our shotgun */ - self->_priv->rounds_in_shotgun++; - } - - public - void - shoot_oneself_in_the_head(self) - { - if(self->_priv->rounds_in_shotgun==0) { - g_warning("No rounds in the shotgun!"); - return; - } - - /* one round was fired */ - self->_priv->rounds_in_shotgun--; - - /* death is imminent if we shoot oneself in the head */ - death(self, (long)time(NULL)); - } - - public GtkObject * - new(void) - { - return (GtkObject *)GET_NEW; - } -} diff --git a/gob2.spec b/gob2.spec index fdeb3bc..fa4b8bb 100644 --- a/gob2.spec +++ b/gob2.spec @@ -1,4 +1,4 @@ -%define ver 1.99.3 +%define ver 2.0.0 %define rel 1 %define prefix /usr diff --git a/src/Makefile.am b/src/Makefile.am index 27d1d6c..b9d186d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1,6 +1,6 @@ #YACCFLAGS += -d -t YFLAGS = -d -t -SUBDIRS = +SUBDIRS = . CFLAGS = @CFLAGS@ \ -Wall \ diff --git a/src/Makefile.in b/src/Makefile.in index 8146f9b..147104d 100644 --- a/src/Makefile.in +++ b/src/Makefile.in @@ -79,7 +79,7 @@ VERSION = @VERSION@ YACC = @YACC@ YFLAGS = -d -t -SUBDIRS = +SUBDIRS = . CFLAGS = @CFLAGS@ -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -- 2.43.0