GTK+ 2.0 App - Icon Chooser

GTK+ 2.0 App -
Icon Chooser
(GNU gettext & Doxygen included)
William.L
wiliwe@gmail.com
2008-10-12

Index
About Icon Chooser........................................................................................................................................ 3
Developing Environment & Build................................................................................................................. 6
Install Libraries for Development ......................................................................................................... 6
Build & Run............................................................................................................................................. 6
About the Memory Management in GTK+ 2.0............................................................................................ 8
GUI Programming Concept <1>: Event-Driven........................................................................................... 9
GUI Programming Concept <2>: MVC.......................................................................................................11
GTK+ 2.0 Tree View ............................................................................................................................. 13
i18n - GNU gettext ........................................................................................................................................ 16
Locale ..................................................................................................................................................... 16
Usage ...................................................................................................................................................... 19
GNU gettext in GLib/GTK+ Program................................................................................................ 24
Doxygen.......................................................................................................................................................... 26
Tools........................................................................................................................................................ 27
Configuration File................................................................................................................................. 28
Documenting the Code ......................................................................................................................... 31
Special Command ......................................................................................................................... 32
Putting documentation after members ....................................................................................... 35
Documentation at other places .................................................................................................... 37
Generate Diagrams/Graphs................................................................................................................. 39
Icon-Chooser Internals................................................................................................................................. 42
Resources ....................................................................................................................................................... 47

About Icon Chooser
In a Linux distro using GNOME desktop environment, when a user wants to add an application launcher on
GNOME Panel (setting steps are shown below), one of steps is to choose an icon to represent the
application and the selected icon will be shown on the panel. To survey GNOME Panel source codes, it
could find a folder named "libpanel-util" containing codes for providing icon choosing dialog - Icon
Chooser , the files panel-icon-chooser.c[.h] which use GtkFileChooserDialog widget as user interface to
select icon.
GNOME Panel source
* Archives - http://ftp.gnome.org/pub/gnome/sources/gnome-panel/
* Git Repository - https://github.com/zeldin/gnome-panel/tree/master/gnome-panel
1) Right click the panel to pop up the function menu, click “Add to Panel” item.
2) Select “Custom Application Launcher” item and click "Add" button.
Download example from GitHub:
https://github.com/wiliwe/gtk2-icon-chooser.git
Using Git tool (http://git-scm.com/downloads) to fork this repo:
git clone https://github.com/wiliwe/gtk2-icon-chooser.git

3) Enter the application name in Name field and the full path to application executable program in
Command field. Input for Comment is optional.
4) Click left button to show a dialog to choose an icon(e.g. icon chooser) for your application. This
icon will be shown on desktop panel.
Click “Open” button to close dialog.
5) The choosen icon will be shown on application launcher setting dialog.
Click “OK” button click close setting dialog.

6) The set application launcher is shown on desktop panel.
Cause to that the icon chooser of GNOME Panel is based on GtkFileChooserDialog widget, so the user
could not view a icon's appearance until the user select it and let it show on the panel aside. If we want to
have an icon chooser that can view all icons in a folder in visual list in a GTK+2 application, we need to
do it by ourselves.
In GTK+2, there has a widget called GtkIconView that can list icons in a grid with its picture. Icon
Chooser uses this widget to list icons in visual style. Also, this program can return the full file path of
the selected icon to the caller for further usage or manipulation. Icon Chooser was written in C++ and
runs as a modal dialog.
GtkIconView widget:
* https://developer.gnome.org/gtk2/stable/GtkIconView.html
* http://www.zetcode.com/tutorials/gtktutorial/gtkwidgetsII/
* http://www.zetcode.com/tutorials/gtktutorial/chinese/gtkwidgetsII/ 中文版

Developing Environment & Build
* Ubuntu 8.04 Hardy Heron LTS
* GTK+ 2.0
* Doxygen v1.5.5
Install Libraries for Development
<GLib>
Ubuntu
# sudo apt-get -y install libglib2.0-dev
CentOS 6
# su
$ yum -y install glib2-devel-*
<GTK+ 2.0>
GTK2 development library includes "gdk-pixbuf" development library.
Ubuntu
# sudo apt-get -y install libgtk2.0-dev
CentOS 6
# su
$ yum -y install gtk2-devel-*
Build & Run
In the source root of Icon Chooser program, just run “make” command to build program. If the build
process succeed, it will generate a executable file name IconChooser under the source root, run it by
entering command:
In Icon Chooser, input the full path of a directory containing icons you want to browse in the icon view by
entering the path string by hand-typing or using file chooser(dialogue) invoked by clicking the button
“Browse…”, choose the wanted icon by clicking it, then click the button “Apply” to close the chooser
dialogue and you can see the full path of the chosen icon in the console(as below snapshots).
./IconChooser

About the Memory Management in GTK+ 2.0
GTK+2 depends on GLib which uses GObject system to achieve object-oriented programming. The
GObject system provides a memory management model based on Reference Counting(Counter)
mechanism (the same as the one used in Microsoft COM technology) for applications to do
garbage-collection(GC).
Reference Counting means that an object has a counter that can be increased (ref-ed, referenced) or
decreased (unref-ed, unreferenced). If the counter is unref-ed to zero, the object is automatically destroyed.
This is useful, because other object or application programmers only have to think about whether they
themselves are still using that object or not, without knowing anything about others also using it. The object
is simply automatically destroyed when no one is using it any more.
XXX_new() and XXX_unref() are for creation and deletion of an object separately. When an object is
created, its reference counter will be increased from zero to one. XXX_unref() is used to decrease the
reference counter of the object. If the reference counter of the object is decreased to zero, the object will be
delete, e.g. the memory of the object will be released.
More detailed information about GObject could be found in below sites:
* https://developer.gnome.org/gobject/
* http://files.myeburg.net/gobject-book-a4.pdf

GUI Programming Concept <1>: Event-Driven
For GUI (Graphic User Interface) programming, one important concept is Event-Driven model:
The GUI applications start a main loop, which continuously checks for
newly generated events. If there is no event, the application waits and
does nothing(idle mode).
All GUI applications are developed based on event driven.
In the event-driven model, the operating system is the Event Manager that monitors events from hardware
devices or other widgets and dispatches events to GUI applications for processing. And the application is the
Event Handler whose function is to wait for an event to occur and then perform the corresponding action.
The software routine in the application for waiting for and processing events is called Event Loop or Main
(Event) Loop. When there has no more events to process, the application will be in idle state (mode).
Most events come from user's operations such as mouse button click or keyboard keystrokes. Events are
used to signal the changing state of an UI component (widget) in graphical user interfaces.
The event-driven model is usually implemented by means of messages passed among the participants. For
example, user clicks mouse button, the mouse sends a message to the operating system, which in turn, sends
a message to GUI application. The application processes messages one by one, and the messages not be
processed yet are put in an queue called Event Queue or Message Queue, in the order it was sent to the
application.
User Input Event
Operating System
(event manager)
GUI Application
(event handler)
/* Event Loop */
MSG msg;
while(1)
{
GetMsg(msg);
switch(msg.type)
{
case 1:
action1;
break;
...
default:
DoNothing;
} // end of switch
} // end of while(1)

