<?xml version="1.0"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" 
  "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
  <!ENTITY url_refdocs_base_glib_html "../../../../glibmm-2.4/docs/reference/html/">
  <!ENTITY url_refdocs_base_glib "../../../../glibmm-2.4/docs/reference/html/classGlib_1_1">
  <!ENTITY url_refdocs_base_gtk_html "../../reference/html/">
  <!ENTITY url_refdocs_base_gtk "../../reference/html/classGtk_1_1">
  <!ENTITY url_refdocs_base_gtk_namespace "../../reference/html/namespaceGtk_1_1">
  <!ENTITY url_figures_base "../figures/"> 
  <!ENTITY path_examples_base "../../examples/book/">
  <!ENTITY url_examples_base "../&path_examples_base;">
  <!ENTITY gtkmm "<application>gtkmm</application>">
  <!ENTITY uuml "&#252;" >
  <!ENTITY szlig "&#223;" >
  <!ENTITY verbar "&#124;" >
  <!ENTITY copy "&#169;" >
]>

<!--
NOTE TO TUTORIAL DOCUMENTATION AUTHORS:
When referring to the gtkmm project in this document, please use the form
&gtkmm; so that the name is consistent throughout the document.  This will wrap
gtkmm with <application></application> tags which can then be styled by CSS if
desired (e.g. boldface, monospace, etc) to make it stand out as the project
name
-->

<book>

  <bookinfo>

    <title>Programming with &gtkmm;</title>

    <authorgroup>
      <author>
        <firstname>Murray</firstname>
        <surname>Cumming</surname>
      </author>
      <author>
        <firstname>Bernhard</firstname>
        <surname>Rieder</surname>
        <contrib>Chapter on &quot;Timeouts&quot;.</contrib>
      </author>
      <author>
        <firstname>Jonathon</firstname>
        <surname>Jongsma</surname>
        <contrib>Chapter on &quot;Drawing with Cairo&quot;.</contrib>
        <contrib>Chapter on &quot;Working with CVS&quot;.</contrib>
        <contrib>Chapter on &quot;Recent Files&quot;.</contrib>
      </author>
      <author>
        <firstname>Jason</firstname>
        <surname>M'Sadoques</surname>
        <contrib>Chapter on &quot;Drawing Area&quot;.</contrib>
      </author>
      <author>
        <firstname>Ole</firstname>
        <surname>Laursen</surname>
        <contrib>Parts of chapter on &quot;Internationalization&quot;.</contrib>
      </author>
      <author>
        <firstname>Gene</firstname>
        <surname>Ruebsamen</surname>
        <contrib>Chapter on &quot;Win32 Installation&quot;.</contrib>
      </author>
      <author>
        <firstname>Cedric</firstname>
        <surname>Gustin</surname>
        <contrib>Chapter on &quot;Win32 Installation&quot;.</contrib>
      </author>
      <author>
        <firstname>Marko</firstname>
        <surname>Anastasov</surname>
        <contrib>Chapter on &quot;Printing&quot;.</contrib>
        <contrib>Parts of chapter on &quot;Internationalization&quot;.</contrib>
      </author>
      <author>
        <firstname>Alan</firstname>
        <surname>Ott</surname>
        <contrib>Appendix on &quot;Visual Studio 2005.&quot;.</contrib>
        </author>
    </authorgroup>

    <abstract>

      <para>
        We very much appreciate any reports of inaccuracies or other errors in
        this document.  Contributions are also most welcome.  Post your
        suggestions, critiques or addenda to the <ulink
          url="mailto:gtkmm-list@gnome.org">&gtkmm; mailing list</ulink> -- The
        &gtkmm; Development Team
      </para>

    </abstract>

    <copyright>
      <year>2002-2006</year>
      <holder>Murray Cumming</holder>
    </copyright>

    <legalnotice>
      <para>
        Permission is granted to copy, distribute and/or modify this document
        under the terms of the GNU Free Documentation License, Version 1.2
        or any later version published by the Free Software Foundation;
        with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
        You may obtain a copy of the GNU Free Documentation License from the Free Software Foundation by visiting their Web site or by writing to: Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
      </para>
    </legalnotice>

  </bookinfo>

<chapter id="sec-introduction">
<title>Introduction</title>

<sect1>
<title>This book</title>

<para>This book assumes a good
understanding of C++, and how to create C++ programs.
</para>

<para>This book attempts to explain key &gtkmm; concepts and introduce some of the more commonly used user interface elements ("widgets"). Although it mentions classes, constructors, and methods, it does not go into great detail. For full API information you should follow the links into the reference documentation.</para>

<para>
This document is a work in progress. You can find updates on the
<ulink url="http://www.gtkmm.org/">&gtkmm; home page</ulink>.
</para>

<para>
We would very much like to hear of any problems you have learning &gtkmm;
with this document, and would appreciate input regarding improvements. Please see the <link linkend="sec-Contributing">Contributing</link> section for further information.
</para>
</sect1>

<sect1 id="sec-gtkmm">
<title>gtkmm</title>
<para>
&gtkmm; is a C++ wrapper for 
<ulink url="http://www.gtk.org/">GTK+</ulink>, 
a library used to create graphical user
interfaces. It is licensed using the LGPL license, so you can develop
open software, free software, or even commercial non-free software
using &gtkmm; without purchasing licenses.
</para>
<para>&gtkmm; was originally named gtk-- because GTK+ already has a + in the name. However, as -- is not easily indexed by search engines the package generally went by the name &gtkmm;, and that's what we stuck with.</para>

<sect2>
<title>Why use &gtkmm; instead of GTK+?</title>
<para>&gtkmm; allows you to write code using normal C++ techniques such as encapsulation, derivation, and polymorphism. As a C++ programmer you probably already realise that this leads to clearer and better organised code.</para>
<para>&gtkmm; is more type-safe, so the compiler can detect errors that would only be detected at run time when using C. This use of specific types also makes the API clearer because you can see what types should be used just by looking at a method's declaration.</para>
<para>Inheritance can be used to derive new widgets. The derivation of new widgets in GTK+ C code is so complicated and error prone that almost no C coders do it. As a C++ developer you know that derivation is an essential Object Orientated technique.</para>
<para>Member instances can be used, simplifying memory management. All GTK+ C widgets are dealt with by use of pointers. As a C++ coder you know that pointers should be avoided where possible.</para>
<para>&gtkmm; involves less code compared to GTK+, which uses prefixed function names and lots of cast macros.</para>
</sect2>

<sect2>
<title>&gtkmm; compared to QT</title>
<para>Trolltech's QT is the closest competition to &gtkmm;, so it deserves discussion.</para>

<para>&gtkmm; developers tend to prefer &gtkmm; to QT because &gtkmm; does things in a more C++ way. QT originates from a time when C++ and the standard library were not standardised or well supported by compilers. It therefore duplicates a lot of stuff that is now in the standard library, such as containers and type information. Most significantly, Trolltech modified the C++ language to provide signals, so that QT classes can not be used easily with non-QT classes. &gtkmm; was able to use standard C++ to provide signals without changing the C++ language. See the FAQ for more detailed differences.</para>
</sect2>

<sect2>
<title>&gtkmm; is a wrapper</title>
<para>
&gtkmm; is not a native C++ toolkit, but a C++ wrapper of a C toolkit. This separation of interface and implementation has advantages. The &gtkmm; developers spend most of their time talking about how &gtkmm; can present the clearest API, without awkward compromises due to obscure technical details. We contribute a little to the underlying GTK+ code base, but so do the C coders, and the Perl coders and the Python coders, etc. Therefore GTK+ benefits from a broader user base than language-specific toolkits - there are more implementers, more developers, more testers, and more users.</para>
<para>Microsoft's MFC has given GUI wrapper libraries a bad name, but &gtkmm; doesn't suffer from the same problems because GTK+ is written in high quality object-orientated C, with language-bindings in mind.</para>
</sect2>
</sect1>

</chapter>

<chapter id="sec-installation">
<title>Installation</title>
<sect1>
<title>Dependencies</title>
<para>
  Before attempting to install &gtkmm; 2.4, you might first need to install these other
  packages.
</para>
<itemizedlist>
  <listitem><para><application>libsigc++ 2.0</application></para></listitem>
  <listitem><para><application>GTK+ 2.4</application></para></listitem>
  <listitem><para><application>cairomm</application></para></listitem>
</itemizedlist>
<para>
These dependencies have their own dependencies, including the following
applications and libraries:
</para>
<itemizedlist>
  <listitem><para><application>pkg-config</application></para></listitem>
  <listitem><para><application>glib</application></para></listitem>
  <listitem><para><application>ATK</application></para></listitem>
  <listitem><para><application>Pango</application></para></listitem>
  <listitem><para><application>cairo</application></para></listitem>
</itemizedlist>
</sect1>

<sect1 id="sec-install_unix_and_linux">
<title>Unix and Linux</title>

<sect2 id="sec-linux-install-from-packages">
<title>Prebuilt Packages</title>

<para>
    Recent versions of &gtkmm; are packaged by nearly every major Linux
    distribution these days.  So, if you use Linux, you can probably get
    started with &gtkmm; by installing the package from the official repository
    for your distribution.  Distributions that include &gtkmm; in their
    repositories include Debian, Ubuntu, Red Hat, Fedora, Mandriva, Suse, and
    many others.
</para>
<para>
    The names of the &gtkmm; packages vary from distribution to distribution
    (e.g. <application>libgtkmm2.4-dev</application> on Debian and Ubuntu or
    <application>gtkmm24-devel</application> on Red Hat Fedora), so check with
    your distribution's package management program for the correct package name
    and install it like you would any other package.
</para>
<note>
<para>
The package names will not change when new API/ABI-compatible versions of &gtkmm; 
are released. Otherwise they would not be API/ABI-compatible. So don't be
surprised, for instance, to find &gtkmm; 2.8 supplied by Debian's
<application>libgtkmm2.4-dev</application> package.
</para>  
</note>
</sect2>

<sect2 id="sec-install_from_source">
<title>Installing From Source</title>

<para>
If your distribution does not provide a pre-built &gtkmm; package, or if you
want to install a different version than the one provided by your distribution,
you can also install &gtkmm; from source.  The source code for &gtkmm; can
be downloaded from <ulink url="http://www.gtkmm.org/"></ulink>. 
</para>
<para>
  After you've installed all of the dependencies, download the &gtkmm; source
  code, unpack it, and change to the newly created directory. &gtkmm; can be
  built and installed with the following sequence of commands:
</para>
<screen>
# ./configure
# make
# make install
</screen>
<note>
<para>
  Remember that on a Unix or Linux operating system, you will probably need to
  be <literal>root</literal> to install software. The <command>su</command>
  command will allow you to enter the <literal>root</literal> password and have
  <literal>root</literal> status temporarily.
</para>
</note>
<para>
    The <filename>configure</filename> script will check to make sure all of
    the required dependencies are already installed.  If you are missing any
    dependencies, it will exit and display an error.
</para>
<para>
    By default, &gtkmm; will be installed under the
    <filename>/usr/local</filename> directory. On some systems you may need to
    install to a different location.  For instance, on Red Hat Linux systems
    you might use the <literal>--prefix</literal> option with configure, like
    so:
<screen>
# ./configure --prefix=/usr
</screen>
</para>
<warning>
    <para>
        You should be very careful when installing to standard system prefixes
        such as <filename>/usr</filename>. Linux distributions install software
        packages to <filename>/usr</filename>, so installing a source package
        to this prefix could corrupt or conflict with software installed using
        your distribution's package-management system.  Ideally, you should use
        a separate prefix for all software you install from source.
    </para>
</warning>
<para>
  If you want to help develop &gtkmm; or experiment with new features, you can
  also install &gtkmm; from CVS.  Most users will never need to do this, but if
  you're interested in helping with &gtkmm; development, see the <link
    linkend="sec-appendix_working_with_cvs">Working with CVS</link> appendix.
</para>
</sect2>

</sect1>

<sect1 id="sec-packages_windows">
<title>Microsoft Windows</title>
<para>GTK+ and &gtkmm; were designed to work well with Microsoft Windows, and the developers encourage its use on the win32 platform.  However, Windows has no standard installation system for development libraries. Please see the <link linkend="sec-windows-installation">Windows Installation</link>
appendix for Windows-specific installation instructions and notes.</para>
</sect1>

</chapter>

<chapter id="sec-basics">
<title>Basics</title>

<para>
This chapter will introduce some of the most important aspects of &gtkmm; coding. These will be demonstrated with simple working example code. However, this is just a taster, so you need to look at the other chapters for more substantial information.
</para>
<para>
Your existing knowledge of C++ will help you with &gtkmm; as it would with any library. Unless we state otherwise, you can expect &gtkmm; classes to behave like any other C++ class, and you can expect to use your existing C++ techniques with &gtkmm; classes.
</para>

<sect1>
<title>Simple Example</title>

<para>
To begin our introduction to &gtkmm;, we'll start with the simplest
program possible. This program will create an empty 200 x 200 pixel window.
</para>

<para>
Source location: examples/base/base.cc
</para>

<programlisting>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
  href="../../examples/base/base.cc" parse="text"/>
</programlisting>

<para>We will now explain each line of the example</para>
<programlisting>#include &lt;gtkmm.h&gt;</programlisting>
<para>
All &gtkmm; programs must include certain &gtkmm; headers; <literal>gtkmm.h</literal>
includes the entire &gtkmm; kit. This is usually not a good idea, because
it includes a megabyte or so of headers, but for simple programs, it
suffices.
</para>

<para>
The next line:

<programlisting>Gtk::Main kit(argc, argv);</programlisting>

creates a <classname>Gtk::Main</classname> object.  This is needed in all &gtkmm;
applications. The constructor for this object initializes &gtkmm;,  and checks the
arguments passed to your application on the command line, looking for
standard options such as <literal>-display</literal>. It takes these from the argument list, leaving anything it does not
recognize for your application to parse or ignore.  This ensures 
that all &gtkmm; applications accept the same set of standard arguments.
</para>

<para>
The next two lines of code create and display a window:
</para>
<programlisting>Gtk::Window window;</programlisting>
<para>
The last line shows the window and enters the &gtkmm; main processing loop, which will finish when the window is closed.
</para>

<programlisting>Gtk::Main::run(window);</programlisting>

<para>
After putting the source code in <literal>simple.cc</literal> you can compile the above program with gcc using:
<programlisting>g++ simple.cc -o simple `pkg-config gtkmm-2.4 --cflags --libs`</programlisting>
Note that you must surround
the <literal>pkg-config</literal> invocation with backquotes.  
Backquotes cause the shell to execute the command inside them, and to use 
the command's output as part of the command line.
</para>
</sect1>

<sect1 id="sec-headers_and_linking">
<title>Headers and Linking</title>
<para>
Although we have shown the compilation command for the simple example, you really should use the automake and autoconf tools, as described in "Autoconf, Automake, Libtool", by G. V. Vaughan et al. The examples used in this book are included in the &gtkmm; package, with appropriate build files, so we won't show the build commands in future. You'll just need to find the appropriate directory and type <literal>make</literal>.
</para>
<para>
To simplify compilation, we use <literal>pkg-config</literal>, which
is present in all (properly installed) &gtkmm; installations.  This
program 'knows' what compiler switches are needed to compile programs
that use &gtkmm;.  The <literal>--cflags</literal> option causes
<literal>pkg-config</literal> to output a list of include directories for the
compiler to look in; the <literal>--libs</literal> option requests the
list of libraries for the compiler to link with and the directories to
find them in. Try running it from your shell-prompt to see the results on your system.
</para>
<para>
However, this is even simpler when using the <function>PKG_CHECK_MODULES()</function> macro in a standard configure.ac file with autoconf and automake.
For instance:
<programlisting>PKG_CHECK_MODULES([MYAPP], [gtkmm-2.4 >= 2.8.0])</programlisting>
This checks for the presence of gtkmm and defines MYAPP_LIBS and MYAPP_CFLAGS for use in your Makefile.am files.
</para>
<para>gtkmm-2.4 is the name of the current stable API. There was an older API called gtkmm-2-0 which installs in parallel when it is available. There are several versions of gtkmm-2.4, such as gtkmm 2.10. Note that the API name does not change for every version because that would be an incompatible API and ABI break. Theoretically, there might be a future gtkmm-3.0 API which would install in parallel with gtkmm-2.4 without affecting existing applications.
</para>

<para>Note that if you mention extra modules in addition to gtkmm-2.4, they should be separated by spaces, not commas. 
</para>
<para>
Openismus has more <ulink url="http://www.openismus.com/documents/linux/automake/automake.shtml">basic help with automake and autoconf</ulink>. 
</para>

</sect1>

<sect1 id="sec-widgets">
<title>Widgets</title>
<para>&gtkmm; applications consist of windows containing widgets, such as buttons and text boxes. In some other systems, widgets are called "controls". For each widget in your application's windows, there is a C++ object in your application's code. So you just need to call a method of the widget's class to affect the visible widget.</para>
 <para>Widgets are arranged inside container widgets such as frames and notebooks, in a hierarchy of widgets within widgets. Some of these container widgets, such as Gtk::VBox, are not visible - they exist only to arrange other widgets. Here is some example code that adds 2 Gtk::Button widgets to a Gtk::VBox container widgets:
<programlisting>m_box.pack_start(m_Button1);
m_box.pack_start(m_Button2);</programlisting>
and here is how to add the Gtk::VBox, containing those buttons, to a Gtk::Frame, which has a visible frame and title:
<programlisting>m_frame.add(m_box);</programlisting>
</para>
<para>
Most of the chapters in this book deal with specific widgets. See the <link linkend="sec-ContainerWidgets">Container Widgets</link> section for more details about adding widgets to container widgets.
</para>

<para>Although you can specify the layout and appearance of windows and widgets with C++ code, you will probably find it more convenient to design your user interfaces with <literal>Glade</literal> and load them at runtime with <literal>libglademm</literal>. See the <link linkend="sec-libglademm">Glade and libglademm</link> chapter.
</para>

<para>Although &gtkmm; widget instances have lifetimes and scopes just like those of other C++ classes, &gtkmm; has an optional time-saving feature that you will see in some of the examples. <function>Gtk::manage()</function> allows you to say that a child widget is owned by the container into which you place it. This is allows you to <function>new()</function> the widget, add it to the container and forget about deleting it. You can learn more about &gtkmm; memory management techniques in the <link linkend="sec-Memory">Memory Management chapter</link>.
</para>

</sect1>

<sect1 id="sec-signals">
<title>Signals</title>

<para>
&gtkmm;, like most GUI toolkits, is <emphasis>event-driven</emphasis>. When an event occurs, such as the press of a mouse
button, the appropriate signal will be <emphasis>emitted</emphasis> by the Widget
that was pressed. Each Widget has a different set of signals that it can emit. To make a
button click result in an action, we set up a
<emphasis>signal handler</emphasis> to catch the button's "clicked" signal.
</para>
<para>&gtkmm; uses the libsigc++ library to implement signals. Here is an example line of code that connects a Gtk::Button's "clicked" signal with a signal handler called "on_button_clicked":
<programlisting>m_button1.signal_clicked().connect( sigc::mem_fun(*this,
  &amp;HelloWorld::on_button_clicked) );</programlisting>
</para>

<para>For more detailed information about signals, see the <link linkend="sec-appendix-signals">appendix</link>.</para> 
<para>For information about implementing your own signals rather than
just connecting to the existing &gtkmm; signals, see the <link linkend="sec-appendix-custom_signals">appendix</link>.</para> 

</sect1>

<sect1 id="sec-basics-ustring">
<title>Glib::ustring</title>
<para>You might be surprised to learn that &gtkmm; doesn't use <classname>std::string</classname> in it its interfaces. Instead it uses <classname>Glib::ustring</classname>, which is so similar and unobtrusive that you could actually pretend that each Glib::ustring is a <classname>std::string</classname> and ignore the rest of this section. But read on if you want to use languages other than English in your application.</para>
<para>std::string uses 8 bit per character, but 8 bits aren't enough to encode languages such as Arabic, Chinese, and Japanese. Although the encodings for these languages has now been specified by the Unicode Constortium, the C and C++ languages do not yet provide any standardised Unicode support. GTK+ and GNOME chose to implement Unicode using UTF-8, and that's what is wrapped by Glib::ustring. It provides almost exactly the same interface as std::string, along with automatic conversions to and from std::string.</para>
<para>One of the benefits of UTF-8 is that you don't need to use it unless you want to, so you don't need to retrofit all of your code at once. <classname>std::string</classname> will still work for 7-bit ASCII strings. But when you try to localize your application for languages like Chinese, for instance, you will start to see strange errors, and possible crashes. Then all you need to do is start using <classname>Glib::ustring</classname> instead.</para>
<para>Note that UTF-8 isn't compatible with 8-bit encodings like ISO-8859-1. For instance, German umlauts are not in the ASCII range and need more than 1 byte in the UTF-8 encoding. If your code contains 8-bit string literals, you have to convert them to UTF-8 (e.g. the Bavarian greeting "Gr&uuml;&szlig; Gott" would be "Gr\xC3\xBC\xC3\x9F Gott").</para>
<para>You should avoid C-style pointer arithmetic, and functions such as strlen(). In UTF-8, each character might need anywhere from 1 to 6 bytes, so it's not possible to assume that the next byte is another character. <classname>Glib::ustring</classname> worries about the details of this for you so you can use methods such as Glib::ustring::substr() while still thinking in terms of characters instead of bytes.</para>

<para>Unlike the Windows UCS-2 Unicode solution, this does not require any special compiler options to process string literals, and it does not result in Unicode executables and libraries which are incompatible with ASCII ones.</para>

<para><ulink url="&url_refdocs_base_glib;ustring.html">Reference</ulink></para>

<para>See the <link linkend="sec-internationalization">Internationalization</link> section for information about providing the UTF-8 string literals.</para> 

</sect1>

<sect1 id="sec-intermediatetypes">
<title>Intermediate types</title>
<para>Some parts of the &gtkmm; API use intermediate data containers, such as <classname>Glib::StringArrayHandle</classname> instead of a specific Standard C++ container such as <classname>std::vector</classname> or <classname>std::list</classname>. You should not declare these types yourself -- you should use whatever Standard C++ container you prefer instead. &gtkmm; will do the conversion for you. Here are some of these intermediate types:
<itemizedlist>
	<listitem><para>Glib::StringArrayHandle or Glib::ArrayHandle&lt;Glib::ustring&gt;: Use std::vector&lt;Glib::ustring&gt;, std::list&lt;Glib::ustring&gt;, const char*[], etc.</para></listitem>
<listitem><para>Glib::ListHandle&lt;Gtk::Widget*&gt;: Use std::vector&lt;Gtk::Widget*&gt;, std::list&lt;Gtk::Widget*&gt;, etc.</para></listitem>
<listitem><para>Glib::SListHandle&lt;Gtk::Widget*&gt;: Use std::vector&lt;Gtk::Widget*&gt;, std::list&lt;Gtk::Widget*&gt;, etc.</para></listitem>
</itemizedlist>

</para>

</sect1>

<sect1 id="sec-helloworld">
<title>Hello World in &gtkmm;</title>

<para>
We've now learned enough to look at a real example.  In accordance with an ancient
tradition of computer science, we now introduce Hello World, a la &gtkmm;:
</para>

<para><ulink url="&url_examples_base;helloworld">Source Code</ulink></para>

<para>
Try to compile and run it before going on. You should see something like this:
</para>

<figure id="figure-helloworld">
  <title>Hello World</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;helloworld.png"/>
  </screenshot>
</figure>

<para>
Pretty thrilling, eh?  Let's examine the code.  First, the
<classname>HelloWorld</classname> class:
</para>

<programlisting>class HelloWorld : public Gtk::Window
{

public:
  HelloWorld();
  virtual ~HelloWorld();

protected:
  //Signal handlers:
  virtual void on_button_clicked();

  //Member widgets:
  Gtk::Button m_button;
};</programlisting>

<para>
This class implements the "Hello World" window.  It's derived from
<classname>Gtk::Window</classname>, and has a single <classname>Gtk::Button</classname> as a member.
We've chosen to use the
constructor to do all of the initialisation work for the window,
including setting up the signals.  Here it is, with the comments
omitted:
</para>

<programlisting>HelloWorld::HelloWorld()
:
  m_button ("Hello World")
{
  set_border_width(10);
  m_button.signal_clicked().connect(sigc::mem_fun(*this,
    &amp;HelloWorld::on_button_clicked));
  add(m_button);.
  m_button.show();
}</programlisting>

<para>
Notice that we've used an initialiser statement to give the <literal>m_button</literal>
object the label &quot;Hello World&quot;.
</para>

<para>
Next we call the Window's <function>set_border_width()</function> method.  This sets
the amount of space between the sides of the window and the widget it
contains.
</para>

<para>
We then hook up a signal handler to <literal>m_button</literal>'s <literal>clicked</literal> signal.
This prints our friendly greeting to <literal>stdout</literal>.
</para>

<para>
Next, we use the Window's <function>add()</function> method to put <literal>m_button</literal> in
the Window.  (<function>add()</function> comes from <classname>Gtk::Container</classname>, which is
described in the chapter on container widgets.)  The <function>add()</function> method
places the Widget in the Window, but it doesn't display
the widget.  &gtkmm; widgets are always invisible when you create them - to display them, you must call their <function>show()</function> method, which
is what we do in the next line.
</para>


<para>
Now let's look at our program's <function>main()</function> function.  Here it is,
without comments:
</para>

<programlisting>int main(int argc, char** argv)
{
  Gtk::Main kit(argc, argv);

  HelloWorld helloworld;
  Gtk::Main::run(helloworld);

  return 0;
}</programlisting>

<para>
First we instantiate an object called <literal>kit</literal>. This is of type
<classname>Gtk::Main</classname>.  Every &gtkmm; program must have one of these.  We pass
our command-line arguments to its constructor. It takes the arguments
it wants, and leaves you the rest, as we described earlier.
</para>

<para>
Next we make an object of our <classname>HelloWorld</classname> class, whose constructor
takes no arguments, but it isn't visible yet. When we call Gtk::Main::run(), giving it the helloworld Window, it shows the Window and starts the &gtkmm; <emphasis>event loop</emphasis>. During the event loop &gtkmm; idles, waiting for actions from the user, and responding appropriately. When the user closes the Window, run() will return, causing the final line of our main() function be to executed. The application will then finish.
</para>

</sect1>
</chapter>


<chapter id="sec-buttonwidget">
<title>Buttons</title>

<para>
&gtkmm; provides four basic types of buttons:
</para>

<variablelist>

<varlistentry>
<term>Push-Buttons</term>
<listitem>
<para>
<ulink url="&url_refdocs_base_gtk;Button.html"><classname>Gtk::Button</classname></ulink>. Standard buttons, usually
marked with a label or picture. Pushing one triggers an action.  See the <link linkend="sec-Pushbuttons">Button</link> section.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Toggle buttons</term>
<listitem>
<para>
<ulink url="&url_refdocs_base_gtk;ToggleButton.html"><classname>Gtk::ToggleButton</classname></ulink>.
Unlike a normal Button, which springs back up, a ToggleButton stays down until you
press it again. It might be useful as an on/off switch.  See the <link linkend="sec-Toggle-Buttons">ToggleButton</link> section.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Checkboxes</term>
<listitem>
<para>
<ulink url="&url_refdocs_base_gtk;CheckButton.html"><classname>Gtk::CheckButton</classname></ulink>.
These act like ToggleButtons, but show their state in small squares,
with their label at the side. They should be used in most situations
which require an on/off setting.  
See the <link linkend="sec-Checkboxes">CheckBox</link> section.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Radio buttons</term>
<listitem>
<para>
<ulink url="&url_refdocs_base_gtk;RadioButton.html"><classname>Gtk::RadioButton</classname></ulink>.
Named after the station selectors on old car
radios, these buttons are used in groups for options which are
mutually exclusive. Pressing one causes all the
others in its group to turn off.  They are similar to
CheckBoxes (a small widget with a label at the side), but usually
look different.
See the <link linkend="sec-Radio-Buttons">RadioButton</link> section.
</para>
</listitem>
</varlistentry>
</variablelist>

<para>
Note that, due to GTK+'s theming system, the appearance of these
widgets will vary.  In the case of checkboxes and radio buttons, they
may vary considerably.
</para>

<sect1 id="sec-Pushbuttons">
<title>Button</title>

<sect2><title>Constructors</title>

<para>
There are two ways to create a Button. You can specify a label
string in the <classname>Gtk::Button</classname> constructor,
or set it later with <function>set_label()</function>.
</para>

<para>To define an accelerator key for keyboard navigation, place an underscore before one of the label's characters and specify <literal>true</literal> for the optional <literal>mnemonic</literal> parameter. For instance:
</para>
<programlisting>Gtk::Button* pButton = new Gtk::Button("_Something", true);</programlisting>

<para>
Wherever possible you should use Stock items, to ensure consistency with other applications, and to improve the appearance of your applications by using icons. For instance,
<programlisting>Gtk::Button* pButton = new Gtk::Button(Gtk::Stock::OK);</programlisting>
This will use standard text, in all languages, with standard keyboard accelerators, with a standard icon.
</para>

<para>
<classname>Gtk::Button</classname> is also
a container so you could put any other widget, such as a
<classname>Gtk::Image</classname> into it.
</para>

<para><ulink url="&url_refdocs_base_gtk;Button.html">Reference</ulink></para>
</sect2>

<sect2><title>Example</title>

<para>
This example creates a button with a picture and a label.
</para>

<figure id="figure-buttons">
  <title>buttons example</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;buttons.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;buttons/button">Source Code</ulink></para>

<para>
Note that the <classname>XPMLabelBox</classname> class can be used to place XPMs and
labels into any widget that can be a container.
</para>
</sect2>

<sect2><title>Signals</title>

<para>
The <classname>Gtk::Button</classname> widget has the following signals, but most of the time you will just handle the <literal>clicked</literal> signal:
</para>

<para>
<variablelist>

<varlistentry>
<term><literal>pressed</literal></term>
<listitem>
<para>
Emitted when the button is pressed.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>released</literal></term>
<listitem>
<para>
Emitted when the button is released.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>clicked</literal></term>
<listitem>
<para>
Emitted when the button is pressed and released.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>enter</literal></term>
<listitem>
<para>
Emitted when the mouse pointer moves over the button's window.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>leave</literal></term>
<listitem>
<para>
Emitted when the mouse pointer leaves the button's window.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

</sect2>
</sect1>

<sect1 id="sec-Toggle-Buttons">
<title>ToggleButton</title>

<para><classname>ToggleButton</classname>s are like normal <classname>Button</classname>s, but when clicked they remain activated, or pressed,  until clicked again.</para>

<para>
To retrieve the state of the <classname>ToggleButton</classname>, you can use the 
<function>get_active()</function> method. This returns <literal>true</literal> if the button
is "down". You can also set the toggle button's state, with <function>set_active()</function>. Note that, if you do this, and the state actually changes, it causes the
"clicked" signal to be emitted.  This is usually what you want.
</para>

<para>
You can use the <function>toggled()</function> method to toggle the button, rather than
forcing it to be up or down: This switches the button's state, and causes the <literal>toggled</literal> signal to be emitted.
</para>

<para>
<classname>Gtk::ToggleButton</classname> is most useful as a base class for the
<classname>Gtk::CheckButton</classname> and
<classname>Gtk::RadioButton</classname> classes.
</para>

<para><ulink url="&url_refdocs_base_gtk;ToggleButton.html">Reference</ulink></para>

</sect1>

<sect1 id="sec-Checkboxes">
<title>CheckButton</title>

<para>
<classname>Gtk::CheckButton</classname> inherits from
<classname>Gtk::ToggleButton</classname>.  The only real difference between the
two is <classname>Gtk::CheckButton</classname>'s
appearance. You can check, set, and toggle a checkbox using the same
member methods as for <classname>Gtk::ToggleButton</classname>.
</para>

<para><ulink url="&url_refdocs_base_gtk;CheckButton.html">Reference</ulink></para>

<sect2><title>Example</title>

<figure id="figure-checkbutton">
  <title>CheckButton</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;checkbutton.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;buttons/checkbutton">Source Code</ulink></para>
</sect2>

</sect1>

<sect1 id="sec-Radio-Buttons">
<title>RadioButton</title>

<para>
Like checkboxes, radio buttons also inherit from
<classname>Gtk::ToggleButton</classname>, but these work in groups, and only
one RadioButton in a group can be selected at any one time.
</para>

<sect2><title>Groups</title>
<para>
There are two ways to set up a group of radio buttons.  The first way
is to create the buttons, and set up their groups afterwards.  Only
the first two constructors are used.  In the following example, we
make a new window class called <classname>RadioButtons</classname>, and then
put three radio buttons in it:
</para>

<programlisting>class RadioButtons : public Gtk::Window
{
public:
    RadioButtons();

protected:
    Gtk::RadioButton m_rb1, m_rb2, m_rb3;
};

RadioButtons::RadioButtons()
  : m_rb1("button1"),
    m_rb2("button2"),
    m_rb3("button3")
{
    Gtk::RadioButton::Group group = m_rb1.get_group();
    m_rb2.set_group(group);
    m_rb3.set_group(group);
}</programlisting>
<para>
We told &gtkmm; to put all three <classname>RadioButton</classname>s in the
same group by obtaining the group with <function>get_group()</function> and using
<function>set_group()</function> to tell the other
<classname>RadioButton</classname>s to share that group.
</para>

<para>
Note that you can't just do
<programlisting>m_rb2.set_group(m_rb1.get_group()); //doesn't work</programlisting>
because the group is modified by <function>set_group()</function> and therefore
non-const.
</para>


<para>
The second way to set up radio buttons is to make a group first, and
then add radio buttons to it.  Here's an example:
</para>
<programlisting>class RadioButtons : public Gtk::Window
{
public:
    RadioButtons();
};

RadioButtons::RadioButtons()
{
    Gtk::RadioButton::Group group;
    Gtk::RadioButton *m_rb1 = Gtk::manage(
      new Gtk::RadioButton(group,"button1"));
    Gtk::RadioButton *m_rb2 = manage(
      new Gtk::RadioButton(group,"button2"));
      Gtk::RadioButton *m_rb3 = manage(
        new Gtk::RadioButton(group,"button3"));
}</programlisting>

<para>
We made a new group by simply declaring a variable, <literal>group</literal>,
of type <classname>Gtk::RadioButton::Group</classname>.  Then we made three radio
buttons, using a constructor to make each of them part of
<literal>group</literal>.
</para>
</sect2>

<sect2><title>Methods</title>
<para>
<classname>RadioButtons</classname> are "off" when created; this means that
when you first make a group of them, they will all be off. Don't forget to turn
one of them on using <function>set_active()</function>:
</para>

<para><ulink url="&url_refdocs_base_gtk;RadioButton.html">Reference</ulink></para>

</sect2>

<sect2><title>Example</title>
<para>
The following example demonstrates the use of
<classname>RadioButton</classname>s:
</para>

<figure id="figure-radiobutton">
  <title>RadioButton</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;radiobuttons.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;buttons/radiobutton">Source Code</ulink></para>

</sect2>

</sect1>

</chapter>


<chapter id="sec-Range-Widgets">
<title>Range Widgets</title>

<para>
<classname>Gtk::Scale</classname> and <classname>Gtk::Scrollbar</classname>
both inherit from <classname>Gtk::Range</classname> and share much
functionality. They contain a "trough" and a "slider" (sometimes called a
"thumbwheel" in other GUI environments). Dragging the slider with the pointer
moves it within the trough, while clicking in the trough advances the slider
towards the location of the click, either completely, or by a designated
amount, depending on which mouse button is used. This should be familiar
scrollbar behaviour.
</para>

<para>
As will be explained in the <link linkend="sec-Adjustment">Adjustment</link>
section, all Range widgets are associated with a
<classname>Adjustment</classname> object. To change the lower, upper, and
current values used by the widget you need to use the methods of its
<classname>Adjustment</classname>, which you can get with the
<function>get_adjustment()</function> method. The <classname>Range</classname>
widgets' default constructors create an <classname>Adjustment</classname>
automatically, or you can specify an existing
<classname>Adjustment</classname>, maybe to share it with another widget. See
the <link linkend="sec-Adjustment">Adjustments</link> section for further
details.
</para>

<para><ulink url="&url_refdocs_base_gtk;Range.html">Reference</ulink></para>

<sect1>
<title>Scrollbar Widgets</title>

<para>
These are standard scrollbars. They should be used only to scroll another
widget, such as, a <classname>Gtk::Entry</classname>, or a
<classname>Gtk::Viewport</classname>, though it's usually easier to use the
<classname>Gtk::ScrolledWindow</classname> widget in most cases.
</para>

<para>
There are horizontal and vertical scrollbar classes -
<classname>Gtk::HScrollbar</classname> and
<classname>Gtk::VScrollbar</classname>.
</para>

<para><ulink url="&url_refdocs_base_gtk;Scrollbar.html">Reference</ulink></para>

</sect1>

<sect1 id="sec-scale_widgets">
<title>Scale Widgets</title>

<para>
<classname>Gtk::Scale</classname> widgets (or "sliders") allow the user to
visually select and manipulate a value within a specific range. You
might use one, for instance, to adjust the
magnification level on a zoomed preview of a picture, or to control
the brightness of a colour, or to specify the number of minutes of
inactivity before a screensaver takes over the screen.
</para>

<para>
As with <classname>Scrollbar</classname>s, there are separate widget types for
horizontal and vertical widgets - <classname>Gtk::HScale</classname> and
<classname>Gtk::VScale</classname>. The default constructors create an
<classname>Adjustment</classname> with all of its values set to
<literal>0.0</literal>. This isn't useful so you will need to set some
<classname>Adjustment</classname> details to get meaningful behaviour. 
</para>

<sect2>
<title>Useful methods</title>

<para>
<classname>Scale</classname> widgets can display their current value as a number
next to the trough. By default they show the value, but you can change this
with the <function>set_draw_value()</function> method.
</para>

<para>
The value displayed by a scale widget is rounded to one decimal point
by default, as is the <literal>value</literal> field in its
<classname>Gtk::Adjustment</classname>. You can change this with the
<function>set_digits()</function> method.
</para>

<para>
Also, the value can be drawn in different positions relative to the trough,
specified by the <function>set_value_pos()</function> method.
</para>

<para><ulink url="&url_refdocs_base_gtk;Scale.html">Reference</ulink></para>

</sect2>
</sect1>

<sect1 id="sec-update_policies">
<title>Update Policies</title>

<para>
The <emphasis>update policy</emphasis> of a <classname>Range</classname> widget
defines at what points during user interaction it will change the
<literal>value</literal> field of its <classname>Gtk::Adjustment</classname> and
emit the <literal>value_changed</literal> signal. The update policies,
set with the <function>set_update_policy()</function> method, are:

<itemizedlist>
<listitem>

<para>
<literal>Gtk::UPDATE_CONTINUOUS</literal> - This is the default. The
<literal>value_changed</literal> signal is emitted continuously, i.e. whenever the
slider is moved by even the tiniest amount.
</para>
</listitem>
<listitem>

<para>
<literal>Gtk::UPDATE_DISCONTINUOUS</literal> - The <literal>value_changed</literal> signal is
only emitted once the slider has stopped moving and the user has
released the mouse button.
</para>
</listitem>
<listitem>

<para>
<literal>Gtk::UPDATE_DELAYED</literal> - The <literal>value_changed</literal> signal is emitted
when the user releases the mouse button, or if the slider stops moving
for a short period of time.
</para>
</listitem>

</itemizedlist>

</para>
</sect1>

<sect1 id="sec-Range-Example">
<title>Example</title>

<para>
This example displays a window with three range widgets all connected
to the same adjustment, along with a couple of controls for adjusting
some of the parameters mentioned above and in the section on
adjustments, so you can see how they affect the way these widgets work
for the user.
</para>

<figure id="figure-range_widgets">
  <title>Range Widgets</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;range_widgets.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;range_widgets">Source Code</ulink></para>

</sect1>

</chapter>

<chapter id="sec-miscwidgets">
<title>Miscellaneous Widgets</title>

<sect1 id="sec-Labels">
<title>Label</title>

<para>
Labels are the  main method of placing non-editable text in windows, for
instance to place a title next to a <classname>Entry</classname> widget. You
can specify the text in the constructor, or with the
<function>set_text()</function> method.
</para>

<para>
The width of the label will be adjusted automatically.  You can produce multi-line labels by putting line breaks ("\n") in the label string.
</para>

<para>
The label text can be justified using the <function>set_justify()</function>
method. The widget is also capable of word-wrapping - this can be activated
with <function>set_line_wrap()</function>.
</para>

<para>
TODO: gtkmm2: markup.
</para>

<para><ulink url="&url_refdocs_base_gtk;Label.html">Reference</ulink></para>

<sect2><title>Example</title>
<para>
Below is a short example to illustrate these functions. This example
makes use of the Frame widget to better demonstrate the label styles.
 (The Frame widget is explained in the <link linkend="sec-Frame">Frame</link> section.)
</para>

<figure id="figure-label">
  <title>Label</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;label.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;label">Source Code</ulink></para>

</sect2>

</sect1>

<sect1 id="sec-TextEntries">
<title>Entry</title>

<para>
Entry widgets allow the user to enter text (surprisingly
enough).
</para>

<para>
You can change the contents with the <function>set_text()</function> method,
and read the current contents with the <function>get_text()</function> method.
</para>

<para>
Occasionally you might want to make an <classname>Entry</classname> widget
read-only.  This can be done by passing <literal>false</literal> to the
<function>set_editable()</function> method.
</para>

<para>
For the input of passwords, passphrases and other information you don't want
echoed on the screen,  calling <function>set_visibility()</function> with
<literal>false</literal> will cause the text to be hidden.
</para>

<para>
You might want to be notified whenever the user types in a text entry widget.
<classname>Gtk::Entry</classname> provides two signals,
<literal>activate</literal> and <literal>changed</literal>, for just this
purpose.  <literal>activate</literal> is emitted when the user presses the
enter key in a text-entry widget; <literal>changed</literal> is emitted when
the text in the widget changes.  You can use these, for instance, to validate
or filter the text the user types.
</para>

<para><ulink url="&url_refdocs_base_gtk;Entry.html">Reference</ulink></para>

<sect2><title>Example</title>
<para>
Here is an example using <classname>Gtk::Entry</classname>.  As well as a
<classname>Gtk::Entry</classname> widget, it has two
<classname>CheckButton</classname>s, with which you can toggle the editable and
visible flags.
</para>

<figure id="figure-entry">
  <title>Entry</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;entry.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;entry">Source Code</ulink></para>

</sect2>

</sect1>

<sect1 id="sec-Spinbuttons">
<title>SpinButton</title>

<para>
A <classname>SpinButton</classname> allows the user to select a value from a
range of numeric values. It has an Entry widget with up and down arrow buttons
at the side. Clicking the buttons causes the value to 'spin' up and down across
the range of possible values. The <classname>Entry</classname> widget may also
be used to enter a value directly.
</para>

<para>
The value can have an adjustable number of decimal places, and the step size is
configurable. <classname>SpinButton</classname>s have an 'auto-repeat' feature
as well: holding down one of the arrows can optionally cause the value to
change more quickly the longer the arrow is held down.
</para>

<para>
<classname>SpinButton</classname>s use an <link
    linkend="sec-Adjustment">Adjustment</link> object to hold information about
the range of values. These Adjustment attributes are used by the Spin Button
like so:
<itemizedlist>
<listitem>

<para>
 <literal>value</literal>: value for the Spin Button
</para>
</listitem>
<listitem>

<para>
 <literal>lower</literal>: lower range value
</para>
</listitem>
<listitem>

<para>
 <literal>upper</literal>: upper range value
</para>
</listitem>
<listitem>
<para>
 <literal>step_increment</literal>: value to increment/decrement when pressing
mouse button 1 on a button
</para>
</listitem>
<listitem>

<para>
 <literal>page_increment</literal>: value to increment/decrement when pressing
mouse button 2 on a button
</para>
</listitem>
<listitem>

<para>
 <literal>page_size</literal>: unused
</para>
</listitem>

</itemizedlist>
</para>

<para>
Additionally, mouse button 3 can be used to jump directly to the
<literal>upper</literal> or <literal>lower</literal> values.
</para>

<para>
The <classname>SpinButton</classname> can create a default
<classname>Adjustment</classname>, which you can access via the
<function>get_adjustment()</function> method, or you can specify an existing
<classname>Adjustment</classname> in the constructor.
</para>


<sect2><title>Methods</title>

<para>
The number of decimal places can be altered using the
<function>set_digits()</function> method.
</para>

<para>
You can set the spinbutton's value using the <function>set_value()</function>
method, and retrieve it with <function>get_value()</function>.
</para>

<para>
The <function>spin()</function> method 'spins' the
<classname>SpinButton</classname>, as if one of its arrows had been clicked.
You need to specify a <classname>Gtk::SpinType</classname> to specify the
direction or new position.
</para>

<para>
To prevent the user from typing non-numeric characters into the entry box, pass
<literal>true</literal> to the <function>set_numeric()</function> method.
</para>

<para>
To make the <classname>SpinButton</classname> 'wrap' between its upper and
lower bounds, use the <function>set_wrap()</function> method.
</para>

<para>
To force it to snap to the nearest <literal>step_increment</literal>,
use <function>set_snap_to_ticks()</function>.
</para>

<para>
You can modify the update policy using the
<function>set_update_policy()</function> method, specifying either
<literal>Gtk::UPDATE_ALWAYS</literal> or
<literal>Gtk::UPDATE_IF_VALID</literal>.
<literal>Gtk::UPDATE_ALWAYS</literal> causes the
<classname>SpinButton</classname> to ignore errors encountered while converting
the text in the entry box to a numeric value.  This setting also therefore
allows the <classname>SpinButton</classname> to accept non-numeric values. You
can force an immediate update using the <function>update()</function> method.
</para>

<para><ulink url="&url_refdocs_base_gtk;SpinButton.html">Reference</ulink></para>

</sect2>

<sect2><title>Example</title>

<para>
Here's an example of a <classname>SpinButton</classname> in action:
</para>

<figure id="figure-spinbutton">
  <title>SpinButton</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;spinbutton.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;spinbutton">Source Code</ulink></para>

</sect2>

</sect1>

<sect1 id="sec-ProgressBar">
<title>ProgressBar</title>

<para>
Progress bars are used to show the status of an ongoing operation. For
instance, a <classname>ProgressBar</classname> can show how much of a task has
been completed.
</para>

<para>
To change the value shown, use the <function>set_fraction()</function> method,
passing a double between 0 and 1 to provide the new percentage.
</para>

<para>
where <literal>percentage</literal> is a number, from 0 to 1, indicating what
fraction of the bar should be filled.
</para>

<para>
A <classname>ProgressBar</classname>is horizontal and left-to-right by default,
but you can change it to a vertical progress bar by using the
<function>set_orientation()</function> method.
</para>

<para><ulink url="&url_refdocs_base_gtk;ProgressBar.html">Reference</ulink></para>

<sect2>
<title>Activity Mode</title>
<para>
Besides indicating the amount of progress that has occured, the
progress bar can also be used to indicate that there is some activity;
this is done by placing the progress bar in <emphasis>activity mode</emphasis>.  In
this mode, the progress bar displays a small rectangle which moves
back and forth.  Activity mode is useful in situations where the
progress of an operation cannot be calculated as a value range (e.g.,
receiving a file of unknown length).
</para>

<para>
To do this, you need to call the <function>pulse()</function> method at regular
intervals. You can also choose the step size, with the
<function>set_pulse_step()</function> method.
</para>

<para>
When in continuous mode, the progress bar can also display a configurable text
string within its trough, using the <function>set_text()</function> method.
</para>
</sect2>

<sect2><title>Example</title>

<figure id="figure-progressbar">
  <title>ProgressBar</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;progressbar.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;progressbar">Source Code</ulink></para>

</sect2>

</sect1>

<sect1 id="sec-Tooltips">
<title>Tooltips</title>

<para>
<classname>Tooltips</classname> are the little text strings that pop up when
you leave your pointer over a widget for a few seconds and the
<classname>Gtk::Tooltips</classname> object is a group of these tooltips. After
creating a <classname>Gtk::Tooltips</classname> instance, you can use the
<function>set_tip()</function> method to associate some descriptive text with a
<classname>Widget</classname>.
</para>

<para>
The <function>enable()</function> and <function>disable()</function> methods
allow you to turn a whole group of tooltips on and off.
</para>

<para><ulink url="&url_refdocs_base_gtk;Tooltips.html">Reference</ulink></para>

</sect1>

</chapter>

<chapter id="sec-ContainerWidgets">
<title>Container Widgets</title>

<para>
All container widgets derive from <classname>Gtk::Container</classname>, not
always directly. Some container widgets, such as
<classname>Gtk::Table</classname> can hold many child widgets, so these
typically have more complex interfaces.  Others, such as
<classname>Gtk::Frame</classname> contain only one child widget.
</para>

<sect1 id="sec-SingleItemWidgets">
<title>Single-item Containers</title>

<para>
The single-item container widgets derive from <classname>Gtk::Bin</classname>,
which provides the <function>add()</function> and <function>remove()</function>
methods for the child widget. Note that <classname>Gtk::Button</classname> and
<classname>Gtk::Window</classname> are technically single-item containers, but
we have discussed them already elsewhere. 
</para>

<para>
We also discuss the <classname>Gtk::Paned</classname> widget, which allows you
to divide a window into two separate "panes".  This widget actually contains
two child widgets, but the number is fixed so it seems appropriate.
</para>

<sect2 id="sec-Frame">
<title>Frame</title>

<para>
Frames can enclose one or a group of widgets within a box, optionally with a
title. For instance, you might place a group of
<classname>RadioButton</classname>s or <classname>CheckButton</classname>s in a
<classname>Frame</classname>.
</para>

<para><ulink url="&url_refdocs_base_gtk;Frame.html">Reference</ulink></para>

<sect3><title>Example</title>

<figure id="figure-frame">
  <title>Frame</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;frame.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;frame">Source Code</ulink></para>

</sect3>

</sect2>


<sect2>
<title>Paned</title>

<para>
Panes divide a widget into two halves, separated by a moveable divider.  There
are two such widgets: <classname>Gtk::HPaned</classname> adds a horizontal
divider, and <classname>Gtk::VPaned</classname> adds a vertical one.  Other
than the names and the orientations, there's no difference between the two.
</para>

<para>
Unlike the other widgets in this chapter, pane widgets contain not one but two
child widgets, one in each pane. Therefore, you should use
<function>add1()</function> and <function>add2()</function> instead of the
<function>add()</function> method.
</para>

<para>
You can adjust the position of the divider using the
<function>set_position()</function> method, and you will probably need to do
so.
</para>

<para><ulink url="&url_refdocs_base_gtk;Paned.html">Reference</ulink></para>

<sect3><title>Example</title>

<figure id="figure-paned">
  <title>Paned</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;paned.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;paned">Source Code</ulink></para>

</sect3>

</sect2>

<sect2 id="sec-ScrolledWindows">
<title>ScrolledWindow</title>

<para>
<classname>ScrolledWindow</classname> widgets are used to create a scrollable
area.  You can insert any type of widget into a
<classname>ScrolledWindow</classname> window, and it will be accessible
regardless of its size by using the scrollbars. Note that
<classname>ScrolledWindow</classname> is not a
<classname>Gtk::Window</classname> despite the slightly misleading name.
</para>

<para>
Scrolled windows have <emphasis>scrollbar policies</emphasis> which determine
whether the <classname>Scrollbar</classname>s will be displayed. The policies
can be set with the <function>set_policy()</function> method. The policy may be
one of <literal>Gtk::POLICY_AUTOMATIC</literal> or
<literal>Gtk::POLICY_ALWAYS</literal>.
<literal>Gtk::POLICY_AUTOMATIC</literal> will cause the scrolled window
to display the scrollbar only if the contained widget is larger than the
visible area.  <literal>Gtk::POLICY_ALWAYS</literal> will cause the
scrollbar to be displayed always.
</para>

<para><ulink url="&url_refdocs_base_gtk;ScrolledWindow.html">Reference</ulink></para>

<sect3><title>Example</title>

<para>
Here is a simple example that packs 100 toggle buttons into a ScrolledWindow. Try resizing the window to see the scrollbars react.
</para>

<figure id="figure-scrolledwindow">
  <title>ScrolledWindow</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;scrolledwindow.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;scrolledwindow">Source Code</ulink></para>

</sect3>

</sect2>

<sect2 id="sec-AspectFrames">
<title>AspectFrame</title>

<para>
The <classname>AspectFrame</classname> widget looks like a
<classname>Frame</classname> widget, but it also enforces the <emphasis>aspect
    ratio</emphasis> (the ratio of the width to the height) of the child
widget, adding extra space if necessary. For instance, this would allow you to
display a photograph without allowing the user to distort it horizontally or
vertically while resizing.
</para>

<para><ulink url="&url_refdocs_base_gtk;AspectFrame.html">Reference</ulink></para>

<sect3>
<title>Example</title>
<para>
The following program uses a <classname>Gtk::AspectFrame</classname> to present a
drawing area whose aspect ratio will always be 2:1, no matter how the user
resizes the top-level window.
</para>

<figure id="figure-aspectframe">
  <title>AspectFrame</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;aspectframe.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;aspectframe">Source Code</ulink></para>
</sect3>

</sect2>


<sect2 id="sec-Alignment">
<title>Alignment</title>

<para>
The <classname>Alignment</classname> widget allows you to place a widget at a
position and size relative to the size of the <classname>Alignment</classname>
widget itself.  For instance, it might be used to center a widget.
</para>

<para>
You need to specify the <classname>Alignment</classname>'s characteristics to
the constructor, or to the <function>set()</function> method. In particular, you
won't notice much effect unless you specify a number other than 1.0 for the
<literal>xscale</literal> and <literal>yscale</literal> parameters, because 1.0
simply means that the child widget will expand to fill all available space.
</para>

<para><ulink url="&url_refdocs_base_gtk;Alignment.html">Reference</ulink></para>

<sect3>
<title>Example</title>
<para>
This example right-aligns a button in a window by using an
<classname>Alignment</classname> widget.
</para>

<figure id="figure-alignment">
  <title>Alignment</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;alignment.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;alignment">Source Code</ulink></para>

<para>
See the <link linkend="sec-ProgressBar">ProgressBar</link> section for another
example that uses an <classname>Alignment</classname>.
</para>

</sect3>

</sect2>

</sect1>

<sect1 id="sec-MultiItemWidgets">
<title>Multiple-item widgets </title>

<para>
Multiple-item widgets inherit from <classname>Gtk::Container</classname>; just
as with <classname>Gtk::Bin</classname>, you use the <function>add()</function>
and <function>remove()</function> methods to add and remove contained widgets.
Unlike <function>Gtk::Bin::remove()</function>, however, the
<function>remove()</function> method for <classname>Gtk::Container</classname>
takes an argument, specifiying which widget to remove.
</para>

<sect2>
<title>Packing</title>
<para>
You've probably noticed that &gtkmm; windows seem "elastic" - they can usually be stretched in many  different ways.  This is due to the <emphasis>widget packing</emphasis>
system.
</para>

<para>
Many GUI toolkits require you to precisely place widgets in a window, using absolute positioning, often using a visual editor. This leads to several problems:
</para>

<itemizedlist>

<listitem>
<para>The widgets don't rearrange themselves when the window is resized. Some widgets are hidden when the window is made smaller, and lots of useless space appears when the window is made larger.</para>
</listitem>

<listitem>
<para>It's impossible to predict the amount of space necessary for text after it has been translated to other languages, or displayed in a different font. On Unix it is also impossible to anticipate the effects of every theme and window manager.</para>
</listitem>

<listitem>
<para>
Changing the layout of a window "on the fly", to make some extra widgets appear, for instance, is complex. It  requires tedious recalculation of every widget's position.</para>
</listitem>

</itemizedlist>

<para>
&gtkmm; uses the packing system to solve these problems.  Rather than specifying the position and size of each widget in the window,
you can arrange your widgets in rows, columns,
and/or tables. &gtkmm; can size your window automatically, based on the
sizes of the widgets it contains. And the sizes of the widgets are, in turn, determined by the amount of text they contain, or the minimum and maximum sizes that you specify, and/or how you have requested that the available space should be shared between sets of widgets.
You can perfect your layout by
specifying padding distance and centering values for each of your widgets. &gtkmm; then uses
all this information to resize and reposition everything sensibly and smoothly when the user manipulates the window. </para>

<para>
&gtkmm; arranges widgets hierarchically, using <emphasis>containers</emphasis>.
A Container widget contains other widgets.  Most &gtkmm; widgets are
containers. Windows, Notebook tabs, and Buttons are all container widgets.
There are two flavours of containers: single-child containers, which are all
descendants of <classname>Gtk::Bin</classname>, and multiple-child containers,
which are descendants of <classname>Gtk::Container</classname>.  Most widgets
in &gtkmm; are descendants of <classname>Gtk::Bin</classname>, including
<classname>Gtk::Window</classname>.
</para>

<para>
Yes, that's correct: a Window can contain at most one widget.  How, then, can
we use a window for anything useful?  By placing a multiple-child container in
the window. The most useful container widgets are
<classname>Gtk:VBox</classname>, <classname>Gtk::HBox</classname>, and
<classname>Gtk::Table</classname>.
</para>


<itemizedlist>

<listitem>
<para>
<classname>Gtk::VBox</classname> and <classname>Gtk::HBox</classname> arrange
their child widgets vertically and horizontally, respectively. Use
<function>pack_start()</function> and <function>pack_end()</function> to insert
child widgets.
</para>
</listitem>

<listitem>
<para>
<classname>Gtk::Table</classname> arranges its widgets in a grid. Use
<function>attach()</function> to insert widgets.
</para>
</listitem>

</itemizedlist>

<para>
 There are several other containers, which we will also discuss.
</para>

<para>
If you've never used a packing toolkit before, it can take some
getting used to.  You'll probably find, however, that you don't
need to rely on visual form editors quite as much as you might with
other toolkits.
</para>

</sect2>

<sect2 id="sec-helloworld2">
<title>An improved Hello World</title>

<para>
Let's take a look at a slightly improved <literal>helloworld</literal>, showing what we've learnt.
</para>

<figure id="figure-helloworld2">
  <title>Hello World 2</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;helloworld2.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;helloworld2">Source Code</ulink></para>

<para>
After building and running this program, try resizing the window to see the
behaviour. Also, try playing with the options to
<function>pack_start()</function> while reading the <link
    linkend="sec-Boxes">Boxes</link> section.
</para>

</sect2>

<sect2 id="sec-stl-style">
<title>STL-style APIs</title>

<para>
TODO: Use 'Standard Library' instead of STL.
If you're an accomplished C++ programmer, you'll be happy to hear that most of
the &gtkmm; <classname>Container</classname> widgets provide STL-style APIs,
available via accessor methods, such as
<function>Gtk::Box::children()</function> or
<function>Gtk::Notebook::pages()</function>. They don't use actual STL
containers (there are good reasons for this), but they look, feel, and act much
like STL container classes.
</para>

<para>These APIs are so similar to STL container APIs that, rather than explaining them in detail, we can refer
you to the STL documentation for most of their methods. This is all part of &gtkmm;'s policy of reusing existing standards.
</para>

<para>
However, STL-style APIs can require awkward or lengthy code in some situations,
so some people prefer not to use them, while other people use them religiously.
Therefore, you are not forced to use them - most container widgets have a
simpler non-STL-style API, with methods such as <function>append()</function>
and <function>prepend()</function>. 
</para>

<para>
At a minimum, &gtkmm; container lists support iterators and the usual insertion, deletion, and addition methods.  You can
always expect the following methods to be available for &gtkmm; STL-style APIs:
<itemizedlist>

<listitem>
<para>
<function>begin()</function> returns a <literal>begin</literal> iterator
</para>
</listitem>

<listitem>
<para>
<function>end()</function> returns an <literal>end</literal> iterator
</para>
</listitem>

<listitem>
<para>
<function>rbegin()</function> returns a reverse <literal>begin</literal> iterator
</para>
</listitem>

<listitem>
<para>
<function>rend()</function> returns a reverse <literal>end</literal> iterator
</para>
</listitem>

<listitem>
<para>
<function>size()</function>
</para>
</listitem>

<listitem>
<para>
<function>max_size()</function>
</para>
</listitem>

<listitem>
<para>
<function>empty()</function>
</para>
</listitem>

<listitem>
<para>
<function>insert()</function>
</para>
</listitem>

<listitem>
<para>
<function>push_front()</function>
</para>
</listitem>

<listitem>
<para>
<function>push_back()</function>
</para>
</listitem>

<listitem>
<para>
<function>pop_front()</function>
</para>
</listitem>

<listitem>
<para>
<function>pop_back()</function>
</para>
</listitem>

<listitem>
<para>
<function>clear()</function>
</para>
</listitem>

<listitem>
<para>
<function>erase()</function>
</para>
</listitem>

<listitem>
<para>
<function>remove()</function>
</para>
</listitem>

<listitem>
<para>
<function>find()</function>
</para>
</listitem>

<listitem>
<para>
<function>front()</function>
</para>
</listitem>

<listitem>
<para>
<function>back()</function>
</para>
</listitem>

</itemizedlist>

</para>

<para>
Also, the <literal>[]</literal> operator is overloaded, but that is usually order
N, so if performance is a consideration, or the list has a large
number of elements, think carefully before using it.
</para>

<para>
The element objects and list objects are defined, for each container, in a
namespace whose name ends in <literal>_Helpers</literal>.  For example,
the helper namespace for the notebook widget is
<classname>Gtk::Notebook_Helpers</classname>.
</para>

<sect3>
<title>Adding items</title>
<para>
There is a major difference between &gtkmm; STL-style APIs and real STL
containers.  Normally, when you use a <classname>std::vector</classname>, for
example, you expect that whatever you put in, you'll get out, unmodified.  You
wouldn't make a <classname>std::vector&lt;int&gt;</classname> and expect to get
<literal>double</literal>s out of it.  But, &gtkmm; STL-style APIs don't always
work like that - you will often put one kind of object in, and later get a
different kind out.  Why this odd behaviour?
</para>

<para>
Consider a menu widget, which must maintain a hierarchical list of
menus and menu items.  Menus can only contain certain objects, such as menu items, separators,
and submenus.  To ensure consistency, a "filter" is needed to
keep out illegal objects.  Also, since only a few types of objects are
allowed, convenience methods can be provided to make it easy to
build up menus.
</para>

<para>
&gtkmm; takes care of both requirements using special
<emphasis>helper elements</emphasis>.  Helper elements are
temporary - they're typically constructed and passed to an insertion method in the same call.
 The list insertion method uses the information in the helper element to construct the real
object, which is then inserted into the container.
</para>

<para>
As an example, let's look at the <classname>Notebook</classname> widget
(explained in the section on <link linkend="sec-Notebook">Notebooks</link>).
<classname>Notebook</classname> widgets contain a series of "pages".
</para>

<para>
Each page in a notebook requires, at minimum, the following
information:
</para>

<itemizedlist>

<listitem>
<para>
A child widget (zero or one), to be placed in the page
</para>
</listitem>

<listitem>
<para>
A label for the page's tab
</para>
</listitem>

</itemizedlist>

<para>
(The &gtkmm; notebook widget keeps other data for each page as well.)
</para>

<para>
To insert a new page in a notebook, we can use one of the notebook
helper classes, like this:
</para>
<programlisting>notebook-&#62;pages().push_back(
          Gtk::Notebook_Helpers::TabElem(*frame, bufferl));</programlisting>

<para>
Let's see what's
going on here.  Assume we have a pointer to a <classname>Notebook</classname>
widget called <literal>notebook</literal>; we go from that to a member method
called <function>pages()</function>, which returns an STL-like list object.  On
this we call the method <function>push_back()</function> (this should be
familiar to those who know STL).
</para>

<para>
The object that the <function>pages()</function> method returns is called a
<classname>Notebook_Helpers::PageList</classname>.  It's one of the
STL-like containers that we keep referring to.  Let's take a look at this class
(this has been heavily edited for clarity; see
<filename>&lt;gtkmm/notebook.h&gt;</filename> for the actual definition):
</para>

<programlisting>namespace Notebook_Helpers
{
    class PageList
    {
    public:
             . . .
        void push_back(const Element&#38; e);
             . . .
        Page* operator[](size_type l);
    };
};</programlisting>

<para>
There are two important things to notice here:
<itemizedlist>

<listitem>
<para>
The <function>push_back()</function> method takes as argument an
<classname>Element</classname> object (helper);
</para>
</listitem>

<listitem>
<para>
The overloaded <literal>[]</literal> operator returns a pointer to a
<classname>Page</classname>.
</para>

</listitem>

</itemizedlist>
</para>

<para>
This scheme has some important advantages:
</para>

<itemizedlist>

<listitem>
<para>
We can provide as many different Helper objects as desired,
making it simple to construct complex widgets like Menus.

</para>
</listitem>

<listitem>
<para>
Construction of the actual objects can be delayed until an appropriate time. Sometimes we don't have enough information until later
with GTK+.
</para>
</listitem>

<listitem>
<para>
The definitions of the objects contained in the list can change; their
interfaces need not concern the programmer.  For example, even if the
<classname>Page</classname> object changes drastically, the programmer need not
be concerned; the <classname>Element</classname>s need not change, and will
continue to work as expected.
</para>
</listitem>

<listitem>
<para>
New <classname>Element</classname> objects can be added at any time to support
new features, without breaking existing code.
</para>
</listitem>

</itemizedlist>

<para>
All multi-item containers have an <classname>Element</classname> object in
their helper namespaces, and usually there are additional classes available
(like <classname>TabElem</classname> and <classname>MenuElem</classname>) which
derive from <classname>Element</classname>.  <classname>Element</classname>
classes vary from container to container, since each contains different kinds
of objects.
</para>

<para>
It's very important to remember that <classname>Element</classname>s are not
"real" objects. They exist only temporarily, and they are never stored in the
container.  They are used <emphasis>only</emphasis> as temporary
"parameter-holders".  Therefore, the following segment of code is illegal:
</para>
<programlisting>MenuElem* m = new MenuElem("hello");
m-&#62;right_justify();
items().push_back(*m);</programlisting>

<para>
We constructed a new <classname>MenuElem</classname> helper object, and then
tried to invoke <function>right_justify()</function> on it before adding
it to the menu.  The trouble is that there is no
<function>right_justify()</function> method in the
<classname>MenuElem</classname> class.  The correct way to accomplish this
would be:
</para>
<programlisting>items().push_back(MenuElem("hello"));
items().back()-&#62;right_justify();</programlisting>

<para>
Here, we've constructed a <classname>MenuElem</classname> and inserted it into
the menu by passing it to <function>push_back()</function>, causing the
real menu item to be created.  We've then called
<function>right_justify()</function> on the object retrieved from the
list.  This is correct - the object retrieved from the list is not a
<classname>MenuElem</classname>, but a real <classname>MenuItem</classname>,
and therefore supports the <function>right_justify()</function> method
as expected.
</para>

</sect3>

</sect2>

<sect2 id="sec-Boxes">
<title>Boxes</title>

<para>
Most packing uses boxes as in the above example. These
are invisible containers into which we can pack our widgets. When
packing widgets into a horizontal box, the objects are inserted
horizontally from left to right or right to left depending on whether
<function>pack_start()</function> or <function>pack_end()</function> is used.
In a vertical box, widgets are packed from top to bottom or vice
versa. You may use any combination of boxes inside or beside other
boxes to create the desired effect.
</para>

<sect3><title>Adding widgets</title>
<sect4><title>Per-child packing options</title>
<para>
The <function>pack_start()</function> and
<function>pack_end()</function> methods place widgets inside these
containers. The <function>pack_start()</function> method will start at
the top and work its way down in a <classname>VBox</classname>, or pack left to
right in an <classname>HBox</classname>.
<function>pack_end()</function> will do the opposite, packing from
bottom to top in a <classname>VBox</classname>, or right to left in an
<classname>HBox</classname>. Using these methods allows us to right justify or
left justify our widgets. We will use <function>pack_start()</function>
in most of our examples.
</para>

<para>
There are several options governing how  widgets are to be packed, and this can
be confusing at first. If you have difficulties then it is sometimes a good
idea to play with the <application>glade</application> GUI designer to see what
is possible. You might even decide to use the
<application>libglademm</application> API to load your GUI at runtime.
</para>

<para>
There are basically five
different styles, as shown in this picture:
</para>

<figure id="figure-box_packing1">
  <title>Box Packing 1</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;box_packing1.png"/>
  </screenshot>
</figure>

<para>
Each line contains one horizontal box (<classname>HBox</classname>) with
several buttons. Each of the buttons on a line is packed into the
<classname>HBox</classname> with the same arguments to the
<function>pack_start()</function> method).
</para>

<para>
This is the declaration of the <function>pack_start()</function> method:
</para>
<programlisting>void pack_start(Gtk::Widget&amp; child,
                PackOptions options = PACK_EXPAND_WIDGET,
                guint padding = 0);</programlisting>

<para>
The first argument is the widget you're packing. In our example these are all <classname>Button</classname>s.
</para>

<para>
The <parameter>options</parameter> argument can take one of these three options:
<itemizedlist>
<listitem><para><literal>PACK_SHRINK</literal>: Space is contracted to the child widget size. The widget will take up just-enough space and never expand.</para></listitem>
<listitem><para><literal>PACK_EXPAND_PADDING</literal>: Extra space is filled with padding. The widgets will be spaced out evenly, but their sizes won't change - there will be empty space between the widgets instead. </para></listitem>
<listitem><para><literal>PACK_EXPAND_WIDGET</literal>: Extra space is taken up by increasing the child widget size, without changing the amount of space between widgets.</para></listitem>
</itemizedlist>
</para>

<para>
The <parameter>padding</parameter> argument specifies the width of an extra
border area to leave around the packed widget.
</para>

<para>
Instead of the <function>pack_start()</function> and
<function>pack_end()</function> methods, you might prefer to use the STL-style
API, available via the <literal>children</literal> method. See the <link
    linkend="sec-stl-style">STL-style APIs</link> section for more details.
</para>

<para><ulink url="&url_refdocs_base_gtk;Box.html">Reference</ulink></para>

</sect4>

<sect4><title>Per-container packing options</title>
<para>
Here's the constructor for the box widgets:
<programlisting>Gtk::Box(bool homogeneous = false, int spacing = 0);</programlisting>
Passing <literal>true</literal> for <parameter>homogeneous</parameter> will
cause all of the contained widgets to be the same size.
<parameter>spacing</parameter> is a (minimum) number of pixels to leave between
each widget.
</para>

<para>
What's the difference between spacing (set when the box is created)
and padding (set when elements are packed)? Spacing is added between
objects, and padding is added on either side of a widget. The following
figure should make it clearer:
</para>

<figure id="figure-box_packing2">
  <title>Box Packing 2</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;box_packing2.png"/>
  </screenshot>
</figure>

</sect4>
</sect3>

<sect3>
<title>Example</title>
<para>
Here is the source code for the example that produced the screenshots above. When you run this example, provide a number between 1 and 3 as a command-line option, to see different packing options in use.</para>

<para><ulink url="&url_examples_base;box">Source Code</ulink></para>
</sect3>

</sect2>

<sect2 id="sec-ButtonBoxes">
<title>ButtonBoxes </title>

<para>
Button boxes are a convenient way to quickly arrange a group of buttons. They
come in both horizontal (<classname>Gtk::HButtonBox</classname>) and vertical
(<classname>Gtk::VButtonBox</classname>) flavours. They are exactly alike,
except in name and orientation.
</para>

<para>
<classname>ButtonBox</classname>es help to make applications appear consistent
because they use standard settings, such as inter-button spacing and packing.
</para>

<para>
Buttons are added to a <classname>ButtonBox</classname> with the
<function>add()</function> method.
</para>

<para>
Button boxes support several layout styles.  The style can be retrieved and
changed using <function>get_layout()</function> and
<function>set_layout()</function>.
</para>

<para><ulink url="&url_refdocs_base_gtk;ButtonBox.html">Reference</ulink></para>

<sect3>
<title>Example</title>

<figure id="figure-buttonbox">
  <title>ButtonBox</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;buttonbox.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;buttonbox">Source Code</ulink></para>

</sect3>

</sect2>

<sect2>
<title>Table</title>

<para>
Tables allows us to place widgets in a grid.
</para>

<sect3><title>Constructor</title>
<para>
The grid's dimensions need to be specified in the constructor:
</para>
<programlisting>Gtk::Table(int rows = 1, int columns = 1, bool homogeneous = false);</programlisting>

<para>
The first argument is the number of rows to make in the table, while the
second, obviously, is the number of columns.  If
<parameter>homogeneous</parameter> is <literal>true</literal>, the table cells
will all be the same size (the size of the largest widget in the table).
</para>

<para>
The rows and columns are indexed starting at 0.  If you specify
<parameter>rows</parameter> = 2 and <parameter>columns</parameter> = 2, the
layout would look something like this:
</para>

<programlisting>
 0          1          2
0+----------+----------+
 |          |          |
1+----------+----------+
 |          |          |
2+----------+----------+
</programlisting>

<para>
Note that the coordinate system starts in the upper left hand corner.
</para>
</sect3>

<sect3><title>Adding widgets</title>
<para>
To place a widget into a box, use the following method:
</para>
<programlisting>void Gtk::Table::attach(Gtk::Widget&amp; child,
                        guint left_attach, guint right_attach,
                        guint top_attach, guint bottom_attach,
                        guint xoptions = Gtk::FILL | Gtk::EXPAND,
                        guint yoptions = Gtk::FILL | Gtk::EXPAND,
                        guint xpadding = 0, guint ypadding = 0);</programlisting>
<para>
The first argument is the widget you wish to place in the table.
</para>

<para>
The <parameter>left_attach</parameter> and
<parameter>right_attach</parameter> arguments specify where to place the
widget, and how many boxes to use.  For example, if you want a button in the
lower-right cell of a 2 x 2 table, and want it to occupy that cell
<emphasis>only</emphasis>, then <parameter>left_attach</parameter> would
be 1, <parameter>right_attach</parameter> 2,
<parameter>top_attach</parameter> 1, and
<parameter>bottom_attach</parameter> 2.  If, on the other hand, you
wanted a widget to take up the entire top row of our 2 x 2 table, you'd set
<parameter>left_attach</parameter> = 0,
<parameter>right_attach</parameter> = 2,
<parameter>top_attach</parameter> = 0, and
<parameter>bottom_attach</parameter> = 1.
</para>

<para>
<parameter>xoptions</parameter> and <parameter>yoptions</parameter> are used to
specify packing options and may be bitwise ORed together to allow multiple
options.  These options are:
</para>

<para>
<variablelist>

<varlistentry>
<term><literal>Gtk::FILL</literal></term>
<listitem>
<para>
If the table box is larger than the widget, and
<literal>Gtk::FILL</literal> is specified, the widget will expand to use all the room available.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>Gtk::SHRINK</literal></term>
<listitem>
<para>
If the table widget is allocated less
space than it requested (because the user resized the window),
then the widgets will normally just disappear off the bottom of the
window. If <literal>Gtk::SHRINK</literal> is specified, the widgets
will shrink with the table.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><literal>Gtk::EXPAND</literal></term>
<listitem>
<para>This will cause the table to expand to use up anyremaining space in the window.
</para>
</listitem>
</varlistentry>

</variablelist>
</para>

<para>
The padding arguments work just as they do for
<function>pack_start()</function>.
</para>
</sect3>

<sect3><title>Other methods</title>

<para>
<function>set_row_spacing()</function> and
<function>set_col_spacing()</function> set the spacing between
the rows at the specified row or column. Note that for columns, the space goes
to the right of the column, and for rows, the space goes below the row.
</para>

<para>
You can also set a consistent spacing for all rows and/or columns with
<function>set_row_spacings()</function> and
<function>set_col_spacings()</function>. Note that with these calls, the last
row and last column do not get any spacing.
</para>

<para><ulink url="&url_refdocs_base_gtk;Table.html">Reference</ulink></para>

</sect3>

<sect3><title>Example</title>
<para>
In the following example, we make a window with three buttons in a 2 x 2
table.  The first two buttons will be placed in the upper row.  A
third button is placed in the lower row, spanning both columns.
</para>

<figure id="figure-table">
  <title>Table</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;table.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;table">Source Code</ulink></para>

</sect3>

</sect2>

<sect2 id="sec-Notebook">
<title>Notebook</title>

<para>
A <classname>Notebook</classname> has a set of stacked
<literal>pages</literal>, each of which contains widgets.  Labelled
<literal>tabs</literal> allow the user to select the pages.
<classname>Notebook</classname>s allow several sets of widgets to be placed in a
small space, by only showing one page at a time. For instance, they are often
used in preferences dialogs.
</para>

<para>
Use the <function>append_page()</function>, <function>prepend_page()</function>
and <function>insert_page()</function> methods to add tabbed pages to the
<literal>Notebook</literal>, supplying the child widget and the name for the
tab.
</para>

<para>
To discover the currently visible page, use the
<function>get_current_page()</function> method. This returns the page number,
and then calling <function>get_nth_page()</function> with that number will give
you a pointer to the actual child widget.
</para>

<para>
To programmatically change the selected page, use the
<function>set_page()</function> method.
</para>

<para>There is also an  <link linkend="sec-Notebook-STL-style">STL-style API</link> which you might find more obvious.</para>

<para><ulink url="&url_refdocs_base_gtk;Notebook.html">Reference</ulink></para>

<sect3><title>Example</title>

<figure id="figure-notebook">
  <title>Notebook</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;notebook.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;notebook/">Source Code</ulink></para>

</sect3>

<sect3 id="sec-Notebook-STL-style">
<title>STL-style API</title>
<para>
The <classname>Gtk::Notebook</classname> widget has an STL-style API, available
via the <function>pages()</function> method,  which you might prefer to use to
add and access pages. See the <link linkend="sec-stl-style">STL-style
    APIs</link> section for generic information.</para>

<para><ulink url="&url_refdocs_base_gtk;Notebook__Helpers_1_1PageList.html">PageList Reference</ulink></para>

<para>
To insert pages into a notebook, use the <classname>TabElem</classname> helper
class, like so:
</para>
<programlisting>m_Notebook.pages().push_back(
    Gtk::Notebook_Helpers::TabElem(m_ChildWidget, "tab 1") );</programlisting>

<para><ulink url="&url_refdocs_base_gtk;Notebook__Helpers_1_1TabElem.html">TabElem Reference</ulink>. TODO: Correct URL.</para>

<para>
To access an existing child widget, you can call
<function>get_child()</function> on one of the <classname>Page</classname> elements
of the <classname>PageList</classname>:
</para>
<programlisting>Gtk::Widget* pWidget = m_Notebook.pages()[2].get_child();</programlisting>

</sect3>

</sect2>

</sect1>

</chapter>

<chapter id="sec-chapter-treeview">

<title>The TreeView widget</title>
<para>
The <classname>Gtk::TreeView</classname> widget can contain lists or trees of
data, in columns.
</para>

<sect1>
<title>The Model</title>
<para>
Each <classname>Gtk::TreeView</classname> has an associated
<classname>Gtk::TreeModel</classname>, which contains the data displayed by the
<classname>TreeView</classname>. Each <classname>Gtk::TreeModel</classname> can
be used by more than one <classname>Gtk::TreeView</classname>. For instance,
this allows the same underlying data to be displayed and edited in 2 different
ways at the same time. Or the 2 Views might display different columns from the
same Model data, in the same way that 2 SQL queries (or "views") might
show different fields from the same database table.
</para>
<para>
Although you can theoretically implement your own Model, you will normally use
either the <classname>ListStore</classname> or <classname>TreeStore</classname>
model classes.
</para>

<para><ulink url="&url_refdocs_base_gtk;TreeModel.html">Reference</ulink></para>

<sect2>
<title>ListStore, for rows</title>
<para>
The <classname>ListStore</classname> contains simple rows of data, and each row
has no children.
</para>

<figure id="figure-treeview-liststore-model">
  <title>TreeView - ListStore</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;treeview_list.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_refdocs_base_gtk;ListStore.html">Reference</ulink></para>

</sect2>

<sect2>
<title>TreeStore, for a hierarchy</title>
<para>
The <classname>TreeStore</classname> contains rows of data, and each row may
have child rows.
</para>

<figure id="figure-treeview-treestore-model">
  <title>TreeView - TreeStore</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;treeview_tree.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_refdocs_base_gtk;TreeStore.html">Reference</ulink></para>

</sect2>

<sect2>
<title>Model Columns</title>
<para>
The <classname>TreeModelColumnRecord</classname> class is used to keep track
of the columns and their data types. You add
<classname>TreeModelColumn</classname> instances to the
<classname>ColumnRecord</classname> and then use those
<classname>TreeModelColumns</classname> when getting and setting the data in
model rows. You will probably find it convenient to derive a new
<classname>TreeModelColumnRecord</classname> which has your
<classname>TreeModelColumn</classname> instances as member data.
</para>

<programlisting>class ModelColumns : public Gtk::TreeModelColumnRecord
{
public:

  ModelColumns()
    { add(m_col_text); add(m_col_number); }

  Gtk::TreeModelColumn&lt;Glib::ustring&gt; m_col_text;
  Gtk::TreeModelColumn&lt;int&gt; m_col_number;
};

ModelColumns m_Columns;</programlisting>

<para>
You specify the <classname>ColumnRecord</classname> when creating the Model,
like so:
</para>
<programlisting>Glib::RefPtr&lt;Gtk::ListStore&gt; refListStore =
    Gtk::ListStore::create(m_Columns);</programlisting>
</sect2>

<sect2>
<title>Adding Rows</title>
<para>
Add rows to the model with the <function>append()</function>,
<function>prepend()</function>, or <function>insert()</function> methods.
</para>
<programlisting>Gtk::TreeModel::iterator iter = m_refListStore-&gt;append();</programlisting>
<para>You can dereference the iterator to get the Row:
</para>
<programlisting>Gtk::TreeModel::Row row = *iter;</programlisting>
<sect3><title>Adding child rows</title>
<para>
<classname>Gtk::TreeStore</classname> models can have child items. Add them
with the <function>append()</function>, <function>prepend()</function>, or
<function>insert()</function> methods, like so:
</para>
<programlisting>Gtk::TreeModel::iterator iter_child =
    m_refListStore-&gt;append(row.children());</programlisting>
</sect3>

</sect2>

<sect2>
<title>Setting values</title>
<para>
You can use the <function>operator[]</function> override to set the data for a
particular column in the row, specifying the
<classname>TreeModelColumn</classname> used to create the model.
</para>
<programlisting>row[m_Columns.m_col_text] = "sometext";</programlisting>
</sect2>

<sect2>
<title>Getting values</title>
<para>
You can use the <function>operator[]</function> override to get the data in a
particular column in a row, specifiying the
<classname>TreeModelColumn</classname> used to create the model.
</para>
<programlisting>Glib::ustring strText = row[m_Columns.m_col_text];
int number = row[m_Columns.m_col_number];</programlisting>
<para>
The compiler will complain if you use an inappropriate type. For
instance, this would generate a compiler error:
</para>
<programlisting>//compiler error - no conversion from ustring to int.
int number = row[m_Columns.m_col_text];</programlisting>
</sect2>

<sect2>
<title>&quot;Hidden&quot; Columns</title>
<para>
You might want to associate extra data with each row. If so, just add
it as a Model column, but don't add it to the View.
</para>
</sect2>

</sect1>

<sect1 id="sec-treeview">
<title>The View</title>
<para>
The View is the actual widget (<classname>Gtk::TreeView</classname>) that
displays the model (<classname>Gtk::TreeModel</classname>) data and allows the
user to interact with it. The View can show all of the model's columns, or just
some, and it can show them in various ways. 
</para>

<para><ulink url="&url_refdocs_base_gtk;TreeView.html">Reference</ulink></para>

<sect2 id="sec-using_a_model">
<title>Using a Model</title>
<para>
You can specify a <classname>Gtk::TreeModel</classname> when constructing the
<classname>Gtk::TreeView</classname>, or you can use the
<function>set_model()</function> method, like so:
</para>
<programlisting>m_TreeView.set_model(m_refListStore);</programlisting>
</sect2>

<sect2>
<title>Adding View Columns</title>
<para>
You can use the <function>append_column()</function> method to  tell the View
that it should display certain Model columns, in a certain order, with a
certain column title.
</para>
<programlisting>m_TreeView.append_column("Messages", m_Columns.m_col_text);</programlisting>
<para>
When using this simple <function>append_column()</function> override, the
<classname>TreeView</classname> will display the model data with an appropriate
<classname>CellRenderer</classname>. For instance, strings and numbers are
shown in a simple <classname>Gtk::Entry</classname> widget, and booleans are
shown in a <classname>Gtk::CheckButton</classname>. This is usually what you
need.  For other column types you must either connect a callback that converts
your type into a string representation, with
<function>TreeViewColumn::set_cell_data_func()</function>, or derive a custom
<classname>CellRenderer</classname>.  Note that (unsigned) short is not
supported by default - You could use (unsigned) int or (unsigned) long as the
column type instead.
</para>
</sect2>

<sect2>
<title>More than one Model Column per View Column</title>
<para>
To render more than one model column in a view column, you need to create the
<classname>TreeView::Column</classname> widget manually, and use
<function>pack_start()</function> to add the model columns to it.
</para>

<para>
Then use <function>append_column()</function> to add the view Column to the
View. Notice that <function>Gtk::View::append_column()</function> is overridden
to accept either a prebuilt <classname>Gtk::View::Column</classname> widget, or
just the <classname>TreeModelColumn</classname> from which it generates an
appropriate <classname>Gtk::View::Column</classname> widget.
</para>
<para>
Here is some example code from
<filename>demos/gtk-demo/example_stockbrowser.cc</filename>, which has a pixbuf
icon and a text name in the same column:
</para>
<programlisting>Gtk::TreeView::Column* pColumn =
    Gtk::manage( new Gtk::TreeView::Column("Symbol") );

// m_columns.icon and m_columns.symbol are columns in the model.
// pColumn is the column in the TreeView:
pColumn-&gt;pack_start(m_columns.icon, false); //false = don't expand.
pColumn-&gt;pack_start(m_columns.symbol);

m_TreeView.append_column(*pColumn);</programlisting>
</sect2>

<sect2>
<title>Specifying CellRenderer details</title>
<para>
The default <classname>CellRenderers</classname> and their default behaviour
will normally suffice, but you might occasionally need finer control. For
instance, this example code from
<filename>demos/gtk-demo/example_treestore.cc</filename>, manually constructs a
<classname>Gtk::CellRenderer</classname> widget and instructs it to render the
data from various model columns through various aspects of its appearance.
</para>
<programlisting>Gtk::CellRendererToggle* pRenderer =
    Gtk::manage( new Gtk::CellRendererToggle() );
int cols_count = m_TreeView.append_column("Alex", *pRenderer);
Gtk::TreeViewColumn* pColumn = m_TreeView.get_column(cols_count-1);
if(pColumn)
{
  pColumn-&gt;add_attribute(pRenderer-&gt;property_active(),
      m_columns.alex);
  pColumn-&gt;add_attribute(pRenderer-&gt;property_visible(),
      m_columns.visible);
  pColumn-&gt;add_attribute(pRenderer-&gt;property_activatable(),
      m_columns.world);</programlisting>

<para>
    You can also connect to <classname>CellRenderer</classname> signals to detect user
actions. For instance:
</para>
<programlisting>Gtk::CellRendererToggle* pRenderer =
    Gtk::manage( new Gtk::CellRendererToggle() );
pRenderer-&gt;signal_toggled().connect(
    sigc::bind( sigc::mem_fun(*this,
        &amp;Example_TreeView_TreeStore::on_cell_toggled), m_columns.dave)
);</programlisting>
</sect2>

<sect2>
<title>Editable Cells</title>

<sect3>
<title>Automatically-stored editable cells.</title>
<para>
Cells in a <classname>TreeView</classname> can be edited in-place by the user.
To allow this, use the <classname>Gtk::TreeView</classname>
<function>insert_column_editable()</function> and
<function>append_column_editable()</function> methods instead of
<function>insert_column()</function> and <function>append_column()</function>.
When these cells are edited the new values will be stored immediately in the
Model. Note that these methods are templates which can only be instantiated for
simple column types such as <classname>Glib::ustring</classname>, int, and
long.
</para>
</sect3>

<sect3>
<title>Implementing custom logic for editable cells.</title>
<para>
However, you might not want the new values to be stored
immediately. For instance, maybe you want to restrict the input to
certain characters or ranges of values.
</para>
<para>
To achieve this, you should use the normal <classname>Gtk::TreeView</classname>
<function>insert_column()</function> and <function>append_column()</function>
methods, then use <function>get_column_cell_renderer()</function> to get the
<classname>Gtk::CellRenderer</classname> used by that column.
</para>
<para>
You should then cast that <classname>Gtk::CellRenderer*</classname> to the
specific <classname>CellRenderer</classname> that you expect, so you can use specific API.
</para>
<para>For instance, for a CellRendererText, you would set the cell's <emphasis>editable</emphasis> property to true, like
so:
</para>
<programlisting>cell.property_editable() = true;</programlisting>
<para>
For a CellRendererToggle, you would set the <emphasis>activatable</emphasis>
property instead.
</para>
<para>You can then connect
to the appropriate "edited" signal. For instance, connect to
<function>Gtk::CellRendererText::signal_edited()</function>, or
<function>Gtk::CellRendererToggle::signal_toggled()</function>. If the column
contains more than one <classname>CellRenderer</classname> then you will need
to use <function>Gtk::TreeView::get_column()</function> and then call
<function>get_cell_renderers()</function> on that view Column.
</para>
<para>
In your signal handler, you should examine the new value and then
store it in the Model if that is appropriate for your application.
</para>
</sect3>

</sect2>


</sect1>

<sect1 id="sec-iterating_over_model_rows">
<title>Iterating over Model Rows</title>
<para>
<classname>Gtk::TreeModel</classname> provides an STL-style container of its
children, via the <function>children()</function> method. You can use the
familiar <function>begin()</function> and <function>end()</function> methods
iterator incrementing, like so:
</para>
<programlisting>typedef Gtk::TreeModel::Children type_children; //minimise code length.
type_children children = refModel-&gt;children();
for(type_children::iterator iter = children.begin();
    iter != children.end(); ++iter)
{
  Gtk::TreeModel::Row row = *iter;
  //Do something with the row - see above for set/get.
}</programlisting>

<sect2>
<title>Row children</title>
<para>
When using a <classname>Gtk::TreeStore</classname>, the rows can have child
rows, which can have their own children in turn. Use
<function>Gtk::TreeModel::Row::children()</function> to get the STL-style
container of child <classname>Row</classname>s:
<programlisting>Gtk::TreeModel::Children children = row.children();</programlisting>
</para>
</sect2>

</sect1>

<sect1 id="sec-treeview_selection">
<title>The Selection</title>
<para>
To find out what rows the user has selected, get the
<classname>Gtk::TreeView::Selection</classname> object from the
<classname>TreeView</classname>, like so:
</para>
<programlisting>Glib::RefPtr&lt;Gtk::TreeSelection&gt; refTreeSelection =
    m_TreeView.get_selection();</programlisting>

<sect2>
<title>Single or multiple selection</title>
<para>
By default, only single rows can be selected, but you can allow
multiple selection by setting the mode, like so:
<programlisting>refTreeSelection-&gt;set_mode(Gtk::SELECTION_MULTIPLE);</programlisting>
</para>
</sect2>

<sect2>
<title>The selected rows</title>
<para>
For single-selection, you can just call <function>get_selected()</function>,
like so:
</para>
<programlisting>TreeModel::iterator iter = refTreeSelection-&gt;get_selected();
if(iter) //If anything is selected
{
  TreeModel::Row row = *iter;
  //Do something with the row.
}</programlisting>

<para>
For multiple-selection, you need to define a callback, and give it to
<function>selected_foreach()</function>,
<function>selected_foreach_path()</function>, or
<function>selected_foreach_iter()</function>, like so:
</para>
<programlisting>refTreeSelection-&gt;selected_foreach_iter(
    sigc::mem_fun(*this, &amp;TheClass::selected_row_callback) );

void TheClass::selected_row_callback(
    const Gtk::TreeModel::iterator&amp; iter)
{
  TreeModel::Row row = *iter;
  //Do something with the row.
}</programlisting>

</sect2>

<sect2>
<title>The "changed" signal</title>
<para>
To respond to the user clicking on a row or range of rows, connect to the
signal like so:
</para>
<programlisting>refTreeSelection-&gt;signal_changed().connect(
    sigc::mem_fun(*this, &amp;Example_StockBrowser::on_selection_changed)
);</programlisting>
</sect2>

<sect2>
<title>Preventing row selection</title>
<para>
Maybe the user should not be able to select every item in your list or tree.
For instance, in the gtk-demo, you can select a demo to see the source code,
but it doesn't make any sense to select a demo category.
</para>
<para>
To control which rows can be selected, use the
<function>set_select_function()</function> method, providing a
<classname>sigc::slot</classname> callback. For instance:
</para>
<programlisting>m_refTreeSelection-&gt;set_select_function( sigc::mem_fun(*this,
    &amp;DemoWindow::select_function) );</programlisting>
<para>
and then
</para>
<programlisting>bool DemoWindow::select_function(
    const Glib::RefPtr&lt;Gtk::TreeModel&gt;&amp; model,
    const Gtk::TreeModel::Path&amp; path, bool)
{
  const Gtk::TreeModel::iterator iter = model-&gt;get_iter(path);
  return iter-&gt;children().empty(); // only allow leaf nodes to be selected
}</programlisting>
</sect2>

<sect2>
<title>Changing the selection</title>
<para>
To change the selection, specify a
<classname>Gtk::TreeModel::iterator</classname> or
<classname>Gtk::TreeModel::Row</classname>, like so:
</para>
<programlisting>Gtk::TreeModel::Row row = m_refModel-&gt;children()[5]; //The fifth row.
if(row)
  refTreeSelection-&gt;select(row);</programlisting>
<para>
or
</para>
<programlisting>Gtk::TreeModel::iterator iter = m_refModel-&gt;children().begin()
if(iter)
  refTreeSelection-&gt;select(iter);</programlisting>
</sect2>

</sect1>


<sect1 id="sec-treeview-sort">
<title>Sorting</title>
<para>
The standard tree models (<classname>TreeStore</classname> and <classname>ListStore</classname> derive from <classname>TreeSortable</classname>, so they offer sorting functionality. For instance, call <function>set_sort_column()</function>, to sort the model by the specified column. Or supply a callback function to <function>set_sort_func()</function> to implement a more complicated sorting algorithm.
</para>

<para><ulink url="&url_refdocs_base_gtk;TreeSortable.html">TreeSortable Reference</ulink></para>

<sect2>
<title>Sorting by clicking on columns</title>
<para>
So that a user can click on a <classname>TreeView</classname>'s column header to sort the <classname>TreeView</classname>'s contents, call <function>Gtk::TreeViewModel::set_sort_column()</function>, supplying the model column on which model should be sorted when the header is clicked. For instance:
</para>
<programlisting>Gtk::TreeView::Column* pColumn = treeview.get_column(0);
if(pColumn)
  pColumn->set_sort_column(m_columns.m_col_id);</programlisting>
</sect2>

<sect2>
<title>Independently sorted views of the same model</title>
<para>
The <classname>TreeView</classname> already allows you to show the same <classname>TreeModel</classname> in two <classname>TreeView</classname> widgets. If you need one of these TreeViews to sort the model differently than the other then you should use a <classname>TreeModelSort</classname> instead of just, for instance, <function>Gtk::TreeViewModel::set_sort_column()</function>. <classname>TreeModelSort</classname> is a model that contains another model, presenting a sorted version of that model. For instance, you might add a sorted version of a model to a <classname>TreeView</classname> like so:
</para>
<programlisting>Glib::RefPtr&lt;Gtk::TreeModelSort&gt; sorted_model =
    Gtk::TreeModelSort::create(model);
sorted_model->set_sort_column(columns.m_col_name, Gtk::SORT_ASCENDING);
treeview.set_model(sorted_model);</programlisting>

<para>Note, however, that the TreeView will provide iterators to the sorted model. You must convert them to iterators to the underlying child model in order to perform actions on that model. For instance:
</para>
<programlisting>void ExampleWindow::on_button_delete()
{
  Glib::RefPtr&lt;Gtk::TreeSelection&gt; refTreeSelection =
      m_treeview.get_selection();
  if(refTreeSelection)
  {
    Gtk::TreeModel::iterator sorted_iter =
        m_refTreeSelection->get_selected();
    if(sorted_iter)
    {
      Gtk::TreeModel::iterator iter =
          m_refModelSort->convert_iter_to_child_iter(sorted_iter);
      m_refModel->erase(iter);
    }
  }
}</programlisting>

<para><ulink url="&url_refdocs_base_gtk;TreeModelSort.html">TreeModelSort Reference</ulink></para>
</sect2>

</sect1>

<sect1 id="sec-treeview-draganddrop">
<title>Drag and Drop</title>
<para>
<classname>Gtk::TreeView</classname> already implments simple drag-and-drop
when used with the <classname>Gtk::ListStore</classname> or
<classname>Gtk::TreeStore</classname> models. If necessary, it also allows you
to implement more complex behaviour when items are dragged and dropped, using
the normal <link linkend="sec-draganddrop">Drag and Drop</link> API.
</para>

<sect2>
<title>Reorderable rows</title>
<para>
If you call <function>Gtk::TreeView::set_reorderable()</function> then your
TreeView's items can be moved within the treeview itself. This is demonstrated
in the <classname>TreeStore</classname> example.
</para>
<para>However, this does not allow you any control of which items can be dragged, and where they can be dropped. If you need that extra control then you might create a derived <literal>Gtk::TreeModel</literal> from <literal>Gtk::TreeStore</literal> or <literal>Gtk::ListStore</literal> and override the <literal>Gtk::TreeDragSource::row_draggable()</literal> and <literal>Gdk::TreeDragDest::row_drop_possible()</literal> virtual methods. You can examine the <literal>Gtk::TreeModel::Path</literal>s provided and allow or disallow dragging or dropping by return <literal>true</literal> or <literal>false</literal>.</para>
<para>This is demonstrated in the drag_and_drop example.</para>
</sect2>

</sect1>

<sect1 id="sec-treeview-contextmenu">
<title>Popup Context Menu</title>
<para>
Lots of people need to implement right-click context menus for
<classname>TreeView</classname>'s so we will explain how to do that  here to
save you some time. Apart from one or two points, it's  much the same as a
normal context menu, as described in the <link linkend="sec-menus-popup">menus
    chapter</link>.
</para>

<sect2>
<title>Handling <literal>button_press_event</literal></title>
<para>
To detect a click of the right mouse button, you need to handle the
<literal>button_press_event</literal> signal, and check exactly which button
was pressed. Because the <classname>TreeView</classname> normally handles this
signal completely, you need to either override the default signal handler in a
derived <classname>TreeView</classname> class, or use
<function>connect_nofify()</function> insted of <function>connect()</function>.
You probably also want to call the default handler before doing anything else,
so that the right-click will cause the row to be selected first.
</para>
<para>This is demonstrated in the Popup Custom Menu example.</para>
</sect2>

</sect1>

<sect1 id="sec-treeview_examples"><title>Examples</title>

<sect2><title>ListStore</title>
<para>
This example has a <classname>Gtk::TreeView</classname> widget, with a
<classname>Gtk::ListStore</classname> model.
</para>


<figure id="figure-treeview-liststore">
  <title>TreeView - ListStore</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;treeview_list.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;treeview/list/">Source Code</ulink></para>

</sect2>

<sect2><title>TreeStore</title>

<para>
This example is very similar to the <classname>ListStore</classname> example,
but uses a <classname>Gtk::TreeStore</classname> model instead, and adds
children to the rows.
</para>

<figure id="figure-treeview-treestore">
  <title>TreeView - TreeStore</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;treeview_tree.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;treeview/tree/">Source Code</ulink></para>

</sect2>

<sect2 id="sec-editable_cells_example"><title>Editable Cells</title>

<para>
This example is identical to the <classname>ListStore</classname> example, but
it uses <function>TreeView::append_column_editable()</function> instead of
<function>TreeView::append_column()</function>.
</para>

<figure id="figure-treeview-editablecells">
  <title>TreeView - Editable Cells</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;treeview_editablecells.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;treeview/editable_cells/">Source Code</ulink></para>

</sect2>

<sect2><title>Drag and Drop</title>

<para>
This example is much like the <classname>TreeStore</classname> example, but has
2 extra columns to indicate whether the row can be dragged, and whether it can
receive drag-and-dropped rows. It uses a derived
<classname>Gtk::TreeStore</classname> which overrides the virtual functions as
described in the <link linkend="sec-treeview-draganddrop">TreeView Drag and
    Drop</link> section..
</para>

<figure id="figure-treeview-draganddrop">
  <title>TreeView - Drag And Drop</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;treeview_draganddrop.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;treeview/drag_and_drop/">Source Code</ulink></para>

</sect2>

<sect2><title>Popup Context Menu</title>

<para>
This example is much like the <classname>ListStore</classname> example, but
derives a custom <classname>TreeView</classname> in order to override the
<literal>button_press_event</literal>, and also to encapsulate the tree model
code in our derived class. See the <link
    linkend="sec-treeview-contextmenu">TreeView Popup Context Menu</link>
section.
</para>

<figure id="figure-treeview-popup">
  <title>TreeView - Popup Context Menu</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;treeview_popup.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;treeview/popup/">Source Code</ulink></para>

</sect2>


</sect1>

</chapter>


<chapter id="sec-chapter-comboboxes">
<title>Combo Boxes</title>

<para>The <classname>ComboBox</classname> and <classname>ComboBoxEntry</classname> widgets offers a list (or tree) of choices in a dropdown menu. If appropriate, they can show extra information about each item, such as text, a picture, a checkbox, or a progress bar. The <classname>ComboBox</classname> widget restricts the user to the available choices, but the <classname>ComboBoxEntry</classname> contains an <classname>Entry</classname>, allowing the user to enter arbitrary text if the none of the available choices are suitable.
</para>

<para>For both widgets, the list is provided via a <classname>TreeModel</classname>, and columns from this model are added to the ComboBox's view with the <function>ComboBox::pack_start()</function>. This provides a great deal of flexibility and compile-time type-safety, but the <classname>ComboBoxText</classname> and <classname>ComboBoxEntryText</classname> classes provide a simple text-based specialisation in case that flexibility is not required.
</para>

<sect1 id="sec-combobox">
<title>ComboBox</title>

<para><ulink url="&url_refdocs_base_gtk;ComboBox.html">Reference</ulink></para>

<sect2 id="sec-combobox-model">
<title>The model</title>
<para>The model for a ComboBox can be defined and filled exactly as for a <classname>TreeView</classname>. For instance, you might derive a ComboBox class with one integer and one text columns, like so:
</para>
<programlisting>ModelColumns()
{ add(m_col_id); add(m_col_name); }

  Gtk::TreeModelColumn&lt;int&gt; m_col_id;
  Gtk::TreeModelColumn&lt;Glib::ustring&lt; m_col_name;
};

ModelColumns m_columns;</programlisting>

<para>After appending rows to this model, you should provide the model to the <classname>ComboBox</classname> with the <function>set_model()</function> method. Then use the <function>pack_start()</function> or <function>pack_end()</function> methods to specify what methods will be displayed in the ComboBox. As with the TreeView you may either use the default cell renderer by passing the <classname>TreeModelColumn</classname> to the pack methods, or you may instantiate a specific <classname>CellRenderer</classname> and specify a particular mapping with either <function>add_attribute()</function> or <function>set_cell_data_func()</function>. Note that these methods are in the <classname>CellLayout</classname> base class.</para>
</sect2>

<sect2 id="sec-combobox-get">
<title>The chosen item</title>
<para>To discover what item, if any, the user has chosen from the ComboBox, call <function>ComboBox::get_active()</function>. This returns a <classname>TreeModel::iterator</classname> that you can dereference to a <classname>Row</classname> in order to read the values in your columns. For instance, you might read an integer ID value from the model, even though you have chosen only to show the human-readable description in the Combo. For instance:
</para>
<programlisting>Gtk::TreeModel::iterator iter = m_Combo.get_active();
if(iter)
{
  Gtk::TreeModel::Row row = *iter;

  //Get the data for the selected row, using our knowledge
  //of the tree model:
  int id = row[m_Columns.m_col_id];
  set_something_id_chosen(id); //Your own function.
}
else
  set_nothing_chosen(); //Your own function.</programlisting>
</sect2>

<sect2 id="sec-combobox-changes">
<title>Responding to changes</title>
<para>
You might need to react to every change of selection in the ComboBox, for instance to update other widgets. To do so, you should handle the &quot;changed&quot; signal. For instance:
</para>
<programlisting>m_combo.signal_changed().connect( sigc::mem_fun(*this,
      &amp;ExampleWindow::on_combo_changed) );</programlisting>
</sect2>

<sect2><title>Full Example</title>

<figure id="figure-combobox_complex">
  <title>ComboBox</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;combobox_complex.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;combobox/complex">Source Code</ulink></para>

</sect2>

<sect2><title>Simple Text Example</title>

<figure id="figure-combobox_text">
  <title>ComboBox</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;combobox_text.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;combobox/text">Source Code</ulink></para>

</sect2>

</sect1>

<sect1 id="sec-comboboxentry">
<title>ComboBoxEntry</title>

<para><ulink url="&url_refdocs_base_gtk;ComboBoxEntry.html">Reference</ulink></para>

<sect2 id="sec-comboboxentry-text-column">
<title>The text column</title>
<para>Unlike a regular <classname>ComboBox</classname>, a <classname>ComboBoxEntry</classname> contains a <classname>Entry</classname> widget for entering of arbitrary text. So that this Entry can interact with the drop-down list of choices, you must specify which of your model columns are the text column, with <function>set_text_column()</function>. For instance:
<programlisting>m_combo.set_text_column(m_columns.m_col_name);</programlisting>
</para>
<para>
When you select a choice from the drop-down menu, the value from this column will be placed in the <classname>Entry</classname>.
</para>
</sect2>

<sect2 id="sec-comboboxentry-model">
<title>The entry</title>
<para>Because the user may enter arbitrary text, an active model row isn't enough to tell us what text the user has inputted. Therefore, you should retrieve the <classname>Entry</classname> widget with the <function>ComboBoxEntry::get_entry()</function> method and call <function>get_text()</function> on that.
</para>
</sect2>

<sect2><title>Full Example</title>

<figure id="figure-comboboxentry_complex">
  <title>ComboBoxEntry</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;comboboxentry_complex.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;comboboxentry/complex">Source Code</ulink></para>

</sect2>

<sect2><title>Simple Text Example</title>

<figure id="figure-comboboxentry_text">
  <title>ComboBoxEntryText</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;comboboxentry_text.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;comboboxentry/text">Source Code</ulink></para>

</sect2>




</sect1>

</chapter>


<chapter id="sec-chapter-textview">
<title>TextView</title>
<para>
The <classname>TextView</classname> widget can be used to display and edit
large amounts of formatted text. Like the <classname>TreeView</classname>, it
has a model/view design. In this case the <classname>TextBuffer</classname> is
the model.
</para>

<sect1>
<title>The Buffer</title>
<para>
<classname>Gtk::TextBuffer</classname> is a model containing the data for the
<classname>Gtk::TextView</classname>, like the
<classname>Gtk::TreeModel</classname> used by <classname>Gtk::TreeView</classname>.
This allows two or more <classname>Gtk::TextView</classname>s to share the same
<classname>TextBuffer</classname>, and allows those TextBuffers to be displayed
slightly differently. Or you could maintain several
<classname>Gtk::TextBuffer</classname>s and choose to display each one at different
times in the same <classname>Gtk::TextView</classname> widget.
</para>
<para>
The <classname>TextView</classname> creates its own default
<classname>TextBuffer</classname>, which you can access via the
<function>get_buffer()</function> method.
</para>

<para><ulink url="&url_refdocs_base_gtk;TextBuffer.html">Reference</ulink></para>

<sect2>
<title>Iterators</title>
<para>
</para>
</sect2> 

<sect2>
<title>Tags and Formatting</title>

<sect3>
<title>Tags</title>
<para>
To specify that some text in the buffer should have specific formatting, you must define a tag to hold that formatting information, and then apply that tag to the region of text. For instance, to define the tag and its properties:
</para>
<programlisting>Glib::RefPtr&lt;Gtk::TextBuffer::Tag&gt; refTagMatch =
    Gtk::TextBuffer::Tag::create();
refTagMatch-&gt;property_background() = "orange";</programlisting>
<para>
You can specify a name for the <classname>Tag</classname> when using the
<function>create()</function> method, but it is not necessary.
</para>

<para>
The <classname>Tag</classname> class has many other properties.
</para>

<para><ulink url="&url_refdocs_base_gtk;TextTag.html">Reference</ulink></para>

</sect3>

<sect3>
<title>TagTable</title>

<para>
Each <classname>Gtk::TextBuffer</classname> uses a
<classname>Gtk::TextBuffer::TagTable</classname>, which contains the
<classname>Tag</classname>s for that buffer. 2 or more
<classname>TextBuffer</classname>s may share the same
<classname>TagTable</classname>. When you create <classname>Tag</classname>s
you should add them to the <classname>TagTable</classname>. For instance:
</para>
<programlisting>Glib::RefPtr&lt;Gtk::TextBuffer::TagTable&gt; refTagTable =
    Gtk::TextBuffer::TagTable::create();
refTagTable-&gt;add(refTagMatch);
//Hopefully a future version of &gtkmm; will have a set_tag_table() method,
//for use after creation of the buffer.
Glib::RefPtr&lt;Gtk::TextBuffer&gt; refBuffer =
    Gtk::TextBuffer::create(refTagTable);</programlisting>

<para>
You can also use <function>get_tag_table()</function> to get, and maybe modify,
the <classname>TextBuffer</classname>'s default <classname>TagTable</classname>
instead of creating one explicitly.
</para>

<para><ulink url="&url_refdocs_base_gtk;TextTagTable.html">Reference</ulink></para>

</sect3>

<sect3>
<title>Applying Tags</title>
<para>
If you have created a <classname>Tag</classname> and added it to the
<classname>TagTable</classname>, you may apply that tag to part of the
<classname>TextBuffer</classname> so that some of the text is displayed with that
formatting. You define the start and end of the range of text by specifying
<classname>Gtk::TextBuffer::iterator</classname>s. For instance:
</para>
<programlisting>refBuffer-&gt;apply_tag(refTagMatch, iterRangeStart, iterRangeStop);</programlisting>
<para>
Or you could specify the tag when first inserting the text:
refBuffer-&gt;insert_with_tag(iter, "Some text", refTagMatch);
</para>

<para>
You can apply more than one <classname>Tag</classname> to the same text, by
using <function>apply_tag()</function> more than once, or by using
<function>insert_with_tags()</function>. The <classname>Tag</classname>s might
specify different values for the same properties, but you can resolve these
conflicts by using <function>Tag::set_priority()</function>.
</para>

</sect3>
</sect2>

<sect2>
<title>Marks</title>
<para>
<classname>TextBuffer</classname> iterators are generally invalidated when the
text changes, but you can use a <classname>Gtk::TextBuffer::Mark</classname> to
remember a position in these situations. For instance,
</para>
<programlisting>Glib::RefPtr&lt;Gtk::TextBuffer::Mark&gt; refMark =
    refBuffer-&gt;create_mark(iter);</programlisting>

<para>
You can then use the <function>get_iter()</function> method later to create an
iterator for the <classname>Mark</classname>'s new position.
</para>

<para>
There are two built-in <classname>Mark</classname>s - <literal>insert</literal>
and <literal>select_bound</literal>, which you can access with
<classname>TextBuffer</classname>'s <function>get_insert()</function> and
<function>get_selection_bound()</function> methods.
</para>

<para><ulink url="&url_refdocs_base_gtk;TextMark.html">Reference</ulink></para>

</sect2>

<sect2>
<title>The View</title>
<para>
As mentioned above, each <classname>TextView</classname> has a
<classname>TextBuffer</classname>, and one or more
<classname>TextView</classname> can share the same
<classname>TextBuffer</classname>. 
</para>

<para>
Like the <classname>TreeView</classname>, you should probably put your
<classname>TextView</classname> inside a <classname>ScrolledWindow</classname>
to allow the user to see and move around the whole text area with
scrollbars.
</para>

<para><ulink url="&url_refdocs_base_gtk;TextView.html">Reference</ulink></para>

<sect3>
<title>Default formatting</title>
<para>
<classname>TextView</classname> has various methods which allow you to change
the presentation of the buffer for this particular view. Some of these may be
overridden by the <classname>Gtk::TextTag</classname>s in the buffer, if they
specify the same things. For instance, <function>set_left_margin()</function>,
<function>set_right_margin()</function>, <function>set_indent()</function>,
etc.
</para>
</sect3>

<sect3>
<title>Scrolling</title>
<para>
<classname>Gtk::TextView</classname> has various
<function>scroll_to_*()</function> methods. These allow you to ensure that a
particular part of the text buffer is visible. For instance, your application's
Find feature might use <function>Gtk::TextView::scroll_to_iter()</function> to
show the found text.
</para>
</sect3>

</sect2>


</sect1>

<sect1 id="sec-widgets_and_childanchors">
<title>Widgets and ChildAnchors</title>
<para>
You can embed widgets, such as <classname>Gtk::Button</classname>s, in the
text. Each such child widget needs a <classname>ChildAnchor</classname>.
ChildAnchors are associated with <classname>iterators</classname>. For
instance, to create a child anchor at a particular position, use
<function>Gtk::TextBuffer::create_child_anchor()</function>:
</para>
<programlisting>Glib::RefPtr&lt;Gtk::TextChildAnchor&gt; refAnchor =
    refBuffer-&gt;create_child_anchor(iter);</programlisting>

<para>
Then, to add a widget at that position, use
<function>Gtk::TextView::add_child_at_anchor()</function>:
</para>
<programlisting>m_TextView.add_child_at_anchor(m_Button, refAnchor);</programlisting>

<para><ulink url="&url_refdocs_base_gtk;TextChildAnchor.html">Reference</ulink></para>

</sect1>

<sect1 id="sec-examples"><title>Examples</title>

<sect2><title>Simple Example</title>

<figure id="figure-textview">
  <title>TextView</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;textview.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;textview/">Source Code</ulink></para>

</sect2>

</sect1>

</chapter>

<chapter id="sec-MenusAndToolbars">
<title>Menus and Toolbars</title>

<para>
There are specific APIs for Menus and toolbars, but you should usually deal
with them together, using the <classname>UIManager</classname> to define
<classname>Action</classname>s which you can then arrange in menu and toolbars.
In this way you can handle activation of the action instead of responding to
the menu and toolbar items separately. And you can enable or disable both the
menu and toolbar item via the action.
</para>
<para>
This involves the use of the <classname>Gtk::ActionGroup</classname>,
<classname>Gtk::Action</classname>, and <classname>UIManager</classname>
classes, all of which should be instantiated via their
<function>create()</function> methods, which return
<classname>RefPtr</classname>s.
</para>

<sect1>
<title>Actions</title>
<para>
First create the <classname>Action</classname>s and add them to an
<classname>ActionGroup</classname>, with
<function>ActionGroup::add()</function>.
</para>

<para>
The arguments to <function>Action::create()</function> specify the action's
name and how it will appear in menus and toolbars. Use stock items where
possible so that you don't need to specify the label, accelerator, icon, and
tooltips, and so you can use pre-existing translations.
</para>
<para>
You can also specify a signal handler when calling
<function>ActionGroup::add()</function>. This signal handler will be called
when the action is activated via either a menu item or a toolbar button.
</para>
<para>Note that you must specify actions for sub menus as well as menu items.</para>

<para>For instance:
</para>
<programlisting>m_refActionGroup = Gtk::ActionGroup::create();

m_refActionGroup-&gt;add( Gtk::Action::create(&quot;MenuFile&quot;, &quot;_File&quot;) );
m_refActionGroup-&gt;add( Gtk::Action::create(&quot;New&quot;, Gtk::Stock::NEW),
  sigc::mem_fun(*this, &amp;ExampleWindow::on_action_file_new) );
m_refActionGroup-&gt;add( Gtk::Action::create(&quot;ExportData&quot;, &quot;Export Data&quot;),
  sigc::mem_fun(*this, &amp;ExampleWindow::on_action_file_open) );
m_refActionGroup-&gt;add( Gtk::Action::create(&quot;Quit&quot;, Gtk::Stock::QUIT),
  sigc::mem_fun(*this, &amp;ExampleWindow::on_action_file_quit) );</programlisting>

<para>Note that this is where we specify the names of the actions as they will be seen by users in menus and toolbars. Therefore, this is where you should make strings translatable, by putting them inside the _() macro. When we use the Gtk::Stock items, of course, translations are automatically available.</para>
</sect1>


<sect1>
<title>UIManager</title>
<para>
Next you should create a <classname>UIManager</classname> and add the
<classname>ActionGroup</classname> to the <classname>UIManager</classname> with
<function>insert_action_group()</function> At this point is also a good idea to
tell the parent window to respond to the specified keyboard shortcuts, by using
<function>add_accel_group()</function>.
</para>  

<para>For instance,
</para>
<programlisting>Glib::RefPtr&lt;Gtk::UIManager&gt; m_refUIManager =
    Gtk::UIManager::create();
m_refUIManager-&gt;insert_action_group(m_refActionGroup);
add_accel_group(m_refUIManager-&gt;get_accel_group());</programlisting>
<para>
Then, you can define the actual visible layout of the menus and toolbars, and
add the UI layout to the <classname>UIManager</classname>. This &quot;ui
string&quot; uses an XML format, in which you should mention the names of the
actions that you have already created. For instance:
</para>
<programlisting>Glib::ustring ui_info =
    &quot;&lt;ui&gt;&quot;
    &quot;  &lt;menubar name='MenuBar'&gt;&quot;
    &quot;    &lt;menu action='MenuFile'&gt;&quot;
    &quot;      &lt;menuitem action='New'/&gt;&quot;
    &quot;      &lt;menuitem action='Open'/&gt;&quot;
    &quot;      &lt;separator/&gt;&quot;
    &quot;      &lt;menuitem action='Quit'/&gt;&quot;
    &quot;    &lt;/menu&gt;&quot;
    &quot;    &lt;menu action='MenuEdit'&gt;&quot;
    &quot;      &lt;menuitem action='Cut'/&gt;&quot;
    &quot;      &lt;menuitem action='Copy'/&gt;&quot;
    &quot;      &lt;menuitem action='Paste'/&gt;&quot;
    &quot;    &lt;/menu&gt;&quot;
    &quot;  &lt;/menubar&gt;&quot;
    &quot;  &lt;toolbar  name='ToolBar'&gt;&quot;
    &quot;    &lt;toolitem action='Open'/&gt;&quot;
    &quot;    &lt;toolitem action='Quit'/&gt;&quot;
    &quot;  &lt;/toolbar&gt;&quot;
    &quot;&lt;/ui&gt;&quot;;

m_refUIManager-&gt;add_ui_from_string(ui_info);</programlisting>

<para>Remember that these names are just the identifiers that we used when creating the actions. They are not the text that the user will see in the menus and toolbars. We provided those human-readable names when we created the actions.</para>
<para>
To instantiate a <classname>Gtk::MenuBar</classname> or
<classname>Gtk::Toolbar</classname> which you can actually show, you should use
the <function>UIManager::get_widget()</function> method, and then add the widget
to a container. For instance:
</para>
<programlisting>Gtk::Widget* pMenubar = m_refUIManager-&gt;get_widget(&quot;/MenuBar&quot;);
pBox-&gt;add(*pMenuBar, Gtk::PACK_SHRINK);</programlisting> 

</sect1>


<sect1 id="sec-menus-popup"><title>Popup Menus</title>
<para>
<classname>Menus</classname> are normally just added to a window, but they can
also be displayed temporarily as the result of a mouse button click. For
instance, a context menu might be displayed when the user clicks their right
mouse button.
</para>

<para>The UI layout for a popup menu should use the <literal>popup</literal> node. For instance:
</para>
<programlisting>Glib::ustring ui_info =
    &quot;&lt;ui&gt;&quot;
    &quot;  &lt;popup name='PopupMenu'&gt;&quot;
    &quot;    &lt;menuitem action='ContextEdit'/&gt;&quot;
    &quot;    &lt;menuitem action='ContextProcess'/&gt;&quot;
    &quot;    &lt;menuitem action='ContextRemove'/&gt;&quot;
    &quot;  &lt;/popup&gt;&quot;
    &quot;&lt;/ui&gt;&quot;;

m_refUIManager-&gt;add_ui_from_string(ui_info);</programlisting>

<para>
To show the popup menu, use <classname>Gtk::Menu</classname>'s
<function>popup()</function> method, providing the button identifier and the
time of activation, as provided by the <literal>button_press_event</literal>
signal, which you will need to handle anyway. For instance:
</para>
<programlisting>bool ExampleWindow::on_button_press_event(GdkEventButton* event)
{
  if( (event-&gt;type == GDK_BUTTON_PRESS) &amp;&amp;
      (event-&gt;button == 3) )
  {
    m_Menu_Popup->popup(event-&gt;button, event-&gt;time);
    return true; //It has been handled.
  }
  else
    return false;
}</programlisting>

</sect1>

<sect1><title>Examples</title>

<sect2><title>Main Menu example</title>

<figure id="figure-menus-mainmenu">
  <title>Main Menu</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;main_menu.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;menus/main_menu/">Source Code</ulink></para>

</sect2>

<sect2><title>Popup Menu example</title>

<figure id="figure-menus-popup">
  <title>Popup Menu</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;menu_popup.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;menus/popup/">Source Code</ulink></para>

</sect2>

</sect1>

</chapter>

<chapter id="sec-Adjustment">
<title>Adjustments </title>

<para>
&gtkmm; has various widgets that can be visually adjusted using the mouse or
the keyboard, such as the <classname>Range</classname> widgets (described in
the <link linkend="sec-Range-Widgets">Range Widgets</link> section).  There are
also a few widgets that display some adjustable part of a larger area, such as
the <classname>Viewport</classname> widget. These widgets have
<classname>Gtk::Adjustment</classname> objects that express this common part of
their API.
</para>

<para>
So that applications can react to changes, for instance when a user moves a
scrollbar, <classname>Gtk::Adjustment</classname> has a
<literal>changed</literal> signal. You can then use the
<function>get_changed()</function> method to discover the new value.
</para>

<sect1>
<title>Creating an Adjustment</title>

<para>
The <classname>Gtk::Adjustment</classname> constructor is as follows:
</para>

<programlisting>Gtk::Adjustment(float value,
                float lower,
                float upper,
                float step_increment = 1,
                float page_increment = 10,
                float page_size = 0);</programlisting>

<para>
The <parameter>value</parameter> argument is the initial value of the
adjustment, usually corresponding to the topmost or leftmost position of an
adjustable widget. The <parameter>lower</parameter> and
<parameter>upper</parameter> arguments specifies the possible range of values
which the adjustment can hold.  The
<parameter>step_increment</parameter> argument specifies the smaller of
the two increments by which the user can change the value, while the
<parameter>page_increment</parameter> is the larger one.  The
<parameter>page_size</parameter> argument usually corresponds somehow to
the visible area of a panning widget. The <parameter>upper</parameter> argument
is used to represent the bottom most or right most coordinate in a panning
widget's child.
TODO: Investigate the upper argument properly. There was some unclear stuff about it not always being the upper value.
</para>

</sect1>

<sect1 id="sec-adjustments_the_easy_way">
<title>Using Adjustments the Easy Way</title>

<para>
The adjustable widgets can be roughly divided into those which use and
require specific units for these values, and those which treat them as
arbitrary numbers.
</para>
<para>
The group which treats the values as arbitrary numbers includes the
<classname>Range</classname> widgets (<classname>Scrollbars</classname> and
<classname>Scales</classname>, the <classname>Progressbar</classname> widget,
and the <classname>SpinButton</classname> widget). These widgets  are typically
"adjusted" directly by the user with the mouse or keyboard. They will treat the
<parameter>lower</parameter> and <parameter>upper</parameter> values of an
adjustment as a range within which the user can manipulate the adjustment's
<parameter>value</parameter>. By default, they will only modify the
<parameter>value</parameter> of an adjustment.
</para>

<para>
The other group includes the <classname>Viewport</classname> widget and the
<classname>ScrolledWindow</classname> widget. All of these widgets use pixel
values for their adjustments. These are also typically adjusted indirectly
using scrollbars.  While all widgets which use adjustments can either create
their own adjustments or use ones you supply, you'll generally want to let this
particular category of widgets create its own adjustments.
</para>

<para>
TODO: Text widget is deprecated: Look at GTK+ tutorial for up-to-date example.
If you share an adjustment object between a Scrollbar and a Text
widget, manipulating the scrollbar will automagically adjust the Text
widget. You can set it up like this:
</para>
<programlisting>// creates its own adjustments
Gtk::Text text(0, 0);
// uses the newly-created adjustment for the scrollbar as well
Gtk::VScrollbar vscrollbar (*(text.get_vadjustment()));</programlisting>

</sect1>

<sect1 id="sec-adjustment_internals">
<title>Adjustment Internals</title>

<para>
OK, you say, that's nice, but what if I want to create my own handlers to
respond when the user adjusts a <classname>Range</classname> widget or a
<classname>SpinButton</classname>.  To access the value of a
<classname>Gtk::Adjustment</classname>, you can use the
<function>get_value()</function> and <function>set_value()</function> methods:
</para>

<para>
As mentioned earlier, <classname>Gtk::Adjustment</classname> can emit signals.
This is, of course, how updates happen automatically when you share an
<classname>Adjustment</classname> object between a
<classname>Scrollbar</classname> and another adjustable widget; all adjustable
widgets connect signal handlers to their adjustment's
<literal>value_changed</literal> signal, as can your program.
</para>

<para>
So, for example, if you have a <classname>Scale</classname> widget, and you
want to change the rotation of a picture whenever its value changes, you would
create a signal handler like this:
</para>
<programlisting>void cb_rotate_picture (Gtk::Widget *picture)
{
  picture-&#62;set_rotation (adj-&#62;value);
...</programlisting>
<para>
and connect it to the scale widget's adjustment like this:
</para>
<programlisting>adj.value_changed.connect(sigc::bind&#60;Widget*&#62;(sigc::mem_fun(*this,
    &amp;cb_rotate_picture), picture));</programlisting>

<para>
What if a widget reconfigures the <parameter>upper</parameter> or
<parameter>lower</parameter> fields of its <classname>Adjustment</classname>,
such as when a user adds more text to a text widget?  In this case, it emits
the <literal>changed</literal> signal.
</para>

<para>
<classname>Range</classname> widgets typically connect a handler to this
signal, which changes their appearance to reflect the change - for example, the
size of the slider in a scrollbar will grow or shrink in inverse proportion to
the difference between the <parameter>lower</parameter> and
<parameter>upper</parameter> values of its
<classname>Adjustment</classname>.
</para>

<para>
You probably won't ever need to attach a handler to this signal, unless you're
writing a new type of range widget.
</para>
<programlisting>adjustment-&#62;changed();</programlisting>

</sect1>

</chapter>

<chapter id="widgets_without_xwindows">
<title>Widgets Without X-Windows</title>

<para>
Some Widgets do not have an associated X-Window, so they therefore do not
receive X events. This means that the signals described in the  <link
    linkend="sec-xeventsignals">X event signals</link> section will not be
emitted. If you want to capture events for these widgets you can use a special
container called <classname>Gtk::EventBox</classname>, which is described in
the <link linkend="sec-EventBox">EventBox</link> section.
</para>

<para>
Here is a list of some of these Widgets:
</para>
<programlisting>Gtk::Alignment
Gtk::Arrow
Gtk::Bin
Gtk::Box
Gtk::Button
Gtk::CheckButton
Gtk::Fixed
Gtk::Image
Gtk::Item
Gtk::Label
Gtk::MenuItem
Gtk::Notebook
Gtk::Paned
Gtk::Pixmap
Gtk::RadioButton
Gtk::Range
Gtk::ScrolledWindow
Gtk::Separator
Gtk::Table
Gtk::Toolbar
Gtk::AspectFrame
Gtk::Frame
Gtk::VBox
Gtk::HBox
Gtk::VSeparator
Gtk::HSeparator</programlisting>

<para>
These widgets are mainly used for decoration or layout, so you won't often need
to capture events on them. They are intended to have no X-Window in order to improve performance.
</para>

<sect1 id="sec-EventBox">
<title>EventBox</title>

<para>
TODO: Why don't they have X Windows - explain clipping.
Some &gtkmm; widgets don't have associated X windows; they draw on
their parents' windows.  Because of this, they cannot receive events.
Also, if they are incorrectly sized, they don't clip, so you can get
messy overwriting etc. If you require more from these widgets, the
<classname>EventBox</classname> is for you.  Although the name
<classname>EventBox</classname> emphasises the event-handling method, the
widget can also be used for clipping (and more; see the example below).
</para>

<para>
The constructor for <classname>Gtk::EventBox</classname> is:
</para>

<programlisting>Gtk::EventBox();</programlisting>

<para>
A child widget can be added to the <classname>EventBox</classname> using:
</para>

<programlisting>event_box.add(child_widget);</programlisting>

<para><ulink url="&url_refdocs_base_gtk;EventBox.html">Reference</ulink></para>

<sect2>
<title>Example</title>
<para>
The following example demonstrates both uses of an
<classname>EventBox</classname> - a label is created that is clipped to a small
box, and set up so that a mouse-click on the label causes the program to exit.
Resizing the window reveals varying amounts of the label.
</para>

<figure id="figure-eventbox">
  <title>EventBox</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;eventbox.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;eventbox">Source Code</ulink></para>
</sect2>

</sect1>

</chapter>

<chapter id="sec-Dialogs">
<title>Dialogs</title>

<para>
Dialogs are used as secondary windows, to provide specific information or to
ask questions. <classname>Gtk::Dialog</classname> windows contain a few pre-packed
widgets to ensure consistency, and a <function>run()</function> method which
blocks until the user dismisses the dialog.
</para>

<para>
There are several derived <classname>Dialog</classname> classes which you might
find useful.  <classname>Gtk::MessageDialog</classname> is used for most simple
notifications. But at other times you might need to derive your own dialog
class to provide more complex functionality.
</para>

<para>
To pack widgets into a custom dialog, you should pack them into the
<classname>Gtk::VBox</classname>, available via
<function>get_vbox()</function>.  To just add a <classname>Button</classname>
to the bottom of the <classname>Dialog</classname>, you could use the
<function>add_button()</function> method.
</para>

<para>
The <function>run()</function> method returns an <literal>int</literal>. This
may be a value from the <literal>Gtk::ResponseType</literal> if the user
closed the button by clicking a standard button, or it could be the custom
response value that you specified when using <function>add_button()</function>.
</para>

<para><ulink url="&url_refdocs_base_gtk;Dialog.html">Reference</ulink></para>

<sect1 id="sec-dialogs_messagedialog"><title>MessageDialog</title>
<para>
<classname>MessageDialog</classname> is a convenience class, used to create
simple, standard message dialogs, with a message, an icon, and buttons for user
response. You can specify the type of message and the text in the constructor,
as well as specifying standard buttons via the
<literal>Gtk::ButtonsType</literal> enum.
</para>

<para><ulink url="&url_refdocs_base_gtk;MessageDialog.html">Reference</ulink></para>

<sect2>
<title>Example</title>

<figure id="figure-dialogs-messagedialog">
  <title>MessageDialog</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;dialogs_messagedialog.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;dialogs/messagedialog">Source Code</ulink></para>
</sect2>

</sect1>

<sect1 id="sec-dialogs_filechooserdialog"><title>FileChooserDialog</title>
<para>
The <classname>FileChooserDialog</classname> is suitable for use with
&quot;Open&quot; or &quot;Save&quot; menu items. 
</para>
<para>
Most of the useful member methods for this class are actually in the
<classname>Gtk::FileChooser</classname> base class.
</para>

<para><ulink url="&url_refdocs_base_gtk;FileChooserDialog.html">Reference</ulink></para>

<sect2>
<title>Example</title>

<figure id="figure-dialogs-filechooser">
  <title>FileChooser</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;dialogs_filechooser.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;dialogs/filechooserdialog">Source Code</ulink></para>
</sect2>
</sect1>

<sect1 id="sec-color_selection_dialog"><title>ColorSelectionDialog</title>
<para>
The <classname>ColorSelectionDialog</classname> allows the user to choose a
color.
</para>

<para><ulink url="&url_refdocs_base_gtk;ColorSelectionDialog.html">Reference</ulink></para>

<sect2>
<title>Example</title>

<figure id="figure-dialogs-colorselectiondialog">
  <title>ColorSelectionDialog</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;dialogs_colorselectiondialog.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;dialogs/colorselectiondialog">Source Code</ulink></para>
</sect2>

</sect1>

<sect1 id="sec-font_selection_dialog"><title>FontSelectionDialog</title>
<para>
The <classname>FontSelectionDialog</classname> allows the user to choose a
font.
</para>

<para><ulink url="&url_refdocs_base_gtk;FontSelectionDialog.html">Reference</ulink></para>

<sect2>
<title>Example</title>

<figure id="figure-dialogs-fontselectiondialog">
  <title>FontSelectionDialog</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;dialogs_fontselectiondialog.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;dialogs/fontselectiondialog">Source Code</ulink></para>
</sect2>

</sect1>


</chapter>

<chapter id="sec-drawingarea">
  <title>The Drawing Area Widget</title>
  <para>
    The <classname>DrawingArea</classname> widget is a blank window that gives
    you the freedom to create any graphic you desire. Along with that freedom
    comes the responsibility to handle expose events on the widget. When a
    widget is first shown, or when it is covered and then uncovered again it
    needs to redraw itself. Most widgets have code to do this, but the
    DrawingArea  does not, allowing you to write your own expose event signal
    handler to determine how the contents of the widget will be drawn.  This is
    most often done by overriding the virtual
    <function>on_expose_event()</function> member function.  
  </para>
  <note>
  <para>
      Before &gtkmm; version 2.10, drawing was mostly done with Graphics Contexts
      (<classname>Gdk::GC</classname>) and other GDK drawing functions, but this
      has been largely superceded by the <ulink
          url="http://cairographics.org">Cairo</ulink> graphics library and its
      C++ binding <application>Cairomm</application>. See the <link linkend="sec-appendix-gdk-drawing">Gdk Appendix</link> for a description of the deprecated GDK techniques. In general, the Cairo drawing API is simpler than the GDK one, and it is
      generally recommended to use the Cairo drawing methods wherever possible
      in preference to the older GDK drawing methods.
  </para>
  </note>
  
  <para>
      You can draw very sophisticated shapes using Cairo, but the methods to do
      so are quite basic.  Cairo provides methods for drawing straight lines,
      curved lines, and arcs (including circles).  These basic shapes can be
      combined to create more complex shapes and paths which can be filled with
      solid colors, gradients, patterns, and other things.  In addition, Cairo
      can perform complex transformations, do compositing of images, and render
      antialiased text.
  </para>
  <note>
      <title>Cairo and Pango</title>
      <para>Although Cairo can render text, it's not meant to be a replacement for
      Pango.  Pango is a better choice if you need to perform more advanced
      text rendering such as wrapping or ellipsizing text.  Drawing text with
      Cairo should only be done if the text is part of a graphic.</para>
  </note>
  <para>
      In this section of the tutorial, we'll cover the basic Cairo drawing
      model, describe each of the basic drawing elements in some detail (with
      examples), and then present a simple application that uses Cairo to draw
      a custom clock widget. 
  </para>
  <sect1 id="sec-cairo_drawing_model">
    <title>The Cairo Drawing Model</title>
    <para>
        The basic concept of drawing in Cairo involves defining 'invisible'
        paths and then stroking or filling them to make them visible.  
    </para>
    <para>
        To do any drawing in &gtkmm; with Cairo, you must first create a
        <classname>Cairo::Context</classname> object. This class holds all of the graphics state parameters that
        describe how drawing is to be done.  This includes information such as
        line width, color, the surface to draw to, and many other things.  This
        allows the actual drawing functions to take fewer arguments to simplify
        the interface.  In &gtkmm;, a <classname>Cairo::Context</classname> is
        created by calling the
        <function>Gdk::Window::create_cairo_context()</function> function.
        Since Cairo context are reference-counted objects, this function
        returns a <classname>Cairo::RefPtr&lt;Cairo::Context&gt;</classname>
        object.
    </para>
    <para>
        The following example shows  how to set up a Cairo context with a
        foreground color of red and a width of 2.  Any drawing functions that
        use this context will use these settings.
    </para>
    <programlisting>Gtk::DrawingArea myArea;
Cairo::RefPtr&lt;Cairo::Context&gt; myContext = myArea.get_window()->create_cairo_context();
myContext->set_source_rgb(1.0, 0.0, 0.0);
myContext->set_line_width(2.0);</programlisting>
    <para>
        Each <classname>Cairo::Context</classname> is associated with a
        particular <classname>Gdk::Window</classname>, so the first line of the
        above example creates a <classname>Gtk::DrawingArea</classname> widget
        and the second line uses its associated
        <classname>Gdk::Window</classname> to create a
        <classname>Cairo::Context</classname> object.  The final two lines
        change the graphics state of the context.
    </para>
    <para>
        There are a number of graphics state variables that can be set for a
        Cairo context.  The most common context attributes are color (using
        <function>set_source_rgb()</function> or
        <function>set_source_rgba()</function> for translucent colors), line
        width (using <function>set_line_width()</function>), line dash pattern
        (using <function>set_dash()</function>), line cap style (using
        <function>set_line_cap()</function>), and line join style (using
        <function>set_line_join()</function>), and font styles (using
        <function>set_font_size()</function>,
        <function>set_font_face()</function> and others).
        There are many other settings as well, such as transformation matrices,
        fill rules, whether to perform antialiasing, and others.  For further
        information, see the Cairomm API documentation.
    </para>
    <para>
        The current state of a <classname>Cairo::Context</classname> can be
        saved to an internal stack of saved states and later be restored to the
        state it was in when you saved it.  To do this, use the
        <function>save()</function>
        method and the <function>restore()</function> method.  This can be
        useful if you need to temporarily change the line width and color (or
        any other graphics setting) in order to draw something and then return
        to the previous settings.  In this situation, you could call
        <function>Cairo::Context::save()</function>, change the graphics
        settings, draw the lines, and then call
        <function>Cairo::Context::restore()</function> to restore the original
        graphics state.  Multiple calls to <function>save()</function> and
        <function>restore()</function> can be nested; each call to
        <function>restore()</function> restores the state from the
        matching paired <function>save()</function>.
        <tip>
            <para>It is good practice to put all modifications to the graphics state
            between <function>save()</function>/<function>restore()</function>
            function calls. For example, if you have a function that takes a
            <classname>Cairo::Context</classname> reference as an argument, you
            might implement it as follows:
          </para>
          <programlisting>void doSomething(Cairo::RefPtr&lt;Cairo::Context&gt; context, int x)
{
    context->save();
    // change graphics state
    // peform drawing operations
    context->restore();
}</programlisting>
        </tip>
    </para>
  </sect1>
  <sect1 id="sec-drawing_lines">
    <title>Drawing Straight Lines</title>
    <para>
        Now that we understand the basics of the Cairo graphics library, we're
        almost ready to start drawing.  We'll start with the simplest of
        drawing elements: the straight line.  But first you need to know a
        little bit about Cairo's coordinate system.  The origin of the Cairo
        coordinate system is located in the upper-left corner of the window
        with positive x values to the right and positive y values going down.
        <tip>
            <para>Since the Cairo graphics library was written with support for
            multiple output targets (the X window system, PNG images, OpenGL,
            etc), there is a distinction between user-space and device-space
            coordinates.  The mapping between these two coordinate systems
            defaults to one-to-one so that integer values map roughly to pixels
            on the screen, but this setting can be adjusted if desired.
            Sometimes it may be useful to scale the coordinates so that the
            full width and height of a window both range from 0 to 1 (the 'unit
            square') or some other mapping that works for your application.
            this can be done with the
            <function>Cairo::Context::scale()</function> function.</para>
        </tip>
    </para>

    <sect2><title>Example</title>
    <para>
        In this example, we'll construct a small but fully functional &gtkmm;
        program and draw some lines into the window.  The lines are drawn by
        creating a path and then stroking it.  A path is created using the
        functions <function>Cairo::Context::move_to()</function> and
        <function>Cairo::Context::line_to()</function>. The function
        <function>move_to()</function> is similar to the act of lifting your
        pen off of the paper and placing it somewhere else -- no line is drawn
        between the point you were at and the point you moved to.  To draw a
        line between two points, use the <function>line_to()</function>
        function. 
    </para>
    <para>
        After you've finished creating your path, you still haven't
        drawn anything visible yet.  To make the path visible, you must use the
        function <function>stroke()</function> which will stroke the current
        path with the line width and style specified in your
        <classname>Cairo::Context</classname> object.  After stroking, the
        current path will be cleared so that you can start on your next path.
    </para>
        <tip>
            <para>Many Cairo drawing functions have a <function>_preserve()</function>
            variant.  Normally drawing functions such as
            <function>clip()</function>, <function>fill()</function>, or
            <function>stroke()</function> will clear the current path.  If you
            use the <function>_preserve()</function> variant, the current path
            will be retained so that you can use the same path with the next
            drawing function.</para>
        </tip>

    <figure id="figure-drawingarea-lines">
      <title>Drawing Area - Lines</title>
      <screenshot>
        <graphic format="PNG" fileref="&url_figures_base;drawingarea_lines.png"/>
      </screenshot>
    </figure>

    <para><ulink url="&url_examples_base;drawingarea/simple">Source Code</ulink></para>

    <para>
        This program contains a single class, <classname>MyArea</classname>,
        which is a subclass of <classname>Gtk::DrawingArea</classname> and
        contains an <function>on_expose_event()</function> member function.
        This method is called whenever the image in the drawing area needs to
        be redrawn.  This function is passed a pointer to a
        <classname>GdkEventExpose</classname> structure which defines the area
        that needs to be redrawn.  We use these values to create a rectangle
        path in Cairo (using the <function>rectangle()</function> function) and
        then <function>clip()</function> to this path.  The
        <function>clip()</function> function sets a clip region.  The current
        clip region affects all drawing operations by effectively masking out
        any changes to the surface that are outside the current clip region.
        This allows us to limit our redrawing to only the area that needs to be
        redrawn. 
        The actual drawing code sets the color we want to use for drawing by
        using <function>set_source_rgb()</function> which takes arguments
        defining the Red, Green, and Blue components of the desired color
        (valid values are between 0 and 1).  After setting the color, we
        created a new path using the functions <function>move_to()</function>
        and <function>line_to()</function>, and then stroked this path with
        <function>stroke()</function>.
    </para>
    <tip>
        <title>Drawing with relative coordinates</title>
        <para>In the example above we drew everything using absolute coordinates.  You can also draw using
        relative coordinates.  For a straight line, this is done with the
        function <function>Cairo::Context::rel_line_to()</function>.</para>
    </tip>
    </sect2>
    <sect2>
        <title>Line styles</title>
        <para>
            In addition to drawing basic straight lines, there are a number of
            things that you can customize about a line.  You've already seen
            examples of setting a line's color and width, but there are others
            as well.  
        </para>
        <para>
            If you've drawn a series of lines that form a path, you may
            want them to join together in a certain way.  Cairo offers
            three different ways to join lines together: Miter, Bevel, and
            Round.  These are show below:
        </para>
        <figure id="figure-cairo-joins">
            <title>Different join types in Cairo</title>
            <screenshot>
                <graphic format="PNG" fileref="&url_figures_base;cairo_joins.png"/>
            </screenshot>
        </figure>
        <para>
            The line join style is set using the function
            <function>Cairo::Context::set_line_join()</function>.
        </para>
        <para>
            Line ends can have different styles as well.  The default style
            is for the line to start and stop exactly at the destination
            points of the line.  This is called a Butt cap.  The other
            options are Round (uses a round ending, with the center of the
            circle at the end point) or Square (uses a squared ending, with
            the center of the square at the end point).  This setting is set
            using the function
            <function>Cairo::Context::set_line_cap()</function>.
        </para>
        <para>
            There are other things you can customize as well, including
            creating dashed lines and other things.  For more information , see
            the Cairo API documentation.
        </para>
    </sect2>
</sect1>
    <sect1>
        <title>Drawing Curved Lines</title>
        <para>
            In addition to drawing straight lines Cairo allows you to easily
            draw curved lines (technically a cubic Bézier spline) using the
            <function>Cairo::Context::curve_to()</function> and
            <function>Cairo::Context::rel_curve_to()</function> functions.
            These functions take coordinates for a destination point as well as
            coordinates for two 'control' points.  This is best explained using
            an example, so let's dive in.
        </para>
        <sect2>
            <title>Example</title>
            <para>
                This simple application draws a curve with Cairo and displays
                the control points for each end of the curve.
            </para>
        <figure id="figure-drawingarea-curve">
            <title>Drawing Area - Lines</title>
            <screenshot>
                <graphic format="PNG" fileref="&url_figures_base;drawingarea_curve.png"/>
            </screenshot>
        </figure>

        <para><ulink url="&url_examples_base;drawingarea/curve">Source Code</ulink></para>
        <para>
            The only difference between this example and the straight line
            example is in the <function>on_expose_event()</function> function,
            but there are a few new concepts and functions introduced here, so
            let's examine them briefly.
        </para>
        <para>
            Note that we clip to the area that needs re-exposing just as we did
            in the last example.  After clipping, however, we make a call to
            <function>Cairo::Context::scale()</function>, passing in the width
            and height of the drawing area.  This scales the user-space
            coordinate system such that the the width and height of the widget
            are both equal to 1.0 'units'.  There's no particular reason to
            scale the coordinate system in this case, but sometimes it can make
            drawing operations easier.
        </para>
        <para>
            The call to <function>Cairo::Context::curve_to()</function> should
            be fairly self-explanatory.  The first pair of coordinates define
            the control point for the beginning of the curve.  The second set
            of coordinates define the control point for the end of the curve,
            and the last set of coordinates define the destination point.  To
            make the concept of control points a bit easier to visualize, a
            line has been draw from each control point to the end-point on the
            curve that it is associated with.  Note that these control point
            lines are both translucent.  This is achieved with a variant of
            <function>set_source_rgb()</function> called
            <function>set_source_rgba()</function>.  This function takes a
            fourth argument specifying the alpha value of the color (valid
            values are between 0 and 1).
        </para>
        </sect2>
  </sect1>
  <sect1>
      <title>Drawing Arcs and Circles</title>
      <para>
          With Cairo, the same function is used to draw arcs, circles, or
          ellipses: <function>Cairo::Context::arc()</function>.  This function
          takes five arguments.  The first two are the coordinates of the
          center point of the arc, the third argument is the radius of the arc,
          and the final two arguments define the start and end angle of the
          arc.  All angles are defined in radians, so drawing a circle is the
          same as drawing an arc from 0 to 2 * M_PI radians.  
          An angle of 0 is in the direction of the positive X axis (in user-space). An
          angle of M_PI/2 radians (90 degrees) is in the direction of the positive Y axis
          (in user-space). Angles increase in the direction from the positive X axis
          toward the positive Y axis. So with the default transformation matrix, angles
          increase in a clockwise direction.
      </para>
      <para>
          To draw an ellipse, you can scale the current transformation matrix
          by different amounts in the X and Y directions. For example, to draw
          an ellipse in the box given by <varname>x</varname>,
          <varname>y</varname>, <varname>width</varname>,
          <varname>height</varname>:

          <programlisting>context->save();
context->translate(x, y);
context->scale(width / 2.0, height / 2.0);
context->arc(0.0, 0.0, 1.0, 0.0, 2 * M_PI);
context->restore();</programlisting>
          Note that this contradicts the <ulink
              url="http://www.cairographics.org/manual/cairo-Paths.html#cairo-arc">advice
              given in the official Cairo documentation</ulink>, but it seems
          to work.
      </para>
      <sect2>
          <title>Example</title>
          <para>
              Here's an example of a simple program that draws an arc, a circle
              and an ellipse into a drawing area.
          </para>
          <figure id="figure-drawingarea-arc">
              <title>Drawing Area - Arcs</title>
              <screenshot>
                  <graphic format="PNG"
                      fileref="&url_figures_base;drawingarea_arcs.png"/>
              </screenshot>
          </figure>

          <para><ulink url="&url_examples_base;drawingarea/arcs">Source Code</ulink></para>

          <para>
              There are a couple of things to note about this example code.
              Again, the only real difference between this example and the
              previous ones is the <function>on_expose_event()</function>
              function, so we'll limit our focus to that function.  In
              addition, the first part of the function is nearly identical to
              the previous examples, so we'll skip that portion.
          </para>
          <para>
              Note that in this case, we've expressed nearly everything in
              terms of the height and width of the window, including the width
              of the lines.  Because of this, when you resize the window,
              everything scales with the window.  Also note that there are
              three drawing sections in the function and each is wrapped with a
              <function>save()</function>/<function>restore()</function> pair
              so that we're back at a known state after each drawing.
          </para>
          <para>
              The section for drawing an arc introduces one new function,
              <function>close_path()</function>.  This function will in effect
              draw a straight line from the current point back to the first
              point in the path.  There is a significant difference between
              calling <function>close_path()</function> and manually drawing a
              line back to the starting point, however.  If you use
              <function>close_path()</function>, the lines will be nicely
              joined together.  If you use <function>line_to()</function>
              instead, the lines will end at the same point, but Cairo won't do
              any special joining.
          </para>
          <note>
              <title>Drawing counter-clockwise</title>
              <para>
                  The function
                  <function>Cairo::Context::arc_negative()</function> is
                  exactly the same as
                  <function>Cairo::Context::arc()</function> but the angles go
                  the opposite direction.
              </para>
          </note>

      </sect2>
  </sect1>
  <sect1 id="sec-drawing_text">
      <title>Drawing Text</title>
      <sect2>
          <title>Drawing Text with Pango</title>
          <para>
              Text is drawn via Pango Layouts. The easiest way to create a
              <classname>Pango::Layout</classname> is to use
              <function>create_pango_layout</function>. Once created, the layout
              can be manipulated in various ways, including changing the text,
              font, etc. Finally, the layout can be rendered using the
              <function>draw_layout</function> method of
              <classname>Gdk::Drawable</classname>, which takes a
              <classname>Gdk::GC</classname> object, an x-position, a
              y-position and the layout itself.
              TODO: Update this section for Cairo instead of Gdk::GC.
          </para>
      </sect2>

      <!--
      <sect2>
          <title>Drawing Text with Cairo</title>
          <warning>TODO: Add Cairo content.</warning>
      </sect2>
      -->
  </sect1>
  <sect1 id="sec-draw_images">
      <title>Drawing Images</title>
      <sect2>
          <title>Drawing Images with Gdk</title>
          <para>
              There are a couple of drawing methods for putting image data into
              a drawing area. <function>draw_pixmap()</function> can copy the
              contents of a <classname>Gdk::Drawable</classname> (the window of
              a drawing area is one) into the drawing area.  There is also
              <function>draw_bitmap()</function> for drawing a two-color image
              into the drawing area, and <function>draw_image()</function> for
              drawing an image with more than two colors.
          </para>
          <para>
              For all of these methods, the first argument is the
              <classname>Gdk::GC</classname>. The second argument is the object
              of the appropriate type to copy in:
              <classname>Gdk::Drawable</classname>,
              <classname>Gdk::Bitmap</classname>,
              <classname>Gdk::Image</classname>. The next two arguments are the
              x and y points in the image to begin copying from. Then come the
              x and y points in the drawing area to copy to. The final two
              arguments are the width and height of the area to copy.
          </para>
          <para>
              There is also a method for drawing from a
              <classname>Gdk::Pixbuf</classname>. A
              <classname>Gdk::Pixbuf</classname> buffer is a useful wrapper
              around a collection of pixels, which can be read from files, and
              manipulated in various ways.
          </para>
          <para>
              Probably the most common way of creating
              <classname>Gdk::Pixbuf</classname>s is to use
              <function>Gdk::Pixbuf::create_from_file()</function>, which can
              read an image file, such as a png file into a pixbuf ready for
              rendering.
          </para>
          <para>
              The <classname>Gdk::Pixbuf</classname> can be rendered with
              <function>render_to_drawable</function>, which takes quite a few
              parameters. The <function>render_to_drawable</function> is a
              member of <classname>Gdk::Pixbuf</classname> rather than
              <classname>Gdk::Drawable</classname>, which is unlike the
              <function>draw_*</function> functions described earlier. As such,
              its first parameter is the drawable to render to. The second
              parameter is still the <classname>Gdk::GC</classname>. The next
              two parameters are the point in the pixbuf to start drawing from.
              This is followed by the point in the drawable to draw it at, and
              by the width and height to actually draw (which may not be the
              whole image, especially if you're only responding to an expose
              event for part of the window). Finally, there are the dithering
              parameters. If you use Gdk::RGB_DITHER_NONE as the dither type,
              then the dither offset parameters can both be 0.
          </para>
          <para>
              Here is a small bit of code to tie it all together: (Note that
              usually you wouldn't load the image every time in the expose
              event handler! It's just shown here to keep it all together)
          </para>
          <programlisting>bool myarea::on_expose_event(GdkEventExpose* ev)
{
Glib::RefPtr&lt;Gdk::PixBuf&gt; image = Gdk::PixBuf::create_from_file("myimage.png");
image-&gt;render_to_drawable(get_window(), get_style()-&gt;get_black_gc(),
0, 0, 100, 80, image-&gt;get_width(), image-&gt;get_height(), // draw the whole image (from 0,0 to the full width,height) at 100,80 in the window
Gdk::RGB_DITHER_NONE, 0, 0);
return true;
}</programlisting>
      </sect2>
      <!--
      <sect2>
          <title>Drawing images with Cairo</title>
          <warning>TODO: Add Cairo content.</warning>
      </sect2>
      -->
  </sect1>
  <!--
  <sect1 id="sec-drawing-fill">
      <title>Gradients and other fill techniques</title>
      <warning>TODO: Add content.</warning>
  </sect1>
  <sect1 id="sec-drawing-transformations">
      <title>Transformations with Cairo</title>
      <warning>TODO: Add content.</warning>
  </sect1>
  -->
  <sect1 id="sec-drawing-clock-example">
      <title>Example Application: Creating a Clock with Cairo</title>
      <para>
          Now that we've covered the basics of drawing with Cairo, let's try to
          put it all together and create a simple application that actually
          does something.  The following example uses Cairo to create a custom
          <classname>Clock</classname> widget.  The clock has a second hand, a
          minute hand, and an hour hand, and updates itself every second.
      </para>
      <screenshot>
          <graphic format="PNG"
              fileref="&url_figures_base;cairo_clock.png"/>
      </screenshot>
      <para><ulink url="&url_examples_base;drawingarea/clock">Source Code</ulink></para>
      <para>
          As before, almost all of the interesting stuff is done in the expose
          event handler <function>on_expose_event()</function>.  Before we dig
          into the expose event handler, notice that the constructor for the
          <classname>Clock</classname> widget connects a handler function
          <function>onSecondElapsed()</function> to a timer with a timeout
          period of 1000 milliseconds (1 second).  This means that
          <function>onSecondElapsed()</function> will get called once per
          second.  The sole responsibility of this function is to invalidate
          the window so that &gtkmm; will be forced to redraw it.
      </para>
      <para>
          Now let's take a look at the code that performs the actual drawing.
          The first section of <function>on_expose_event()</function> should be
          pretty familiar by now as it's mostly 'boilerplate' code for getting
          the <classname>Gdk::Window</classname>, creating a
          <classname>Cairo::Context</classname>, and clipping to the area that
          we want to re-draw.  This example again scales the coordinate system
          to be a unit square so that it's easier to draw the clock as a
          percentage of window size so that it will automatically scale when
          the window size is adjusted.  Furthermore, the coordinate system is
          scaled over and down so that the (0, 0) coordinate is in the very
          center of the window.  
      </para>
      <para>
          The function <function>Cairo::Context::paint()</function> is used here
          to set the background color of the window.  This function takes no
          arguments and fills the current surface (or the clipped portion of
          the surface) with the source color currently active.  After setting
          the background color of the window, we draw a circle for the clock
          outline, fill it with white, and then stroke the outline in black.
          Notice that both of these actions use the
          <function>_preserve</function> variant to preserve the current path,
          and then this same path is clipped to make sure than our next lines
          don't go outside the outline of the clock.
      </para>
      <para>
          After drawing the outline, we go around the clock and draw ticks for
          every hour, with a larger tick at 12, 3, 6, and 9. Now we're finally
          ready to implement the time-keeping functionality of the clock, which
          simply involves getting the current values for hours, minutes and
          seconds, and drawing the hands at the correct angles.
      </para>
  </sect1>
</chapter>

<chapter id="sec-draganddrop">
<title>Drag and Drop</title>
<para>
<classname>Gtk::Widget</classname> has several methods and signals which are
prefixed with "drag_". These are used for Drag and Drop.
</para>
<sect1>
<title>Sources and Destinations</title>
<para>
Things are dragged from <literal>sources</literal> to be dropped on
<literal>destinations</literal>. Each source and destination has infomation
about the data formats that it can send or receive, provided by
<classname>Gtk::TargetEntry</classname> items. A drop destination will only
accept a dragged item if they both share a compatible
<classname>Gtk::TargetEntry</classname> item.  Appropriate signals will then be
emitted, telling the signal handlers which
<classname>Gtk::TargetEntry</classname> was used.
</para>
<para>
<classname>Gtk::TargetEntry</classname> objects contain this information:
<itemizedlist>
<listitem><para>target: A name, such as &quot;STRING&quot;</para></listitem>
<listitem><para>info: An identifier which will be sent to your signals to tell you which TargetEntry was used.</para></listitem>
<listitem><para>flags: TODO</para></listitem>
</itemizedlist>
</para>

</sect1>

<sect1 id="sec-drag_and_drop_methods">
<title>Methods</title>
<para>
<classname>Widgets</classname> can be identified as sources or destinations
using these <classname>Gtk::Widget</classname> methods:
</para>
<programlisting>void drag_source_set(const ArrayHandle_TargetEntry&amp; targets,
      GdkModifierType start_button_mask, GdkDragAction actions);</programlisting>

<itemizedlist>
<listitem>
    <para>
        <literal>targets</literal> is a container of
        <classname>Gtk::TargetEntry</classname>
        (<classname>std::list&lt;Gtk::TargetEntry&gt;</classname> or
        <classname>std::vector&lt;Gtk::TargetEntry&gt;</classname>, for
        instance) elements.
    </para>
</listitem>
<listitem>
    <para>
        <literal>start_button_mask</literal> is an ORed combination of values,
        which specify which modifier key or mouse button must be pressed to
        start the drag.
    </para>
</listitem>
<listitem>
    <para>
        <literal>actions</literal> is an ORed combination of values, which
        specified which Drag and Drop operations will be possible from this
        source - for instance, copy, move, or link. The user can choose between
        the actions by using modifier keys, such as <keycap>Shift</keycap> to
        change from <literal>copy</literal> to <literal>move</literal>, and
        this will be shown by a different cursor.
    </para>
</listitem>
</itemizedlist>

<programlisting>void drag_dest_set(const ArrayHandle_TargetEntry&amp; targets,
    GtkDestDefaults flags, GdkDragAction actions);</programlisting>

<itemizedlist>
<listitem>
    <para>
        <literal>flags</literal> is an ORed combination of values which
        indicates how the widget will respond visually to Drag and Drop items.
    </para>
</listitem>
<listitem>
    <para>
        <literal>actions</literal> indicates the Drag and Drop actions which
        this destination can receive - see the description above.
    </para>
</listitem>
</itemizedlist>
</sect1>

<sect1 id="sec-drag_and_drop_signals">
<title>Signals</title>
<para>
When a drop destination has accepted a dragged item, certain signals will be
emitted, depending on what action has been selected. For instance, the user
might have held down the <keycap>Shift</keycap> key to specify a
<literal>move</literal> rather than a <literal>copy</literal>. Remember that
the user can only select the actions which you have specified in your calls to
<function>drag_dest_set()</function> and
<function>drag_source_set()</function>.
</para>

<sect2 id="sec-drag_and_drop_signals_copy">
<title>Copy</title>
<para>
The source widget will emit these signals, in this order:
<itemizedlist>
<listitem><para><literal>drag_begin</literal>: Provides DragContext.</para></listitem>
<listitem><para><literal>drag_motion</literal>: Provides DragContext and coordinates. You can call the drag_status() method of the DragContext to indicate which target will be accepted.</para></listitem>
<listitem><para><literal>drag_get</literal>: Provides <literal>info</literal> about the dragged data format, and a <literal>GtkSelectionData</literal> structure, in which you should put the requested data.</para></listitem>
<listitem><para><literal>drag_drop</literal>: Provides DragContext and coordinates.</para></listitem>
<listitem><para><literal>drag_end</literal>: Provides DragContext.</para></listitem>
</itemizedlist>
</para>
<para>
The destination widget will emit this signal, after the source destination has emitted the <literal>drag_get</literal> signal:
<itemizedlist>
<listitem>
    <para>
        <literal>drag_data_received</literal>: Provides <literal>info</literal>
        about the dragged data format, and a
        <literal>GtkSelectionData</literal> structure which contains the
        dropped data. You should  call the <function>drag_finish()</function>
        method of the <literal>DragContext</literal> to indicate whether the
        operation was successful.
    </para>
</listitem>
</itemizedlist>
</para>

</sect2>

<sect2>
<title>Move</title>
<para>During a <literal>move</literal>, the source widget will also emit this signal:
<itemizedlist>
<listitem><para><literal>drag_delete</literal>: Gives the source the opportunity to delete the original data if that's appropriate.</para></listitem>
</itemizedlist>
</para>
</sect2>

<sect2>
<title>Link</title>
<para>TODO: Find an example or documentation.</para>
</sect2>
</sect1>

<sect1 id="sec-dragcontext">
<title>DragContext</title>
<para>
The drag and drop signals provide a DragContext, which contains some
information about the drag and drop operation and can be used to influence the
process. For instance, you can discover the source widget, or  change the drag
and drop icon, by using the <function>set_icon()</function> methods. More
importantly, you should call the <function>drag_finish()</function> method from
your <literal>drag_data_received</literal> signal handler to indicate whether
the drop was successful.
</para>
</sect1>

<sect1 id="sec-drag_and_drop_example">
<title>Example</title>
<para>Here is a very simple example, demonstrating a drag and drop <literal>Copy</literal> operation:</para>

<figure id="figure-drag_and_drop">
  <title>Drag and Drop</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;drag_and_drop.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;drag_and_drop">Source Code</ulink></para>

<para>
There is a more complex example in examples/dnd.
</para>

</sect1>

</chapter>

<chapter id="sec-clipboard">
<title>The Clipboard</title>
<para>Simple text copy-paste functionality is provided for free by widgets such as Gtk::Entry and Gtk::TextView, but you might need special code to deal with your own data formats. For instance, a drawing program would need special code to allow copy and paste within a view, or between documents.</para>

<para>
<classname>Gtk::Clipboard</classname> is a singleton. You can get the one and
only instance with <function>Gtk::Clipboard::get()</function>.
</para>

<para>
So your application doesn't need to wait for clipboard operations, particularly
between the time when the user chooses Copy and then later chooses Paste, most
<classname>Gtk::Clipboard</classname> methods take
<classname>sigc::slot</classname>s which specify callback methods. When
<classname>Gtk::Clipboard</classname> is ready, it will call these methods,
either providing the requested data, or asking for data.  
</para>

<para><ulink url="&url_refdocs_base_gtk;Clipboard.html">Reference</ulink></para>

<sect1>
<title>Targets</title>
<para>
Different applications contain different types of data, and they might make that data available in
a variety of formats. &gtkmm; calls these data types <literal>target</literal>s.</para> 

<para>
For instance, gedit can supply and receive the <literal>&quot;UTF8_STRING&quot;</literal> target, so you can paste data into gedit from any application that supplies that target. Or two different image editing applications might supply and receive a variety of image formats as targets. As long as one application can receive one of the targets that the other supplies then you will be able to copy data from one to the other.
</para>

<para>
A target can be in a variety of binary formats. This chapter, and the examples,
assume that the data is 8-bit text. This would allow us to use an XML format
for the clipboard data. However this would probably not be appropriate for
binary data such as images.  <classname>Gtk::Clipboard</classname> provides
overloads that allow you to specify the format in more detail if
necessary.
</para>

<para>The <link linkend="sec-draganddrop">Drag and Drop</link> API uses the same mechanism. You should probably use the same data targets and formats for both Clipboard and Drag and Drap operations.</para>
</sect1>

<sect1 id="sec-drag_and_drop_copy">
<title>Copy</title>
<para>
When the user asks to copy some data, you should tell the
<classname>Clipboard</classname> what targets are available, and provide the
callback methods that it can use to get the data. At this point you should
store a copy of the data, to be provided when the clipboard calls your callback
method in repsonse to a paste.
</para>
<para>For instance,
</para>
<programlisting>Glib::RefPtr&lt;Gtk::Clipboard&gt; refClipboard = Gtk::Clipboard::get();

//Targets:
std::list&lt;Gtk::TargetEntry&gt; listTargets;
listTargets.push_back( Gtk::TargetEntry(&quot;example_custom_target&quot;) );
listTargets.push_back( Gtk::TargetEntry("UTF8_STRING") );

refClipboard-&gt;set( listTargets,
    sigc::mem_fun(*this, &amp;ExampleWindow::on_clipboard_get),
    sigc::mem_fun(*this, &amp;ExampleWindow::on_clipboard_clear) );</programlisting>

<para>Your callback will then provide the store data when the user chooses to paste the data. For instance:
</para>
<programlisting>void ExampleWindow::on_clipboard_get(
    Gtk::SelectionData&amp; selection_data, guint info)
{
  const Glib::ustring target = selection_data.get_target();

  if(target == &quot;example_custom_target&quot;)
    selection_data.set(&quot;example_custom_target&quot;, m_ClipboardStore);
}</programlisting>
<para>
The <literal>ideal</literal> example below can supply more than one clipboard target.
</para>

<para>The clear callback allows you to free the memory used by your stored data when the clipboard replaces its data with something else.
</para>

</sect1>

<sect1 id="sec-drag_and_drop_paste">
<title>Paste</title>
<para>
When the user asks to paste data from the <classname>Clipboard</classname>, you
should request a specific format and provide a callback method which will be
called with the actual data. For instance: 
</para>
<programlisting>refClipboard-&gt;request_contents(&quot;example_custom_target&quot;,
    sigc::mem_fun(*this, &amp;ExampleWindow::on_clipboard_received) );</programlisting>

<para>Here is an example callback method:
</para>
<programlisting>void ExampleWindow::on_clipboard_received(
    const Gtk::SelectionData&amp; selection_data)
{
  Glib::ustring clipboard_data = selection_data.get_data_as_string();
  //Do something with the pasted data.
}</programlisting>

<sect2>
<title>Discovering the available targets</title>
<para>
To find out what targets are currently available on the
<classname>Clipboard</classname> for pasting, call the
<function>request_targets()</function> method, specifying a method to be called
with the information. For instance:
</para>
<programlisting>refClipboard-&gt;request_targets( sigc::mem_fun(*this,
    &amp;ExampleWindow::on_clipboard_received_targets) );</programlisting>

<para>
In your callback, compare the list of available targets with those that your application supports for pasting. You could enable or disable a Paste menu item, depending on whether pasting is currently possible. For instance:
</para>
<programlisting>void ExampleWindow::on_clipboard_received_targets(
    const Gtk::SelectionData&amp; selection_data)
{
  bool bPasteIsPossible = false;

  //Get the list of available clipboard targets:
  typedef std::list&lt;Glib::ustring&gt; type_listTargets;
  type_listTargets targets = selection_data.get_targets();

  //and see if one is suitable:
  for(type_listTargets::const_iterator iter = targets.begin();
      iter != targets.end(); ++iter)
  {
    if(*iter == &quot;example_custom_target&quot;)
      bPasteIsPossible = true;
  }

  //Do something, depending on whether bPasteIsPossible is true.
}</programlisting>
</sect2>

</sect1>

<sect1 id="sec-clipboard_examples"><title>Examples</title>

<sect2 id="sec-clipboard-example-simple"><title>Simple</title>
<para>
This example allows copy and pasting of application-specific data, using the
standard text target. Although this is simple, it's not ideal because it does
not identify the <classname>Clipboard</classname> data as being of a particular
type.
</para>

<figure id="figure-clipboard-simple">
  <title>Clipboard - Simple</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;clipboard_simple.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;clipboard/simple/">Source Code</ulink></para>

</sect2>

<sect2 id="sec-clipboard-example-ideal"><title>Ideal</title>
<para>This is like the simple example, but it 
<orderedlist>
<listitem><simpara>Defines a custom clipboard target, though the format of that target is still text.</simpara></listitem>
<listitem><simpara>It supports pasting of 2 targets - both the custom one and a text one that creates an arbitrary text representation of the custom data.</simpara></listitem>
<listitem><simpara>It uses <function>request_targets()</function> and disables the Paste button if it can't use anything on the clipboard</simpara></listitem>
</orderedlist>
</para>

<figure id="figure-clipboard-ideal">
  <title>Clipboard - Ideal</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;clipboard_ideal.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;clipboard/ideal/">Source Code</ulink></para>

</sect2>

</sect1>


</chapter>

<chapter id="sec-printing">
<title>Printing</title>

<note>
  <para>Printing support is available in &gtkmm; version 2.10 and later.</para>
</note>

<para>
At the application development level, &gtkmm;'s printing API
provides dialogs that are consistent across applications and allows us of Cairo's common drawing API, with Pango-driven text rendering. In the implementation of this common API, platform-specific backends and printer-specific drivers are used.
</para>

<sect1 id="sec-printoperation">
<title>PrintOperation</title>

<para>
The primary object is <classname>Gtk::PrintOperation</classname>, allocated
for each print operation. To handle page drawing connect to its signals,
or inherit from it and override the default virtual signal handlers.
<classname>PrintOperation</classname> automatically handles all the settings
affecting the print loop.
</para>

<sect2 id="sec-printoperation-signals">
<title>Signals</title>

<para>
The <function>PrintOperation::run()</function> method starts the print loop, 
during which various signals are emitted:

<itemizedlist>
  <listitem>
    <para>
      <literal>begin_print</literal>:
      You must handle this signal, because this is where you
      create and set up a <classname>Pango::Layout</classname> using the
      provided <classname>Gtk::PrintContext</classname>, and break up your
      printing output into pages.
    </para>
  </listitem>

  <listitem>
    <para>
      <literal>paginate</literal>: Pagination is potentially slow so if you
      need to monitor it you can call the
      <function>PrintOperation::set_show_progress()</function> method and
      handle this signal.
    </para>
  </listitem>

  <listitem>
    <para>
      For each page that needs to be rendered, the following signals
      are emitted:
      <itemizedlist>
        <listitem>
	  <para>
	    <literal>request_page_setup</literal>: Provides a
	    <classname>PrintContext</classname>, page number and
	    <classname>Gtk::PageSetup</classname>. Handle this signal if you
	    need to modify page setup on a per-page basis.
	  </para>
	</listitem>

	<listitem>
	  <para>
	    <literal>draw_page</literal>: You must handle this signal, which provides a
	    <classname>PrintContext</classname> and a page number.
	    The <classname>PrintContext</classname> should be used 
	    to create a <classname>Cairo::Context</classname> into which
	    the provided page should be drawn. To render text, iterate over
	    the <classname>Pango::Layout</classname> you created in the
	    <literal>begin_print</literal> handler.
	  </para>
	</listitem>
      </itemizedlist>
    </para>
  </listitem>

  <listitem>
    <para>
      <literal>end_print</literal>: A handler for it is a safe place to free
      any resources related to a <classname>PrintOperation</classname>.
      If you have your custom class that inherits from
      <classname>PrintOperation</classname>, it is naturally simpler to do it
      in the destructor.
    </para>
  </listitem>

  <listitem>
    <para>
      <literal>done</literal>: This signal is emitted when printing is finished, meaning when the
      print data is spooled. Note that the provided 
      <literal>Gtk::PrintOperationResult</literal> may indicate that
      an error occurred. In any case you probably want to notify the user
      about the final status.
    </para>
  </listitem>

  <listitem>
    <para>
      <literal>status_changed</literal>: Emitted whenever a print job's
      status changes, until it is finished. Call the 
      <function>PrintOperation::set_track_print_status()</function> method to
      monitor the job status after spooling. To see the status, use
      <function>get_status()</function> or
      <function>get_status_string()</function>.
    </para>
  </listitem>
</itemizedlist>

</para>

<para>
<ulink url="&url_refdocs_base_gtk;PrintOperation.html">Reference</ulink>
</para>

</sect2>

</sect1>

<sect1 id="sec-page_setup">
<title>Page setup</title>

<para>
The <classname>PrintOperation</classname> class has a method called
<function>set_default_page_setup()</function> which selects the default
paper size, orientation and margins. To show a page setup dialog from your
application, use the <function>Gtk::run_page_setup_dialog()</function> method,
which returns a <classname>Gtk::PageSetup</classname> object with the chosen
settings. Use this object to update a <classname>PrintOperation</classname>
and to access the selected <classname>Gtk::PaperSize</classname>,
<literal>Gtk::PageOrientation</literal> and printer-specific margins.
</para>
<para>You should save the chosen <classname>Gtk::PageSetup</classname>
so you can use it again if the page setup dialog is shown again.</para>

<para>For instance,
<programlisting>
//Within a class that inherits from Gtk::Window and keeps m_refPageSetup and m_refSettings as members...
Glib::RefPtr&lt;Gtk::PageSetup&gt; new_page_setup = Gtk::run_page_setup_dialog(*this, m_refPageSetup, m_refSettings);
m_refPageSetup = new_page_setup;
</programlisting>
</para>

<para>
<ulink url="&url_refdocs_base_gtk;PageSetup.html">Reference</ulink>
</para>

<para>
The Cairo coordinate system, in the <literal>draw_page</literal> handler,
is automatically rotated to the current page orientation. It is normally
within the printer margins, but you can change that via the 
<function>PrintOperation::set_use_full_page()</function>
method. The default measurement unit is device pixels. To select other units,
use the <function>PrintOperation::set_unit()</function> method.
</para>

</sect1>

<sect1 id="sec-printing_rendering_text">
<title>Rendering text</title>

<para>
Text rendering is done using Pango.
The <classname>Pango::Layout</classname> object for printing should be created by calling
the <function>PrintContext::create_pango_layout()</function> method.
The <classname>PrintContext</classname> object also provides the page metrics,
via <function>get_width()</function> and <function>get_height()</function>.
The number of pages can be set with
<function>PrintOperation::set_n_pages()</function>. To actually render the
 Pango text in <literal>on_draw_page</literal>, get a
<classname>Cairo::Context</classname> with 
<function>PrintContext::get_cairo_context()</function> and show the
<classname>Pango::LayoutLine</classname>s that appear within the requested
page number.
</para>

<para>
See <link linkend="sec-printing_example-simple">an example</link>
of exactly how this can be done.
</para>

</sect1>

<sect1 id="sec-async_printing_ops">
<title>Asynchronous operations</title>

<para>
By default, <function>PrintOperation::run()</function> returns when a print
operation is completed. If you need to run a non-blocking print operation,
call <function>PrintOperation::set_allow_async()</function>. Note that <function>set_allow_async()</function> is not supported
on all platforms, however the <literal>done</literal> signal will still be emitted.
</para>

<para>
<function>run()</function> may return
<literal>PRINT_OPERATION_RESULT_IN_PROGRESS</literal>. To track status
and handle the result or error you need to implement signal handlers for
the <literal>done</literal> and <literal>status_changed</literal> signals:
</para>

<para>For instance,
<programlisting>
// in class ExampleWindow's method...
Glib::RefPtr&lt;PrintOperation&gt; op = PrintOperation::create();
// ...set up op...
op->signal_done().connect(sigc::bind(sigc::mem_fun(*this, &amp;ExampleWindow::on_printoperation_done), op));
// run the op
</programlisting>
</para>

<para>Second, check for an error and connect to the <literal>status_changed</literal> signal. For instance:
<programlisting>
void ExampleWindow::on_printoperation_done(Gtk::PrintOperationResult result, const Glib::RefPtr&lt;PrintOperation&gt;&amp; op)
{
  if (result == Gtk::PRINT_OPERATION_RESULT_ERROR)
    //notify user
  else if (result == Gtk::PRINT_OPERATION_RESULT_APPLY)
    //Update PrintSettings with the ones used in this PrintOperation

  if (! op->is_finished())
    op->signal_status_changed().connect(sigc::bind(sigc::mem_fun(*this, &amp;ExampleWindow::on_printoperation_status_changed), op));
}
</programlisting>
</para>

<para>Finally, check the status. For instance,
<programlisting>
void ExampleWindow::on_printoperation_status_changed(const Glib::RefPtr&lt;PrintFormOperation&gt;&amp; op)
{
  if (op->is_finished())
    //the print job is finished
  else
    //get the status with get_status() or get_status_string()

  //update UI
}
</programlisting>
</para>

</sect1>

<sect1 id="sec-export_to_pdf">
<title>Export to PDF</title>
<para>
The 'Print to file' option is available in the print dialog, without the need for extra implementation. However, it is sometimes useful to generate a pdf file directly from code. For instance,

<programlisting>
Glib::RefPtr&lt;Gtk::PrintOperation&gt; op = Gtk::PrintOperation::create();
// ...set up op...
op->set_export_filename(&quot;test.pdf&quot;);
Gtk::PrintOperationResult res = op-&gt;run(Gtk::PRINT_OPERATION_ACTION_EXPORT);
</programlisting>

</para>

</sect1>

<sect1 id="sec-extending_print_dialog">
<title>Extending the print dialog</title>

<para>
You may add a custom tab to the print dialog:

<itemizedlist>
  <listitem>
    <para>
      Set the title of the tab via
      <function>PrintOperation::set_custom_tab_label()</function>,
      create a new widget and return it from the
      <literal>create_custom_widget</literal> signal handler. You'll probably
      want this to be a container widget, packed with some others.
    </para>
  </listitem>

  <listitem>
    <para>
      Get the data from the widgets in the
      <literal>custom_widget_apply</literal> signal handler.
    </para>
  </listitem>
</itemizedlist>
</para>

<para>
Although the <literal>custom_widget_apply</literal> signal provides the widget you
previously created, to simplify things you can keep the widgets you expect
to contain some user input as class members. For example, let's say you have
a <classname>Gtk::Entry</classname> called <literal>m_Entry</literal> as
a member of your <classname>CustomPrintOperation</classname> class:

<programlisting>
Gtk::Widget* CustomPrintOperation::on_create_custom_widget()
{
  set_custom_tab_label(&quot;My custom tab&quot;);

  Gtk::HBox* hbox = new Gtk::HBox(false, 8);
  hbox-&gt;set_border_width(6);

  Gtk::Label* label = Gtk::manage(new Gtk::Label("Enter some text: "));
  hbox-&gt;pack_start(*label, false, false);
  label-&gt;show();

  hbox-&gt;pack_start(m_Entry, false, false);
  m_Entry.show();

  return hbox;
}

void CustomPrintOperation::on_custom_widget_apply(Gtk::Widget* /* widget */)
{
  Glib::ustring user_input = m_Entry.get_text();
  //...
}
</programlisting>

</para>

<para>
The example in examples/book/printing/advanced demonstrates this.
</para>

</sect1>

<sect1 id="sec-printing_preview">
<title>Preview</title>

<para>
The native GTK+ print dialog has a preview button, but you may also start
a preview directly from an application:

<programlisting>
// in a class that inherits from Gtk::Window...
Glib::RefPtr&lt;PrintOperation&gt; op = PrintOperation::create();
// ...set up op...
op->run(Gtk::PRINT_OPERATION_ACTION_PREVIEW, *this);
</programlisting>
</para>

<para>
On Unix, the default preview handler uses an external viewer program.
On Windows, the native preview dialog will be shown. If necessary you may
override this behaviour and provide a custom preview dialog. See the example
located in /examples/book/printing/advanced.
</para>

</sect1>

<sect1 id="sec-printing_example">
<title>Example</title>

<sect2 id="sec-printing_example-simple">
<title>Simple</title>

<para>
The following example demonstrates how to print some input from a user
interface. It shows how to implement <literal>on_begin_print</literal>
and <literal>on_draw_page</literal>, as well as how to track print status
and update the print settings.
</para>

<figure id="figure-printing-simple">
  <title>Printing - Simple</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;printing.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;printing/simple/">Source Code</ulink></para>

</sect2>

</sect1>

</chapter>

<chapter id="sec-recent-documents">
  <title>Recently Used Documents</title>
  <note>
    <para>Recent Files support is available in &gtkmm; version 2.10 and
      later</para>
  </note>
  <para>
    &gtkmm; provides an easy way to manage recently used documents.  The classes
    involved in implementing this functionality are
    <classname>RecentManager</classname>,
    <classname>RecentChooserDialog</classname>,
    <classname>RecentChooserMenu</classname>,
    <classname>RecentChooserWidget</classname>, and
    <classname>RecentFilter</classname>.
  </para>
  <para>
    Each item in the list of recently used files is identified by its URI, and
    can have associated metadata.  The metadata can be used to specify how the
    file should be displayed, a description of the file, its mime type, which
    application registered it, whether it's private to the registering
    application, and several other things.
  </para>
  <sect1>
    <title>RecentManager</title>
    <para>
      <classname>RecentManager</classname> acts as the central database of
      recently used files.  You use this class to register new files, remove
      files from the list, or look up recently used files.
    </para>
    <para>
      You can create a new <classname>RecentManager</classname>, but you'll most
      likely just want to use the default one.  You can get a reference to the
      default <classname>RecentManager</classname> with
      <function>get_default()</function>.  
      </para>
    <sect2>
      <title>Adding Items to the List of Recent Files</title>
      <para>
        To add a new file to the list of recent documents, in the simplest case,
        you only need to provide the URI.  For example:
      </para>
      <programlisting>Glib::RefPtr&lt;Gtk::RecentManager&gt; recent_manager = Gtk::RecentManager::get_default();
recent_manager->add_item(uri);</programlisting>
      <para>
        If you want to register a file with metadata, you can pass a
        <classname>RecentManager::Data</classname> parameter to
        <function>add_item()</function>.  The metadata that can be set on a
        particular file item is as follows:
      </para>
      <itemizedlist>
        <listitem>
          <para><varname>app_exec</varname>: The command line to be used to launch
            this resource.  This string may contain the "f" and "u" escape
            characters which will be expanded to the resource file path and URI
            respectively</para>
        </listitem>
        <listitem>
          <para><varname>app_name</varname>: The name of the application that
            registered the resource</para>
        </listitem>
        <listitem>
          <para><varname>description</varname>: A short description of the
            resource as a UTF-8 encoded string</para>
        </listitem>
        <listitem>
          <para><varname>display_name</varname>: The name of the resource to be
            used for display as a UTF-8 encoded string</para>
        </listitem>
        <listitem>
          <para><varname>groups</varname>: A list of groups associated with this
            item.  Groups are essentially arbitrary strings associated with a
            particular resource.  They can be thought of as 'categories' (such
            as "email", "graphics", etc) or tags for the resource.</para>
        </listitem>
        <listitem>
          <para><varname>is_private</varname>: Whether this resource should be
            visible only to applications that have registered it or not</para>
        </listitem>
        <listitem>
          <para><varname>mime_type</varname>: The MIME type of the resource</para>
        </listitem>
      </itemizedlist>
      <para>
        In addition to adding items to the list, you can also look up items from
        the list and modify or remove items.
      </para>
    </sect2>
    <sect2>
      <title>Looking up Items in the List of Recent Files</title>
      <para>
        To look up recently used files, <classname>RecentManager</classname>
        provides several functions.  To look up a specific item by its URI, you
        can use the <function>lookup_item()</function> function, which will
        return a <classname>RecentInfo</classname> class.  If the specified URI
        did not exist in the list of recent files, the
        <classname>RecentInfo</classname> object will be invalid.
        <classname>RecentInfo</classname> provides an implementation for
        <function>operator bool()</function> which can be used to test for
        validity.  For example:
      </para>
<programlisting>Gtk::RecentInfo info = recent_manager-&gt;lookup_item(uri);
if (info)
{
  // item was found
}</programlisting>
      <para>
        A <classname>RecentInfo</classname> object is essentially an object
        containing all of the metadata about a single recently-used file.  You
        can use this object to look up any of the properties listed above. FIXME
        - add cross-reference.
      </para>
      <para>
        If you don't want to look for a specific URI, but instead want to get a
        list of all recently used items, <classname>RecentManager</classname>
        provides the <function>get_items()</function> function.  The return
        value of this function can be assigned to any standard C++ container
        (e.g. <classname>std::vector</classname>,
        <classname>std::list</classname>, etc) and contains a list of all
        recently-used files up to a user-defined limit (FIXME: what's the
        default limit?).  The following code demonstrates how you might get a
        list of recently-used files:
      </para>
      <programlisting>std::vector&lt;Gtk::RecentInfo&gt; info_list = recent_manager-&gt;get_items();</programlisting>
      <para>
        The limit on the number of items returned can be set
        by <function>set_limit()</function>, and queried with
        <function>get_limit()</function>.  
      </para>
    </sect2>
    <sect2>
      <title>Modifying the List of Recent Files</title>
      <para>
        There may be times when you need to modify the list of recent files.
        For instance, if a file is moved or renamed, you may need to update the
        file's location in the recent files list so that it doesn't point to an
        incorrect location.  You can update an item's location by using
        <function>move_item()</function>.
      </para>
      <para>
        In addition to changing a file's URI, you can also remove items from the
        list, either one at a time or by clearint them all at once.  The former
        is accomplished with <function>remove_item()</function>, the latter with
        <function>purge_items()</function>.
      </para>
      <note>
        <para>
        The functions <function>move_item()</function>,
        <function>remove_item()</function> and
        <function>purge_items()</function> have no effect on the actual files
        that are referred to by the URIs, they only modify the list of recent
        files.
        </para>
      </note>
    </sect2>
  </sect1>

  <sect1>
    <title>RecentChooser</title>
    <note>
      <para>Recent Files support is available in &gtkmm; version 2.10 and
        later</para>
    </note>
    <para>
      <classname>RecentChooser</classname> is an interface that can be
      implemented by widgets displaying the list of recently used files.
      &gtkmm; provides three built-in implementations for choosing recent files:
      <classname>RecentChooserWidget</classname>,
      <classname>RecentChooserDialog</classname>, and
      <classname>RecentChooserMenu</classname>.
    </para>
    <para>
      <classname>RecentChooserWidget</classname> is a simple widget for
      displaying a list of recently used files.
      <classname>RecentChooserWidget</classname> is the basic building block for
      <classname>RecentChooserDialog</classname>, but you can embed it into your
      user interface if you want to.
    </para>
    <para>
      The last class that implements the <classname>RecentChooser</classname>
      interface is <classname>RecentChooserMenu</classname>.  This class allows
      you to list recently used files as a menu.
    </para>
    <sect2>
      <title>Simple RecentChooserWidget example</title>
      <para>
        Shown below is a simple example of how to use the
        <classname>RecentChooserDialog</classname> class in a program.  This
        simple program has a menubar with a "Recent Files Dialog" menu item.
        When you select this menu item, a dialog pops up showing the list of
        recently used files.
      </para>
      <note>
        <para>
          If this is the first time you're using a program that uses the Recent
          Files framework, the dialog may be empty at first.  Otherwise it
          should show the list of recently used documents registered by other
          applications.
        </para>
      </note>
      <para>
        After selecting the <guimenuitem>Recent Files Dialog</guimenuitem> menu
        item, you should see something similar to the following window.
      </para>
      <screenshot>
          <graphic format="PNG"
              fileref="&url_figures_base;recentchooserdialog.png"/>
      </screenshot>
      <para><ulink url="&url_examples_base;recent_files">Source Code</ulink></para>
      <para>
        The constructor for <classname>ExampleWindow</classname> creates the
        menu using <classname>UIManager</classname> (see <xref
          linkend="sec-MenusAndToolbars"/> for more information).  It then adds
        the menu and the toolbar to the window.
      </para>
    </sect2>
    <sect2>
      <title>Filtering Recent Files</title>
      <para>
        For any of the <classname>RecentChooser</classname> classes, if you
        don't wish to display all of the items in the list of recent files, you
        can filter the list to show only those that you want.  You can filter
        the list with the help of the <classname>RecentFilter</classname> class.
        This class allows you to filter recent files by their name
        (<function>add_pattern()</function>), their mime type
        (<function>add_mime_type()</function>), the application that registered
        them (<function>add_application()</function>), or by a custom filter
        function (<function>add_custom()</function>).  It also provides the
        ability to filter based on how long ago the file was modified and which
        groups it belongs to.
      </para>
      <para>
        After you've created and set up the filter to match only the items you
        want, you can apply a filter to a chooser widget with the
        <function>RecentChooser::add_filter()</function> function.
      </para>
    </sect2>
  </sect1>
</chapter>

<chapter id="sec-plugs-sockets">
  <title>Plugs and Sockets</title>
  <sect1>
    <title>Overview</title>
    <para>
      From time to time, it may be useful to be able to embed a widget from
      another application within your application.  &gtkmm; allows you to do
      this with the <classname>Gtk::Socket</classname> and
      <classname>Gtk::Plug</classname> classes.  It is not anticipated that very
      many applications will need this functionality, but in the rare case that
      you need to display a widget that is running in a completely different
      process, these classes can be very helpful.
    </para>
    <para>
      The communication between a <classname>Socket</classname> and a
      <classname>Plug</classname> follows the XEmbed protocol. This protocol has
      also been implemented in other toolkits (e.g. Qt), which allows the same
      level of integration when embedding a Qt widget in GTK+ or vice versa.
    </para>
    <para>
      The way that <classname>Sockets</classname> and
      <classname>Plugs</classname> work together is through their window ids.
      Both a <classname>Socket</classname> and a <classname>Plug</classname>
      have IDs that can be retrieved with their <function>get_id()</function>
      member functions.  The use of these IDs will be explained below in <xref
          linkend="sec-connecting-plugs-sockets"/>.
    </para>
    <sect2>
      <title>Sockets</title>
      <para>
        A <classname>Socket</classname> is a special kind of container widget that
        provides the ability to embed widgets from one process into another
        process in a way that is transparent to the user.
      </para>
    </sect2>
    <sect2>
      <title>Plugs</title>
      <para>
        A <classname>Plug</classname> is a special kind of Window that can be
        plugged into a <classname>Socket</classname>.  Besides the normal
        properties and methods of <classname>Gtk::Window</classname>, a
        <classname>Plug</classname> provides a constructor that takes the ID of
        a <classname>Socket</classname>, which will automatically embed the
        <classname>Plug</classname> into the <classname>Socket</classname> that
        matches that ID.
      </para>
      <para>
        Since a <classname>Plug</classname> is just a special type of
        <classname>Gtk::Window</classname> class, you can add containers or
        widgets to it like you would to any other window.
      </para>
    </sect2>
    <sect2 id="sec-connecting-plugs-sockets">
      <title>Connecting Plugs and Sockets</title>
      <para>
        After a <classname>Socket</classname> or <classname>Plug</classname>
        object is realized, you can obtain its ID with its
        <function>get_id()</function> function.  This ID can then be shared with
        other processes so that other processes know how to connect to
        eachother.
      </para>
      <para>
        There are two basic strategies that can be used:
        <itemizedlist>
          <listitem>
            <para>
              Create a <classname>Socket</classname> object in one process and
              pass the ID of that <classname>Socket</classname> to another
              process so that it can create a <classname>Plug</classname> object
              by specifying the given <classname>Socket</classname> ID in its
              constructor.  There is no way to assign a
              <classname>Plug</classname> to a particular
              <classname>Socket</classname> after creation, so you must pass the
              <classname>Socket</classname> ID to the
              <classname>Plug</classname>'s constructor.
            </para>
          </listitem>
          <listitem>
            <para>
              Create a <classname>Plug</classname> independantly from any
              particular <classname>Socket</classname> and pass the ID of the
              <classname>Plug</classname> to other processes that need to use
              it.  The ID of the <classname>Plug</classname> can be associated
              with a particular <classname>Socket</classname> object using the
              <function>Socket::add_id()</function> function.  This is the
              approach used in the example below.
            </para>
          </listitem>
        </itemizedlist>
      </para>
    </sect2>
  </sect1>
  <sect1>
    <title>Plugs and Sockets Example</title>
    <para>
      The following is a simple example of using sockets and plugs.  The method
      of communication between processes is deliberately kept very simple: The
      <classname>Plug</classname> writes its ID out to a text file named
      <filename>plug.id</filename> and the process with the socket reads the ID
      from this files.  In a real program, you may want to use a more
      sophisticated method of inter-process communication.
    </para>
    <para><ulink url="&url_examples_base;socket/">Source Code</ulink></para>
    <para>
      This example creates two executable programs: <filename>socket</filename>
      and <filename>plug</filename>.  The idea is that
      <filename>socket</filename> has an application window that will embed a
      widget from the <filename>plug</filename> program.  The way this example
      is designed, <filename>plug</filename> must be running first before
      starting <filename>socket</filename>.  To see the example in action,
      execute the following commands in order from within the example directory:
    </para>
    <para>
      Start the <filename>plug</filename> program and send it to the background
      (or just use a different terminal).
    </para>
    <screen>$ ./plug &amp;</screen>
    <para>
      After which you should see something like the following:
    </para>
    <screen>The window ID is: 69206019</screen>
    <para>Then start the <filename>socket</filename> program:</para>
    <screen>$ ./socket</screen>
    <para>
      After starting <filename>socket</filename>, you should see the following
      output in the terminal:
    </para>
    <screen>I've been embedded.
A plug was added</screen>
    <para>
      The first line of output is from <filename>plug</filename>, after it has
      been notified that it has been embedded inside of a
      <classname>Socket</classname>.  The second line was emitted by
      <filename>socket</filename> in response to its
      <function>plug_added</function> signal. If everything was done as
      described above, the <filename>socket</filename> window should look
      roughly like the following:
    </para>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;socket.png"/>
    </screenshot>
    <para>
      If for some reason the <classname>Socket</classname> couldn't attach the
      <classname>Plug</classname>, the window would look something like this:
    </para>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;socket-fail.png"/>
    </screenshot>
  </sect1>
</chapter>

<chapter id="sec-timeouts">
<title>Timeouts, I/O and Idle Functions </title>

<sect1>
<title>Timeouts</title>

<para>
You may be wondering how to make &gtkmm; do useful work while it's idling along
(well, sleeping actually) in <function>Gtk::Main::run()</function>.  Happily,
you have several options.  Using the following methods you can create a timeout
method that will be called every few milliseconds.
</para>

<para>
<programlisting>
sigc::connection Glib::SignalTimeout::connect(const sigc::slot&lt;bool&gt;&amp; slot, unsigned int interval, int priority = Glib::PRIORITY_DEFAULT);
</programlisting>
</para>

<para>
The first argument is a <classname>slot</classname> you wish to have called
when the timeout occurs. The second argument is the number of milliseconds
between calls to that method. You receive a
<classname>sigc::connection</classname> object that can be used to deactivate
the connection using its <function>disconnect()</function> method:
</para>

<para>

<programlisting>
my_connection.disconnect();
</programlisting>
</para>

<para>
Another way of destroying the connection is your signal handler.
It has to be of the type <classname>sigc::slot&lt;bool&gt;</classname>.
As you see from the definition your signal handler has to return a value of
the type <literal>bool</literal>. A definition of a sample method might
look like this:

<programlisting>
bool MyCallback() { std::cout &lt;&lt; "Hello World!\n" &lt;&lt; std::endl; return true; }
</programlisting>

</para>

<para>
You can stop the timeout method by returning <literal>false</literal> from
your signal handler.  Therefore, if you want your
method to be called repeatedly, it should return <literal>true</literal>.
</para>

<para>
Here's an example of this technique:
</para>

<para><ulink url="&url_examples_base;timeout/">Source Code</ulink></para>

</sect1>

<sect1 id="sec-monitoring_io">
<title>Monitoring I/O</title>

<para>
TODO: This is now in Glib, not Gdk. 

A nifty feature of GDK (one of the libraries underlying
&gtkmm;) is the ability to have it check for data on a file descriptor
for you.  This is especially useful for networking applications. The
following method is used to do this:
</para>

<para>
<programlisting>
sigc::connection Glib::Main::SignalInput::connect(const SlotType&amp; sd, int source,
                                    Glib::InputCondition condition);
</programlisting>
</para>

<para>
The first argument is a slot (<classname>SlotType</classname> is a typedef to a
<classname>sigc::slot&lt;&gt;</classname>) you wish to have called when then
the specified event (see argument 3) occurs on the file descriptor you specify
using argument two. Argument three may be one or more (using
<literal>&verbar;</literal>) of:
</para>

<itemizedlist>
<listitem>

<para>
GDK_INPUT_READ - Call your method when there is data ready for
reading on your file descriptor.

</para>
</listitem>
<listitem>

<para>
GDK_INPUT_WRITE - Call your method when the file descriptor is
ready for writing.

</para>
</listitem>
<listitem>

<para>
GDK_INPUT_EXCEPTION - Call your method when an exception happened
on the file descriptor.
</para>
</listitem>

</itemizedlist>

<para>
    The return value is a <classname>sigc::connection</classname> that may be used to stop monitoring
this file descriptor using its <function>disconnect()</function> method.  The
<parameter>sd</parameter> signal handler should be declared as follows:
</para>

<para>
<programlisting>
void input_callback(int source, GdkInputCondition condition);
</programlisting>
</para>

<para>
where <parameter>source</parameter> and <parameter>condition</parameter> are as
specified above. As usual the slot is created with
<function>sigc::mem_fun()</function> (for a member method of an object.), or
<function>sigc::ptr_fun()</function> (for a function).
</para>

<para>
A little example follows.  To use the example just execute it from a terminal;
it doesn't create a window.  It will create a pipe named 
<literal>testfifo</literal> in the current directory. Then start another shell
and execute <literal>echo "Hello" &#62; testfifo</literal>. The example will 
print each line you enter until you execute <literal>echo "Q" &#62; 
testfifo</literal>.
</para>

<para><ulink url="&url_examples_base;input/">Source Code</ulink></para>

</sect1>

<sect1 id="sec-idle_functions">
<title>Idle Functions</title>

<para>
If you want to specify a method that gets called when nothing else is happening, use the following:
</para>

<para>
<programlisting>
sigc::connection  Glib::Main::SignalIdle::connect(const Slot&lt;int&gt;&amp; idlefunc, int priority);
</programlisting>
</para>

<para>
This causes &gtkmm; to call the specified method whenever nothing else is
happening. You can add a priority (lower numbers are higher priorities).  If
you don't supply a priority value, then Gtk::PRIORITY_DEFAULT will be
used. There are two ways to remove the signal handler: calling
<function>disconnect()</function> on the
<classname>sigc::connection</classname> object, or returning
<literal>false</literal> (or 0) in the signal handler, which should be declared
as follows:
</para>

<para>
<programlisting>
int idleFunc();
</programlisting>
</para>

<para>
Since this is very similar to the methods above this explanation should
be sufficient to understand what's going on. However, here's a little example:
</para>

<para><ulink url="&url_examples_base;idle/">Source Code</ulink></para>

<para>
This example points out the difference of idle and timeout methods a
little.  If you need methods that are called periodically, and speed
is not very important, then you want timeout methods. If
you want methods that are called as often as possible (like
calculating a fractal in background), then use idle methods.
</para>

<para>
Try executing the example and increasing the system load. The upper
progress bar will increase steadily; the lower one will slow down.
</para>

</sect1>

</chapter>

<chapter id="sec-Memory">
<title>Memory management</title>

<sect1>
<title>Widgets</title>

<sect2>
<title>Normal C++ memory management</title>

<para>
&gtkmm; allows the programmer to control the lifetime (that is, the construction
and destruction) of any widget in the same manner as any other C++ object.
This flexibility allows you to use <literal>new</literal> and
<literal>delete</literal> to create and destroy objects dynamically
or to use regular class members (that are destroyed automatically when the
class is destroyed) or to use local instances (that are destroyed when the
instance goes out of scope).  This flexibility is not present in some C++ GUI
toolkits, which restrict the programmer to only a subset of C++'s memory
management features.  
</para>

<para>Here are some examples of normal C++ memory management:</para>

<sect3>
<title>Class Scope widgets</title>

<para>
If a programmer does not need dynamic memory allocation, automatic widgets in class 
scope may be used.  One advantage of automatic widgets in class scope is that
memory management is grouped in one place.  The programmer does not 
risk memory leaks from failing to <literal>delete</literal> a widget.
</para>

<para>
The primary disadvantages of using class scope widgets are revealing
the class implementation rather than the class interface in the class header.  Class
scope widgets also require Automatic widgets in class scope suffer the same disadvantages as 
any other class scope automatic variable.  
</para>

<para>
<programlisting>
#include &lt;gtkmm/button.h&gt;
class Foo
{
private:
  Gtk::Button theButton;
  // will be destroyed when the Foo object is destroyed
};
</programlisting>
</para>
</sect3>

<sect3>
<title>Function scope widgets</title>

<para>
If a programmer does not need a class scope widget, a function scope widget 
may also be used.  The advantages to function scope over class scope are the 
increased data hiding and reduced dependencies.


<programlisting>
{
  Gtk::Button aButton;
  aButton.show();
  ...
  kit.run();
}
</programlisting>
</para>
</sect3>

<sect3>
<title>Dynamic allocation with new and delete</title>

<para> 
Although, in most cases, the programmer will prefer to allow containers to
automatically destroy their children using <function>manage()</function> (see
below), the programmer is not required to use <function>manage()</function>.
The traditional <literal>new</literal> and <literal>delete</literal> operators
may also be used.  
</para>

<para>

<programlisting>
Gtk::Button* pButton = new Gtk::Button("Test");
	
// do something useful with pButton
	
delete pButton;
</programlisting>

Here, the programmer deletes pButton to prevent a memory leak.
</para>
</sect3>

</sect2>

<sect2>
<title>Managed Widgets</title>

<para>
Alternatively, you can let a widget's container control when the widget is
destroyed.  In most cases, you want a widget to last only as long as the
container it is in.  To delegate the management of a widget's lifetime to its
container, first create it with <function>manage()</function> and
pack it into its container with <function>add()</function>.  Now, the
widget will be destroyed whenever its container is destroyed.
</para>

<sect3>
<title>Dynamic allocation with manage() and add()</title>

<para>
&gtkmm; provides the <function>manage()</function> function and
<function>add()</function> methods to create and destroy widgets.  Every widget
except a top-level window must be added or packed into a container in order to
be displayed.  The <function>manage()</function> function marks a packed widget
so that when the widget is added to a container, the container becomes
responsible for deleting the widget.
</para>

<para>
<programlisting>
MyWidget::MyWidget()
{
  Gtk::Button* pButton = manage(new Gtk::Button("Test"));
  add(*pButton); //add aButton to MyWidget
}
</programlisting>

Now, when objects of type <classname>MyWidget</classname> are destroyed, the
button will also be deleted.  It is no longer necessary to delete pButton to
free the button's memory; its deletion has been delegated to the
<classname>MyWidget</classname> object.
</para>

<para>
&gtkmm; also provides the <function>set_manage()</function> method for
all widgets.  This can be used to generate the same result as
<function>manage()</function>, but is more tedious: 
</para>

<para>
foo.add( (w=new Gtk::Label("Hello"), w-&gt;set_manage(), &amp;w) );
</para>

<para>
is the same as
</para>

<para>
foo.add( manage(new Gtk::Label("Hello")) );
</para>

<para>
Of course, a top level container will not be added to another container.  The
programmer is responsible for destroying the top level container using one of
the traditional C++ techniques. For instance, your top-level Window might just
be an instance in your <function>main()</function> function..
</para>

</sect3>
</sect2>
</sect1>

<sect1 id="sec-Memory-SharedResources">
<title>Shared resources</title>

<para>
Some objects, such as <classname>Gdk::Pixmap</classname>s and
<classname>Pango::Font</classname>s, are obtained from a shared store.
Therefore you cannot instantiate your own instances. These classes typically
inherit from <classname>Glib::Object</classname>. Rather than requiring you to
reference and unreference these objects, &gtkmm; uses the
<classname>RefPtr&lt;&gt;</classname> smartpointer.
</para>

<para>
Objects such as <classname>Gdk::Bitmap</classname> can only be instantiated
with a <function>create()</function> function. For instance,
<programlisting>
Glib::RefPtr&lt;Gdk::Bitmap&gt; bitmap = Gdk::Bitmap::create(window, data, width, height);
</programlisting>
</para>

<para>
You have no way of getting a bare <classname>Gdk::Bitmap</classname>. In the
example, <varname>bitmap</varname> is a smart pointer, so you can do this, much
like a normal pointer:
<programlisting>
if(bitmap)
{
  int depth = bitmap-&gt;get_depth().
}
</programlisting>
</para>

<para>
When <varname>bitmap</varname> goes out of scope an
<function>unref()</function> will happen in the background and you don't need
to worry about it anymore. There's no <literal>new</literal> so there's no
<literal>delete</literal>.
</para>
<para>
If you copy a <classname>RefPtr</classname>, for instance
<programlisting>
Glib::RefPtr&lt;Gdk::Bitmap&gt; bitmap2 = bitmap.
</programlisting>
, or if you pass it as a method argument or a return type, then
<classname>RefPtr</classname> will do any necessary referencing to ensure that
the instance will not be destroyed until the last <classname>RefPtr</classname>
has gone out of scope.
</para>
<para>See the <link linkend="sec-appendix-refptr">appendix</link> for detailed information about RefPtr.</para>
<para>
If you wish to learn more about smartpointers, you might look in these
books:
<itemizedlist>
<listitem><para>
Bjarne Stroustrup, "The C++ Programming Language" - section 14.4.2
</para></listitem>
<listitem><para>
Nicolai M. Josuttis, "The C++ Standard Library" - section 4.2
</para></listitem>
</itemizedlist>
</para>

</sect1>

</chapter>

<chapter id="sec-libglademm">
<title>Glade and libglademm</title>
<para>
Although you can use C++ code to instantiate and arrange widgets, this
can soon become tedious and repetitive. And it requires a recompilation to show
changes. The <application>Glade</application> application allows you to layout
widgets on screen and then save an XML description of the arrangement. Your
application can then use the <application>libglademm</application> API to load
that XML file at runtime and obtain a pointer to specifically named widget
instances. 
</para>

<para>
This has the following advantages:
<orderedlist>
<listitem><simpara>Less C++ code is required.</simpara></listitem>
<listitem><simpara>UI changes can be seen more quickly, so UIs are able to improve.</simpara></listitem>
<listitem><simpara>Designers without programming skills can create and edit UIs.</simpara></listitem>
</orderedlist>
</para>

<para>
You still need C++ code to deal with User Interface changes triggered by user
actions, but using <application>libglademm</application> for the basic widget
layout allows you to focus on implementing that functionality.
</para>

<sect1 id="sec-libglademm_headers_and_linking">
<title>Headers and Linking</title>
<para>To use libglade, you must include the header file, like so:
<programlisting>
#include &lt;libglademm.h&gt;
</programlisting>
</para>
<para>You must also link to the libglademm library. For instance, you can add libglademm-2.4 to your list of pkg-config modules, as described in the <link linkend="sec-headers_and_linking">Headers and Linking section for gtkmm</link>.
</para>
</sect1>

<sect1 id="sec-loading_glade_file">
<title>Loading the .glade file</title>
<para>
<classname>Gnome::Glade::Xml</classname> must be used via a
<classname>Glib::RefPtr</classname>. Like all such classes, you need to use
<function>create()</function> method to instantiate it. 
<programlisting>
Glib::RefPtr&lt;Gnome::Glade::Xml&gt; refXml = Gnome::Glade::Xml::create(&quot;basic.glade&quot;);
</programlisting>
This will instantiate the windows defined in the .glade file, though they will
not be shown immediately unless you have specified that via the Properties
window in <application>Glade</application>.
</para>

<para>To instantiate just one window, or just one of the child widgets, you can specify the name of a widget as the second parameter. For instance,
<programlisting>
Glib::RefPtr&lt;Gnome::Glade::Xml&gt; refXml = Gnome::Glade::Xml::create(&quot;basic.glade&quot;, &quot;treeview_products&quot;);
</programlisting>
</para>

</sect1>

<sect1 id="sec-accessing_widgets">
<title>Accessing widgets</title>

<para>
To access a widget, for instance to <function>show()</function> a dialog, use
the <function>get_widget()</function> method, providing the widget's name. This
name should be specified in the <application>Glade</application> Properties
window. If the widget could not be found, or is of the wrong type, then the
pointer will be set to 0.
<programlisting>
Gtk::Dialog* pDialog = 0;
refXml-&gt;get_widget(&quot;DialogBasic&quot;, pDialog);
</programlisting>
</para>

<para>
<application>libglademm</application> checks for a null pointer, and checks
that the widget is of the expected type, and will show warnings on the command
line about these.
</para>

<para>
Remember that you are not instantiating a widget with
<function>get_widget()</function>, you are just obtaining a pointer to one that
already exists. You will always receive a pointer to the same instance when you
call <function>get_widget()</function> on the same
<classname>Gnome::Glade::Xml</classname>, with the same widget name. The
widgets are instantiated during <function>Glade::Xml::create()</function>. 
</para>

<para>
<function>get_widget()</function> returns child widgets that are
<function>manage()</function>ed (see the <link linkend="sec-Memory">Memory 
Management</link> chapter), so they will be deleted when their parent
container is deleted. So, if you get only a child widget from
<application>libglademm</application>, instead of a whole window, then you must
either put it in a <classname>Container</classname> or delete it.
<classname>Windows</classname> (such as <classname>Dialogs</classname>) can not
be managed because they have no parent container, so you must delete them at
some point.
</para>

<sect2>
<title>Example</title>
<para>
The <literal>basic</literal> example in the
<application>libglademm</application> package shows how to load a
<application>Glade</application> file at runtime and access the widgets with
<application>libglademm</application>.
</para>
</sect2>

</sect1>


<sect1 id="sec-using_derived_widgets">
<title>Using derived widgets</title>
<para>
You can use <application>Glade</application> to layout your own custom widgets
derived from &gtkmm; widget classes. This keeps your code organised and
encapsulated. Of course you won't see the exact appearance and properties of
your derived widget in <application>Glade</application>, but you can specify
its location and child widgets and the properties of its &gtkmm; base class.
</para>

<para>Use <function>Glade::Xml::get_widget_derived()</function> like so: 
<programlisting>
DerivedDialog* pDialog = 0;
refXml-&gt;get_widget_derived(&quot;DialogBasic&quot;, pDialog);
</programlisting>
</para>

<para>
Your derived class must have a constructor that takes a pointer to the
underlying C type, and the <classname>Gnome::Glade::Xml</classname> instance.
All relevant classes of &gtkmm; typedef their underlying C type as
<classname>BaseObjectType</classname> (<classname>Gtk::Dialog</classname>
typedefs <classname>BaseObjectType</classname> as <type>GtkDialog</type>, for instance).
</para>
<para>
You must call the base class's constructor in the initialization list, providing the C pointer.  For
instance,
<programlisting>
DerivedDialog::DerivedDialog(BaseObjectType* cobject, const Glib::RefPtr&lt;Gnome::Glade::Xml&gt;&amp; refGlade)
: Gtk::Dialog(cobject)
{
}
</programlisting>
</para>
 
<para>
You could then encapsulate the manipulation of the child widgets in the
constructor of the derived class, maybe using <function>get_widget()</function>
or <function>get_widget_derived()</function> again. For instance,
<programlisting>
DerivedDialog::DerivedDialog(BaseObjectType* cobject, const Glib::RefPtr&lt;Gnome::Glade::Xml&gt;&amp; refGlade)
: Gtk::Dialog(cobject),
  m_refGlade(refGlade),
  m_pButton(0)
{
  //Get the Glade-instantiated Button, and connect a signal handler:
  m_refGlade-&gt;get_widget(&quot;quit_button&quot;, m_pButton);
  if(m_pButton)
  {
    m_pButton-&gt;signal_clicked().connect( sigc::mem_fun(*this, &amp;DerivedDialog::on_button_quit) );
  }
}
</programlisting>
</para>

<sect2>
<title>Example</title>
<para>The <literal>derived</literal> example in the <literal>libglademm</literal> package shows how to load a Glade file at runtime and access a widgets via a derived class.
</para>
</sect2>

</sect1>

</chapter>

<chapter id="sec-internationalization">
  <title>Internationalization and Localization</title>

  <para>
    &gtkmm; applications can easily support multiple languages, including
    non-European languages such as Chinese and right-to-left languages such as
    Arabic. An appropriately-written and translated &gtkmm; application will use
    the appropriate language at runtime based on the user's environment.
  </para>
  <para>
    You might not anticipate the need to support additional languages, but
    you can never rule it out. And it's easier to develop the application
    properly in the first place rather than retrofitting later.
  </para>

  <para>
    The process of writing source code that allows for translation is called
    <literal>internationalization</literal>, often abbreviated to
    <literal>i18n</literal>. The <literal>Localization</literal> process,
    sometimes abbreviated as <literal>l10n</literal>, provides translated text
    for other languages, based on that source code.
  </para>

  <para>
    The main activity in the internationalization process is finding strings
    seen by users and marking them for translation. You do not need to do it all
    at once - if you set up the necessary project infrastructure correctly then
    your application will work normally regardless of how many strings you've
    covered.
  </para>

  <para>
    String literals should be typed in the source code in English, but
    surrounded by a macro.  The <application>gettext</application> (or intltool)
    utility can then extract the marked strings for tramslation, and substitute
    the translated text at runtime.
  </para>

  <sect1 id="sec-internationalization-intro">
    <title>Preparing your project</title>

    <note>
      <para>
        In the instructions below we will assume that you will not be using
        <application>gettext</application> directly, but
        <application>intltool</application>, which was written specifically for
        <literal>GNOME</literal>. <application>intltool</application> uses
        <function>gettext()</function>, which extracts strings from source code,
        but <application>intltool</application> can also combine strings from
        other files, for example from desktop menu details, and GUI resource
        files such as <application>Glade</application> files, into standard
        <application>gettext</application> <filename>.pot/.po</filename> files.
      </para>
      <para>
        We also assume that you are using autotools (e.g.
        <application>automake</application> and
        <application>autoconf</application>) to build your project, and
        that you are using <ulink
          url="http://svn.gnome.org/viewcvs/gnome-common/trunk/autogen.sh?view=markup">
          <literal>./autogen.sh</literal> from
          <application>gnome-common</application></ulink>, which, among other
        things, takes care of some <application>intltool</application>
        initialization.
      </para>
    </note>

    <para>
      Create a sub-directory named <literal>po</literal> in your project's root
      directory. This directory will eventually contain all of your
      translations.  Within it, create a file named <literal>LINGUAS</literal>
      and a file named <literal>POTFILES.in</literal>.  It is common practice to
      also create a <literal>ChangeLog</literal> file in the
      <literal>po</literal> directory so that translators can keep track of
      translation changes.
    </para>

    <para>
      <literal>LINGUAS</literal> contains an alphabetically sorted list of codes
      identifying the languages for which your program is translated (comment
      lines starting with a <literal>#</literal> are ignored). Each language
      code listed in the <literal>LINGUAS</literal> file must have a
      corresponding <literal>.po</literal> file.  So, if your program has German
      and Japanese translations, your <literal>LINGUAS</literal> file would
      look like this:
    </para>
    <programlisting># keep this file sorted alphabetically, one language code per line
de
ja</programlisting>
    <para>
      (In addition, you'd have the files <literal>ja.po</literal> and
      <literal>de.po</literal> in your
      <literal>po</literal> directory which contain the German and Japanese
      translations, respectively.)
    </para>

    <para>
      <literal>POTFILES.in</literal> is a list of paths to all files which
      contain strings marked up for translation, starting from the project root
      directory.  So for example, if your project sources were located in a
      subdirectory named <literal>src</literal>, and you had two files that
      contained strings that should be translated, your
      <literal>POTFILES.in</literal> file might look like this:
    </para>

    <programlisting>src/main.cc
src/other.cc</programlisting>

    <para>
      If you are using <application>gettext</application> directly, you can only
      mark strings for translation if they are in source code file.  However, if
      you use <application>intltool</application>, you can mark strings for
      translation in a variety of other file formats, including
      <application>Glade</application> UI files, xml, <ulink
        url="http://standards.freedesktop.org/desktop-entry-spec/latest/">.desktop
        files</ulink> and several more.  So, if you have designed some of the
      application UI in <application>Glade</application> then also add your
      <filename>.glade</filename> files to the list in
      <literal>POTFILES.in</literal>.
    </para>

    <para>
      Now that there is a place to put your translations, you need to initialize
      <application>intltool</application> and <application>gettext</application>.
      Add the following code to your <literal>configure.ac</literal>,
      substituting 'programname' with the name of your program:
    </para>

    <programlisting>IT_PROG_INTLTOOL([0.35.0])

GETTEXT_PACKAGE=programname
AC_SUBST(GETTEXT_PACKAGE)
AC_DEFINE_UNQUOTED([GETTEXT_PACKAGE], ["$GETTEXT_PACKAGE"],
                   [The domain to use with gettext])
AM_GLIB_GNU_GETTEXT

PROGRAMNAME_LOCALEDIR=[${datadir}/locale]
AC_SUBST(PROGRAMNAME_LOCALEDIR)</programlisting>

    <para>
      This <varname>PROGRAMNAME_LOCALEDIR</varname> variable will be used later
      in the <literal>Makefile.am</literal> file, to define a macro that will be
      used when you initialize <application>gettext</application> in your source
      code.
    </para>

    <para>
      In the top-level Makefile.am:
      <itemizedlist>
        <listitem>
          <para>Add <literal>po</literal> to the <literal>SUBDIRS</literal>
            variable.  Without this, your translations won't get built and
            installed when you build the program</para>
        </listitem>
        <listitem>
          <para>
            Define <literal>INTLTOOL_FILES</literal> as:
            <programlisting>INTLTOOL_FILES = intltool-extract.in \
                 intltool-merge.in \
                 intltool-update.in</programlisting>
          </para>
        </listitem>
        <listitem>
          <para>
            Add <literal>INTLTOOL_FILES</literal> to the
            <literal>EXTRA_DIST</literal> list of files.  This ensures that when
            you do a <command>make dist</command>, these commands will be
            included in the source tarball.
          </para>
        </listitem>
        <listitem>
          <para>
            Update your <literal>DISTCLEANFILES</literal>:
            <programlisting>DISTCLEANFILES = ... intltool-extract \
                 intltool-merge \
                 intltool-update \
                 po/.intltool-merge-cache</programlisting>
          </para>
        </listitem>
      </itemizedlist>
    </para>

    <para>
      In your <literal>src/Makefile.am</literal>, update your
      <literal>AM_CPPFLAGS</literal> to add the following preprocessor macro
      definition:
    </para>
    <programlisting>AM_CPPFLAGS = ... -DPROGRAMNAME_LOCALEDIR=\"${PROGRAMNAME_LOCALEDIR}\"</programlisting>
    <para>
      This macro will be used when you initialize <literal>gettext</literal> in
      your source code.
    </para>
  </sect1>

<sect1 id="sec-i18n-marking-strings">
  <title>Marking strings for translation</title>

  <para>
    String literals should be typed in the source code in English, but
    they should be surrounded by a call to the <function>gettext()</function>
    function. These strings will be extracted for translation and the
    translations may be used at runtime instead of the original English
    strings.
  </para>

  <para>
    The <application>GNU gettext</application> package allows you to mark
    strings in source code, extract those strings for translation, and use
    the translated strings in your application.
  </para>

  <para>
    However, <application>Glib</application> defines
    <function>gettext()</function>
    support macros which are shorter wrappers in an easy-to-use form.
    To use these macros, include <literal>&lt;glibmm/i18n.h&gt;</literal>,
    and then, for example, substitute:
    <programlisting>display_message("Getting ready for i18n.");</programlisting>
    with:
    <programlisting>display_message(_("Getting ready for i18n."));</programlisting>
  </para>

  <para>
    For reference, it is possible to generate a file which contains all
    strings which appear in your code, even if they are not marked for translation, 
    together with file name and line
    number references. To generate such a file named
    <literal>my-strings</literal>, execute the following command,
    within the source code directory:

    <programlisting>xgettext -a -o my-strings --omit-header *.cc *.h</programlisting>
  </para>

  <para>
    Finally, to let you program use the translation for the current locale,
    add this code to the beginning of your <filename>main.cc</filename> file, to initialize gettext.

<programlisting>bindtextdomain(GETTEXT_PACKAGE, PROGRAMNAME_LOCALEDIR);
bind_textdomain_codeset(GETTEXT_PACKAGE, "UTF-8");
textdomain(GETTEXT_PACKAGE);</programlisting>
  </para>

  <sect2 id="sec-i18n-gettext">
    <title>How gettext works</title>

    <para>
      <application>intltool</application> /
      <application>xgettext</application> script extracts the strings
      and puts them in a <filename>mypackage.pot</filename> file.
      The translators of your application create their translations by
      first copying this <filename>.pot</filename> file to a
      <filename>localename.po</filename> file. A locale identifies a
      language and an encoding for that language, including date and numerical
      formats. Later, when the text in your source code has changed, the
      <literal>msmerge</literal> script is used to update the
      <filename>localename.po</filename> files from the regenerated
      <filename>.pot</filename> file.
    </para>

    <para>
      At install time, the <filename>.po</filename> files are converted to
      a binary format (with the extension <filename>.mo</filename>) and
      placed in a system-wide directory for locale files, for example
      <filename>/usr/share/locale/</filename>.
    </para>

    <para>
      When the application runs, the <application>gettext</application>
      library checks the system-wide directory to see if there is a
      <filename>.mo</filename> file for the user's locale environment
      (you can set the locale with, for instance, "export LANG=de_DE.UTF-8"
      from a bash console). Later, when the program reaches a
      <literal>gettext</literal> call, it looks for a translation of a
      particular string. If none is found, the original string is used.
    </para>
  </sect2>

  <sect2 id="sec-i18n-testing">
    <title>Testing and adding translations</title>

    <para>
      To convince yourself that you've done well, you may wish to add a
      translation for a new locale. In order to do that, go to the
      <filename>po</filename> subdirectory of your project and
      execute the following command:
      <programlisting>intltool-update --pot</programlisting>
    </para>

    <para>
      That will create a file named <filename>programname.pot</filename>.
      Now copy that file to <filename>languagecode.po</filename>, such as
      <filename>de.po</filename> or <filename>hu.po</filename>. Also add
      that language code to <literal>LINGUAS</literal>. The
      <filename>.po</filename> file contains a header and a list of English strings,
      with space for the translated strings to be entered. Make sure you set the
      encoding of the <filename>.po</filename> file (specified in the header, but
      also as content) to <literal>UTF-8</literal>.
    </para>

    <!-- TODO: This need more explanation. What's the point of the fuzzy tag then? murrayc -->
    <note>
      <para>
      It's possible that certain strings will be marked as
      <literal>fuzzy</literal> in the <filename>.po</filename> file.
      These translations will not substitute the original string. To make
      them appear, simply remove the <literal>fuzzy</literal> tag.
      </para>
    </note>
  </sect2>

  <sect2 id="sec-i18n-resources">
    <title>Resources</title>

    <para>
      More information about what lies behind the internationalization and localization process
      is presented and demonstrated in:

      <itemizedlist>
        <listitem>
          <para>
            <ulink url="http://www.gnome.org/~malcolm/i18n/index.html">
              Internationalizing GNOME applications</ulink>
          </para>
        </listitem>

        <listitem>
          <para>
            <ulink url="http://svn.gnome.org/viewcvs/intltool/trunk/README?view=markup">Intltool README</ulink>
          </para>
        </listitem>

        <listitem>
          <para>
            <ulink url="http://developer.gnome.org/doc/tutorials/gnome-i18n/translator.html">How to use GNOME CVS as a Translator</ulink>
          </para>
        </listitem>

        <listitem>
          <para>
            <ulink url="http://www.gnu.org/software/gettext/manual/gettext.html">gettext manual</ulink>
          </para>
        </listitem>

        <listitem>
          <para>
            <ulink url="http://ftp.gnome.org/pub/GNOME/sources/gtkmm_hello/"><literal>gtkmm_hello</literal> example package</ulink>
          </para>
        </listitem>

        <listitem>
          <para>
            <ulink url="http://ftp.gnome.org/pub/GNOME/sources/gnomemm_hello/"><literal>gnomemm_hello</literal> example package</ulink>
          </para>
        </listitem>
      </itemizedlist>
    </para>
  </sect2>

</sect1>

<sect1 id="sec-expecting_utf8">
<title>Expecting UTF8</title>
<para>
A properly internationalized application will not make assumptions about the
number of bytes in a character. That means that you shouldn't use pointer
arithmetic to step through the characters in a string, and it means you
shouldn't use <classname>std::string</classname> or standard C functions such
as <function>strlen()</function> because they make the same assumption.
</para>
<para>
However, you probably already avoid bare char* arrays and pointer arithmetic by
using <classname>std::string</classname>, so you just need to start using
<classname>Glib::ustring</classname> instead. See the <link
    linkend="sec-basics-ustring">Basics</link> chapter about
<classname>Glib::ustring</classname>.
</para>

<sect2><title>Glib::ustring and std::iostreams</title>
<para>TODO: This section is not clear - it needs to spell things out more clearly and obviously.</para>
<para>
Unfortunately, the integration with the standard iostreams is not completely
foolproof. &gtkmm; converts <classname>Glib::ustring</classname>s to a
locale-specific encoding (which usually is not UTF-8) if you output them to an
<classname>ostream</classname> with <function>operator&lt;&lt;</function>.
Likewise, retrieving <classname>Glib::ustrings</classname> from
<classname>istream</classname> with <function>operator&gt;&gt;</function>
causes a conversion in the opposite direction. But this scheme breaks down if
you go through a <classname>std::string</classname>, e.g. by inputting text
from a stream to a <classname>std::string</classname> and then implicitly
converting it to a <classname>Glib::ustring</classname>. If the string
contained non-ASCII characters and the current locale is not UTF-8 encoded, the
result is a corrupted <classname>Glib::ustring</classname>. You can work around
this with a manual conversion. For instance, to retrieve the
<classname>std::string</classname> from a <classname>ostringstream</classname>:
<programlisting>std::ostringstream output;
output.imbue(std::locale("")); // use the user's locale for this stream
output &lt;&lt; percentage &lt;&lt; " % done";
label-&gt;set_text(Glib::locale_to_utf8(output.str()));</programlisting>
</para>
</sect2>

</sect1>

<sect1 id="sec-i18n-pitfalls">
      <title>Pitfalls</title>

      <para>There are a few common mistakes that you would discover eventually yourself. But this section might help you to avoid them.</para>

<sect2>
	<title>Same strings, different semantics</title>

	<para>Sometimes two english strings are identical but have different meanings in
different contexts, so they would probably not be identical when translated. Since the English strings are
	  used as look-up keys, this causes problems.</para>

<para>
In these cases, you should add extra characters to the strings. For instance,
use <literal>"jumps[noun]"</literal> and <literal>"jumps[verb]"</literal>
instead of just <literal>"jumps"</literal>) and strip them again outside the
<function>gettext</function> call. If you add extra characters you should also
add a comment for the translators before the <function>gettext</function> call.
Such comments will be shown in the <filename>.po</filename> files. For
instance:
</para>

<programlisting>// note to translators: don't translate the "[noun]" part - it is
// just here to distinguish the string from another "jumps" string
text = strip(gettext("jumps[noun]"), "[noun]");</programlisting>
      </sect2>

<sect2>
  <title>Composition of strings</title>

<para>
C programmers use <function>sprintf()</function> to compose and concatenate
strings. C++ favours streams, but unfortunately, this approach makes
translation difficult, because each fragment of text is translated separately,
without allowing the translators to rearrange them according to the grammar of
the language.</para>

<para>For instance, this code would be problematic:</para>

<programlisting>std::cout &lt;&lt; _("Current amount: ") &lt;&lt; amount
          &lt;&lt; _(" Future: ") &lt;&lt; future &lt;&lt; std::endl;

label.set_text(_("Really delete ") + filename + _(" now?"));</programlisting>

<para>
So you should either avoid this situation or revert to the C-style
<function>sprintf()</function>.  One possible solution is the <ulink
    url="http://www.cs.auc.dk/~olau/compose/">compose library</ulink> which
supports syntax such as:
</para>

<programlisting>label.set_text(compose(_("Really delete %1 now?"), filename));</programlisting>
</sect2>

<sect2>
	<title>Assuming the displayed size of strings</title>

	<para>You never know how much space a string will take on screen when translated. It might very possibly be twice the size of the original English string. Luckily, most &gtkmm; widgets will expand at runtime to the required size.</para>
</sect2>

<sect2>
	<title>Unusual words</title>

	<para>You should avoid cryptic abbreviations, slang, or jargon.
	  They are usually difficult to translate, and are often difficult
for even native speakers to understand. For instance, prefer &quot;application&quot; to &quot;app&quot;</para>
</sect2>

<sect2>
<title>Using non-ASCII characters in strings</title>

<para>
Currently, <application>gettext</application> does not support non-ASCII
characters (i.e. any characters with a code above 127) in source code. For
instance, you cannot use the copyright sign (&copy;).
</para>

	<para>To work around this, you could write a comment in the
	  source code just before the string, telling the translators to
	  use the special character if it is available in their languages. For english, you could then make an American English
	  <filename>en_US.po</filename> translation which used that special charactger.</para>
      </sect2>
    </sect1>

    <sect1 id="sec-getting_help_with_translations">
      <title>Getting help with translations</title>

      <para>If your program is free software, there is a whole <literal>GNOME</literal>
	subproject devoted to helping you make translations, the
	<ulink url="http://developer.gnome.org/projects/gtp/"><literal>GNOME</literal>
	Translation Project</ulink>.</para>

      <para>The way it works is that you contact the gnome-i18n
	mailing list to find out how the translators can access your
	<filename>po/</filename> subdirectory, and to add your project
	to the big <ulink
	url="http://developer.gnome.org/projects/gtp/status/">status
	tables</ulink>.</para>

      <para>Then you make sure you update the file
	<filename>POTFILES.in</filename> in the
	<filename>po/</filename> subdirectory
	(<command>intltool-update -M</command> can help with this) so
	that the translators always access updated
	<filename>myprogram.pot</filename> files, and simply freeze
	the strings at least a couple of days before you make a new
	release, announcing it on gnome-i18n. Depending on the number
	of strings your program contains and how popular it is, the
	translations will then start to tick in as
	<filename>languagename.po</filename> files.</para>

      <para>Note that most language teams only consist of 1-3 persons,
	so if your program contains a lot of strings, it might last a
	while before anyone has the time to look at it. Also, most
	translators do not want to waste their time (translating is
	a very time-consuming task) so if they do not assess your
	project as being really serious (in the sense that it is
	polished and being maintained) they may decide to spend their
	time on some other project.</para>
    </sect1>
</chapter>

<chapter id="sec-customwidgets">
    <title>Custom Widgets</title>

    <para>&gtkmm; makes it very easy to derive new widgets by inheriting from an existing widget class, either by deriving from a container and adding child widgets, or by deriving from a single-item widget, and changing its behaviour. But you might occasionally find that no suitable starting point already exists. In this case, you can implement a widget from scratch.</para>
    <sect1>
    <title>Custom Containers</title>
    <para>When deriving from <classname>Gtk::Container</classname>, you should override the following virtual methods:
    <itemizedlist>
      <listitem><para><function>on_size_request()</function>: Calculate the minimum height and width needed by the container.</para></listitem>
      <listitem><para><function>on_size_allocate()</function>: Position the child widgets, given the height and width that the container has actually been given.</para></listitem>
      <listitem><para><function>forall_vfunc()</function>: Call the same callback for each of the children.</para></listitem>
      <listitem><para><function>on_add()</function>: </para></listitem>
      <listitem><para><function>on_remove()</function>: </para></listitem>
      <listitem><para><function>child_type_vfunc()</function>: Return what type of child can be added.</para></listitem>
    </itemizedlist>
    </para>

    <para>The <function>on_size_request()</function> and
        <function>on_size_allocate()</function> virtual methods control the
        layout of the child widgets. For instance, if your container has 2
        child widgets, with one below the other, your
        <function>on_size_request()</function> might report the maximum of
        their widths and the sum of their heights. If you want padding between
        the child widgets then you would add that to the width and height too.
        Your widget's container will use this result to ensure that your widget
        gets enough space, and not less. By examining each widget's parent, and
        its parent, this logic will eventually decide the size of the top-level
        window.</para>

   <para><function>on_size_allocate()</function>, however, receives the actual
       height and width that the parent container has decided to give to your
       widget. This might be more than the minimum, for instance if the
       top-level window has been expanded. You might choose to ignore the extra
       space and leave a blank area, or you might choose to expand your child
       widgets to fill the space, or you might choose to expand the padding
       between your widgets. Its your container, so you decide. Don't forget to
       call <function>set_allocation()</function> inside your
       <function>on_size_allocate()</function> implementation to actually use the
       allocated space that has been offered by the parent container.</para>

  <para>Unless your container is a top-level window that derives from
      <classname>Gtk::Window</classname>, you should also call
      <function>Gtk::Container::set_flags(Gtk::NO_WINDOW)</function> in your
      constructor. Otherwise, your container will appear in its own window,
      regardless of what container you put it in. And unless your container
      draws directly onto the underlying <classname>Gdk::Window</classname>,
      you should probably call
      <function>set_redraw_on_allocate(false)</function> to improve
      performance.</para>

  <para>By overriding <function>forall_vfunc()</function> you can allow
      applications to operate on all of the container's child widgets. For
      instance, <function>show_all_children()</function> uses this to find all
      the child widgets and show them.</para>
 
  <para>Although your container might have its own method to set the child
      widgets, you should still provide an implementation for the virtual
      <function>on_add()</function> and <function>on_remove()</function>
      methods from the base class, so that the add() and remove() methods will
      do something appropriate if they are called.</para>

  <para>Your implementation of the <function>child_type_vfunc()</function>
      method should report the type of widget that may be added to your
      container, if it is not yet full. This is usually
      <function>Gtk::Widget::get_type()</function> to indicate that the
      container may contain any class derived from
      <classname>Gtk::Widget</classname>. If the container may not contain any
      more widgets, then this method should return
      <literal>G_TYPE_NONE</literal>.</para> 


<sect2><title>Example</title>

    <para>This example implements a container with two child widgets, one above
        the other. Of course, in this case it would be far simpler just to use
        a <classname>Gtk::VBox</classname>.</para>

<figure id="figure-custom-container">
  <title>Custom Container</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;custom_container.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;custom/custom_container/">Source Code</ulink></para>
</sect2>

    </sect1>  

    <sect1>
    <title>Custom Widgets</title>
    <para>By deriving directly from <classname>Gtk::Widget</classname> you can
        do all the drawing for your widget directly, instead of just arranging
        child widgets. For instance, a <classname>Gtk::Label</classname> draws
        the text of the label, but does not do this by using other
        widgets.</para>

<sect2><title>Example</title>

<para>This example implements a widget which draws a Penrose triangle.</para>

<figure id="figure-custom-widget">
  <title>Custom Widget</title>
  <screenshot>
    <graphic format="PNG" fileref="&url_figures_base;custom_widget.png"/>
  </screenshot>
</figure>

<para><ulink url="&url_examples_base;custom/custom_widget/">Source Code</ulink></para>
</sect2>

    </sect1>



</chapter>
  
<chapter id="sec-gathering">
<title>Recommended Techniques</title>

<para>This section is simply a gathering of wisdom, general style guidelines
and hints for creating &gtkmm; applications.
</para>

<para>Use GNU <application>autoconf</application> and
    <application>automake</application>! They are your friends :)
    <application>Automake</application> examines C files, determines how they
    depend on each other, and generates a <filename>Makefile</filename> so the
    files can be compiled in the correct order.
    <application>Autoconf</application> permits automatic configuration of
    software installation, handling a large number of system quirks to increase
    portability..
</para>

<para>Subclass Widgets to better organise your code. You should probably
    subclass your main <classname>Window</classname> at least. Then you can
    make your child Widgets and signal handlers members of that class.
</para>

<para>Create your own signals instead of passing pointers around. Objects can
    communicate with each other via signals and signal handlers. This is much
    simpler than objects holding pointers to each other and calling each
    other's methods. &gtkmm;'s classes uses special versions of
    <classname>Sigc::Signal</classname>, but you should use normal
    <classname>sigc::signal</classname>s, as described in the
    <application>libsigc++</application> documentation.</para>

<sect1><title>Application lifetime</title>
<para>Most applications will have only one <classname>Window</classname>, or
    only one main window. These applications can use the
    <function>Gtk::Main::run(Gtk::Window&amp;)</function> overload. It shows
    the window and returns when the window has been hidden. This might happen
    when the user closes the window, or when your code decides to
    <function>hide()</function> the window.  You can prevent the user from
    closing the window (for instance, if there are unsaved changes) by
    overriding <function>Gtk::Window::on_delete_event()</function>.</para>
<para>Most of our examples use this technique.</para>
</sect1>

<sect1 id="sec-using_a_gtkmm_widget">
<title>Using a &gtkmm; widget</title>

<para>
    Our examples all tend to have the same structure. They follow these steps
    for using a <classname>Widget</classname>:
</para>

<para>

<orderedlist>
<listitem>
<para>
Declare a variable of the type of <classname>Widget</classname> you wish to
use, generally as member variable of a derived container class. You could also
declare a pointer to the widget type, and then create it with
<literal>new</literal> in your code. Even when using the widget via a pointer,
it's still probably best to make that pointer a member variable of a container
class so that you can access it later.
</para>
</listitem>

<listitem>
<para>
 Set the attributes of the widget. If the widget has no default constructor, then you will need to initialize the widget in the initalizer list of your container class's constructor.
</para>
</listitem>

<listitem>
<para>
Connect any signals you wish to use to the appropriate handlers.
</para>
</listitem>

<listitem>
<para>
Pack the widget into a container using the appropriate call,
e.g. <function>Gtk::Container::add()</function> or
<function>pack_start()</function>.
</para>
</listitem>

<listitem>
<para>
Call <function>show()</function> to display the widget.
</para>
</listitem>

</orderedlist>

</para>

<para>
<function>Gtk::Widget::show()</function> lets &gtkmm; know that we have
finished setting the attributes of the widget, and that it is ready to be
displayed. You can use <function>Gtk::Widget::hide()</function> to make it
disappear again. The order in which you show the widgets is not important, but
we do suggest that you show the top-level window last; this way, the whole
window will appear with its contents already drawn.  Otherwise, the user will
first see a blank window, into which the widgets will be gradually drawn.
</para>

</sect1>
</chapter>

<chapter id="sec-Contributing">
<title>Contributing </title>

<para>
This document, like so much other great software out there, was
created for free by volunteers.  If you are at all knowledgeable about
any aspect of &gtkmm; that does not already have documentation, please
consider contributing to this document.
</para>
<para>
Ideally, we would like you to <ulink url="http://www.gtkmm.org/bugs.shtml">provide a patch</ulink> to the
<filename>docs/tutorial/gtkmm-tut.xml</filename> file.  This file is currently
in the <literal>gtkmm</literal> module in GNOME cvs. See 
</para>

<para>
If you do decide to contribute, please post your contribution to the
&gtkmm; mailing list at <ulink url="mailto:gtkmm-list@gnome.org">&#60;gtkmm-list@gnome.org&#62;</ulink>.  Also, be aware that
the entirety of this document is free, and any addition you provide
must also be free. That is, people must be able to use any portion of
your examples in their programs, and copies of this document
(including your contribution) may be distributed freely.
</para>

</chapter>

<appendix id="sec-appendix-refptr">
<title>The RefPtr smartpointer</title>
<para>
<classname>Glib::RefPtr</classname> is a smartpointer. Specifically, it is a
reference-counting smartpointer. You might be familiar with
<literal>std::auto_ptr&lt;&gt;</literal>, which is also a smartpointer, but
<literal>Glib::RefPtr&lt;&gt;</literal> is much simpler, and more useful. We
expect a future version of the C++ Standard Library to contain a
reference-counting shared smartpointer, and a future version of &gtkmm; might possibly use that instead.</para>

<para><ulink url="&url_refdocs_base_glib;RefPtr.html">Reference</ulink></para>

<para>A smartpointer acts much like a normal pointer. Here are a few examples.</para> 

<sect1><title>Copying</title>
<para>
You can copy <classname>RefPtr</classname>s, just like normal pointers. But
unlike normal pointers, you don't need to worry about deleting the underlying
instance.
</para>
<para>
<programlisting>
Glib::RefPtr&lt;Gdk::Bitmap&gt; refBitmap = Gdk::Bitmap::create(window,
data, width, height);
Glib::RefPtr&lt;Gdk::Bitmap&gt; refBitmap2 = refBitmap;
</programlisting>
</para>
<para>
Of course this means that you can store <classname>RefPtrs</classname> in
standard containers, such as <classname>std::vector</classname> or
<classname>std::list</classname>.</para>
<para>
<programlisting>
std::list&lt; Glib::RefPtr&lt;Gdk::Pixmap&gt; &gt; listPixmaps;
Glib::RefPtr&lt;Gdk::Pixmap&gt; refPixmap = Gdk::Pixmap::create(window,
width, height, depth);
listPixmaps.push_back(refPixmap);
</programlisting>
</para>
</sect1>

<sect1 id="sec-dereferencing"><title>Dereferencing</title>
<para>You can dereference a smartpointer with the -&gt; operator, to
call the methods of the underlying instance, just like a normal pointer.
</para>
<para>
<programlisting>
Glib::RefPtr&lt;Gdk::Bitmap&gt; refBitmap = Gdk::Bitmap::create(window,
data, width, height);
int depth = refBitmap-&gt;get_depth();
</programlisting>
</para>
<para>But unlike most smartpointers, you can't use the * operator to
access the underlying instance.
</para>
<para>
<programlisting>
Glib::RefPtr&lt;Gdk::Bitmap&gt; refBitmap = Gdk::Bitmap::create(window,
data, width, height);
Gdk::Bitmap* underlying = *refBitmap; //Syntax error - will not compile.
</programlisting>
</para>
</sect1>

<sect1 id="sec-casting"><title>Casting</title>
<para>
You can cast <classname>RefPtrs</classname> to base types, just like normal
pointers.
</para>
<para>
<programlisting>
Glib::RefPtr&lt;Gtk::TreeStore&gt; refStore = Gtk::TreeStore::create(columns);
Glib::RefPtr&lt;Gtk::TreeModel&gt; refModel = refStore;
</programlisting>
</para>
<para>This means that any method which takes a <type>const
Glib::RefPtr&lt;BaseType&gt;</type> argument can also take a
<type>const Glib::RefPtr&lt;DerivedType&gt;</type>. The cast is
implicit, just as it would be for a normal pointer.</para> 
<para>You can also cast to a derived type, but the syntax is
a little different than with a normal pointer.
</para>
<para>
<programlisting>
Glib::RefPtr&lt;Gtk::TreeStore&gt; refStore =
Glib::RefPtr&lt;Gtk::TreeStore&gt;::cast_dynamic(refModel);
Glib::RefPtr&lt;Gtk::TreeStore&gt; refStore2 =
Glib::RefPtr&lt;Gtk::TreeStore&gt;::cast_static(refModel);
</programlisting>
</para>
</sect1>


<sect1 id="sec-checking_for_null"><title>Checking for null</title>
<para>
Just like normal pointers, you can check whether a
<classname>RefPtr</classname> points to anything.
</para>
<para>
<programlisting>
Glib::RefPtr&lt;Gtk::TreeModel&gt; refModel = m_TreeView.get_model();
if(refModel)
{
  int cols_count = refModel-&gt;get_n_columns();
  ...
}
</programlisting>
</para>
<para>
But unlike normal pointers, <classname>RefPtr</classname>s are automatically
initialized to null so you don't need to remember to do that yourself.
</para>
</sect1>


<sect1 id="sec-constness"><title>Constness</title>
<para>
The use of the <literal>const</literal> keyword in C++ is not always clear. You
might not realise that <type>const Something*</type> declares a pointer to a
<type>const Something</type>, The pointer can be changed, but not the
<type>Something</type> that it points to.
</para>
<para>
Therefore, the <classname>RefPtr</classname> equivalent of
<type>Something*</type> for a method parameter is <type>const
    Glib::RefPtr&lt;Something&gt;&amp;</type>, and the equivalent of
<type>const Something*</type> is <type>const Glib::RefPtr&lt;const
    Something&gt;&amp;</type>.
</para>
<para>
The <literal>const ... &amp;</literal> around both is just for efficiency, like
using <classname>const std::string&amp;</classname> instead of
<classname>std::string</classname> for a method parameter to avoid unnecessary
copying.
</para> 
</sect1>

</appendix>


<appendix id="sec-appendix-signals">
<title>Signals</title>

<sect1>
<title>Connecting signal handlers</title>
<para>
&gtkmm; widget classes have signal accessor methods, such as
<function>Gtk::Button::signal_clicked()</function>, which allow you to connect
your signal handler. Thanks to the flexibility of
<application>libsigc++</application>, the callback library used by &gtkmm;, the
signal handler can be almost any kind of function, but you will probably want
to use a class method. Among <application>GTK+</application> C coders, these
signal handlers are often named callbacks.
</para>

<para>
Here's an example of a signal handler being connected to a signal:
</para>

<para>
<programlisting>
#include &#60;gtkmm/button.h&#62;

void on_button_clicked()
{
    std::cout &#60;&#60; "Hello World" &#60;&#60; std::endl;
}

main()
{
    Gtk::Button button("Hello World");
    button.signal_clicked().connect(sigc::ptr_fun(&amp;on_button_clicked));
}
</programlisting>
</para>

<para>
There's rather a lot to think about in this (non-functional) code.
First let's identify the parties involved:
</para>

<itemizedlist>
<listitem>

<para>
The signal handler is <function>on_button_clicked()</function>.
</para>
</listitem>
<listitem>

<para>
We're hooking it up to the <classname>Gtk::Button</classname> object called
<varname>button</varname>.
</para>
</listitem>
<listitem>

<para>
When the Button emits its <literal>clicked</literal> signal,
<function>on_button_clicked()</function> will be called.
</para>
</listitem>

</itemizedlist>

<para>
Now let's look at the connection again:
</para>

<para>
<programlisting>
    ...
    button.signal_clicked().connect(sigc::ptr_fun(&amp;on_button_clicked));
    ...
</programlisting>
</para>

<para>
Note that we don't pass a pointer to <function>on_button_clicked()</function>
directly to the signal's <function>connect()</function> method.  Instead, we
call <function>sigc::ptr_fun()</function>, and pass the result to
<function>connect()</function>.
</para>

<para>
<function>sigc::ptr_fun()</function>  generates a <classname>sigc::slot</classname>. 
A slot is an object which 
looks and feels like a function, but is actually an object.  These are also
known as function objects, or functors.
<function>sigc::ptr_fun()</function> generates a slot for a standalone function or static method. 
<function>sigc::mem_fun()</function> generates a slot for a member method of a particular instance.
</para>

<para>
Here's a slightly larger example of slots in action:
</para>

<para>
<programlisting>
void on_button_clicked();

class some_class
{
    void on_button_clicked();
};

some_class some_object;

main()
{
    Gtk::Button button;
    button.signal_clicked().connect( sigc::ptr_fun(&amp;on_button_clicked) );
    button.signal_clicked().connect( sigc::mem_fun(some_object, &amp;some_class::on_button_clicked) );
}
</programlisting>
</para>

<para>
The first call to <function>connect()</function> is just like the one we saw
last time; nothing new here.</para>
<para>The next is more interesting. 
<function>sigc::mem_fun()</function> is called with two arguments.  The first
argument is <parameter>some_object</parameter>, which is the object that our
new slot will be pointing at. The second argument is a pointer to one of its
methods. This particular version of <function>sigc::mem_fun()</function>
creates a slot which will, when "called", call the pointed-to method of the
specified object, in this case 
<function>some_object.on_button_clicked()</function>.
</para>

<para>
Another thing to note about this example is that we made the call to
<function>connect()</function> twice for the same signal object.  This is
perfectly fine - when the button is clicked, both signal handlers will be
called.
</para>

<para>
We just told you that the button's <literal>clicked</literal> signal is expecting
to call a method with no arguments.  All signals have
requirements like this - you can't hook a function with two arguments
to a signal expecting none (unless you use an adapter, such as
<function>sigc::bind()</function>, of course).  Therefore, it's important to
know what type of signal handler you'll be expected to connect to a given
signal.
</para>
</sect1>

<sect1 id="sec-writing_signal_handlers">
<title>Writing signal handlers</title>

<para>
To find out what type of signal handler you can connect to a signal, you can
look it up in the reference documentation or the header file. Here's an example of a signal declaration you
might see in the &gtkmm; headers:
</para>

<para>
<programlisting>
Glib::SignalProxy1&lt;bool, Gtk::DirectionType&gt; signal_focus() 
</programlisting>
</para>

<para>
Other than the signal's name (<literal>focus</literal>), two things are
important to note here: the number following the word
<classname>SignalProxy</classname> at the beginning (1, in this case), and the
types in the list (<type>bool</type> and <type>Gtk::DirectionType</type>).  The
number indicates how many arguments the signal handler should have; the first
type, <type>bool</type>, is the type that the signal handler should return; and
the next type, <type>Gtk::DirectionType</type>, is the type of this signal's
first, and only, argument. By looking at the reference documentation, you can
see the names of the arguments too.
</para>

<para>
The same principles apply for signals which have more arguments.  Here's one
with three (taken from <filename>&lt;gtkmm/editable.h&gt;</filename>):
</para>

<para>
<programlisting>
Glib::SignalProxy3&lt;void, const Glib::ustring&amp;, int, int*&gt; signal_insert_text()

</programlisting>
</para>

<para>
It follows the same form.  The number 3 at the end of the type's name indicates
that our signal handler will need three arguments.  The first type in the type
list is <type>void</type>, so that should be our signal handler's return type.
The following three types are the argument types, in order. Our signal
handler's prototype could look like this:
</para>

<para>
<programlisting>
void on_insert_text(const Glib::ustring&amp; text, int length, int* position);
</programlisting>
</para>
</sect1>

<sect1 id="sec-disconnecting_signal_handlers">
<title>Disconnecting signal handlers</title>

<para>
Let's take another look at a Signal's <literal>connect</literal> method:
</para>

<para>
<programlisting>
sigc::signal&lt;void,int&gt;::iterator signal&lt;void,int&gt;::connect( const sigc::slot&lt;void,int&gt;&amp; );
</programlisting>
</para>

<para>
Notice that the return value is of type
<classname>sigc::signal&lt;void,int&gt;::iterator</classname>.  This can be
implicitely converted into a <classname>sigc::connection</classname> which in
turn can be used to control the connection. By keeping a connection object you
can disconnect its associated signal handler using the method
<function>sigc::connection::disconnect()</function>.
</para>

</sect1>
<sect1 id="sec-overriding_default_signal_handlers">
<title>Overriding default signal handlers</title>

<para>
So far we've told you to perform actions in
response to button-presses and the like by handling signals.
That's certainly a good way to do things, but it's not the only
way.
</para>

<para>
Instead of laboriously connecting signal handlers to signals,
you can simply make a new class which inherits from a widget - say, a
Button - and then override the default signal handler, such as Button::on_clicked().  This can be a
lot simpler than hooking up signal handlers for everything.
</para>

<para>
Subclassing isn't always the best way to accomplish
things. It is only useful when you want the widget to handle its own signal by itself. If you want some other class to handle the signal then you'll need to connect a separate handler. This is even more true if you want several objects to handle the same signal, or if you want one signal handler to respond to the same signal from different objects.
</para>

<para>
&gtkmm; classes are designed with overriding in mind; they contain
virtual member methods specifically intended to be overridden.
</para>

<para>
Let's look at an example of overriding:
</para>

<para>
<programlisting>
#include &#60;gtkmm/button.h&#62;

class OverriddenButton : public Gtk::Button
{
protected:
    virtual void on_clicked();
}

void OverriddenButton::on_clicked()
{
    std::cout &#60;&#60; "Hello World" &#60;&#60; std::endl;

    // call the base class's version of the method:
    Gtk::Button::on_clicked();
}
</programlisting>
</para>

<para>
Here  we define a new class called <classname>OverriddenButton</classname>,
which inherits from <classname>Gtk::Button</classname>.  The only thing we
change is the <function>on_clicked()</function> method, which is called
whenever <classname>Gtk::Button</classname> emits the
<literal>clicked</literal> signal.  This method prints "Hello World" to
<literal>stdout</literal>, and then calls the original, overridden method, to
let <classname>Gtk::Button</classname> do what it would have done had we not
overridden.
</para>

<para>
You don't always need to call the parent's method; there are times
when you might not want to.  Note that we called the parent method
<emphasis>after</emphasis> writing "Hello World", but we could have called it before.
In this simple example, it hardly matters much, but there are times
when it will.  With signals, it's not quite so easy to change details
like this, and you can do something here which you can't do at all
with connected signal handlers: you can call the parent method in the <emphasis>middle</emphasis> of
your custom code.
</para>

</sect1>

<sect1 id="sec-binding_extra_arguments">
<title>Binding extra arguments</title>
<para>
If you use one signal handler to catch the same signal from several widgets,
you might like that signal handler to receive some extra information. For
instance, you might want to know which button was clicked. You can do this with
<function>sigc::bind()</function>. Here's some code from the <link
    linkend="sec-helloworld2">helloworld2</link> example, which you will
encounter later.
<programlisting>
m_button1.signal_clicked().connect( sigc::bind&lt;Glib::ustring&gt;( sigc::mem_fun(*this, &amp;HelloWorld::on_button_clicked), "button 1") );
</programlisting>
This says that we want the signal to send an extra
<classname>Glib::ustring</classname> argument to the signal handler, and that
the value of that argument should be "button 1".  Of course we will need to add
that extra argument to the declaration of our signal handler:
<programlisting>
virtual void on_button_clicked(Glib::ustring data);
</programlisting>
Of course, a normal "clicked" signal handler would have no arguments.
</para>
<para>
<function>sigc::bind()</function> is not commonly used, but you might find it
helpful sometimes. If you are familiar with <application>GTK+</application>
programming then you have probably noticed that this is similar to the extra
<literal>gpointer data</literal> arguments which all GTK+ callbacks have. This
is generally overused in <application>GTK+</application> to pass information
that should be stored as member data in a derived widget, but widget derivation
is very difficult in C.  We have far less need of this hack in &gtkmm;.
</para>  
</sect1>

<sect1 id="sec-xeventsignals">
<title>X Event signals</title>
<para>
The <classname>Widget</classname> class has some special signals which
correspond to the underlying X-Windows events. These are suffixed by
<literal>_event</literal>; for instance,
<function>Widget::signal_button_pressed_event()</function>.
</para>
<para>
You might occasionally find it useful to handle X events when there's something
you can't accomplish with normal signals.  <classname>Gtk::Button</classname>,
for example, does not send mouse-pointer coordinates with its
<literal>clicked</literal> signal, but you could handle
<literal>button_pressed_event</literal> if you needed this
information.  X events are also often used to handle key-presses.
</para>

<para>
These signals behave slightly differently.  The value returned from the signal handler indicates whether it has fully "handled"
the event.  If the value is <literal>false</literal> then &gtkmm; will pass the event on to the next signal handler.  If the value is <literal>true</literal> then no other signal handlers will need to be called.
</para>

<para>
Handling an X event doesn't affect the Widget's other signals.  If you handle
<literal>button_pressed_event</literal> for
<classname>Gtk::Button</classname>, you'll still be able to get the
<literal>clicked</literal> signal.  They are emitted at (nearly) the same time.
</para>

<para>
Here's a simple example:
<programlisting>
bool on_button_press(GdkEventButton* event);
Gtk::Button button("label");
button.signal_button_press_event().connect( sigc::ptr_fun(&amp;on_button_press) );
</programlisting>
</para>
<para>
When the mouse is over the button and a mouse button is pressed,
<function>on_button_pressed()</function> will be called.
</para>

<para>
<type>GdkEventButton</type> is a structure containing the event's parameters,
such as the coordinates of the mouse pointer at the time the button was
pressed.  There are several different types of <type>GdkEvent</type> structures
for the various events.
</para>

<sect2>
<title>Signal Handler sequence</title>
<para>By default, your signal handlers are called after any previously-connected signal handlers. However, this can be a problem with the X Event signals. For instance, the existing signal handlers, or the default signal handler, might return true to stop other signal handlers from being called. To specify that your signal handler should be called before the other signal handlers, so that will always be called, you can specify <literal>false</literal> for the optional <literal>after</literal> parameter. For instance,
<programlisting>
button.signal_button_press_event().connect( sigc::ptr_fun(&amp;on_mywindow_button_press), false );
</programlisting>
</para>
 
</sect2>

</sect1>

</appendix>



<appendix id="sec-appendix-custom_signals">
<title>Creating your own signals</title>
<para>
Now that you've seen signals and signal handlers in &gtkmm;, you
might like to use the same technique to allow interaction between your
own classes. That's actually very simple by using the
<application>libsigc++</application> library directly.
</para>
<para>
This isn't purely a &gtkmm; or GUI issue. &gtkmm; uses
<application>libsigc++</application> to implement its proxy wrappers for the
<application>GTK+</application> signal system, but for new,
non-GTK+ signals, you can create pure C++ signals, using the
<classname>sigc::signal&lt;&gt;</classname> template.
</para>
<para>
For instance, to create a signal that sends 2 parameters, a <type>bool</type>
and an <type>int</type>, just declare a <classname>sigc::signal</classname>,
like so:
<programlisting>
sigc::signal&lt;void, bool int&gt; signal_something;
</programlisting>
</para>
<para>
You could just declare that signal as a public member variable, but
some people find that distasteful and prefer to make it available via
an accessor method, like so:
<programlisting>
class Server
{
  //signal accessor:
  typedef sigc::signal&lt;void, bool, int&gt; type_signal_something;
  type_signal_something signal_something();

protected:
  type_signal_something m_signal_something;
};

Server::type_signal_something Server::signal_something()
{
  return m_signal_something;
}
</programlisting> 
</para>

<para>
You can then connect to the signal using the same syntax used when
connecting to &gtkmm; signals. For instance,
<programlisting>
server.signal_something().connect(
  sigc::mem_fun(client, &amp;Client::on_server_something) );
</programlisting>
</para>
<para>
See <filename>examples/book/signals/custom/</filename> for a full
working example.
</para>

</appendix>




<appendix id="sec-signals-comparison">
<title>Comparison with other signalling systems</title>
<para>
TODO: Rewrite this paragraph and talk about QT's moc. 
(An aside: <application>GTK+</application> calls this scheme "signalling"; the
sharp-eyed reader with GUI toolkit experience will note that this same design
is often
seen under the name of "broadcaster-listener" (e.g., in Metrowerks'
PowerPlant framework for the Macintosh).  It works in much the same
way: one sets up <literal>broadcasters</literal>, and then connects
<literal>listeners</literal> to them; the broadcaster keeps a list of the
objects listening to it, and when someone gives the broadcaster a
message, it calls all of its objects in its list with the message.  In
&gtkmm;, signal objects play the role of broadcasters, and slots
play the role of listeners - sort of.  More on this later.)
</para>
<para>
&gtkmm; signal handlers are strongly-typed, whereas
<application>GTK+</application> C code allows you to connect a callback with
the wrong number and type of arguments, leading to a segfault at runtime. And,
unlike <application>QT</application>, &gtkmm; achieves this without modifying
the C++ language.</para>
<para>
Re. Overriding signal handlers: You can do this in the straight-C world of GTK+ too; that's what GTK's
object system is for.  But in GTK+, you have to go through some
complicated procedures to get object-oriented features like
inheritance and overloading.  In C++, it's simple, since those
features are supported in the language itself; you can let the
compiler do the dirty work.
</para>
<para>
This is one of the places where the beauty of C++ really comes out.
One wouldn't think of subclassing a GTK+ widget simply to override its
action method; it's just too much trouble.  In GTK+, you almost always
use signals to get things done, unless you're writing a new widget.
But because overriding methods is so easy in C++, it's entirely
practical - and sensible - to subclass a button for that purpose.
</para>
</appendix>

<appendix id="sec-windows-installation">
	<title>&gtkmm; and Win32</title>
    <para>
      One of the major advantages of &gtkmm; is that it is crossplatform. &gtkmm; programs written on other platforms such as
      GNU/Linux can generally be transferred to Windows (and vice
      versa) with few modifications to the source.
    </para>
    <para>
      &gtkmm; currently only works with the <ulink
	url="http://mingw.org/">MingW/GCC3.2 compiler</ulink> on the
      Windows platform. This is unlikely to change in the near
      future, unless Microsoft upgrades its compilers in Visual
      Studio to fully support the C++ standard. Information about the &gtkmm; and the latest Microsoft C++ compiler might be on the mailing list.
    </para>
    <para>
      Installation of MingW is beyond the scope of this document, though not excessively difficult.
      However, a good GPL'd C++ IDE for windows called <ulink
	url="http://www.bloodshed.net/">Dev-C++</ulink> has a
      convenient Windows installer that installs both the IDE and
      the MingW/GCC3.2 compiler, and we can recommend it.  We will now 
      show step by step how to install &gtkmm; and properly set
      up Dev-C++ as your &gtkmm; development environment. The following
	  instructions should work for Dev-C++ versions 4.9.8.0 or higher.
	  For people who prefer command line compiler tools, a solution based
	  on the cygwin distribution will be described in the last section of
      this chapter.
    </para>
    <sect1>
      <title>The Dev-C++ IDE</title>
      <sect2>
	<title>Pre-Installation Issues</title>
	<para>
	  We strongly recommend that Dev-C++ is installed and
	  tested before installing any of the GTK+ or &gtkmm; libraries,
	  as we will be installing all the libraries into the Dev-C++
	  directory.  Ensure that you are able to successfully compile and
	  run a simple C++ program from Dev-C++ before proceeding to the
	  next step. For instance, try a simple Hello World program.
	</para>
	<para>
	  Note: Currently (as of v4.9.8.0) Dev-C++ does not like to be
	  installed in directories with spaces in them. Installing
	  Dev-C++ to the "Program Files" directory may cause problems at
	  a later stage when it looks for the include and lib
	  directories.
	</para>
      </sect2>

      <sect2>
	<title>Dependencies</title>
	<para>
	  The &gtkmm; Windows installer requires you to first
	  install the following dependencies:
	</para>
	<itemizedlist>
	  <listitem>
	    <para>GTK+ 2.x</para>
	    <para>
	      Before installing &gtkmm;, you need to install the latest GTK+ 2.x.  You
	      can find the latest windows installer at <ulink
		url="http://gladewin32.sourceforge.net/">Glade/Gtk+ for Win32</ulink>. The Windows
	      installer will correctly install any dependencies that GTK+
	      2.x may need.
	    </para>
	    <para>
		  You will need to download and install the Gtk+/Win32 Development
		  Environment.  This includes the runtime, devel, docs, and glade.
	      Start with the Development GTK+ installer, and allow the
	      installation to proceed to the default directory.  
	    </para>
	  </listitem>
	</itemizedlist>
      </sect2>

      <sect2>
	<title>Installation</title>
	<para>
	  Now you are ready to install &gtkmm;. You can find a link to an installer on the <ulink url="http://www.gtkmm.org/">&gtkmm; web site's</ulink> download page.
	  The &gtkmm; Windows installer includes both the development
	  and the runtime files.
	</para>
	<para>
	  Since we are going to be using Dev-C++ as our IDE, it is
	  strongly suggested that you install &gtkmm; into the base
	  Dev-C++ directory (ie. d:\dev-cpp). This will make things
	  easier later on when setting up the include and lib
	  directories in Dev-C++.
	</para>
	<para>
	  You should now be ready to execute Win32 &gtkmm; compiled
	  binaries.  Note: Some older versions of Windows may require a reboot
	  before the installer's change to the PATH variable takes effect.
	</para>
      </sect2>

      <sect2>
	<title>Compiling &gtkmm; Apps with Dev-C++</title>
	<para>
	  Now we need to set some project options to create our
	  first &gtkmm; project in Dev-C++.
	</para>
	<para>
	  First, we need to let Dev-C++ know what files and libraries to
	  include when it invokes MingW/GCC3.2. To find out what
	  arguments need to be passed to GCC, we need to open a command
	  prompt and type the following:
	</para>
	<para>
	  <command>
	    pkg-config --cflags gtkmm-2.4
	  </command>
	</para>
	<para>
	  If the pkg-config command cannot be found, you can cd to the
	  bin/ directory of where you installed Dev-C++ and execute the
	  above line from there.  Depending on where you installed
	  &gtkmm;, you will get output that looks similar to the
	  following:
	</para>
	<para>
	  <programlisting>
	    -Id:/dev-c++/include/gtkmm-2.4
	    -Id:/dev-c++/lib/gtkmm-2.4/include
	    -Id:/dev-c++/include/gtk-2.0
	    -Id:/dev-c++/lib/sigc++-2.0/include
	    -Id:/dev-c++/include/sigc++-2.0
	    -Id:/dev-c++/include/glib-2.0
	    -Id:/dev-c++/lib/glib-2.0/include
	    -Id:/dev-c++/lib/gtk-2.0/include
	    -Id:/dev-c++/include/pango-1.0 -Id:/dev-c++/include/atk-1.0
	    -Ld:/dev-c++/lib 
	  </programlisting>
	</para>
	<para>
	  The next step is to obtain the list of libraries by issuing the following
	  command:
	</para>
	<para>
	  <command>
	    pkg-config --libs gtkmm-2.4
	  </command>
	</para>
	<para>
	  Your results may look something similar to this:
	</para>
	<para>
	  <programlisting>
	    -lgtkmm-2.4 -lgdkmm-2.4 -latkmm-1.0
	    -lgtk-win32-2.0 -lpangomm-1.4 -lglibmm-2.4 -lsigc-2.0
	    -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0
	    -lgdi32 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
	    -lintl -liconv
	  </programlisting>
	</para>

	<para>
	  <figure id="figure-project-options">
	    <title>Dev-C++ Project Options</title>
	    <screenshot>
	      <graphic format="PNG" fileref="&url_figures_base;devcpp_project_options.png"/>
	    </screenshot>
	  </figure>
	</para>

	<para>
	  Now create a new Project.  We will make this project work with
	  &gtkmm;.  After creating a new project, select <literal>Project Options</literal>
	  from the menu, and under the <literal>Parameters</literal> tab, we will need to enter the information
	  we obtained earlier:  In the <literal>Additional commandline options</literal> for
	  the C++ compiler, paste the include and lib <emphasis>directories</emphasis> you obtained with
	  the --cflags argument. (The commandline options preceeded by either an -I or a -L).
	</para>

	<para>
	  Now we must tell the linker what libraries to include, by pasting the libraries into the <literal>Additional commandline options</literal> for the Linker. (These commandline options are preceeded by a -l).
	</para>

	<para>
	  Congratulations. You have successfully created a new project in Dev-C++ that
	  works with &gtkmm;.  Try compiling some of the examples in this
	  tutorial.
	</para>
    </sect2>
    </sect1>

    <sect1 id="sec-build_with_command_line_tools">
      <title>Command line tools</title>
      <para>
	To build your &gtkmm; application with command line tools, we recommend you either use mingw combined with cygwin
	(<ulink url="http://www.cygwin.com"></ulink>) or msys (<ulink
	  url="http://www.mingw.org"></ulink>). If you use
	mingw/cygwin, make sure that the directory that contains the
	mingw executables is first in your PATH (by checking with g++
	-v). Then
      </para>
      <para>
	<orderedlist>
	  <listitem>
	    <para>Add the directories with the &gtkmm; and gtk+ DLLs and
	      the gtk+ executables (particularly the one containing
	      pkg-config.exe) to your path. If you have selected the
	      corresponding option in the &gtkmm; installer, both the
	      &gtkmm; and gtk+ runtime will already be in your
	      PATH. Make sure pkg-config is available by typing
	      <command>'pkg-config --version'</command>.
	    </para>
	  </listitem>
	  <listitem>
	    <para>Set the PKG_CONFIG_PATH environment variable to
	      point to the various lib/pkgconfig directories. Look for
	      files with the .pc extension in the gtk+ and &gtkmm;
	      developer packages. It's the same syntax as on
	      linux but the directories are separated by semicolons.</para>
	  </listitem>
	  <listitem>
	    <para>Check the &gtkmm; distribution by typing
	      <command>'pkg-config --modversion --cflags --libs
		gtkmm-2.4'</command>. You should get something like
	    </para>
	    <para><programlisting>
		2.2.1
		-IC:/target/libsigc/lib/sigc++-2.0/include
		-IC:/target/libsigc/include/sigc++-2.0
		-IC:/target/gtkmm/include/gtkmm-2.4
		-IC:/target/gtkmm/lib/gtkmm-2.4/include
		-IC:/target/gtk-2.0/include/gtk-2.0
		-IC:/target/gtk-2.0/include/glib-2.0
		-IC:/target/gtk-2.0/lib/glib-2.0/include
		-IC:/target/gtk-2.0/lib/gtk-2.0/include
		-IC:/target/gtk-2.0/include/pango-1.0
		-IC:/target/gtk-2.0/include/atk-1.0
		-LC:/target/libsigc/lib
		-LC:/target/gtkmm/lib
		-LC:/target/gtk-2.0/lib -lgtkmm-2.4
		-lgdkmm-2.4 -latkmm-1.4 -lgtk-win32-2.0 -lpangomm-1.4
		-lglibmm-2.4 -lsigc-2.0 -lgdk-win32-2.0 -latk-1.0
		-lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0
		-lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl
		-liconv</programlisting>
	    </para>
	    <para>Of course, the target directories will show your local
	      installation tree.
	    </para>
	  </listitem>
	  <listitem>
	    <para>You can compile a single source file like so:</para>
	    <para>
	      <command>g++ `pkg-config --cflags gtkmm-2.4`
		my_programs.cc -o my_program `pkg-config --libs
		gtkmm-2.4`</command>
	    </para>
	  </listitem>
	</orderedlist>
      </para>
      <para>
	See the &gtkmm; FAQ for more build help.
      </para>
    </sect1>

  <sect1 id="sec-building_on_win32">
	<title>Building &gtkmm; on Win32</title>
    <para>Please see the appropriate README file in the source distribution.
    </para>
    
    </sect1>
</appendix>

<appendix id="sec-appendix-gdk-drawing">
<title>Drawing With GDK</title>
<para>The GDK drawing API described here is now deprecated, in favour of Cairo. See the <link linkend="sec-drawingarea">DrawingArea</link> chapter for information about the Cairo API.</para> 
<para>
      Gdk graphics contexts (<classname>Gdk::GC</classname>) are a
      server-side resource. They contain information that describes how
      drawing is to be done. This provides for fewer arguments to the
      drawing methods, and less communication between the client and the
      server. The following example shows  how to set up a graphics context
      with a foreground color of red for drawing.
  </para>
  <programlisting>Gdk::GC some_gc;
some_gc.create(get_window());
Gdk::Color some_color;
Gdk::Colormap some_colormap(Gdk::Colormap::get_system());
some_color.set_red(65535);
some_color.set_green(0);
some_color.set_blue(0);
some_colormap.alloc(some_color);
some_gc.set_foreground(some_color);</programlisting>
  <para>
      The first two lines create the graphics context and assign it to the
      appropriate widget. The <function>get_window() </function> method is
      a part of the <classname>Gtk::Widget</classname> class, so if you put
      this code into a derived widget's implementation then you can call it
      just as it is, otherwise you'd use
      <function>some_widget.get_window()</function>.
  </para>
  <para>
      The next two lines create the <classname>Gdk::Color</classname> and
      <classname>Gdk::Colormap</classname>. After setting the color values
      you then need to allocate the color. The system figures out what to
      do in this case. The colormap contains information about how colors
      can be displayed on your screen, and is able to allocate the
      requested color. For example, on a display of only 256 colors the
      exact color requested may not be available, so the closest color to
      the one requested will be used instead. The final line sets the color
      as the foreground color.
  </para>
  <para>
      There are a number of attributes that can be set for a graphics
      context. There's the foreground and background color.  When drawing
      lines, you can set the thickness of the line with
      <function>set_line_width()</function>. Whether a solid or dashed line
      is drawn can be set with <function>set_line_style()</function>. The
      size and proportions of the dashes are set with
      <function>set_dashes</function>. How two lines join together, whether
      round or pointed or beveled off, is set with
      <function>set_join_style()</function>.  Other things that can be set
      within a graphics context include font style, stippling and tiling
      for the filling of solid polygons.
  </para>
  <para>
      Graphics contexts are central to drawing with Gdk, because nearly all Gdk
      drawing functions and many Pango functions take a
      <classname>Gdk::GC</classname> object as an argument.  So although Cairo
      has largely superceded many Gdk drawing functions, you're still likely to
      run into <classname>Gdk::GC</classname> objects quite often, so it's
      important to know what they are and how they're used.
  </para>
</appendix>
<appendix id="sec-appendix_working_with_cvs">
  <title>Working with CVS</title>
  <para>
    If you are interested in helping out with the development of &gtkmm;, or
    fixing a bug in &gtkmm;, you'll probably need to build the development
    version of &gtkmm;.  You don't want to install a development version over
    your stable version, you want to install it alongside your existing &gtkmm;
    installation.
  </para>
  <para>
    The easiest way to do this is using <ulink
      url="http://www.gnome.org/~jamesh/jhbuild.html">jhbuild</ulink>.
    <application>jhbuild</application> is a program that makes building GNOME
    software much easier by calculating dependencies and building things in the
    correct order.  This section will give a brief explanation of how to set up
    jhbuild to build and install &gtkmm; from CVS.  For up-to-date information
    on <application>jhbuild</application>, please refer to the <ulink 
      url="http://www.gnome.org/~jamesh/jhbuild.html">jhbuild website</ulink>.
    If you need assistance using <application>jhbuild</application>, you should
    ask for help on the <ulink
      url="http://mail.gnome.org/mailman/listinfo/gnome-love">gnome-love
      mailing list</ulink>.
  </para>
  <note>
    <para>
    Note that to build &gtkmm; from <application>CVS</application>, you'll
    need to build all of its dependencies from CVS as well.
    <application>jhbuild</application> makes this easier than it would normally
    be, but it will take quite a while to build and install them all.
    </para>
  </note>
  <sect1 id="sec-setting_up_jhbuild">
    <title>Setting up jhbuild</title>
    <para>
      To set up <application>jhbuild</application>, follow the basic
      installation instructions from the <ulink
        url="http://www.gnome.org/~jamesh/jhbuild.html">jhbuild manual</ulink>.
      After you've gotten <application>jhbuild</application> installed, you
      should copy the sample <application>jhbuild</application> configuration
      file into your home directory by executing the following command from the
      <application>jhbuild</application> directory:
      <command>$ cp sample.jhbuildrc ~/.jhbuildrc</command>
    </para>
    <para>
      The &gtkmm; module is defined in the GNOME moduleset (i.e.
      <filename>gnome-2.xx.modules</filename>, so edit your
      <filename>.jhbuildrc</filename> file and set your moduleset setting to the
      latest version of GNOME like so:
      <programlisting>moduleset = 'gnome-2.16'</programlisting>
    </para>
    <para>
      After setting the correct moduleset, you need to tell
      <application>jhbuild</application> which module or modules to build.  To
      build &gtkmm; and all of its dependencies, set <varname>modules</varname>
      like so: <programlisting>modules = [ 'gtkmm', ]</programlisting>
    </para>
    <para>
      You can build all GNOME C++ modules by setting the
      <varname>modules</varname> variable to the meta-package named
      <literal>meta-gnome-c++</literal> or build all of the core GNOME modules
      with <literal>meta-gnome-desktop</literal>.  The
      <varname>modules</varname> variable specifies which modules that will be
      built when you don't explicitly specify anything on the command line.  You
      can always build a different moduleset later by specifying it on the
      commandline (e.g.  <command>jhbuild build gtkmm</command>).
    </para>
    <para>
      Note that the GNOME moduleset is most likely set up to build the branch of
      &gtkmm; that will be included with that GNOME release, so it may not build
      &gtkmm; HEAD by default.  The branch name is specified in the
      <literal>revision</literal> attribute of the <literal>cvsmodule</literal>
      element.  In order to build the HEAD version of &gtkmm;, edit your
      moduleset file and delete the <literal>revision</literal> attribute.
    </para>
    <important>
      <title>Setting a prefix</title>
      <para>
        By default, <application>jhbuild</application>'s configuration is
        configured to install all software built with
        <application>jhbuild</application> under the
        <filename>/opt/gnome2</filename> prefix.  You can choose a different
        prefix, but it is recommended that you keep this prefix different from
        other software that you've installed (don't set it to
        <filename>/usr</filename>!) This way you can keep using your stable
        versions without conflict and use the CVS versions when you want to.
        You may want to choose a prefix that your user account has write access
        to so that you don't need to run <application>jhbuild</application> as
        <literal>root</literal>.
      </para>
    </important>
  </sect1>
  <sect1 id="sec-installing_jhbuild">
    <title>Installing and Using the CVS version of &gtkmm;</title>
    <para>
      Once you've configured <application>jhbuild</application> as described
      above, building &gtkmm; should be relatively straightforward.  The first
      time you run <application>jhbuild</application>, you should run the
      following sequence of commands to ensure that 
      <application>jhbuild</application> has the required tools and verify that
      it is set up correctly:
      <screen>$ jhbuild bootstrap
$ jhbuild sanitycheck</screen>
    </para>
    <sect2>
      <title>Installing &gtkmm; with <application>jhbuild</application></title>
      <para>
        If everything worked correctly, you should be able to build &gtkmm; and
        all of its dependencies from CVS by executing <command>jhbuild
          build</command> (or, if you didn't specify &gtkmm; in the
        <varname>modules</varname> variable, with the command <command>jhbuild
          build gtkmm</command>).
      </para>
      <para>
        This command will build and install a series of modules and will probably
        take quite a long time the first time through.  After the first time,
        however, it should go quite a bit faster since it only needs to rebuild
        files than changed since the last build.  Alternatively, after you've
        built and installed &gtkmm; the first time, you can rebuild &gtkmm; by
        itself (without rebuilding all of its dependencies) with the command 
        <command>jhbuild buildone gtkmm</command>.
      </para>
    </sect2>
    <sect2>
      <title>Using the CVS version of &gtkmm;</title>
      <para>
        After you've installed the CVS version of &gtkmm;, you're ready to start
        using and experimenting with it.  In order to use the new version of
        &gtkmm; you've just installed, you need to set some environment
        variables so that your <filename>configure</filename> script knows where
        to find the new libraries.  Fortunately,
        <application>jhbuild</application> offers an easy solution to this
        problem.  Executing the command <command>jhbuild shell</command> will
        start a new shell with all of the correct environment variables set.
        Now if you re-configure and build your project just as you usually do,
        it should link against the newly installed libraries.  To return to your
        previous environment, simply exit the <application>jhbuild</application>
        shell. 
      </para>
      <para>
        Once you've built your software, you'll need to run your program within
        the jhbuild environment as well.  To do this, you can again use the
        <command>jhbuild shell</command> command to start a new shell with the
        <application>jhbuild</application> environment set up.  Alternatively,
        you can execute a one-off command in the
        <application>jhbuild</application> environment using the following
        command: <command>jhbuild run command-name</command>.  In this case,
        the command will be run with the correct environment variables set, but
        will return to your previous environment after the program exits.
      </para>

    </sect2>
  </sect1>
</appendix>

<appendix id="sec-appendix-wrapping-c-libraries">
<title>Wrapping C Libraries with gmmproc</title>
<para>gtkmm uses the gmmproc tool to generate most of its source code, using .defs files that define the APIs of GObject-based libraries. So it's quite easy to create additional gtkmm-style wrappers of other glib/GObject-based libraries.</para> 
<para>This involves a variety of tools and some copying of existing build files, but it does at least work, and has been used successfully by several projects.</para>

<sect1>
<title>The build structure</title>
<para>Generation of the source code for a gtkmm-style wrapper API requires use of tools such as gmmproc and  generate_wrap_init.pl. In theory you could write your own build files to use these appropriately, but in practice it's usually easier to simply copy an existing project and modify it for your needs. Note however, that there is plenty of scope for improvement in the build structure that we use, so try to copy the latest version, and feel free to suggest improvements to make it more generic.</para>
<para>For instance, let's pretend that we are wrapping a C library called libexample. It provides a GObject-based API with types named, for instance, ExampleThing and ExampleStuff.</para>

<sect2>
<title>Copying an existing project</title>

<para>Typically our wrapper library would be called libexamplemm. We can start by copying an existing *mm library, such as libgdamm, after checking it out from cvs.
<programlisting>
$ cvs -z3 co gnomemm/libgdamm
$ cp -r gnomemm/libgdamm libsomethingmm
</programlisting>
</para>
<para>
This provides a directory structure for the source .hg and .ccg files and the generated .h and .cc files, with Makefile.am fragments that can specify the various files in use, in terms of generic Makefile.am variables. The directory structure usually looks like this, after we have renamed the directories appropriately:
<itemizedlist>
  <listitem><para>libsomethingmm: The top-level directory.</para>
     <itemizedlist>
       <listitem><para>libsomething: Contains the main include file and the pkg-config .pc file.</para>
         <itemizedlist>
           <listitem><para>src: Contains .hg and .ccg source files.</para></listitem>
           <listitem><para>libsomethingmm: Contains generated and hand-written .h and .cc files.</para>
             <itemizedlist>
               <listitem><para>private: Contains generated *_p.h files.</para></listitem>
             </itemizedlist>
           </listitem>
         </itemizedlist>
       </listitem>
    </itemizedlist>
  </listitem>
</itemizedlist>
</para>

<para>As well as renaming the directories, we should rename some of the source files. For instance:
<programlisting>
$ mv libsomething/libgdamm-2.0.pc.in libsomething/libsomethingmm-1.0.pc.in
$ mv libsomething/libgdammconfig.h.in libsomething/libsomethingmmconfig.h.in
$ mv libsomething/libgdamm.h libsomething/libsomethingmm.h
$
$ mv libsomething/src/libgda.defs libsomething/src/libsomething.defs
$ mv libsomething/src/libgda_enums.defs libsomething/src/libsomething_enums.defs
$ mv libsomething/src/libgda_methods.defs libsomething/src/libsomething_methods.defs
$ mv libsomething/src/libgda_others.defs libsomething/src/libsomething_others.defs
$ mv libsomething/src/libgda_signals.defs libsomething/src/libsomething_signals.defs
$ mv libsomething/src/libgda_vfuncs.defs libsomething/src/libsomething_vfuncs.defs
$ mv libsomething/src/libgda_docs.xml libsomething/src/libsomething_docs.xml
$ mv libsomething/src/libgda_docs_override.xml libsomething/src/libsomething_docs_override.xml
</programlisting>
A multiple-file renaming tool, such as prefixsuffix might help with this. We will provide the contents of these files later.
</para>
<para>
Note that files ending in .in will be used to generate files with the same name but without the .in suffix, by replacing some variables with actual values during the configure stage.
</para>
</sect2>

<sect2>
<title>Modifying build files</title>

<para>Now we edit the files to adapt them to to our needs. You might prefer to use a multiple-file search-replace too for this, such as regexxer.</para>

<sect3>
<title>autogen.sh</title>
<para>For instance, in autogen.sh:
<itemizedlist>
  <listitem><para>PKG_NAME must contain the new package name, such as libexamplemm.</para></listitem>
  <listitem><para>The test script lines must check for appropriate directory names, such as $srcdir/libsomething/src.</para></listitem>
</itemizedlist>
</para>
</sect3>

<sect3>
<title>configure.in</title>
<para>In configure.in (or configure.ac in newer projects),
<itemizedlist>
  <listitem><para>The AC_INIT() line must mention a file in our library. We can edit this later if we don't yet know the names of any of the files that we will create.</para></listitem>
  <listitem><para>The PACKAGE variable must be changed to the correct name of the project, such as libsomethingmm.</para></listitem>
  <listitem><para>The version numbers should be reset to something small, such as 0.0.1. You may want to rename the version variables if they are not something generic. For instance, we would rename LIBGDAMM_MAJOR_VERSION to LIBSOMETHINGMM_MAJOR_VERSION or LIBGENERICMM_MAJOR_VERSION.</para></listitem>
  <listitem><para>The AM_CONFIG_HEADER() line must mention the correctly named config header file.</para></listitem>
  <listitem><para>The PKG_CHECK_MODULES() line must be modified to check for the correct dependencies. For instance, it might be changed to PKG_CHECK_MODULES(LIBGENERICMM, gtkmm-2.4 &gt;= 2.6.0 libsomething-1.0 &gt;= 1.0.0).</para></listitem>
  <listitem><para>The AC_OUTPUT() block must mention the correct directory names, as described above.</para></listitem>
  <listitem><para>The m4 script to generate doxygen input directory paths must mention the correct directory.</para></listitem>
</itemizedlist>
</para>
</sect3>

<sect3>
<title>Makefile.am files</title>
<para>Next we must adapt the various Makefile.am files:
<itemizedlist>
  <listitem><para>The top-level Makefile.am must mention the correct child directory in the SUBDIRS variable.</para></listitem>
  <listitem><para>The libexample/Makefile.am must mention:</para>
    <itemizedlist>
      <listitem><para>The correct child directories in the SUBDIRS variable.</para></listitem>
      <listitem><para>The correct filenames in EXTRA_DIST.</para></listitem>
      <listitem><para>The correct filenames in *_includedir, *_include_HEADERS, *_configdir, and *_config_DATA.</para></listitem>
    </itemizedlist>
  </listitem>
  <listitem><para>In libexample/libexamplemm/Makefile.am we must mention the correct names in the generic variables that are used elsewhere in the build system:</para>
    <itemizedlist>
      <listitem><para>sublib_name: The name of the library, such as libsomethingmm.</para></listitem>
      <listitem><para>sublib_libname: The versioned name of the library, such as libsomethingmm-1.0</para></listitem>
      <listitem><para>sublib_namespace: The name of the C++ namespace to use for this library, such as Something.</para></listitem>
      <listitem><para>files_defs: The list of .defs and *docs*.xml files.</para></listitem>
      <listitem><para>The lib_LTLIBRARIES variable must mention the correct library name, and this library name must be used to form the _SOURCES, _LDFLAGS, and _LIBADD variable names.</para></listitem>	
    </itemizedlist>
  </listitem>
  <listitem><para>In libexample/libexamplemm/private/Makefile.am, private_includedir must contain the correct path.</para></listitem>
  <listitem><para>In examples/Makefile.am_fragment, local_libgenericmm_lib and all_includes must contain the correct paths.</para></listitem>
  <listitem><para>In libexample/src/Makefile.am we must set some more generic variables:</para>
    <itemizedlist>
      <listitem><para>sublib_name: The name of the library, as in libexample/libexamplemm/Makefile.am.</para></listitem>
      <listitem><para>sublib_namespace: The name of the C++ namespace, as in libexample/libexamplemm/Makefile.am</para></listitem>
      <listitem><para>sublib_parentdir: The name of the directory containing the generated files, such as libexamplemm.</para></listitem>
      <listitem><para>files_defs: The list of .defs and *docs*.xml files.</para></listitem>	
    </itemizedlist>
  </listitem>
  <listitem><para>In build_shared/Makefile_gensrc.am_fragment, you should remove the --namespace=Gnome option from 
      the gen_wrap_init_args variable if your namespace will not be under the Gnome namespace. This should be the only place that you need to edit the generic build_shared/ files.</para></listitem>
</itemizedlist>
</para>
</sect3>

<sect3>
<title>Creating .hg and .ccg files</title>
<para>We should now create our first .hg and .ccg files, to wrap one of the objects in the C library. We will delete any existing .hg and .ccg files:
<programlisting>
$ rm -rf libexample/src/*.hg
$ rm -rf libexample/src/*.ccg
</programlisting>
and create new files:
<programlisting>
$ touch libexample/src/thing.hg
$ touch libexample/src/thing.ccg
</programlisting>
</para>
<para>We must mention all of our .hg and .ccg files in the libexample/src/Makefile_list_of_hg.am_fragment file, in the files_hg variable.</para>
<para>Any extra non-generated .h and .cc source files may be placed in libexample/libexamplemm/ and mentioned in  libexample/libexamplemm/Makefile.am, in the files_extra_h and files_extra_cc variables.</para>
<para>In the <link linkend="sec-appendix_wrapping_hg_files">.hg and .ccg files</link> section you can learn about the syntax used in these files.</para>
</sect3>
</sect2>
</sect1>

<sect1 id="sec-appendix_wrapping_defs_files">
<title>Generating the .defs files.</title>
<para>The .defs file are text files, in a lisp format, that describe the API of a C library, including its
<itemizedlist>
  <listitem><para>objects (GObjects, widgets, interfaces, boxed-types and plain structs)</para></listitem>
  <listitem><para>functions</para></listitem>
  <listitem><para>enums</para></listitem>
  <listitem><para>signals</para></listitem>
  <listitem><para>properties</para></listitem>
  <listitem><para>vfuncs</para></listitem>
</itemizedlist>
</para>
<para>At the moment, we have separate tools for generating different parts of these .defs, so we split them up into separate files. For instance, in gtkmm/gtk/src, you will find these files:
<itemizedlist>
  <listitem><para>gtk.defs: Includes the other files.</para></listitem>
  <listitem><para>gtk_methods.defs: Objects and functions.</para></listitem>
  <listitem><para>gtk_enums.defs: Enums.</para></listitem>
  <listitem><para>gtk_signals.def: Signals and properties.</para></listitem>
  <listitem><para>gtk_vfuncs.defs: vfuncs (function pointer member fields in structs), written by hand.</para></listitem>
</itemizedlist>
</para>

<sect2>
<title>Generating the methods .defs</title>
<para>This .defs file describes objects and their functions. It is generated by the h2defs.py script which you can find in pygtk's codegen directory. For instance,
<programlisting>
$ ./h2defs.py /usr/include/gtk-2.0/gtk/*.h &gt; gtk_methods.defs
</programlisting>
</para>
</sect2>

<sect2>
<title>Generating the enums .defs</title>
<para>This .defs files describes enum types and their possible values. It is generated by the enums.pl script which you can find in glibmm's tools directory. For instance,
<programlisting>
$ ./enum.pl /usr/include/gtk-2.0/gtk/*.h &gt; gtk_enums.defs
</programlisting>
</para>
</sect2>

<sect2>
<title>Generating the signals and properties .defs</title>
<para> This .defs file describes signals and properties. It is generated by the special extra_defs utility that is in every wrapping project, such as gtkmm/tools/extra_defs_gen/. For instance <command></command>
<programlisting>
$ cd tools/extra_defs_gen
$ ./generate_extra_defs &gt; gtk_signals.defs
</programlisting>
</para>
<para>You must edit the source code of your own extra_defs_gen tool in order to generate the .defs for the C types that you wish to wrap. Start by renaming the file:
<programlisting>
$ cd tools/extra_defs_gen
$ mv generate_defs_gda.cc generate_defs_example.cc
</programlisting>
</para>
<para>Then edit the Makefile.am so that it mentions the new file name, and edit the new .cc file to specify the correct types. For instance, your main() function might look like this:
<programlisting>
#include &lt;libsomething.h&gt;

int main (int argc, char *argv[])
{
    libexample_init(argc, argv);

    std::cout &lt;&lt; get_defs(EXAMPLE_TYPE_SOMETHING)
              &lt;&lt; get_defs(EXAMPLE_TYPE_THING);
    return 0;
}
</programlisting>
</para>
</sect2>

<sect2>
<title>Writing the vfuncs .defs</title>
<para>
<programlisting>
</programlisting>
</para>
</sect2>

</sect1>

<sect1 id="sec-appendix_wrapping_hg_files">
<title>The .hg and .ccg files</title>
<para>The .hg and .ccg source files are very much like .h anc .cc C++ source files, but they contain extra macros, such as _CLASS_GOBJECT() and _WRAP_METHOD(), from which gmmproc generates appropriate C++ source code, usually at the same position in the header. Any additional C++ source code will be copied verbatim into the corresponding .h or .cc file.</para>
<para>A .hg file will typically include some headers and then declare a class, using some macros to add API or behaviour to this class. For instance, gtkmm's button.hg looks roughly like this:

<programlisting>
#include &lt;gtkmm/bin.h&gt;
#include &lt;gtkmm/stockid.h&gt;
_DEFS(gtkmm,gtk)
_PINCLUDE(gtkmm/private/bin_p.h)

namespace Gtk
{

class Button : public Bin
{
  _CLASS_GTKOBJECT(Button,GtkButton,GTK_BUTTON,Gtk::Bin,GtkBin)
public:

  _CTOR_DEFAULT
  explicit Button(const Glib::ustring&amp; label, bool mnemonic = false);
  explicit Button(const StockID&amp; stock_id);

  _WRAP_METHOD(void set_label(const Glib::ustring&amp; label), gtk_button_set_label)

  ...

  _WRAP_SIGNAL(void clicked(), "clicked")
 
  ...

  _WRAP_PROPERTY("label", Glib::ustring)
};

} // namespace Gtk
</programlisting>
</para>
<para>The macros in this example do the following:
<itemizedlist>
  <listitem><para>_DEFS(): Specifies the destination directry for generated sources, and the name of the main .defs file that gmmproc should parse.</para></listitem>
  <listitem><para>_PINCLUDE(): Tells gmmproc to include a header from the generated private/button_p.h file.</para></listitem>
  <listitem><para>_CLASS_GTKOBJECT(): Tells gmmproc to add some typedefs, constructors, and standard methods to this class, as appropriate when wrapping a GtkObject-derived type.</para></listitem>
  <listitem><para>_WRAP_METHOD(), _WRAP_SIGNAL(), and _WRAP_PROPERTY() add methods to wrap parts of the C API.</para></listitem>
</itemizedlist>
</para>
<para>The .h and .cc files will be generated from the .hg and .ccg files by processing them with gmmproc like so, though this happens automatically when using the above build structure:
<programlisting>
$ cd gtk/src
$ /usr/lib/glibmm-2.4/proc/gmmproc -I ../../tools/m4 --defs . button . ./../gtkmm
</programlisting>
</para>
<para>Notice that we provided gmmproc with the path to the .m4 convert files, the path to the .defs file, the name of a .hg file, the src directory, and the destination directory.</para> 
<para>You should avoid including the C header from your C++ header, to avoid polluting the global namespace, and to avoid exporting unnecessary public API. But you will need to include the necessary C headers from your .ccg file.</para>

<para>The macros are explained in more detail in the following sections.</para>
<sect2>
<title>Class macros</title>
<para>The class macro declares the class itself and its relationship with the underlying C type. It generates some internal constructors, the member gobject_, typedefs, the gobj() accessors, type registration, and the Glib::wrap() method, among other things.</para>
<para>Other macros, such as _WRAP_METHOD() and _SIGNAL() may only be used after a call to a _CLASS_* macro.</para>

<sect3>
<title>_CLASS_GOBJECT</title>
<para>This macro declares a wrapper for a type that is derived from GObject, but which is not derived from GtkObject.</para>
<para><function>_CLASS_GOBJECT( C++ class, C class, C casting macro, C++ base class, C base class )</function></para>
<para>For instance, from accelgroup.hg:
<programlisting>
_CLASS_GOBJECT(AccelGroup, GtkAccelGroup, GTK_ACCEL_GROUP, Glib::Object, GObject)
</programlisting>
</para>
</sect3>

<sect3>
<title>_CLASS_GTKOBJECT</title>
<para>This macro declares a wrapper for a type that is derived from GtkObject, such as a widget or dialog.</para>
<para><function>_CLASS_GTKOBJECT( C++ class, C class, C casting macro, C++ base class, C base class )</function></para>
<para>For instance, from button.hg:
<programlisting>
_CLASS_GTKOBJECT(Button, GtkButton, GTK_BUTTON, Gtk::Bin, GtkBin)
</programlisting>
</para>
</sect3>

<sect3>
<title>_CLASS_BOXEDTYPE</title>
<para>This macro declares a wrapper for a non-GObject struct, registed with g_boxed_type_register_static().</para>
<para><function>_CLASS_BOXEDTYPE( C++ class, C class, new function, copy function, free function )</function></para>
<para>For instance, for Gdk::Color:
<programlisting>
_CLASS_BOXEDTYPE(Color, GdkColor, NONE, gdk_color_copy, gdk_color_free)
</programlisting>
</para>
</sect3>

<sect3>
<title>_CLASS_BOXEDTYPE_STATIC</title>
<para>This macro declares a wrapper for a simple assignable struct such as GdkRectangle. It is similar to _CLASS_BOXEDTYPE,
but the C struct is not allocated dynamically.</para>
<para><function>_CLASS_BOXEDTYPE_STATIC( C++ class, C class )</function></para>
<para>For instance, for Gdk::Rectangle:
<programlisting>
_CLASS_BOXEDTYPE_STATIC(Rectangle, GdkRectangle)
</programlisting>
</para>
</sect3>

<sect3>
<title>_CLASS_OPAQUE_COPYABLE</title>
<para>This macro declares a wrapper for an opaque struct that has copy and free functions. The new, copy and free functions will be used to instantiate the default constructor, copy constructor and destructor.</para>
<para><function>_CLASS_OPAQUE_COPYABLE( C++ class, C class, new function, copy function, free function )</function></para>
<para>For instance, for Gdk::Region:
<programlisting>
_CLASS_OPAQUE_COPYABLE(Region, GdkRegion, gdk_region_new, gdk_region_copy, gdk_region_destroy)
</programlisting>
</para>
</sect3>

<sect3>
<title>_CLASS_OPAQUE_REFCOUNTED</title>
<para>This macro declares a wrapper for a reference-counted opaque struct. The C++ wrapper can not be directly
instantiated and can only be used with Glib::RefPtr.</para>
<para><function>_CLASS_OPAQUE_COPYABLE( C++ class, C class, new function, ref function, unref function )</function></para>
<para>For instance, for Pango::Coverage:
<programlisting>
_CLASS_OPAQUE_REFCOUNTED(Coverage, PangoCoverage, pango_coverage_new, pango_coverage_ref, pango_coverage_unref)
</programlisting>
</para>
</sect3>

<sect3>
<title>_CLASS_GENERIC</title>
<para>This macro can be used to wrap structs which don't fit into any specialized category.</para>
<para><function>_CLASS_GENERIC( C++ class, C class )</function></para>
<para>For instance, for Pango::AttrIter:
<programlisting>
_CLASS_GENERIC(AttrIter, PangoAttrIterator)
</programlisting>
</para>
</sect3>


</sect2>

<sect2>
<title>Constructor macros</title>
<para>The _CTOR_DEFAULT() and _WRAP_CTOR() macros add constructors, wrapping the specified *_new() C functions. These macros assume that the C object has properties with the same names as the function parameters, as is usually the case, so that it can supply the parameters directly to a g_object_new() call. These constructors never actually call the *_new() C functions, because gtkmm must actually instantiate derived GTypes, and the *_new() C functions are meant only as convenience functions for C programmers.</para> 
<para>When using _CLASS_GOBJECT(), the constructors should be protected (rather than public) and each constructor should have a corresponding _WRAP_CREATE() in the public section. This prevents the class from being instantiated without using a RefPtr. For instance, 
<programlisting>
class ActionGroup : public Glib::Object
{
  _CLASS_GOBJECT(ActionGroup, GtkActionGroup, GTK_ACTION_GROUP, Glib::Object, GObject)

protected:
  _WRAP_CTOR(ActionGroup(const Glib::ustring&amp; name = Glib::ustring()), gtk_action_group_new)

public:
  _WRAP_CREATE(const Glib::ustring&amp; name = Glib::ustring())
</programlisting>
</para>

<sect3>
<title>_CTOR_DEFAULT</title>
<para>This macro creates a default constructor with no arguments. 
</para>
</sect3>

<sect3>
<title>_WRAP_CTOR</title>
<para>This macro creates a constructor with arguments, equivalent to a *_new() C function. It takes a C++ constructor signature, and a C function name.
</para>
</sect3>

<sect3>
<title>Hand-coding constructors</title>
<para>When a constructor must be partly hand written because, for instance, the *_new() C function's parameters do not correspond directly to object properties, or because the *_new() C function does more than call g_object_new(), the _CONSTRUCT() macro may be used in the .ccg file to save some work. The _CONSTRUCT macro takes a series of property names and values. For instance, from button.ccg:
<programlisting>
Button::Button(const Glib::ustring&amp; label, bool mnemonic)
:
  _CONSTRUCT("label", label.c_str(), "use_underline", gboolean(mnemonic))
{}
</programlisting> 
</para>
</sect3>

</sect2>

<sect2>
<title>Method macros</title>
<para></para>

<sect3>
<title>_WRAP_METHOD</title>
<para>This macro generates the C++ method to wrap a C function.</para>
<para><function>_WRAP_METHOD( C++ method signature, C function name)</function></para>
<para>For instance, from entry.hg:
<programlisting>
_WRAP_METHOD(void set_text(const Glib::ustring&amp; text), gtk_entry_set_text)
</programlisting>
</para>
<para>The C function (e.g. gtk_entry_set_text) is described more fully in the .defs file, and the convert*.m4 files contain the necessary conversion from the C++ parameter type to the C parameter type. This macro also generates doxygen documentation comments based on the *_docs.xml and *_docs_override.xml files.</para>
<para>There are some optional extra arguments:
<itemizedlist>
  <listitem><para>refreturn: Do an extra reference() on the return value, in case the C function does not provide a reference.</para></listitem>
  <listitem><para>errthrow: Use the last GError* parameter of the C function to throw an exception.</para></listitem>
  <listitem><para>deprecated: Puts the generated code in #ifdef blocks. Text about the deprecation can be specified as an optional parameter.</para></listitem>
  <listitem><para>constversion: Just call the non-const version of the same function, instead of generating almost duplicate code.</para></listitem>
</itemizedlist>
</para>
<para>Though it's usually obvious what C++ types should be used in the C++ method, here are some hints:
<itemizedlist>
  <listitem><para>Objects used via RefPtr: Pass the RefPtr as a const reference. For instance, const Glib::RefPtr&lt;Gtk::Action&gt;&amp; action.</para></listitem>
  <listitem><para>Const Objects used via RefPtr: If the object should not be changed by the function, then make sure that the object is const, even if the RefPtr is already const. For instance, const Glib::RefPtr&lt;const Gtk::Action&gt;&amp; action.</para></listitem>
  <listitem><para>Wrapping GList* and GSList* parameters: First, you need to discover what objects are contained in the list's data field for each item, usually by reading the documentation for the C function. The list can then be wrapped by an appropriate intermediate type, such as Glib::ListHandle or Glib::SListHandle. These are templates, so you can specify the item type. For instance, Glib::ListHandle&lt; Glib::RefPtr&lt;Action&gt; &gt;. Existing typedefs exist for some common list types. You may need to define a Traits type to specify how the C and C++ types should be converted.</para></listitem>
  <listitem><para>Wrapping GList* and GSList* return types: You must discover whether the caller should free the list and whether it should release the items in the list, again by reading the documentation of the C function. With this information you can choose the ownership (none, shallow or deep) for the m4 conversion rule, which you should probably put directly into the .hg file because the ownership depends on the function rather than the type. For instance:
<programlisting>#m4 _CONVERSION(`GSList*', `Glib::SListHandle&lt;Widget*&gt;', `$2($3, Glib::OWNERSHIP_NONE)')</programlisting></para></listitem>
</itemizedlist>
</para>
</sect3>

<sect3>
<title>_WRAP_METHOD_DOCS_ONLY</title>
<para>This macro is like _WRAP_METHOD(), but it generates only the documentation for a  C++ method that wraps a C function. Use this when you must hand-code the method, but you want to use the documentation that would be generated if the method was generated.</para>
<para><function>_WRAP_METHOD( C++ method signature, C function name)</function></para>
<para>For instance, from container.hg:
<programlisting>
_WRAP_METHOD_DOCS_ONLY(gtk_container_remove)
</programlisting>
</para>
</sect3>

<sect3>
<title>_IGNORE()</title>
<para>gmmproc will warn you on stdout about functions that you have forgotten to wrap, helping to ensure that you are wrapping the complete API. Buf if you don't want to wrap some functions or if you chose to hand-code some methods then you can use the _IGNORE() macro the make gmmproc stop complaining.</para>
<para><function>_IGNORE(C function name 1, C function name2, etc)</function></para>
<para>For instance, from buttonbox.hg:
<programlisting>
_IGNORE(gtk_button_box_set_spacing, gtk_button_box_get_spacing,
</programlisting>
</para>
</sect3>

<sect3>
<title>_WRAP_SIGNAL</title>
<para>This macro generates the C++ libsigc++-style signal to wrap a C GObject signal. It actually generates a public accessor method, such as signal_clicked(), which returns a proxy object.  gmmproc uses the .defs file to discover the C parameter types and the .m4 convert files to discover appropriate type conversions.</para>
<para><function>_WRAP_SIGNAL( C++ signal handler signature, C signal name)</function></para>
<para>For instance, from button.hg:
<programlisting>
_WRAP_SIGNAL(void clicked(),"clicked")
</programlisting>
</para>
<para>Signals usually have function pointers in the GTK struct, with a corresponding enum value. and a g_signal_new() in the .c file.</para>
<para>There are some optional extra arguments:
<itemizedlist>
  <listitem>
    <para>no_default_handler: Do not generate an on_something() virtual
      method to allow easy overriding of the default signal handler. Use this
      when adding a signal with a default signal handler would break the ABI by
      increasing the size of the class's virtual function
      table.</para>
  </listitem>
</itemizedlist>
</para>
</sect3>

<sect3>
<title>_WRAP_PROPERTY</title>
<para>This macro generates the C++ method to wrap a C GObject property. You must specify the property name and the wanted C++ type for the property. gmmproc uses the .defs file to discover the C type and the .m4 convert files to discover appropriate type conversions.</para>
<para><function>_WRAP_PROPERTY(C property name, C++ type)</function></para>
<para>For instance, from button.hg:
<programlisting>
_WRAP_PROPERTY("label", Glib::ustring)
</programlisting>
</para>
<para>Signals usually have function pointers in the GTK struct, with a corresponding enum value. and a g_signal_new() in the .c file.</para>
<para>There are some optional extra arguments:
<itemizedlist>
  <listitem>
    <para>no_default_handler: Do not generate an on_something() virtual method
      to allow easy overriding of the default signal handler. Use this when
      adding a signal with a default signal handler would break the ABI by
      increasing the size of the class's virtual function table.</para>
  </listitem>
</itemizedlist>
</para>
</sect3>

</sect2>

<sect2>
<title>Other macros</title>
<sect3>
<title>_WRAP_ENUM()</title>
<para>This macro generates a C++ enum, usually in a C++ namespace, to wrap a C enum from the globabl namespace. You must specify the desired C++ name and the name of the underlying C enum.</para>
<para>For instance, from widget.hg:
<programlisting>
_WRAP_ENUM(WindowType, GdkWindowType)
</programlisting>
</para>
</sect3>
</sect2>

</sect1>


<sect1>
<title>Hand-coded source files</title>
<para>You might want to contain extra source files that will not be generated by gmmproc from .hg and .ccg files. You can simply place these in your libsomething/libsomethingmm directory and mention them in the Makefile.am in the files_extra_h and files_extra_cc variables.</para>
</sect1>

<sect1>
<title>Initialization</title>
<para>Your library must be initialized before it can be used, to register the new types that it makes available. Also, the C library that you are wrapping might have its own initialization function that you should call. You can do this in an init() function that you can place in hand-coded init.h and init.cc files. This function should initialize your dependencies (such as the C function, and gtkmm) and call your generated wrap_init() function. For instance:
<programlisting>
void init()
{
  Gtk::Main::init_gtkmm_internals(); //Sets up the g type system and the Glib::wrap() table.
  wrap_init(); //Tells the Glib::wrap() table about the libsomethingmm classes.
}
</programlisting>
</para>
<para>The implemenation of the wrap_init() method in wrap_init.cc is generated by generate_wrap_init.pl, but the declaration in wrap_init.h is hand-coded, so you will need to adjust wrap_init.h so that the init() function appears in the correct C++ namespace.</para> 
</sect1>

<sect1>
<title>Problems in the C API.</title>
<para>You are likely to encounter some problems in the library that you are wrapping, particularly if it is a new project. Here are some common problems, with solutions.</para>
<sect2>
<title>Unable to predeclare structs</title>
<para>By convention, structs are declared in glib/GTK+-style headers like so:
<programlisting>
typedef struct _ExampleWidget ExampleWidget;

struct _ExampleWidget
{
  ...  
};
</programlisting>
</para>
<para>The extra typedef allows the struct to be used in a header without including its full defintion, simply by predeclaring it, by repeating that typedef. This means that you don't have to include the C library's header in your C++ header, thus keeping it out of your public API. gmmproc assumes that this technique was used, so you will see compiler errors if that is not the case.</para>
<para>
This compiler error might look like this:
<programlisting>
example-widget.h:56: error: using typedef-name 'ExampleWidget' after 'struct'
../../libexample/libexamplemm/example-widget.h:34: error: 'ExampleWidget' has a previous declaration here
make[4]: *** [example-widget.lo] Error 1
</programlisting>
or this:
<programlisting>
example-widget.h:60: error: '_ExampleWidget ExampleWidget' redeclared as different kind of symbol
../../libexample/libexamplemm/example-widget.h:34: error: previous declaration of 'typedef struct _ExampleWidget ExampleWidget'
</programlisting>
</para>
<para>This is easy to correct in the C library, so do send a patch to the relevant maintainer.</para>
</sect2>

<sect2>
<title>Lack of properties</title>
<para>By convention, glib/GTK+-style objects have *_new() functions, such as example_widget_new() that do nothing more than call g_object_new() and return the result. The input parameters are supplied to g_object_new() along with the names of the properties for which they are values. For instance,
<programlisting>
GtkWidget* example_widget_new(int something, const char* thing)
{
        return g_object_new (EXAMPLE_TYPE_WIDGET, "something", something, "thing", thing, NULL);
}
</programlisting>
</para>
<para>This allows language bindings to implement their own equivalents (such as C++ constructors), without using the *_new() function. This is often necessary so that they can actually instantiate a derived GType, to add their own hooks for signal handlers and vfuncs.</para>
<para>At the least, the _new() function should not use any private API (functions that are only in a .c file). Even when there are no functions, we can sometimes reimplement 2 or 3 lines of code in a _new() function as long as those lines of code use API that is available to us.</para> 
<para>Another workaround is to add a *_construct() function that the C++ constructor can call after instantiating its own type. For instance,
<programlisting>
GtkWidget* example_widget_new(int something, const char* thing)
{
	ExampleWidget* widget;
        widget = g_object_new (EXAMPLE_TYPE_WIDGET, NULL);
	example_widget_construct(widget, "something", something, "thing", thing);
}

void example_widget_construct(ExampleWidget* widget, int something, const char* thing)
{
	//Do stuff that uses private API:
	widget->priv->thing = thing;
	do_something(something);
}
</programlisting>
</para>
<para>Adding properties, and ensuring that they interact properly with each other, is relatively difficult to correct in the C library, but it is possible, so do file a bug and try to send a patch to the relevant maintainer.</para>
</sect2>
</sect1>

<sect1 id="sec-appendix_wrapping_documentation">
<title>Documentation</title>
<para>In general, gtkmm-style projects use Doxygen, which reads specially formatted C++ comments and generates HTML documentation. You may write these doxygen comments directly in the header files.</para>

<sect2>
<title>Reusing C documentation</title>
<para>You might wish to reuse documentation that exists for the C library that you are wrapping. GTK-style C libraries typically use gtk-doc and therefore have source code comments formatted for gtk-doc and some extra documentation in .tmpl files. The docextract_to_xml.py script, from pygtk's codegen directory, can read these files and generate an .xml file that gmmproc can use to generate doxygen comments. gmmproc will even try to transform the documentation to make it more appropriate for a C++ API.</para>
<para>
For instance,
<programlisting>./docextract_to_xml.py -s /gnome/head/cvs/gtk+/gtk/ -s /gnome/head/cvs/gtk+/docs/reference/gtk/tmpl/ > gtk_docs.xml
</programlisting>
</para>
<para>Because this automatic transformation is not always appropriate, you might want to provide hand-written text for a particular method. You can do this by copying the XML node for the function from your something_docs.xml file to the something_docs_override.xml file and changing the contents.</para>
</sect2>

<sect2>
<title>Documentation build structure</title>
<para>If you copied the structure of an existing project then you will already have a suitable Makefile and doxygen file. The standard makefile target uses the Doxyfile doxygen file to process the .h and .cc files and output generated documentation to the html directory. 
</para>
</sect2>

</sect1>

</appendix>


<appendix id="sec-appendix-optional-api">
<title>Optional API</title>
<para>The gtkmm API is meant to be easy and convenient. However, some of these conveniences are not worth the overhead on reduced resources devices, such as the Nokia 770 internet tablet. For instance, with regular gtkmm you can implement a signal handler by deriving the class and overriding its virtual on_thesignalname() method. But that additional API increases code size. And in the case of virtual methods, it increases per-object memory size, and demands that the linker loads the method's symbol even if you don't use it. Therefore, gtkmm can be built with a reduced API. In general, the optional API is rarely used, and there are slightly less convenient alternatives for all of the optional API.</para>
<para>When gtkmm has been built with optional API disabled, macros will be undefined, indicating that the API is not available. If you attempt to compile an application that uses this optional API, against a version of gtkmm that has disabled that API, you will see compiler warnings about missing functions.</para>
<para>The following sections describe the available configure options used to disable optional API. Most developers will rarely need to provide these configure options, because they will rarely build glibmm or gtkmm, preferring to use official packages or installers. However, if you are developing for an embedded device, you might need to be aware of these options.</para>

<sect1>
<title>Optional API when building glibmm</title>


<sect2>
<title>--enable-deprecated-api=no</title>
<para>
When enable-deprecated-api is disabled, no deprecated classes or methods will be available in glibmm. For instance, the Date::set_time(GTime time) method overload will not be provided. The reference documentation contains a <ulink url="&url_refdocs_base_glib_html;deprecated.html">full list of deprecated glibmm API</ulink>.</para>
<para>If deprecated glibmm API is available, the GLIBMM_DISABLE_DEPRECATED macro will not be defined.</para>
</sect2>

<sect2>
<title>--enable-api-exceptions=no</title>
<para>
When enable-api-exceptions is disabled, no exceptions will be used in the glibmm or gtkmm API, and no exceptions will be thrown. This allows applications to be built without support for exceptions. For intance, the g++ -fno-exceptions option may be used. Where a method would normally throw an exception, that method will instead take an additional std::auto_ptr&lt;Glib::Error&gt;&amp; output parameter. If you are not using exceptions then you should check whether this parameter was set and handle any error appropriately.</para>
<para>If exceptions are not available, the GLIBMM_EXCEPTIONS_ENABLED macro will not be defined.</para>
</sect2>

<sect2>
<title>--enable-api-properties=no</title>
<para>
When enable-api-properties is disabled, no property accessors will be available in the glibmm or gtkmm API. For instance, the <function>Gtk::Button::property_label()</function> method will not be available. &quot;getter&quot; and &quot;setter&quot; methods, such as <function>Gtk::Button::set_label()</function> will still be available.</para>
<para>When you really need to set or get the property value directly, for instance when using the <classname>Gtk::CellRenderer</classname> API, you can use the alternative <function>set_property()</function> and <function>get_property()</function> methods. For instance:</para>
<para>
<programlisting>
#ifdef GLIBMM_PROPERTIES_ENABLED
  m_cellrenderer.property_editable() = true;
#else
  m_cellrenderer.set_property("editable", true);
#endif
</programlisting>
</para>
<para>If property accessors are not available, the GLIBMM_PROPERTIES_ENABLED macro will not be defined.</para>
</sect2>

<sect2>
<title>--enable-api-vfuncs=no</title>
<para>
When enable-api-exceptions is disabled, no _vfunc virtual methods will be available in the glibmm or gtkmm API. These methods allow the developer to override some low-level behaviour of the underlying GTK+ objects, and they are therefore rarely used. For instance, <function>Gtk::Frame::compute_child_allocation_vfunc()</function> will not be available.</para>
<para>However, if you really need to override a _vfunc, for instance when implementing a custom <classname>Gtk::TreeModel</classname>, you may directly access the underlying GObject via the <function>gobj()</function> method.</para>
<para>If vfuncs are not available, the GLIBMM_VFUNCS_ENABLED macro will not be defined.</para>
</sect2>

<sect2>
<title>--enable-api-default-signal-handlers=no</title>
<para>
When enable-api-exceptions is disabled, no virtual signal handler methods will be available in the glibmm or gtkmm API. For instance, the <function>Gtk::Button::on_clicked()</function> method will not be provided. Instead you must connect a signal handler by using the signal_clicked() accessor. This option offers a considerable code size and per-object memory reduction.</para>
<para>Note, however, that the compiler will not complain if you attempt to override a default signal handler when they are not supported by &gtkmm;, because the compiler cannot know that you expected to override a virtual method.</para>
<para>If default signal handlers are not available, the GLIBMM_DEFAULT_SIGNAL_HANDLERS_ENABLED macro will not be defined.</para>
</sect2>

</sect1>

<sect1>
<title>Optional API when building gtkmm</title>

<sect2>
<title>--enable-deprecated-api=no</title>
<para>
When enable-deprecated-api is disabled, no deprecated classes or methods will be available in gtkmm. For instance, the Gtk::FileSelection dialog will not be provided, because it is replaced by Gtk::FileChooserDialog. The reference documentation contains a <ulink url="&url_refdocs_base_gtk_html;deprecated.html">full list of deprecated gtkmm API</ulink>.</para>
<para>If deprecated gtkmm API is available, the GTKMM_DISABLE_DEPRECATED macro will not be defined.</para>
</sect2>

<sect2>
<title>--enable-api-atk=no</title>
<para>
When enable-api-atk is disabled, no atkmm API will be available in gtkmm. For instance, Gtk::Widget will not inherit from Atk::Implementor.</para>
<para>If the atkmm API is not available, the GTKMM_ATKMM_ENABLED macro will not be defined.</para>
</sect2>

</sect1>

</appendix>

<appendix id="sec-appendix-msvc">
<title>Using &gtkmm; with Visual Studio 2005</title>
<sect1 id="sec-installing-and-configuring-vs2005-express">
<title>Installing and Configuring Visual Studio 2005 Express</title>
<para>
You may wish to build and run &gtkmm; applications on Microsoft Windows with the
free-of-cost Visual Studio 2005 Express Edition. The following instructions
descibe how to configure a workstation to build &gtkmm; applications easily. If
you already have Visual Studio 2005 Standard Edition or above, skip to the
section titled <link linkend="sec-win32-installing-gtkmm-exe">Installing
  Gtkmm</link>
</para>

<para>
Download Visual Studio 2005 Express from <ulink
  url="http://msdn.microsoft.com/vstudio/express/visualc/">Microsoft's Visual
  C++ Download Page.</ulink>
</para>

<para>
After installing VS 2005 Express, you'll need to download the Windows Platform
SDK. Because Microsoft requires that you validate your Windows install using the
GenuineAdvantage ActiveX control, you must download it using Internet Explorer
from a Windows box with a valid license.
</para>

<para>
The Platform SDK can be downloaded from the <ulink
  url="http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&amp;displaylang=en">platform
  SDK download page.</ulink>
</para>

<para>
After installing the Platform SDK, use the instructions from <ulink
  url="http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/">Brian
  Johnson's MSDN page</ulink> to configure Visual Studio to build native Win32
Applications. 
</para>
</sect1>

<sect1 id="sec-win32-installing-gtkmm-exe">
<title>Installing &gtkmm;</title>
<para>
Once Visual Studio is installed and has been configured to build native Win32
applications, you must install the Gtk+ and &gtkmm; development packages. First,
download and install the Gtk+ development package (listed as
<literal>gtk+-win32-devel</literal>) from the <ulink
  url="http://gladewin32.sourceforge.net/modules/wfdownloads/">GladeWin32
  website</ulink>. Next, download the &gtkmm; development package from the
<ulink url="http://ftp.gnome.org/pub/gnome/binaries/win32/gtkmm/2.10/">Gnome FTP
  site.</ulink> Make sure you get the same version of both packages. At the time
of this writing, the latest version is 2.10. Do not be afraid of the size of the
development packages as they are much larger than the runtime packages which
your end users will depend on.
</para>
</sect1>

<sect1>
<title>Creating a New Project with Gtkmm Support</title>
<sect2>
  <title>Getting Started</title>
  <para>
    First, create a new project in Visual Studio by Selecting <literal>New
      Project</literal> in the <literal>File</literal> menu as shown in <xref
      linkend="figure-msvc-new-project"/>. From the <literal>New
      Project</literal> window, make sure to select <literal>Win32</literal> and
    <literal>Console Application</literal> as shown in <xref
      linkend="figure-msvc-new-project-dialog"/>. Also, give your project a name
    and a location. For this example, the name of the project is
    <literal>gtkmm_test</literal> and the location is
    <literal>C:\work</literal>.
  </para>

  <para>
    <figure id="figure-msvc-new-project">
      <title>Selecting <literal>New Project</literal> from the menu.</title>
      <screenshot>
        <graphic format="PNG" fileref="&url_figures_base;msvc_new_project_menu.png"/>
      </screenshot>
    </figure>
  </para>

  <para>
    <figure id="figure-msvc-new-project-dialog">
      <title>Selecting Win32 Console Application.</title>
      <screenshot>
        <graphic format="PNG" fileref="&url_figures_base;msvc_new_project_dialog.png"/>
      </screenshot>
    </figure>
  </para>

  <para>
    <figure id="figure-msvc-application-settings">
      <title>Verifying Application Settings.</title>
      <screenshot>
        <graphic format="PNG" fileref="&url_figures_base;msvc_application_settings.png"/>
      </screenshot>
    </figure>
  </para>

  <para>
    Clicking <literal>Finish</literal> will create for you a new native Win32
    console project. Now we need to modify this project to use Gtkmm.
  </para>

  <para>
    <figure id="figure-msvc-project-created">
      <title>New Project as Created by Visual Stuido.</title>
      <screenshot>
        <graphic format="PNG" fileref="&url_figures_base;msvc_project_created.png"/>
      </screenshot>
    </figure>
  </para>
</sect2>

<sect2>
  <title>Correct <literal>main()</literal> function</title>
  <para>
    The first order of business for this new project is to correct the
    <literal>main()</literal> function. Visual Studio wants to use a translated
    main function called <literal>_tmain()</literal>. This is fine, but will
    give you a non-portable project, and one of the goals of &gtkmm; is to
    provide a framework for portable applications. That being said, remove
    <literal>_tmain()</literal> and replace it with good old fashioned
    <literal>main()</literal>, just like mom used to make.
  </para>

  <para>
    <figure id="figure-msvc-corrected-main">
      <title>Corrected <literal>main()</literal> function.</title>
      <screenshot>
        <graphic format="PNG" fileref="&url_figures_base;msvc_corrected_main.png"/>
      </screenshot>
    </figure>
  </para>
</sect2>

<sect2>
  <title>Correct <literal>stdafx.h</literal></title>
  <para>
    The next thing to alter is the <literal>stdafx.h</literal> precompiled
    header file. At the time of this writing, many Windows programmers are
    familiar with the concept of precompiled headers. However, many Unix
    programmers are not, as precompiled header support was only recently added
    to GCC (in version 3.4) and is still not used in most open source projects.
    Unix programmers may be tempted to just disable precompiled headers
    altogether, but think carefully before doing this. Proper use of precompiled
    headers provides a much improved compile time when using &gtkmm;, and will
    save you many hours over the course of a project.
  </para>

  <para>
    <xref linkend="figure-msvc-corrected-stdafx"/> shows how to change the default <literal>stdafx.h</literal> to be more portable, and also shows the include line for the <literal>&gtkmm;.h</literal> header file. The portability changes include removing the <literal>#pragma once</literal> line and replacing it with a standard <literal>#ifdef</literal> include guard as well as removing the <literal>tchar.h</literal> include. It is advisable to put all of your &gtkmm; related headers (e.g.: <literal>libglademm.h, libxml++</literal>, etc.) in this file as opposed to other files as this will <emphasis>greatly</emphasis> speed up the compilation of your project.
  </para>

  <figure id="figure-msvc-corrected-stdafx">
    <title>Corrected <literal>stdafx.h</literal> header file.</title>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;msvc_corrected_stdafx.png"/>
    </screenshot>
  </figure>
</sect2>

<sect2>
  <title>Add Code to Create a Simple &gtkmm; Window</title>
  <para>
    Next, add the contents of a simple &gtkmm; program to the
    <literal>main()</literal> function. The example shown in the figure below is
    the one from <xref linkend="sec-basics"/>
  </para>

  <figure id="figure-msvc-main_program">
    <title>Simple &gtkmm; Program.</title>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;msvc_main_program.png"/>
    </screenshot>
  </figure>
</sect2>

<sect2>
  <title>Add the MSVC Property Files for &gtkmm;</title>
  <para>
    The next step is to add the MSVC Property files which come with the &gtkmm;
    distribution. As of the 2005 version, Visual Studio supports the use of
    property files for adding settings to a project. Property files can contain
    build settings of all kinds (e.g.: defines, include paths, link paths, and
    libraries) and make it easy to build against 3rd party packages. When a
    property file is added to a project, the project inherits all the build
    settings which the property file specifies. To keep your project portable
    (portable in the relative path vs. fixed path sense), you will want to copy
    the property files from the &gtkmm; distribution (commonly
    <literal>C:\Gtk\MSVC\</literal>) to the directory which contains your
    project (in our case <literal>C:\work\&gtkmm;_test\</literal>).
  </para>

  <figure id="figure-msvc-property-files">
    <title>Visual Stuio Property files in the &gtkmm; Distribution.</title>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;msvc_property_files.png"/>
    </screenshot>
  </figure>

  <para>
    Next, add the property files to your project. Do this by clicking the
    <literal>Property Manager</literal> tab of your Solution explorer as
    indicated in <xref linkend="figure-msvc-property-manager" />.
  </para>

  <figure id="figure-msvc-property-manager">
    <title>Property Manager (left) with <literal>Property Manager</literal> tab circled.</title>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;msvc_property_manager.png"/>
    </screenshot>
  </figure>

  <para>
    Right-Click on the <literal>Debug | Win32</literal> folder and select
    <literal>Add Existing Property Sheet.</literal> From the file browser,
    select the file <literal>&gtkmm;-2.4<literal>d</literal>.vsprops</literal>.
    Next, Right-Click on the <literal>Release | Win32</literal> folder and again
    select <literal>Add Existing Property Sheet.</literal> From the file
    browser, this time select the file <literal>&gtkmm;-2.4.vsprops</literal>.
    When you are done, the Property Manager should look like the one in <xref
      linkend="figure-msvc-property-manager-with-gtkmm-properties" />.
  </para>

  <figure id="figure-msvc-add_existing-property-sheet">
    <title>Adding an Existing Property Sheet.</title>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;msvc_add_existing_property_sheet.png"/>
    </screenshot>
  </figure>

  <figure id="figure-msvc-property-manager-with-gtkmm-properties">
    <title>Property manager with &gtkmm; property files added.</title>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;msvc_property_manager_with_gtkmm_properties.png"/>
    </screenshot>
  </figure>
</sect2>

<sect2>
  <title>Change a Few Project Settings</title>
  <para>
    At this point we're almost done. The last part is to change a few settings
    in the <literal>Project Properties</literal> page. The easiest way to get to
    this page is to right-click on the project name in the Solution Explorer and
    click the <literal>Properties</literal> menu item as shown in <xref
      linkend="figure-msvc-project-properties"/>.
  </para>

  <figure id="figure-msvc-project-properties">
    <title>Opening the Project Properties.</title>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;msvc_project_properties.png"/>
    </screenshot>
  </figure>

  <para>
    The first thing to do is remove the <literal>$(NoInherit)</literal> option
    from the linker settings as shown in <xref
      linkend="figure-msvc-properties-noinherit"/>. Get to the linker page using
    the tree on the left. Open <literal>Configuration Properties,</literal> then
    <literal>Linker,</literal> then click on <literal>Input</literal>. Now
    remove the <literal>$(NoInherit)</literal> token from the
    <literal>Additional Dependencies</literal> line. Make sure to do this in
    both <literal>Debug</literal> and <literal>Release</literal> modes.
  </para>

  <figure id="figure-msvc-properties-noinherit">
    <title>Removing the <literal>$(NoInherit)</literal> flag.</title>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;msvc_properties_noinherit.png"/>
    </screenshot>
  </figure>

  <para>
    At this point your application will build and run. However, The &gtkmm;
    headers will cause a harmless warning during the build. Fortunately, this
    warning can be disabled from the same Project Settings dialog. In the tree
    on the left of the dialog, open <literal>Configuration Properties,</literal>
    then <literal>C/C++,</literal> then click <literal>Advanced</literal>. Now
    type <literal>4250</literal> in the <literal>Disable Specific
      Warnings</literal> field as shown in <xref
      linkend="figure-msvc-properties-remove-warning-4250"/>. Make sure to make
    this change in both <literal>Release</literal> and <literal>Debug</literal>
    modes. Press <literal>Ok</literal> when done.
  </para>

  <figure id="figure-msvc-properties-remove-warning-4250">
    <title>Disabling warning 4250.</title>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;msvc_properties_remove_warning_4250.png"/>
    </screenshot>
  </figure>
</sect2>

<sect2>
  <title>About the Windows Console</title>
  <para>
    If you build and run your application now, you will see a simple Gtk+ window
    appear with nothing on it. Your application will also pop up a console
    window with it. The console window is quite valuable for debugging a &gtkmm;
    application because many Gtk+ warnings will print to this console and
    nowhere else (unlike the <literal>OutputDebugString()</literal> or
    <literal>TRACE()</literal> functions which Windows programmers are familiar
    with).
  </para>

  <para>
    When you release your application however, you will probably want to have it
    <emphasis>not</emphasis> pop up the console. This requires two small changes
    to the linker settings. From the tree on the left of the properties page,
    open <literal>Configuration Properties,</literal> then
    <literal>Linker,</literal> then <literal>System</literal>. Now change the
    value of the <literal>Subsystem</literal> field from
    <literal>CONSOLE</literal> to <literal>WINDOWS</literal> as shown in <xref
      linkend="figure-msvc-properties-subsystem-windows"/>. This will disable
    the creation of the console window when your app starts. When you do this,
    you also have to change the entry point of your application. From the tree
    on the left, select <literal>Advanced</literal> then change the
    <literal>Entry Point</literal> field to read
    <literal>mainCRTStartup</literal> (make sure to use the proper case) as
    shown in <xref linkend="figure-msvc-properties-maincrtstartup"/>.
  </para>

  <para>
    Some users have found it convenient to leave the console active in Debug
    mode and disabled in Release mode. Others will want to have it the same in
    both modes. It is completely up to the preference of the developer. Press
    <literal>Ok</literal> when done. 
  </para>

  <figure id="figure-msvc-properties-subsystem-windows">
    <title>Setting the Subsystem to <literal>Windows</literal> to disable the console.</title>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;msvc_properties_subsystem_windows.png"/>
    </screenshot>
  </figure>

  <figure id="figure-msvc-properties-maincrtstartup">
    <title>Setting the correct entry point symbol for Windows programs using <literal>main()</literal>.</title>
    <screenshot>
      <graphic format="PNG" fileref="&url_figures_base;msvc_properties_maincrtstartup.png"/>
    </screenshot>
  </figure>

  <para>
    That's all there is to it. After this initial setup, your &gtkmm; app can be
    edited, built, and run just like any other Visual Studio project.
  </para>

</sect2>

</sect1>

</appendix>

</book>

<!-- some vim settings
    vim:ts=2 sw=2 et
-->
