RubyGems - gio2 - Versions diffs - 0.90.5-x86-mingw32 → 0.90.6-x86-mingw32 - Mend

gio2 0.90.5-x86-mingw32 → 0.90.6-x86-mingw32

Files changed (830) hide show

data/vendor/local/share/gtk-doc/html/gobject/howto-gobject-methods.html DELETED

@@ -1,257 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<title>Object methods</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.75.2">
-<link rel="home" href="index.html" title="GObject Reference Manual">
-<link rel="up" href="howto-gobject.html" title="How to define and implement a new GObject">
-<link rel="prev" href="howto-gobject-destruction.html" title="Object Destruction">
-<link rel="next" href="howto-gobject-chainup.html" title="Chaining up">
-<meta name="generator" content="GTK-Doc V1.15.1 (XML mode)">
-<link rel="stylesheet" href="style.css" type="text/css">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="2"><tr valign="middle">
-<td><a accesskey="p" href="howto-gobject-destruction.html"><img src="left.png" width="24" height="24" border="0" alt="Prev"></a></td>
-<td><a accesskey="u" href="howto-gobject.html"><img src="up.png" width="24" height="24" border="0" alt="Up"></a></td>
-<td><a accesskey="h" href="index.html"><img src="home.png" width="24" height="24" border="0" alt="Home"></a></td>
-<th width="100%" align="center">GObject Reference Manual</th>
-<td><a accesskey="n" href="howto-gobject-chainup.html"><img src="right.png" width="24" height="24" border="0" alt="Next"></a></td>
-</tr></table>
-<div class="sect1">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="howto-gobject-methods"></a>Object methods</h2></div></div></div>
-<p>
-      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.
-      <a class="ulink" href="http://www.cplusplus.com/doc/tutorial/" target="_top">http://www.cplusplus.com/doc/tutorial/</a> to refresh
-      their memories.)
-      </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-            non-virtual public methods,
-          </p></li>
-<li class="listitem"><p>
-            virtual public methods and
-          </p></li>
-<li class="listitem"><p>
-            virtual private methods
-          </p></li>
-</ul></div>
-<p>
-    </p>
-<div class="sect2">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id458520"></a>Non-virtual public methods</h3></div></div></div>
-<p>
-        These are the simplest: you want to provide a simple method which
-        can act on your object. All you need to do is to provide a function
-        prototype in the header and an implementation of that prototype
-        in the source file.
-</p>
-<pre class="programlisting">
-/* declaration in the header. */
-void maman_bar_do_action (MamanBar *self, /* parameters */);
-/* implementation in the source file */
-void
-maman_bar_do_action (MamanBar *self, /* parameters */)
-{
-  g_return_if_fail (MAMAN_IS_BAR (self));
-  /* do stuff here. */
-}
-</pre>
-<p>
-      </p>
-<p>There is really nothing scary about this.</p>
-</div>
-<div class="sect2">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id458545"></a>Virtual public methods</h3></div></div></div>
-<p>
-        This is the preferred way to create polymorphic GObjects. All you
-        need to do is to define the common method and its class function in
-        the public header, implement the common method in the source file
-        and re-implement the class function in each object which inherits
-        from you.
-</p>
-<pre class="programlisting">
-/* declaration in maman-bar.h. */
-struct _MamanBarClass
-{
-  GObjectClass parent_class;
-  /* stuff */
-  void (*do_action) (MamanBar *self, /* parameters */);
-};
-void maman_bar_do_action (MamanBar *self, /* parameters */);
-/* implementation in maman-bar.c */
-void
-maman_bar_do_action (MamanBar *self, /* parameters */)
-{
-  g_return_if_fail (MAMAN_IS_BAR (self));
-  MAMAN_BAR_GET_CLASS (self)-&gt;do_action (self, /* parameters */);
-}
-</pre>
-<p>
-        The code above simply redirects the do_action call to the relevant
-        class function. Some users, concerned about performance, do not
-        provide the <code class="function">maman_bar_do_action</code> wrapper function
-        and require users to dereference the class pointer themselves. This
-        is not such a great idea in terms of encapsulation and makes it
-        difficult to change the object's implementation afterwards, should
-        this be needed.
-      </p>
-<p>
-        Other users, also concerned by performance issues, declare
-        the <code class="function">maman_bar_do_action</code> function inline in the
-        header file. This, however, makes it difficult to change the
-        object's implementation later (although easier than requiring users
-        to directly dereference the class function) and is often difficult
-        to write in a portable way (the <span class="emphasis"><em>inline</em></span> keyword
-        is part of the C99 standard but not every compiler supports it).
-      </p>
-<p>
-        In doubt, unless a user shows you hard numbers about the performance
-        cost of the function call, just implement <code class="function">maman_bar_do_action</code>
-        in the source file.
-      </p>
-<p>
-        Please, note that it is possible for you to provide a default
-        implementation for this class method in the object's
-        <code class="function">class_init</code> function: initialize the
-        klass-&gt;do_action field to a pointer to the actual implementation.
-        You can also make this class method pure virtual by initializing
-        the klass-&gt;do_action field to NULL:
-</p>
-<pre class="programlisting">
-static void
-maman_bar_real_do_action_two (MamanBar *self, /* parameters */)
-{
-  /* Default implementation for the virtual method. */
-}
-static void
-maman_bar_class_init (BarClass *klass)
-{
-  /* pure virtual method: mandates implementation in children. */
-  klass-&gt;do_action_one = NULL;
-  /* merely virtual method. */
-  klass-&gt;do_action_two = maman_bar_real_do_action_two;
-}
-void
-maman_bar_do_action_one (MamanBar *self, /* parameters */)
-{
-  g_return_if_fail (MAMAN_IS_BAR (self));
-  MAMAN_BAR_GET_CLASS (self)-&gt;do_action_one (self, /* parameters */);
-}
-void
-maman_bar_do_action_two (MamanBar *self, /* parameters */)
-{
-  g_return_if_fail (MAMAN_IS_BAR (self));
-  MAMAN_BAR_GET_CLASS (self)-&gt;do_action_two (self, /* parameters */);
-}
-</pre>
-<p>
-      </p>
-</div>
-<div class="sect2">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="id458629"></a>Virtual private Methods</h3></div></div></div>
-<p>
-        These are very similar to Virtual Public methods. They just don't
-        have a public function to call the function directly. The header
-        file contains only a declaration of the class function:
-</p>
-<pre class="programlisting">
-/* declaration in maman-bar.h. */
-struct _MamanBarClass
-{
-  GObjectClass parent;
-  /* stuff */
-  void (* helper_do_specific_action) (MamanBar *self, /* parameters */);
-};
-void maman_bar_do_any_action (MamanBar *self, /* parameters */);
-</pre>
-<p>
-        These class functions are often used to delegate part of the job
-        to child classes:
-</p>
-<pre class="programlisting">
-/* this accessor function is static: it is not exported outside of this file. */
-static void
-maman_bar_do_specific_action (MamanBar *self, /* parameters */)
-{
-  MAMAN_BAR_GET_CLASS (self)-&gt;do_specific_action (self, /* parameters */);
-}
-void
-maman_bar_do_any_action (MamanBar *self, /* parameters */)
-{
-  /* random code here */
-  /*
-   * Try to execute the requested action. Maybe the requested action
-   * cannot be implemented here. So, we delegate its implementation
-   * to the child class:
-   */
-  maman_bar_do_specific_action (self, /* parameters */);
-  /* other random code here */
-}
-</pre>
-<p>
-      </p>
-<p>
-        Again, it is possible to provide a default implementation for this
-        private virtual class function:
-</p>
-<pre class="programlisting">
-static void
-maman_bar_class_init (MamanBarClass *klass)
-{
-  /* pure virtual method: mandates implementation in children. */
-  klass-&gt;do_specific_action_one = NULL;
-  /* merely virtual method. */
-  klass-&gt;do_specific_action_two = maman_bar_real_do_specific_action_two;
-}
-</pre>
-<p>
-      </p>
-<p>
-        Children can then implement the subclass with code such as:
-</p>
-<pre class="programlisting">
-static void
-maman_bar_subtype_class_init (MamanBarSubTypeClass *klass)
-{
-  MamanBarClass *bar_class = MAMAN_BAR_CLASS (klass);
-  /* implement pure virtual class function. */
-  bar_class-&gt;do_specific_action_one = maman_bar_subtype_do_specific_action_one;
-}
-</pre>
-<p>
-      </p>
-</div>
-</div>
-<div class="footer">
-<hr>
-          Generated by GTK-Doc V1.15.1</div>
-</body>
-</html>