GTK+2 depends on GLib mainloop to manage all the available sources of events. The GMainLoop data
type represents a main event loop. A GMainLoop is created with g_main_loop_new(). After adding the
initial event sources, g_main_loop_run() is called. This continuously checks for new events from each of
the event sources and dispatches them. Finally, the processing of an event from one of the sources leads to a
call to g_main_loop_quit() to exit the main loop, and g_main_loop_run() returns.
GTK+2 contains wrappers of some of GLib mainloop functions:
* gtk_main()
* gtk_main_quit()
* gtk_events_pending().
On UNIX, the GLib mainloop is incompatible with fork(). Any program using the mainloop must either
exec() or exit() from the child without returning to the mainloop.
On Linux platform, an event in GTK+2 is a message from the X server. When the event reaches a widget,
it may react to this event by emitting a signal. The GTK+2 programmer can connect a specific callback to
a signal. The callback is a handler function, that reacts to a signal (P.S: Qt framework uses similar
method for processing widget events, it calls Signal-Slot).
More detailed information about GLib/GTK+ message loop could be found in sites:
* https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html
* https://developer.gnome.org/gtk2/stable/gtk2-General.html
X Server Widget Event Handlersignal
(event)
message

GUI Programming Concept <2>: MVC
Another important concept of GUI (Graphic User Interface) programming is Model-View-Controller,
abbreviated as MVC.
The Model-View-Controller architecture is a well-known object-oriented user interface software
architecture design paradigm/pattern and decomposition and was first introduced into object-oriented
programming language Smalltalk in the 1970s. Its concept is that complete separation between data and
how that data is displayed on the screen. Basically, MVC breaks a GUI component into three elements
(roles): model, view and controller. MVC is an example of the Observer design pattern (also known as
Dependents, Publish/Subscribe or Publisher/Subscriber) where model is the Subject and views are
Observers that can register to get notified of any change to the model.
Model
The model stores data of various type (strings, numbers, images, etc). Generally, Model is constructed first
and is the most important of all three elements: the data is the core of an application and is what an
application mainly focuses on. Moreover, data identifies the state of an application: if the data is changed,
it means the state of the application is changed.
The data remains the same no matter how the UI component is painted on the screen; model data is always
independent of the component's visual representation. Upon the model (data) is changed, the model will
send update notifications to all views that are interested in(depend on) it, so that views can retrieve the
updated data and refresh themselves; this way could be said that there has a Subscribe-Notify protocol
between model and view.
In practice, it may have many kinds of model in a GUI framework or library for different classes of
view(visual component, e.g. widget, control) and the model is implemented in some kinds of data structure
written in the programming language the GUI framework or library uses.
View
The view is told which data to display, where to display it, and how to display it by model. The view
determines the visual representation of the component’s model. This is a component’s “look.”
Controller
The controller is the portion of the user interface (view) and is responsible for determining whether the
component should react to any user action(i.e. input events from keyboard or mouse) that affects the
model or views. The controller is the “feel” of the UI component, and it determines what actions are
performed when the UI component is used.
In this separation, the view and controller depend on the model, while the model does NOT depend on
either of the two making it so the model can be independent of the visual presentation when building and
testing.

The three elements of a model-view-controller architecture
From book - Java Swing 2/e, 2002, O’Reilly
Communication through the Model-View-Controller architecture
One of advantages of this approach is that you can have multiple views that display the same data in
different ways, or in the same way in multiple times, with only one copy of the underlying data. This
avoids duplication of data and programming effort if the same data is re-used in different contexts and the
UI component can be updated with a new look or visual style without having to change the data model or
the controller. Also, it keeps the program modularized, allowing for high cohesion and loose coupling.
The MVC concept has been adopted into many frameworks, such as:
* Microsoft MFC Document/View Model
GUI Tool
user
Controller View
Model
The model passes its
data to the view
for rendering.
The controller
updates the model
based on the events
seesuses
Update view such
as menu selected
< user action>
The view determines
which events are
passed to the controller.

Document is model and CFrameWnd class is controller dispatching window messages to programmer
implemented methods
* Java Swing Framework (precisely speaking, it uses a variation of MVC pattern, Model/Delegate)
Here using table view for example. For the table view widget, JTable, it needs to set the model object
of a class derived from AbstractTableModel abstract class; when model's content is changed, it needs to
call model’s method fireTableXXX() (from AbstractTableModel class) to notify JTable to
refresh/repaint table view display depending on the changed model content
* Apache Struts (written in Java)
* Apple Mac OS X Cocoa / iOS Cocoa Touch Framework (written in Objective-C).
GTK+ 2.0 Tree View
The GtkTreeView is a widget that displays single- or multi-columned lists and trees. It replaces the old
Gtk+-1.2 GtkCList and GtkCTree widgets. The GtkTreeView widget is designed based on MVC model.
To create a tree or list in GTK+2, use the GtkTreeModel interface in conjunction with the GtkTreeView
widget. GtkTreeModel is an abstract interface to the data store and defines generic tree or list interfaces
used by the GtkTreeView widget; it only provides a way to query a data store's characteristics and to
retrieve existing data. It does not provide a way to remove rows from or add rows to the store or put data
into the store, this is done using functions of the specific store implementing GtkTreeModel interface. The
model is represented as a hierarchical tree of strongly-typed, columned data.
The programmer needs not to implement GtkTreeModel by him(her)self, two models implementing
GtkTreeModel are provided:
* GtkTreeStore is used to model tree widgets
* GtkListStore is used to model list widgets.
A list is basically just a special case of a tree with none of the items having any children, so one could use
a tree store to maintain a simple list of items as well. The only reason GtkListStore exists is in order to
provide an easier interface that does not need to cater for child-parent relationships, and because a simple
list model can be optimized for the special case where no children exist, which makes it faster and more
efficient. To use these model data structures, the developer simply pushes data into these models as
necessary. GtkListStore is internally a simple linked list and stores a list node in one of pointers.
GtkListStore and GtkTreeStore are GObjects and have a reference count of one after creation. The tree
view will add its own reference to the model when you add the model with gtk_tree_view_set_model(),
and will unref it again when you replace the model with another model, unset the model by passing NULL
as a model, or when the tree view is destroyed. This means that you need to take care of "your" reference
yourself, otherwise the model will NOT be destroyed properly when you disconnect it from the tree view,
and its memory will not be freed (which does not matter much if the same model is connected to the tree
view from application start to end).
If you plan to use the same model for a tree view for the whole duration of the application, you can get rid

