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

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

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>