+2005-05-25 Mathieu Lacage <mathieu@gnome.org>
+
+ * gobject/tut_*.xml: fix lots of typos,
+ some of which were reported by Leonardo Boshell.
+
2005-05-23 Matthias Clasen <mclasen@redhat.com>
* glib/tmpl/threads.sgml: Point out exceptions to the
<para>
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, <emphasis>Bad Bad Things</emphasis>
will happen.
</para>
<para>
The <type><link linkend="GClosure">GClosure</link></type> 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.
<footnote><para>
In Practice, Closures sit at the boundary of language runtimes: if you are
#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))
</programlisting>
- <note>Stick to the naming <code>klass</code> as <code>class</code> is a registered c++ keyword.</note>
+ <note><simpara>Stick to the naming <varname>klass</varname> as <varname>class</varname> is a registered c++ keyword.</simpara></note>
</para>
<para>
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 ())
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;
}
</row>
<row>
<entry>First call to <function><link linkend="g-type-create-instance">g_type_create_instance</link></function> for target type</entry>
- <entry colspan="2">interface initialization, see
+ <entry>interface initialization, see
<xref linkend="gtype-non-instantiable-classed-init"/></entry>
+ <entry></entry>
</row>
<row>
<entry>Each call to <function><link linkend="g-type-create-instance">g_type_create_instance</link></function> for target type</entry>
</row>
<row>
<entry>Last call to <function><link linkend="g-type-free-instance">g_type_free_instance</link></function> for target type</entry>
- <entry colspan="2">interface destruction, see
+ <entry>interface destruction, see
<xref linkend="gtype-non-instantiable-classed-dest"/></entry>
<entry></entry>
</row>
MAMAN_IBAZ_GET_INTERFACE (self)->do_action (self);
}
</programlisting>
- <function>maman_ibaz_get_gtype</function> registers a type named <emphasis>MamanIBaz</emphasis>
+ <function>maman_ibaz_get_type</function> registers a type named <emphasis>MamanIBaz</emphasis>
which inherits from G_TYPE_INTERFACE. All interfaces must be children of G_TYPE_INTERFACE in the
inheritance tree.
</para>
MamanBarPrivate *priv;
};
</programlisting>
- <note>Do not call this <code>private</code>, as that is a registered c++ keyword.</note>
+ <note><simpara>Do not call this <varname>private</varname>, as that is a registered c++ keyword.</simpara></note>
The private structure is then defined in the .c file, instantiated in the object's
<function>init</function> function and destroyed in the object's <function>finalize</function> function.
<programlisting>
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 */
}
</programlisting>
</para></listitem>
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. <ulink>http://www.cplusplus.com/doc/tutorial/</ulink> to refresh their
+ write C++ code recently can refer to e.g. <ulink url="http://www.cplusplus.com/doc/tutorial/"/> to refresh their
memories.)
<itemizedlist>
<listitem><para>
<figure>
<mediaobject>
<imageobject> <!-- this is for HTML output -->
- <imagedata fileref="glue.png" format="png" align="center"/>
+ <imagedata fileref="glue.png" format="PNG" align="center"/>
</imageobject>
<imageobject> <!-- this is for PDF output -->
- <imagedata fileref="glue.jpg" format="jpg" align="center"/>
+ <imagedata fileref="glue.jpg" format="JPG" align="center"/>
</imageobject>
</mediaobject>
</figure>
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.
</para>
</sect1>
<partintro>
<para>
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.
</para>
</partintro>
<para>
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.
- <ulink url="http://www.5z.com/jirka/gob.html">GOB/</ulink> (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.
+ <ulink url="http://www.5z.com/jirka/gob.html">GOB/</ulink> (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.
</para>
</chapter>
+<chapter id="tools-ginspector">
+ <title>Graphical inspection of Gobjects</title>
+
+ <para>
+ Yet another tool that you may find helpful when working with
+ GObjects is <ulink
+ url="http://sourceforge.net/projects/g-inspector">G-Inspector</ulink>. It
+ is able to display Glib/Gtk+ objects and their properties.
+ </para>
+</chapter>
+
+
<chapter id="tools-refdb">
<title>Debugging reference count problems</title>
<para>
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 a
t a too named <ulink url="http://refdbg.sf.net/">refdbg/</ulink>
+ there exist a
tool named <ulink url="http://refdbg.sf.net/">refdbg/</ulink>
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.
<ulink url="http://developer.gnome.org/arch/doc/authors.html">documentation</ulink>
on how to setup and use gtk-doc in your
project is provided on the gnome developer website.
- gtk-doc generates
</para>
</chapter>
projects / platform / upstream / glib.git / commitdiff