of "your" reference right after you have connected the model to the view - then the model will be destroyed
automatically when the tree view is destroyed (which will be automatically destroyed when the window it
is in is destroyed)
There are several other components that are used with the GtkTreeView widget:
GtkTreeViewColumn A GtkTreeView is made up of tree view columns.
A model column represents a certain data field of an item that has a fixed data type
but does NOT display any data. It is only used as a device to represent the user-side
of the tree view and serves as packing widgets for the components that do the
actual rendering of data onto the screen, namely the GtkCellRenderer family of
objects.
You need to know what kind of data you want to store when you create a list store
or a tree store, as you can NOT add new fields later on.
GtkCellRenderer Cell renderers are packed into tree view columns to display data.
The GtkCellRenderer determines, how the data is going to be displayed in the
GtkTreeViewColumn. There are a number of different cell renderers that
specialize in rendering certain data like strings, pixbufs, or toggle buttons.
A tree view column needs to contain at least one cell renderer, but can contain
multiple cell renderers.
Note that the tree view will not resize icons for you, but displays them in their
original size.
GtkTreeIter A structure used to refer to a row in the GtkTreeView.
GtkTreeSelection A structure that handles selections
There has an alternative view widget to show list model (GtkListStore). This kind of the widget is
GtkIconView which is similar to GtkTreeView.
Basic Usage of Tree View
* Creating a tree view widget.
* Construct the tree model for tree view.
* Connect tree model to tree view widget by calling function gtk_tree_view_set_model().
Basic Usage of Icon View
* Creating a icon view widget.
* Construct the list model(store) for icon view.

* Connect tree model to icon view widget by calling function gtk_icon_view_set_model().

i18n - GNU gettext
If a software can display texts/strings in different natural languages for users using different mother
tongues, the software is said to be multilingual (or internationalized) software. If the software wants to have
multilingual functionality, it needs to be considered how to achieve it and what mechanism to be adopted
during design phase and adding corresponding codes when developing. Here using GNU gettext framework,
a widely used framework for internationalization, to achieve it. Before doing it, it needs to introduce some
terms relative to the development of the multilingual program.
Internationalization, i18n, is the process of making the software be able to use localization (l10n) easily
for users that vary in culture, region, or language without further any engineering changes. This is a kind of
generalization on part of the software that hard-coded information(ex: text strings) are pulled out to external
files as resource bundle and the software will load proper resource file based on the locale type set on
machine(where the software is running on) at runtime. It lets software be completely independent of any
culture specific information.
Localization, l10n, is the process of customizing the software for that it can display its messages in an
appropriately translated form for a particular locale. Internationalization and localization are the first phase
and the second phase of Globalization (g11n), the process of developing and marketing multilingual
software products to a global market.
Native Language Support, or merely NLS, is for speaking of the overall activity or feature encompassing
both internationalization and localization, allowing for multi-lingual interactions in a program.
Locale
Locale is used to define a set of information or attributes (characters and code sets, currency, dates,
numbers and messages) corresponding to a given language & country. “Messages” attribute is where GNU
gettext provides the means for developers and users to easily change the language that the software uses to
communicate to the user. The locale used by GUI programs in desktop environment can be specified in a
configuration program called “control center”, “language settings” or “country settings”.
Users achieve localization of programs by setting proper values to special environment variables, prior to
executing those programs, identifying which locale should be used. When a program looks up locale
dependent values, it does this according to following environment variables in priority order:
<1st> LANGUAGE
<2nd> LC_ALL
<3rd> LC_xxx
according to selected locale category: LC_CTYPE, LC_NUMERIC, LC_TIME,
LC_COLLATE, LC_MONETARY, LC_MESSAGES, ...
<4th> LANG .
Variables whose value is set but is empty are ignored in this lookup.

LANG is the normal environment variable for specifying a locale. As a user, if your language has been
installed for this package, you only have to set the LANG environment variable to the appropriate ‘ll_CC’
combination (unless some of the other variables have already been set by the system, in /etc/profile or
similar initialization files).‘ll’ is an ISO 639-1 two-letter Language code, and ‘CC’ is an ISO 3166
two-letter Country code(see below URLs).
* Language Code - http://www.loc.gov/standards/iso639-2/php/code_list.php
* Country Code - http://www.iso.org/iso/english_country_names_and_code_elements
At the shell prompt, merely execute:
CSH shell
# setenv LANG en_US
SH shell
# export LANG; LANG= en_US
BASH shell
# export LANG= en_US
or
# LANG= en_US
. This can be done from your .login or .profile file under your home directory, “/home/YourLoginName/”.
Many locale names have an extended syntax ‘ll_CC.encoding’ that also specifies the character encoding.
Most users have switched to locales in UTF-8 encoding. For example, “zh_TW.UTF-8” is for Chinese
Traditional with UTF-8 character encoding.
For a software that has been internationalized (generalized), if a user sets a particular locale, the software
will show proper information (text string) based on the language described by the locale variable when the
software is being run. This is done using the concept of Message Catalog, which is a database of strings in
some file.
GNU gettext framework is one approach supporting Message Catalog to do text i18n. This framework
refers to a collection of tools used to internationalize and localize an application or package. Apart from
internationalization of applications or packages, these tools assist in translating the strings on menus,
messages boxes or icons on the applications in the language that the user is interested in.
The below figure shows the flow to use GNU gettext tools.

