From 8db223409d630e16b741919528543fc71cd844b5 Mon Sep 17 00:00:00 2001 From: Mathieu Lacage Date: Fri, 27 May 2005 12:04:54 +0000 Subject: [PATCH] fix lots of typos, some of which were reported by Leonardo Boshell. 2005-05-25 Mathieu Lacage * gobject/tut_*.xml: fix lots of typos, some of which were reported by Leonardo Boshell. --- docs/reference/ChangeLog | 5 +++++ docs/reference/gobject/tut_gobject.xml | 2 +- docs/reference/gobject/tut_gsignal.xml | 2 +- docs/reference/gobject/tut_gtype.xml | 19 +++++++++--------- docs/reference/gobject/tut_howto.xml | 8 ++++---- docs/reference/gobject/tut_intro.xml | 6 +++--- docs/reference/gobject/tut_tools.xml | 36 ++++++++++++++++++++++------------ 7 files changed, 48 insertions(+), 30 deletions(-) diff --git a/docs/reference/ChangeLog b/docs/reference/ChangeLog index 57dd708..f5c398a 100644 --- a/docs/reference/ChangeLog +++ b/docs/reference/ChangeLog @@ -1,3 +1,8 @@ +2005-05-25 Mathieu Lacage + + * gobject/tut_*.xml: fix lots of typos, + some of which were reported by Leonardo Boshell. + 2005-05-23 Matthias Clasen * glib/tmpl/threads.sgml: Point out exceptions to the diff --git a/docs/reference/gobject/tut_gobject.xml b/docs/reference/gobject/tut_gobject.xml index 638f41f..7a76154 100644 --- a/docs/reference/gobject/tut_gobject.xml +++ b/docs/reference/gobject/tut_gobject.xml @@ -498,7 +498,7 @@ void g_object_run_dispose (GObject *object); The above example, which might seem a bit contrived can really happen if your - GObject's are being by language bindings. I would thus suggest the rules stated above + GObject's are being handled by language bindings. I would thus suggest the rules stated above for object destruction are closely followed. Otherwise, Bad Bad Things will happen. diff --git a/docs/reference/gobject/tut_gsignal.xml b/docs/reference/gobject/tut_gsignal.xml index 3779325..9ab4b6f 100644 --- a/docs/reference/gobject/tut_gsignal.xml +++ b/docs/reference/gobject/tut_gsignal.xml @@ -29,7 +29,7 @@ return_type function_callback (... , gpointer user_data); The GClosure structure represents the common functionality of all - closure implementations: there exist a different Closure implementation for + closure implementations: there exists a different Closure implementation for each separate runtime which wants to use the GObject type system. In Practice, Closures sit at the boundary of language runtimes: if you are diff --git a/docs/reference/gobject/tut_gtype.xml b/docs/reference/gobject/tut_gtype.xml index e3bfc8e..0fabe35 100644 --- a/docs/reference/gobject/tut_gtype.xml +++ b/docs/reference/gobject/tut_gtype.xml @@ -286,7 +286,7 @@ struct _GTypeValueTable #define MAMAN_IS_BAR_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), MAMAN_BAR_TYPE)) #define MAMAN_BAR_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), MAMAN_BAR_TYPE, MamanBarClass)) - Stick to the naming klass as class is a registered c++ keyword. + Stick to the naming klass as class is a registered c++ keyword. @@ -387,13 +387,13 @@ typedef struct { int field_a; } MamanBar; -struct _MamanBarClass { +typedef struct { GObjectClass parent; /* class members */ void (*do_action_public_virtual) (MamanBar *self, guint8 i); void (*do_action_public_pure_virtual) (MamanBar *self, guint8 i); -}; +} MamanBarClass; #define MAMAN_BAR_TYPE (maman_bar_get_type ()) @@ -413,9 +413,9 @@ maman_bar_get_type (void) 0, /* n_preallocs */ (GInstanceInitFunc) NULL /* instance_init */ }; - type = g_type_register_fundamental (G_TYPE_OBJECT, - "BarType", - &info, 0); + type = g_type_register_static (G_TYPE_OBJECT, + "BarType", + &info, 0); } return type; } @@ -609,8 +609,9 @@ The class initialization process is entirely implemented in First call to g_type_create_instance for target type - interface initialization, see + interface initialization, see + Each call to g_type_create_instance for target type @@ -619,7 +620,7 @@ The class initialization process is entirely implemented in Last call to g_type_free_instance for target type - interface destruction, see + interface destruction, see @@ -675,7 +676,7 @@ void maman_ibaz_do_action (MamanIbaz *self) MAMAN_IBAZ_GET_INTERFACE (self)->do_action (self); } - maman_ibaz_get_gtype registers a type named MamanIBaz + maman_ibaz_get_type registers a type named MamanIBaz which inherits from G_TYPE_INTERFACE. All interfaces must be children of G_TYPE_INTERFACE in the inheritance tree. diff --git a/docs/reference/gobject/tut_howto.xml b/docs/reference/gobject/tut_howto.xml index a03c87e..1f32337 100644 --- a/docs/reference/gobject/tut_howto.xml +++ b/docs/reference/gobject/tut_howto.xml @@ -164,20 +164,20 @@ struct _MamanBar { MamanBarPrivate *priv; }; - Do not call this private, as that is a registered c++ keyword. + Do not call this private, as that is a registered c++ keyword. The private structure is then defined in the .c file, instantiated in the object's init function and destroyed in the object's finalize function. static void maman_bar_finalize(GObject *object) { MamanBar *self = MAMAN_BAR (object); - ... + /* do stuff */ g_free (self->priv); } static void maman_bar_init(GTypeInstance *instance, gpointer g_class) { MamanBar *self = MAMAN_BAR (instance); self->priv = g_new0(MamanBarPrivate,1); - ... + /* do stuff */ } @@ -495,7 +495,7 @@ if (self->private->dispose_has_run) { Just as with C++, there are many different ways to define object methods and extend them: the following list and sections draw on C++ vocabulary. (Readers are expected to know basic C++ buzzwords. Those who have not had to - write C++ code recently can refer to e.g. http://www.cplusplus.com/doc/tutorial/ to refresh their + write C++ code recently can refer to e.g. to refresh their memories.) diff --git a/docs/reference/gobject/tut_intro.xml b/docs/reference/gobject/tut_intro.xml index fdd58fb..a353e9b 100644 --- a/docs/reference/gobject/tut_intro.xml +++ b/docs/reference/gobject/tut_intro.xml @@ -148,10 +148,10 @@ boundaries is written once: the figure below states this more clearly.
- + - +
@@ -165,7 +165,7 @@ is no need to generate huge amounts of glue code either automatically or by hand the whole GType/GObject library. C programmers are likely to be puzzled at the complexity of the features exposed in the following chapters if they forget that the GType/GObject library was not only designed to offer OO-like features to C programmers but also transparent -cross-langage interoperability. +cross-language interoperability. diff --git a/docs/reference/gobject/tut_tools.xml b/docs/reference/gobject/tut_tools.xml index a68e318..0fd0fe6 100644 --- a/docs/reference/gobject/tut_tools.xml +++ b/docs/reference/gobject/tut_tools.xml @@ -1,7 +1,7 @@ Several useful developer tools have been build around GObject technology. - Next sections briefly introduce them and link to the respective project pages. + The next sections briefly introduce them and link to the respective project pages. @@ -10,26 +10,39 @@ Writing gobjects can be a tedious task. It requires a lot of typing and just - doing copy and paste needs care. On obvious idea is to use some sort of - templates for the class skelletons. Then a tool could generate the real c - files from them. - GOB/ (or GOB2) is suc - h a tool. It is a preprocessor for making GObjects with inline C code so - that generated files are not edited. - Syntax is inspired by Java and Yacc or Lex. The implementation is - intentionally kept simple, and no C actual code parsing is done. + doing a copy/paste requires a great deal of care. + One obvious idea is to use some sort of templates for the class skeletons. + and then run them through a special tool to generate the real C files. + GOB/ (or GOB2) is such + a tool. It is a preprocessor which can be used to build GObjects + with inline C code so that there is no need to edit the generated C code. + The syntax is inspired by Java and Yacc or Lex. The implementation is + intentionally kept simple: the inline C code provided by the user + is not parsed. + + Graphical inspection of Gobjects + + + Yet another tool that you may find helpful when working with + GObjects is G-Inspector. It + is able to display Glib/Gtk+ objects and their properties. + + + + Debugging reference count problems The reference counting scheme used by GObject does solve quite a few memory management problems but also introduces new sources of bugs. - In large applications, finding the exact spot where a the reference count + In large applications, finding the exact spot where the reference count of an Object is not properly handled can be very difficult. Hopefully, - there exist at a too named refdbg/ + there exist a tool named refdbg/ which can be used to automate the task of tracking down the location of invalid code with regard to reference counting. This application intercepts the reference counting calls and tries to detect invalid behavior. @@ -71,6 +84,5 @@ gtk_widget_freeze_child_notify (GtkWidget *widget) documentation on how to setup and use gtk-doc in your project is provided on the gnome developer website. - gtk-doc generates -- 2.7.4