data/vendor/local/share/gtk-doc/html/gobject/howto-gobject.html DELETED

@@ -1,283 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<title>How to define and implement a new GObject</title>
-<meta name="generator" content="DocBook XSL Stylesheets V1.75.2">
-<link rel="home" href="index.html" title="GObject Reference Manual">
-<link rel="up" href="pt02.html" title="Part IV. Tutorial">
-<link rel="prev" href="pt02.html" title="Part IV. Tutorial">
-<link rel="next" href="howto-gobject-code.html" title="Boilerplate code">
-<meta name="generator" content="GTK-Doc V1.15.1 (XML mode)">
-<link rel="stylesheet" href="style.css" type="text/css">
-</head>
-<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
-<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="2"><tr valign="middle">
-<td><a accesskey="p" href="pt02.html"><img src="left.png" width="24" height="24" border="0" alt="Prev"></a></td>
-<td><a accesskey="u" href="pt02.html"><img src="up.png" width="24" height="24" border="0" alt="Up"></a></td>
-<td><a accesskey="h" href="index.html"><img src="home.png" width="24" height="24" border="0" alt="Home"></a></td>
-<th width="100%" align="center">GObject Reference Manual</th>
-<td><a accesskey="n" href="howto-gobject-code.html"><img src="right.png" width="24" height="24" border="0" alt="Next"></a></td>
-</tr></table>
-<div class="chapter">
-<div class="titlepage"><div><div><h2 class="title">
-<a name="howto-gobject"></a>How to define and implement a new GObject</h2></div></div></div>
-<div class="toc"><dl>
-<dt><span class="sect1"><a href="howto-gobject.html#howto-gobject-header">Boilerplate header code</a></span></dt>
-<dt><span class="sect1"><a href="howto-gobject-code.html">Boilerplate code</a></span></dt>
-<dt><span class="sect1"><a href="howto-gobject-construction.html">Object Construction</a></span></dt>
-<dt><span class="sect1"><a href="howto-gobject-destruction.html">Object Destruction</a></span></dt>
-<dt><span class="sect1"><a href="howto-gobject-methods.html">Object methods</a></span></dt>
-<dd><dl>
-<dt><span class="sect2"><a href="howto-gobject-methods.html#id458520">Non-virtual public methods</a></span></dt>
-<dt><span class="sect2"><a href="howto-gobject-methods.html#id458545">Virtual public methods</a></span></dt>
-<dt><span class="sect2"><a href="howto-gobject-methods.html#id458629">Virtual private Methods</a></span></dt>
-</dl></dd>
-<dt><span class="sect1"><a href="howto-gobject-chainup.html">Chaining up</a></span></dt>
-</dl></div>
-<p>
-    Clearly, this is one of the most common questions people ask: they just
-    want to crank code and implement a subclass of a GObject. Sometimes because
-    they want to create their own class hierarchy, sometimes because they want
-    to subclass one of GTK+'s widget. This chapter will focus on the
-    implementation of a subtype of GObject.
-  </p>
-<div class="sect1">
-<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="howto-gobject-header"></a>Boilerplate header code</h2></div></div></div>
-<p>
-      The first step before writing the code for your GObject is to write the
-      type's header which contains the needed type, function and macro
-      definitions. Each of these elements is nothing but a convention which
-      is followed not only by GTK+'s code but also by most users of GObject.
-      If you feel the need not to obey the rules stated below, think about it
-      twice:
-      </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>If your users are a bit accustomed to GTK+ code or any
-        GLib code, they will be a bit surprised and getting used to the
-        conventions you decided upon will take time (money) and will make them
-        grumpy (not a good thing)</p></li>
-<li class="listitem"><p>You must assess the fact that these conventions might
-        have been designed by both smart and experienced people: maybe they
-        were at least partly right. Try  to put your ego aside.</p></li>
-</ul></div>
-<p>
-    </p>
-<p>
-      Pick a name convention for your headers and source code and stick to it:
-      </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>use a dash to separate the prefix from the typename:
-        <code class="filename">maman-bar.h</code> and <code class="filename">maman-bar.c</code>
-        (this is the convention used by Nautilus and most GNOME libraries).</p></li>
-<li class="listitem"><p>use an underscore to separate the prefix from the
-        typename: <code class="filename">maman_bar.h</code> and
-        <code class="filename">maman_bar.c</code>.</p></li>
-<li class="listitem"><p>Do not separate the prefix from the typename:
-        <code class="filename">mamanbar.h</code> and <code class="filename">mamanbar.c</code>.
-        (this is the convention used by GTK+)</p></li>
-</ul></div>
-<p>
-      I personally like the first solution better: it makes reading file names
-      easier for those with poor eyesight like me.
-    </p>
-<p>
-      When you need some private (internal) declarations in several
-      (sub)classes, you can define them in a private header file which
-      is often named by appending the <span class="emphasis"><em>private</em></span> keyword
-      to the public header name. For example, one could use
-      <code class="filename">maman-bar-private.h</code>,
-      <code class="filename">maman_bar_private.h</code> or
-      <code class="filename">mamanbarprivate.h</code>. Typically, such private header
-      files are not installed.
-    </p>
-<p>
-      The basic conventions for any header which exposes a GType are described
-      in <a class="xref" href="gtype-conventions.html" title="Conventions">the section called “Conventions”</a>. Most GObject-based code also
-      obeys one of of the following conventions: pick one and stick to it.
-      </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem">
-<p>
-            If you want to declare a type named bar with prefix maman, name the type instance
-            <code class="function">MamanBar</code> and its class <code class="function">MamanBarClass</code>
-            (name is case-sensitive). It is customary to declare them with code similar to the
-            following:
-</p>
-<pre class="programlisting">
-/*
- * Copyright/Licensing information.
- */
-/* inclusion guard */
-#ifndef __MAMAN_BAR_H__
-#define __MAMAN_BAR_H__
-#include &lt;glib-object.h&gt;
-/*
- * Potentially, include other headers on which this header depends.
- */
-/*
- * Type macros.
- */
-#define MAMAN_TYPE_BAR                  (maman_bar_get_type ())
-#define MAMAN_BAR(obj)                  (G_TYPE_CHECK_INSTANCE_CAST ((obj), MAMAN_TYPE_BAR, MamanBar))
-#define MAMAN_IS_BAR(obj)               (G_TYPE_CHECK_INSTANCE_TYPE ((obj), MAMAN_TYPE_BAR))
-#define MAMAN_BAR_CLASS(klass)          (G_TYPE_CHECK_CLASS_CAST ((klass), MAMAN_TYPE_BAR, MamanBarClass))
-#define MAMAN_IS_BAR_CLASS(klass)       (G_TYPE_CHECK_CLASS_TYPE ((klass), MAMAN_TYPE_BAR))
-#define MAMAN_BAR_GET_CLASS(obj)        (G_TYPE_INSTANCE_GET_CLASS ((obj), MAMAN_TYPE_BAR, MamanBarClass))
-typedef struct _MamanBar        MamanBar;
-typedef struct _MamanBarClass   MamanBarClass;
-struct _MamanBar
-{
-  GObject parent_instance;
-  /* instance members */
-};
-struct _MamanBarClass
-{
-  GObjectClass parent_class;
-  /* class members */
-};
-/* used by MAMAN_TYPE_BAR */
-GType maman_bar_get_type (void);
-/*
- * Method definitions.
- */
-#endif /* __MAMAN_BAR_H__ */
-</pre>
-<p>
-          </p>
-</li>
-<li class="listitem">
-<p>
-            Most GTK+ types declare their private fields in the public header
-            with a /* private */ comment, relying on their user's intelligence
-            not to try to play with these fields. Fields not marked private
-            are considered public by default. The /* protected */ comment
-            (same semantics as those of C++) is also used, mainly in the GType
-            library, in code written by Tim Janik.
-</p>
-<pre class="programlisting">
-struct _MamanBar
-{
-  GObject parent_instance;
-  /*&lt; private &gt;*/
-  int hsize;
-};
-</pre>
-<p>
-          </p>
-</li>
-<li class="listitem">
-<p>
-            All of Nautilus code and a lot of GNOME libraries use private
-            indirection members, as described by Herb Sutter in his Pimpl
-            articles(see <a class="ulink" href="http://www.gotw.ca/gotw/024.htm" target="_top">Compilation Firewalls</a>
-            and <a class="ulink" href="http://www.gotw.ca/gotw/028.htm" target="_top">The Fast Pimpl Idiom</a>:
-            he summarizes the different issues better than I will).
-</p>
-<pre class="programlisting">
-typedef struct _MamanBarPrivate MamanBarPrivate;
-struct _MamanBar
-{
-  GObject parent_instance;
-  /*&lt; private &gt;*/
-  MamanBarPrivate *priv;
-};
-</pre>
-<p>
-            </p>
-<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
-<h3 class="title">Note</h3>
-<p>Do not call this <code class="varname">private</code>, as
-            that is a registered c++ keyword.</p>
-</div>
-<p>
-            The private structure is then defined in the .c file, using the
-            g_type_class_add_private() function to notify the presence of
-            a private memory area for each instance and it can either
-            be retrieved using <code class="function">G_TYPE_INSTANCE_GET_PRIVATE()</code>
-            each time is needed, or assigned to the <code class="literal">priv</code>
-            member of the instance structure inside the object's
-            <code class="function">init</code> function.
-</p>
-<pre class="programlisting">
-#define MAMAN_BAR_GET_PRIVATE(obj) (G_TYPE_INSTANCE_GET_PRIVATE ((obj), MAMAN_TYPE_BAR, MamanBarPrivate))
-struct _MamanBarPrivate
-{
-  int hsize;
-}
-static void
-maman_bar_class_init (MamanBarClass *klass)
-{
-  g_type_class_add_private (klass, sizeof (MamanBarPrivate));
-}
-static void
-maman_bar_init (MamanBar *self)
-{
-  MamanBarPrivate *priv;
-  self-&gt;priv = priv = MAMAN_BAR_GET_PRIVATE (self);
-  priv-&gt;hsize = 42;
-}
-</pre>
-<p>
-          </p>
-</li>
-<li class="listitem"><p>
-            You don't need to free or allocate the private structure, only the
-            objects or pointers that it may contain. Another advantage of this
-            to the previous version is that is lessens memory fragmentation,
-            as the public and private parts of the instance memory are
-            allocated at once.
-          </p></li>
-</ul></div>
-<p>
-    </p>
-<p>
-      Finally, there are different header include conventions. Again, pick one
-      and stick to it. I personally use indifferently any of the two, depending
-      on the codebase I work on: the rule, as always, is consistency.
-      </p>
-<div class="itemizedlist"><ul class="itemizedlist" type="disc">
-<li class="listitem"><p>
-            Some people add at the top of their headers a number of #include
-            directives to pull in all the headers needed to compile client
-            code. This allows client code to simply #include "maman-bar.h".
-          </p></li>
-<li class="listitem"><p>
-            Other do not #include anything and expect the client to #include
-            themselves the headers they need before including your header. This
-            speeds up compilation because it minimizes the amount of
-            pre-processor work. This can be used in conjunction with the
-            re-declaration of certain unused types in the client code to
-            minimize compile-time dependencies and thus speed up compilation.
-          </p></li>
-</ul></div>
-<p>
-    </p>
-</div>
-</div>
-<div class="footer">
-<hr>
-          Generated by GTK-Doc V1.15.1</div>
-</body>
-</html>