( From GNU gettext manual - https://www.gnu.org/software/gettext/manual/gettext.html )
The following figure shows what files would be generated when using gettext to do internationalization.
( From Wikipedia - http://en.wikipedia.org/wiki/Gettext#mediaviewer/File:Gettext.svg )
In the above figures:
* POT - Portable Object Template (.pot). This file contains all original program strings(extracted by
gettext tool xgettext). It has sets of pointers to exactly where in C sources each string is used. All
translations are set to empty. For example,
"Content-Type: text/plain; charset=CHARSETn"
"Content-Transfer-Encoding: 8bitn"
#: helloworld.c:16
#, c-format
msgid "Hello, world! n"
msgstr ""

* PO - Portable Object (.po). This file is made up of many entries, each entry holding the relation between
an original string and its corresponding translation. All entries in a given PO file
usually pertain to a single project, and all translations are expressed in a single target language. Also,
it needs to change character encoding for your language by setting the field “charset”. For
example:
The string after msgid is the original string and the string after msgstr is translated string.
* MO - Machine Object (.mo). This file is used to support Message Catalog. This kind of files are meant to
be read by programs, and are binary in nature. The content of the file is generated by gettext tool
msgfmt. This file could be put into your project directory or system default directory:
/usr/local/share/locale/LocaleName/LC_MESSAGES/
, where "LocaleName" is the name of the locale category such as "en", "zh", "zh_TW", etc.
Usage
Step 1. Mark texts to be internationalized
<I> Adding following headers and macros in the file containing the main() function.
* The header "libintl.h" is for the setlocale() function.
* _(String) macro is for the convenience of using gettext() on those text needs to be translated.
* PACKAGE represents package name, the name of MO file without file extension
“.mo”.
* LOCALEDIR represents the locale directory containing LC_MESSAGE folder which has
“Package Name.mo” files. This is usually as "/usr/share/locale."
#include <libintl.h>
#include <locale.h>
#define _(String) gettext (String)
#define PACKAGE MO_File_Name
#define LOCALEDIR Path_to_MO_File
"Content-Type: text/plain; charset=UTF-8n"
#: helloworld.c:16
#, c-format
msgstr "哈囉哈囉哈囉哈囉, 世界世界世界世界! n"

<II> Adding following gettext functions at the very beginning of the main() function body (but after the
variable declarations) to initialize locale data.
When it is going to compile code, remember to define "ENABLE_NLS " to use i18n/gettext.
<III> To use "_()" to enclose any string that must be translated(shown as below example).
In case you can't use "_()" (like in array declarations), use "N_()" where the original English string is
and then call "_()" at real display time(show as below example).
Step 2. Parse source files and extract marked strings as msgids and put it into
POT(.pot) file
Using GNU gettext tool, xgettext, to extract marked strings from source and store it into the POT(.pot)
file. For example:
"helloworld" is the package (domain) name assigned as the value of the macro PACKAGE in Step 1. The
keyword (-k) to mark original string as gettext string is underscore character "_." Output file is
"helloworld.pot."
Note that if it does NOT assign output file name using -o parameter, it will generate a PO file be named
after “package (domain) name” assigned using -d parameter. In this example, it will be “helloworld.po”
#ifdef ENABLE_NLS
/* Clear out LC_ALL environment variable. */
setlocale(LC_ALL, "");
/* To designate where to search for message catalogs, e.g. MO files. */
bindtextdomain (PACKAGE, LOCALEDIR);
/* (Optional) To specify the output character set(encoding) for message
catalogs for the designated domain */
bind_textdomain_codeset (PACKAGE, "UTF-8");
/* To select domain, e.g. the name of MO file */
textdomain (PACKAGE);
#endif
#define ENABLE_NLS 1
printf(_("Hello Worldn"));
char *foo[]={ N_("aaaaa"), N_("bbbb") };
int i;
for (i=0;i<2;i++) printf( _(foo[i]) );
xgettext -d helloworld -o helloworld.pot -k_ -s helloworld.c

file and then rename the generated file to “helloworld.pot”.
Step 3. Translate POT(.pot) file into a PO(.po) file
Copy the POT(.pot) file and change copied file's extension to ".po", this copied file becomes a PO file.
In the copied PO file, set information about your PO file by changing following fields.
Then, set proper character encoding by setting “charset” field and add translated string to “msgstr” field.
For example, the content of “helloworld.po” would be:
Finally, remove the Fuzzy Mark shown below.
The fuzzy mark is used to denote the messages in current PO file are fuzzy messages that are NOT been
validated / translated by a human translator.
If each PO file entry for which the msgstr field has been filled with a translation, and which is not marked
as fuzzy, is said to be a translated entry. Only translated entries will later be compiled by GNU msgfmt
and become usable in programs. Other entry types will be excluded.
"Content-Type: text/plain; charset=UTF-8n"
#: helloworld.c:16
#, c-format
msgstr "哈囉哈囉哈囉哈囉, 世界世界世界世界! n"
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
"Project-Id-Version: PACKAGE VERSIONn"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONEn"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>n"
"Language-Team: LANGUAGE <LL@li.org>n"
# William.L <wiliwe@gmail.com>, 2008.
"Project-Id-Version: helloworld 1.0n"
"PO-Revision-Date: 2008-10-22 18:55+0800 n"
"Last-Translator: William.L <wiliwe@gmail.com>n"
"Language-Team: Chinese Traditional <LL@li.org>n"
#, fuzzy

After the translation work is done, you could verify the PO file’s content by below command.
Step 4. Convert PO(.po) files into binary resource file, MO(.mo) file.
Using GNU gettext tool, msgfmt, to generates a binary Message Catalog from a textual translation
description, e.g. PO file.
Then put the generated MO files into the path designated as the macro LOCALEDIR in Step 1.
For example,
Step 5. Set locale environment variable to the language type you want and run your
program.
Set the locale environment variable, LANG, as described in “Locale” section of this chapter and then launch
your program. The following example shows results of wrong encoding type and correct encoding type.
Note that when gettext does not find a translation for msgid, it returns msgid unchanged independently of
the current output character set.
Note that when it wants to show strings in a language other than English, it needs to have other Language
Packages installed in the system where the program will run on. Below steps show how to install language
package in Linux Ubuntu.
Steps to install wanted language package:
1) On desktop panel, click System -> Administration -> Language Support .
msgfmt helloworld.po -o helloworld.mo
msgfmt -cv helloworld.po

2) In "Language & Text" setting dialog, click button "Install/Remove Languages..."
3) Select and check languages you want install and click "Apply Changes" button.

Alternatively, it could install language packages in Synaptic Package Manager.
GNU gettext in GLib/GTK+ Program
For the program using GLib or GTK+ libraries, 1)it could replace the header "libintl.h" with "gi18n.h" or
"gi18n-lib.h" and 2)it needs not to declare macros for GNU gettext APIs.
The contents of headers "gi18n.h" or "gi18n-lib.h" are shown below:
#include <glib/gi18n.h> #include <glib/gi18n-lib.h>

