luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-05-29 17:00:06 +02:00
Code Issues Packages Projects Releases Wiki Activity

fix lots of typos, some of which were reported by Leonardo Boshell.

Browse Source 
2005-05-25  Mathieu Lacage <mathieu@gnome.org>

	* gobject/tut_*.xml: fix lots of typos,
	some of which were reported by Leonardo Boshell.
This commit is contained in:
Mathieu Lacage 2005-05-27 12:04:54 +00:00 committed by Mathieu Lacage
parent 1397c53eb7
commit 8db223409d
7 changed files with 48 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
docs/reference/ChangeLog
View File

@ -1,3 +1,8 @@
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

2
docs/reference/gobject/tut_gobject.xml
View File

@ -498,7 +498,7 @@ void g_object_run_dispose (GObject *object);
<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>

2
docs/reference/gobject/tut_gsignal.xml
View File

@ -29,7 +29,7 @@ return_type function_callback (... , gpointer user_data);
<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

19
docs/reference/gobject/tut_gtype.xml
View File

@ -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))
</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>
@ -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",
&amp;info, 0);
type = g_type_register_static (G_TYPE_OBJECT,
"BarType",
&amp;info, 0);
}
return type;
}
@ -609,8 +609,9 @@ The class initialization process is entirely implemented in
</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>
@ -619,7 +620,7 @@ The class initialization process is entirely implemented in
</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>
@ -675,7 +676,7 @@ void maman_ibaz_do_action (MamanIbaz *self)
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>

8
docs/reference/gobject/tut_howto.xml
View File

@ -164,20 +164,20 @@ struct _MamanBar {
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>
@ -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. <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>

6
docs/reference/gobject/tut_intro.xml
View File

@ -148,10 +148,10 @@ boundaries is written once: the figure below states this more clearly.
<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>
@ -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.
</para>
</sect1>

36
docs/reference/gobject/tut_tools.xml
View File

@ -1,7 +1,7 @@
<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>
@ -10,26 +10,39 @@
<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 at 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.
@ -71,6 +84,5 @@ gtk_widget_freeze_child_notify (GtkWidget *widget)
<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>