* /usr/include/glib-2.0/glib/gi18n.h
* /usr/include/glib-2.0/glib/gi18n-lib.h
The difference of using these two headers is that one header uses fixed macro(GETTEXT_PACKAGE) to
represent the package(domain) name and the other let the macro definition to users.
#include < glib/gi18n.h >
#include <locale.h>
#define PACKAGE MO_File_Name
#define LOCALEDIR Path_to_MO_File
#define GETTEXT_PACKAGE MO_File_Name
#include < glib/ gi18n-lib.h >
#include <locale.h>
(it MUST define GETTEXT_PACKAGE before
including gi18n-lib.h header)

Doxygen
When viewing source codes written by others or sharing codes to others, it would be better for readers if
there have documents to comment or explain codes and show architecture(relationship of each part, such as
files, modules, packages, functions, classes, in codes) using graph or diagram. This may let readers get idea
(overview, a big map/picture) of codes quickly.
There have many tools to generate documents of source codes by adding special markings in comment
blocks, this kind of tool is called Document Generator. For a programmer, if he or she can add comments
while coding, the work to document codes could be accomplished when code is done, it would save much
time compared to that adding comments after code is done. Comments about code's implementation are
called Implementation comments. Comments describe the specification of the code, from an
implementation-free perspective to be read by developers who might not have the source code at hand, are
called Documentation comments. Tools such as JavaDoc, Doxygen, DOC++, Qt Qdoc(for Qt Project
itself only) are well-known. Doxygen is used to generate documents for Icon Chooser program..
Doxygen (http://www.doxygen.org/) is for generating documentation from annotated C++ sources, but it
also supports other popular programming languages such as C, Objective-C, C#, PHP, Java, Python, IDL
(Corba, Microsoft, and UNO/OpenOffice flavors), Fortran, VHDL, Tcl, and to some extent D. It runs on
most Unix systems as well as on Windows and Mac OS X.
Doxygen is written in Qt (http://qt-project.org/). Initially doxygen was specifically designed to be used for
projects that make use of Troll Tech’s Qt toolkit. So it is ‘Qt-compatible’:
doxygen can read the documentation contained in the Qt source code and create a class browser that
looks quite similar to the one that is generated by Troll Tech. Doxygen understands the C++
extensions used by Qt such as signals and slots and many of the markup commands used in the Qt
sources.
How did the name "Doxygen" come from? From Doxygen FAQ of the official site, its solution is that:
" Doxygen got its name from playing with the words documentation and generator.
At the time I was looking into lex and yacc, where a lot of things start with "yy", so the "y" slipped in
and made things pronounceable (the proper pronouncement is Docs-ee-gen, so with a long "e")."
Doxygen FAQ link: http://www.stack.nl/~dimitri/doxygen/manual/faq.html
It can generate an on-line documentation browser (in HTML) and/or an off-line reference manual (in
LATEX) from a set of documented source files. There is also support for generating output in RTF
(MS-Word), PostScript, hyperlinked PDF, compressed HTML(.chm), and Unix man pages. The
documentation is extracted directly from the sources, which makes it much easier to keep the documentation
consistent with the source code.
documentation -> docs -> dox
generator -> gen

The following figure shows the relation between the tools and the flow of information between them.
( From doxygen site - http://www.stack.nl/~dimitri/doxygen/manual/starting.html )
Doxygen looks at the file's extension to selects the proper parser to parse a file. Extension types
recognized by doxygen is listed in http://www.stack.nl/~dimitri/doxygen/manual/starting.html
Tools
The executable doxygen is the main program that parses the sources and generates the documentation.
To generate a manual for your project you typically need to follow these steps:
<1> Document your source code with special documentation blocks , or called special command blocks.
See http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html
<2> Generate a template configuration file by running doxygen with the -g option:
doxygen -g <config_file>

<3> Edit the configuration file so it matches your project. In the configuration file you can specify the input
files and a lot of optional information.
<4> Let doxygen generate the documentation, based on the settings in the configuration file. The default
output directory is the directory in which doxygen is started.
<5> If you have a configuration file generated with an older version of doxygen, you can upgrade it to the
current version by running doxygen with the -u option.
All configuration settings in the original configuration file will be copied to the new configuration file.
Any new options will have their default value. Note that comments that you may have added in the
original configuration file will be lost.
More detailed information about doxygen tool is here:
http://www.stack.nl/~dimitri/doxygen/manual/doxygen_usage.html
Optionally, the doxywizard tool which is a graphical front-end written in Qt can be used for editing the
configuration file that is used by doxygen and for running doxywizard in a graphical environment. More
detailed usage information about doxywizard is here:
http://www.stack.nl/~dimitri/doxygen/manual/doxywizard_usage.html
Configuration File
A configuration file is a free-form ASCII text file with a structure that is similar to that of a Makefile, with
the default name Doxyfile. It is parsed by doxygen tool.
The file essentially consists of a list of assignment statements.
* Each statement consists of a TAG_NAME written in capitals, followed by the equal sign (=) and one or
more values.
* If the same tag is assigned more than once, the last assignment overwrites any earlier assignment.
* For tags that take a list as their argument, the += operator can be used instead of = to append new values
to the list.
* Values are sequences of non-blanks.
* If the value should contain one or more blanks it must be surrounded by quotes ("..."). Multiple lines
can be concatenated by inserting a backslash () as the last character of a line.
* Environment variables can be expanded using the pattern $(ENV_VARIABLE_NAME).
* The statements in the file are case-sensitive.
The file may contain tabs and newlines for formatting purposes.
The default encoding used for all characters in the configuration file is UTF-8 and it could be changed by
setting the tag DOXYFILE_ENCODING. Doxygen uses libiconv (or the iconv built into libc) for
doxygen <config_file>
doxygen -u <config_file>

transcoding. See http://www.gnu.org/software/libiconv for the list of possible encodings.
Here listing some tags usually used in project:
Tag Name Description Default
Value
Depending Tag
PROJECT_NAME A single word (or a sequence of
words surrounded by
double-quotes) that should
identify the project.
PROJECT_NUMBER Project or revision number
PROJECT_BRIEF To provide an optional one line
description for a project that
appears at the top of each page
and should give viewer a quick
idea about the purpose of the
project.
OUTPUT_DIRECTORY To specify the (relative or
absolute) path into which the
generated documentation will
be written.
OUTPUT_LANGUAGE To specify the language in
which all documentation
generated by doxygen is
written.
English
INPUT To specify the files and/or
directories that contain
documented source files.
You may enter file names like
myfile.cpp or directories like
/usr/src/myproject.
Separate the files or directories
with spaces.
If this tag is
empty the
current
directory is
searched.
RECURSIVE Be used to specify whether or
not subdirectories should be
searched for input files as well.
No
EXTRACT_ALL Assume all entities in
documentation are
documented, even if no
documentation was available.
No
EXTRACT_ANON_NSPACES Include the members of
anonymous namespaces
No
EXTRACT_LOCAL_CLASSES Include classes (and structs)
defined locally in source files.
Yes

EXTRACT_LOCAL_METHODS Include local methods, which
are defined in the
implementation section but not
in the interface
No
EXTRACT_PRIVATE Include private members of
a class
No
EXTRACT_STATIC Include static members of a
class
No
SORT_MEMBER_DOCS Sort the (detailed)
documentation of file and
class members alphabetically
by member name.
Yes
GENERATE_HTML Generate HTML output Yes
HTML_HEADER
HTML_FOOTER A footer typically contains the
author of the document,
copyright information, links to
terms of use, contact
information, etc.
HTML_OUTPUT Specify output folder
HTML_FILE_EXTENSION Specify the file extension .html
GENERATE_TREEVIEW No
GENERATE_HTM
L
HAVE_DOT To use dot tool to generate
diagrams and graphs
No
CALL_GRAPH Generate a call dependency
graph for every global function
or class method.
No
CALLER_GRAPH Generate a caller dependency
graph for every global function
or class method
No
GENERATE_LEGEND Yes
GRAPHICAL_HIERARCHY Yes
DIRECTORY_GRAPH Yes
UML_LOOK No
UML_LIMIT_NUM_FIELDS Threshold limits the number of
items for each type to make the
size more manageable.
Set this to 0 for no limit.
Minimum value: 0
Maximum value: 100
10
CLASS_GRAPH Yes
COLLABORATION_GRAPH Yes
HAVE_DOT

For a small project consisting of a few C and/or C++ source and header files, you can leave INPUT tag
empty and doxygen will search for sources in the current directory.
If you have a larger project consisting of a source directory or tree you should assign the root directory or
directories to the INPUT tag, and add one or more file patterns to the FILE_PATTERNS tag (for instance
*.cpp *.h). Only files that match one of the patterns will be parsed (if the patterns are omitted a list of source
extensions is used). For recursive parsing of a source tree you must set the RECURSIVE tag to YES.
If you start using doxygen for an existing project (thus without any documentation that doxygen is aware
of), you can still get an idea of what the structure is and how the documented result would look like. To
do so, you must set the EXTRACT_ALL tag in the configuration file to YES. Then, doxygen will pretend
everything in your sources is documented. Please note that as a consequence warnings about undocumented
members will not be generated as long as EXTRACT_ALL is set to YES.
If the EXTRACT_ALL option is set to NO in the configuration file (the default), then doxygen will only
generate documentation for documented members, files, structs, classes and namespaces.
To analyze an existing piece of software it is useful to cross-reference a (documented) entity with its
definition in the source files. Doxygen will generate such cross-references if you set the
SOURCE_BROWSER tag to YES. It can also include the sources directly into the documentation by
setting INLINE_SOURCES to YES (this can be handy for code reviews for instance).
More detailed usage information about configuration file is here:
http://www.stack.nl/~dimitri/doxygen/manual/config.html
Documenting the Code
For members, structs, classes and namespaces there are basically two options to document codes:
1. Place a special documentation block in front of the declaration or definition of the member, struct,
class or namespace. For file, struct, class and namespace members it is also allowed to place the
documentation directly after the member.
2. Place a special documentation block somewhere else (another file or another location) and put a
structural command in the documentation block. A structural command links a documentation
block to a certain entity that can be documented (e.g. a member, struct, class, namespace or file).
Files can only be documented using the second option, since there is no way to put a documentation block
before a file. Of course, file members (functions, variables, typedefs, defines) do not need an explicit
structural command; just putting a special documentation block in front or behind them will work fine.
The text inside a special documentation block is parsed before it is written to the HTML and/or LaTeX
output files.
GENERATE_LATEX Yes

During parsing the following steps take place:
* Markdown formatting is replaced by corresponding HTML or special commands.
* The special commands inside the documentation are executed.
* If a line starts with some whitespace followed by one or more asterisks (*) and then optionally more
white space, then all whitespace and asterisks are removed.
* All resulting blank lines are treated as a paragraph separators. This saves you from placing
new-paragraph commands yourself in order to make the generated documentation readable.
* Links are created for words corresponding to documented classes (unless the word is preceded by a %;
then the word will not be linked and the % sign is removed).
* Links to members are created when certain patterns are found in the text. This link is called Automatic
Link ( http://www.stack.nl/~dimitri/doxygen/manual/autolink.html .)
* HTML tags that are in the documentation are interpreted. More information could be found in
http://www.stack.nl/~dimitri/doxygen/manual/htmlcmds.html .
The following doxygen documenting commands are used in comment blocks for C-like languages(C, C++,
C#, Objective-C, PHP, Java).
Special Command
A special documentation block is a C or C++ style comment block with some additional markings, so
doxygen knows it is a piece of documentation that needs to end up in the generated documentation.
For each code item there are two (or in some cases three) types of descriptions, which together form the
documentation: a brief description and detailed description, both are optional.
For methods and functions there is also a third type of description, the so called ”in body” description,
which consists of the concatenation of all comment blocks found within the body of the method or
function.
Having more than one brief or detailed description is allowed (but NOT recommended, as the order in
which the descriptions will appear is not specified).
As the name suggest, a brief description is a short one-liner, whereas the detailed description provides
longer, more detailed documentation. An ”in body” description can also act as a detailed description or
can describe a collection of implementation details. For the HTML output brief descriptions are also use
to provide tooltips at places where an item is referenced.
There are several ways to mark a comment block as a detailed description:
<1> JavaDoc style
/**
* ... text ...
*/

<2> Qt style(e.g. Qdoc, )
In both cases the intermediate * (asterisk)’s are optional, so below example is also valid.
<3> A block of at least two C++ comment lines, where each line starts with an additional slash or an
exclamation mark.
or
<4> To make their comment blocks more visible in the documentation.
(note the 2 slashes to end the normal comment block and start a special comment block)
or
For the brief description there are also several possibilities:
<1> One could use the brief command with one of the above comment blocks. This command ends at
the end of a paragraph, so the detailed description follows after an empty line.
<2> If JAVADOC_AUTOBRIEF is set to YES in the configuration file, then using JavaDoc style
comment blocks will automatically start a brief description which ends at the first dot followed by a
/*!
* ... text ...
*/
/*!
... text ...
*/
///
/// ... text ...
///
//!
//! ... text ...
//!
/********************************************//**
* ... text
***********************************************/
/////////////////////////////////////////////////
/// ... text ...
/////////////////////////////////////////////////
/*! brief Brief description.
* Brief description continued.
*
* Detailed description starts here.
*/

space or new line.
The option has the same effect for multi-line special C++ comments:
<3> To use a special C++ style comment which does not span more than one line.
or
(Note the blank line in the last example, which is required to separate the brief description from the
block containing the detailed description. The JAVADOC_AUTOBRIEF should also be set to NO
for this case.)
If you have multiple detailed descriptions (as below example), they will be joined. Note that this is also the
case if the descriptions are at different places in the code! In this case the order will depend on the order in
which doxygen parses the code.
Furthermore, if there is one brief description before a declaration and one before a definition of a code
item, only the one before the declaration will be used. If the same situation occurs for a detailed
description, the one before the definition is preferred and the one before the declaration will be ignored.
Unlike most other documentation systems, doxygen also allows you to put the documentation of members
(including global functions) in front of the definition. This way the documentation can be placed in the
source file instead of the header file. This keeps the header file compact, and allows the implementer of the
members more direct access to the documentation.
/** Brief description which ends at this dot. Details follow
* here.
*/
/// Brief description which ends at this dot. Details follow
/// here.
/// Brief description.
/** Detailed description. */
//! Brief descripion.
//! Detailed description
//! starts here.
//! Brief description, which is
//! really a detailed description since it spans multiple lines.
/*! Another detailed description!
*/

Putting documentation after members
If you want to document the members of a file, struct, union, class, or enum, it is sometimes desired to
place the documentation block after the member instead of before. For this purpose you have to put an
additional < marker in the comment block. Note that this also works for the parameters of a function.
(This block can be used to put a Qt style detailed documentation block after a member.)
or
or
or
Most often one only wants to put a brief description after a member. This is done as follows:
or
For functions one can use the @param command to document the parameters and then use [in], [out],
[in,out] to document the direction. For inline documentation this is also possible by starting with the
direction attribute, e.g.
Note that these blocks have the same structure and meaning as the special comment blocks, only the <
indicates that the member is located in front of the block instead of after the block.
[Warning]
These blocks can only be used to document members and parameters. They cannot be used to document
files, classes, unions, structs, groups, namespaces and enums themselves. Furthermore, the structural
commands are NOT allowed inside these comment blocks.
int var; /*!< Detailed description after the member */
int var; /**< Detailed description after the member */
int var; //!< Detailed description after the member
//!<
int var; ///< Detailed description after the member
///<
int var; //!< Brief description after the member
int var; ///< Brief description after the member
void foo(int v /**< [in] docs for input parameter v. */);

An example of C++ code using the Qt style:
The one-line comments contain a brief description, whereas the multi-line comment blocks contain a more
detailed description.
The brief descriptions are included in the member overview of a struct, class, namespace or file and are
printed using a small italic font (this description can be hidden by setting BRIEF_MEMBER_DESC to
NO in the configuration file).
By default the brief descriptions become the first sentence of the detailed descriptions (but this can be
changed by setting the REPEAT_BRIEF tag to NO). Both the brief and the detailed descriptions are
optional for the Qt style.
By default a JavaDoc style documentation block behaves the same way as a Qt style documentation block.
This is not according the JavaDoc specification however, where the first sentence of the documentation
//! A test class.
/*!
A more elaborate class description.
*/
class Test
{
public:
//! An enum.
/*! More detailed enum description. */
enum TEnum {
TVal1, /*!< Enum value TVal1. */
TVal2, /*!< Enum value TVal2. */
TVal3 /*!< Enum value TVal3. */
}
//! Enum pointer.
/*! Details. */
*enumPtr,
//! Enum variable.
/*! Details. */
enumVar;
.....................................................
//! A function variable.
/*!
Details.
*/
int (*handler)(int a,int b);
};

block is automatically treated as a brief description. To enable this behavior you should set
JAVADOC_AUTOBRIEF to YES in the configuration file. If you enable this option and want to put a dot
in the middle of a sentence without ending it, you should put a backslash and a space after it as below
example.
Here is the same piece of code as shown above, this time documented using the JavaDoc style and
JAVADOC_AUTOBRIEF set to YES:
Similarly, to set QT_AUTOBRIEF to YES in the configuration file to take the first sentence of a Qt style
documentation block to automatically be treated as a brief description.
Documentation at other places
In above examples the comment blocks were always located in front of the declaration or definition of a
file, class or namespace or in front or after one of its members. Although this is often comfortable, there
may sometimes be reasons to put the documentation somewhere else.
/** Brief description (e.g. using only a few words). Details follow. */
/**
* A test class. A more elaborate class description.
*/
class Test
{
public:
/**
* An enum.
* More detailed enum description.
*/
enum TEnum {
TVal1, /**< enum value TVal1. */
TVal2, /**< enum value TVal2. */
TVal3 /**< enum value TVal3. */
}
*enumPtr, /**< enum pointer. Details. */
enumVar; /**< enum variable. Details. */
.....................................................
/**
* a function variable.
* Details.
*/
int (*handler)(int a,int b);
};

Doxygen allows you to put your documentation blocks practically anywhere (the exception is inside the
body of a function or inside a normal C style comment block).
The price you pay for not putting the documentation block directly before (or after) an item is the need to
put a structural command inside the documentation block, which leads to some duplication of information.
So in practice you should avoid the use of structural commands unless other requirements force you to do
so.
Structural commands (like all other commands) start with a backslash (), or an at-sign (@) if you prefer
JavaDoc style, followed by a command name and one or more parameters. The below example is for
class Test using command “class”:
Below list shows some structural commands:
FileFileFileFile ((((HeaderHeaderHeaderHeader //// SourceSourceSourceSource)))) comments
filefilefilefile Source code file name with extension file name.
datedatedatedate Date
authorauthorauthorauthor Author of this program
versionversionversionversion Program version
b Change_Historyb Change_Historyb Change_Historyb Change_History Date and contents of changing or modifying
MacroMacroMacroMacro comments
defdefdefdef To document a #def#def#def#defineineineine.
FucntionFucntionFucntionFucntion comment
fnfnfnfn to document a function.
param[in]param[in]param[in]param[in] InputInputInputInput parameter
Format: VariableName + Space + Description
param[param[param[param[outoutoutout]]]] OutputOutputOutputOutput parameter
Format: VariableName + Space + Description
returnreturnreturnreturn Function return value.
NamespaceNamespaceNamespaceNamespace comment
namesnamesnamesnamespacepacepacepace To document a namespace.
ClassClassClassClass comment
classclassclassclass To document a class.
InterfaceInterfaceInterfaceInterface comment
interfaceinterfaceinterfaceinterface To document an IDLIDLIDLIDL interface.
NoteNoteNoteNote: InterfaceInterfaceInterfaceInterfaces in C++C++C++C++ are implemented using Abstract ClassAbstract ClassAbstract ClassAbstract Class.
EnumEnumEnumEnum comment
/*! class Test
brief A test class.
A more detailed class description.
*/

enumenumenumenum To document an enumeration type.
StStStStuctuctuctuct comment
structstructstructstruct To document a C-struct.
UnionUnionUnionUnion comment
unionunionunionunion To document a union.
PackagePackagePackagePackage comment
packagepackagepackagepackage To document a Java package.
OtherOtherOtherOther comment
varvarvarvar To document a variablevariablevariablevariable or typedeftypedeftypedeftypedef or enumenumenumenum value.
briefbriefbriefbrief Shore description.
nnnn New line
cccc Convert font type.
More information about structural commands could be found in the page:
http://www.stack.nl/~dimitri/doxygen/manual/commands.html
Note:
1) To document a member of a C++ class, you must also document the class itself. The same holds for
namespaces.
2) To document a global C function, variable, typedef, enum or preprocessor definition you must first
document the file that contains it (usually this will be a header file, because that file contains the
information that is exported to other source files). Using a comment block containing a file or @file
command to document the file in which those commands are located.
or
3) Alternatively, you can put all members in a group (or module) using the ingroup command and then
document the group using a comment block containing the defgroup command. For member
functions or functions that are part of a namespace you should document either the class or
namespace.
Generate Diagrams/Graphs
Doxygen can use the "dot" tool from GraphViz (Graph Visualization Software) to generate more
advanced diagrams and graphs. GraphViz is an open-source, cross-platform graph drawing toolkit and can
be found at http://www.graphviz.org/
To install GraphViz tool, run below commands in two Linux distro separately:
Ubuntu
sudo apt-get -y install graphviz
/*! file */
/* * @file */

The below screenshot shows installed graphviz tool in Synaptic Package Manager program.
CentOS 6
$ su
# yum -y install graphviz
(prompt $ is for Regular user and prompt # is for Super user)
To view details about GraphViz package, run command:
# rpminfo graphviz

If you have the "dot" tool in the path, you can set tag HAVE_DOT to YES in the configuration file to let
doxygen use it.

Icon-Chooser Internals
In this program, it uses GtkIconView widget as the main component to list icons under a designated
directory.
This program uses GtkEntry widget for user to enter the full path to a folder containing icons wanted to be
shown.
When the text entry has new text input (either by hand-typing or file chooser), it will send out “changed”
signal and the programmer could connect a callback function to this signal for further process.
In Icon Chooser program, it is used to indicate that it is time to refresh/update list model(store) of the icon
view. After the list model is updated, it calls the function gtk_icon_view_set_model() to update icon view’s
model with the updated one.
Icon Chooser applies GNU gettext on 1)the main dialog/window title, 2)the title of file chooser dialog, 3)the
label on the button and 4)the labels indicating the number of icons. Below screenshots show the result.

In Icon Chooser program, the special mark used in comment blocks for Doxygen document generation is Qt
style.
or
The doxygen configuration files are in the “doxygen“ folder under Icon Chooser program source root. There
are two configuration files, one for generating documents with graphs (this needs graphivz tool to be
installed) and the other is for the document without graphs. By running command “doxygen Conf-File” to
generate documents.
If it succeeds to generate documents, it will have a folder named “html“ in the doxygen folder.
/*!
* ... text ...
*/
/*!
... text ...
*/

The main Web page of the generated HTML document is “index.html”.
The below figures show screenshots of Icon Chooser program HTML documents generated by doxygen.

(If you want to let the document include your source codes for browsing, remember to set the variable
“SOURCE_BROWSER” to YES in the doxygen configuration file.)

Resources
GTK+ 2.0
# https://developer.gnome.org/gtk2/stable/
# http://www.dgsiegel.net/files/tog2dg.pdf The Official GNOME 2 Developer's Guide
# http://www.yolinux.com/TUTORIALS/GTK+ProgrammingTips.html
# http://www.zetcode.com/tutorials/gtktutorial/
# http://www.zetcode.com/tutorials/gtktutorial/chinese/ 中文中文中文中文
# http://tetralet.luna.com.tw/index.php?op=ViewArticle&articleId=188&blogId=1 中文中文中文中文
# http://pcman.sayya.org/tnlug-2006.02.18/tnlug.pdf Introducing GTK+ by PCMan (洪任諭洪任諭洪任諭洪任諭)
# http://www.gtkbook.com/
# http://book.huihoo.com/gtk+-gnome-application-development/
GTK+ 2.0 Tree View
# https://developer.gnome.org/gtk2/stable/TreeWidgetObjects.html
# http://scentric.net/tutorial/treeview-tutorial.html
# http://scentric.net/tutorial/treeview-tutorial.pdf
# http://scentric.net/tutorial/treeview-tutorial.tar.gz Example code for Treeview tutorial
# http://chingyichan.tw.googlepages.com/gtk_tree_view_tutorial.html 中文中文中文中文
# http://www.zetcode.com/tutorials/gtktutorial/gtktreeview/
# http://www.zetcode.com/tutorials/gtktutorial/chinese/gtktreeview/ 中文中文中文中文
# http://inti.sourceforge.net/tutorial/libinti/treeandlistwidget.html
# http://en.wikibooks.org/wiki/GTK%2B_By_Example/Tree_View
GNU gettext (i18n)
# https://www.gnu.org/software/gettext/
# http://fedoraproject.org/wiki/How_to_do_I18N_through_gettext GNU gettext tutorial with example
# http://nkumar.fedorapeople.org/helloi18n GNU gettext example
# http://people.linux.org.tw/~pofeng/free-doc/linuxi18n/gtk.html Internationalize Gtk+ programs

GTK+ 2.0 App - Icon Chooser

Recommended

More Related Content

What's hot (14)

Similar to GTK+ 2.0 App - Icon Chooser (20)

More from William Lee (20)

Recently uploaded (20)

GTK+ 2.0 App - Icon Chooser