The CentOS Artwork Repository is supported by Subversion
(@url{http://subversion.tigris.org/}), a version control system which
allows you to keep old versions of files and directories (usually
source code), keep a log of who, when, and why changes occurred, etc.,
like CVS, RCS or SCCS.  When using Subversion there is one source
repository and many working copies of that source repository. The
working copies are independent one another, can be distributed all
around the world and provide a local place for designers, documentors,
translators and programmers to perform their works in a descentralized
way.  The source repository, on the other hand, provides a central
place for all independent working copies to interchange data and the
information required to permit extracting previous versions of files
at any time.

@subsection Repository policy

The CentOS Artwork Repository is a collaborative tool that anyone can
have access to. However, changing that tool in any form is something
that should be requested in @email{centos-devel@@centos.org} mailing
list.  Generally, people download working copies from CentOS Artwork
Repository, study the repository organization, make some changes in
their working copies, make some tests to verify such changes work the
way expected and request access to commit them up to the CentOS
Artwork Repository for others to benefit from them.

Once you've received access to commit your changes, there is no need
for you to request permission again to commit other changes from your
working copy to CentOS Artwork Repository as long as you behave as a
@emph{good community citizen}.

As a good community citizen one understand of a person whom respects
the work already done for others and share ideas with authors before
changing relevant parts of their work, specially in situations when
the access required to realize those changes has been granted already.
Of course, there is a time when conversation has taken place, the
paths has been traced and changing the work is so obvious that there
is no need to talk about it; that's because you already did, you
already built the trust to keep going. Anyway, the mailing list
mentioned above is available for sharing ideas in a way that good
relationship between community citizens could be constantly balanced.

The relationship between community citizens is monitored by repository
administrators. Repository administrators are responsible of granting
everything goes the way it needs to go in order for the CentOS Artwork
Repository to comply its mission which is: to provide a colaborative
tool for The CentOS Community where The CentOS Project Corporate
Identity is built and maintained from The CentOS Community itself.

It is also important to remember that all source files inside CentOS
Artwork Repository should comply the terms of GNU General Public
License in order for them to remain inside the repository. See file
@url{file:///home/centos/artwork/trunk/Scripts/COPYING,trunk/Scripts/COPYING},
for a complete license description.

@subsection Repository organization 

The CentOS Artwork Repository uses a @file{trunk}, @file{branches},
and @file{tags} organization.  

@table @file
@item trunk

The @file{trunk} directory organizes the main development line of
CentOS Artwork Repository. @xref{Directories trunk}, for more
information.

@item branches

The @file{branches} directory oranizes intermedaite development lines
taken from the main development line.  @xref{Directories branches},
for more information.

@item tags

The @file{tags} directory organizes frozen development lines taken
from the main or the intermediate lines of development.
@xref{Directories tags}, for more information.
@end table

@subsection Repository file names

For name concistency in CentOS Artwork Repository, file names are all
written in lowercase (@samp{01-welcome.png}, @samp{splash.png},
@samp{anaconda_header.png}, etc.) and directory names are all written
capitalized (e.g., @samp{Identity}, @samp{Themes}, @samp{Motifs},
@samp{TreeFlower}, etc.).

@subsection Repository work lines

Inside CentOS Artwork Repository there are four major production work
lines which are: @emph{graphic design}, @emph{documentation},
@emph{localization} and @emph{automation}.  These work lines describe
different areas of content production. Content production inside these
specific areas may vary as much as persons be working on them.
Producing content in too many different ways may result innapropriate
in a collaborative environment like CentOS Artwork Repository where
content produced in one area depends somehow from content produced in
another different area. To produce content in a syncronized but
descentralized way, it is required to define a @emph{content
production standard} that lead everyone work in order for the content
produced in each different work line to gear correctly once it is put
together.

The standard way of producing content inside CentOS Artwork Repository
is implemented through @command{centos-art.sh} script and described in
@file{trunk/Scripts} documentation entry (@pxref{Directories trunk
Scripts}).


@subsubsection Graphic design

The graphic design work line exists to cover brand design, typography
design and theme design. Additionally, some auxiliar areas like icon
design, illustration design for documentation, brushes design,
patterns designs and definition of palettes of colors could be
included here for completeness.

Inside CentOS Artwork Repository graphic design is performed through
Inkscape (@url{http://www.inkscape.org/}) and GIMP
(@url{http://www.gimp.org/}).  Inkscape is used to create and
manipulate scalable vector graphics and export them to PNG format; it
also provides a command-line interface that we use to perform massive
exportation from SVG files to PNG files through automation scripts. On
the other hand, GIMP is used to create and manipulate rastered images,
create brushes, patterns and palettes of colors.  

@quotation
@strong{Tip} You can combine both Inkscape and GIMP specific
functionalities and possibilities to produce very beautiful images.
@end quotation

Another area covered by graphic design is that related to visual
manifestations The CentOS Project Corporate Identity is made of.
Visual manifestations implement the corporate identity concepts by
mean of images placed in key areas of their visual space.  To produce
these images, we've decomposed image production in @emph{design
models} and @emph{artistic motifs}. 

Design models provide the structural information of images (i.e.,
dimension, position of common elements, translation markers, etc.) and
they are generally produced as scalable vector graphics to take
advantage of the inclusion feature supported by that standard which
let us load different background images for the same design model
changing path information. On the other hand, artistic motifs provide
the visual style (i.e., the background information, the look and feel)
and are generally produced as rastered images.  

Design models are created for each visual manifestation the CentOS
Project is made of. This way it is possible to describe the visual
manifestation and provide a template system for it.  

Artistic motifs are created with design models in mind, not the visual
manifestation those design models are built for.

The result produced by combining one design model with one artistic
motif is what we know as a @emph{theme}. Inside themes directory
structure (@pxref{Directories trunk Identity Themes}), you can find
several design models and several artistic motifs, apart one another,
that can be albitrarily combined one another through @emph{theme
rendition}, a flexible way to produce images for different visual
manifestations inside CentOS Artwork Repository. Inside themes
directory structure, theme rendition is performed in
@file{trunk/Identity/Themes/Motifs} directory structures and required
design models are taken from @file{trunk/Identity/Themes/Models}
directory structure.

In addition to theme rendition you can find @emph{direct rendition},
another way of image production where there is no artistic motif at
all but design models only. Direct rendition is very useful to produce
simple content that doesn't need specific background information like
brands, icons and illustrations.  Direct rendition takes place in
@file{trunk/Identity/Images} and the required design models are taken
from @file{trunk/Identity/Models} directory structure.

@xref{Directories trunk Identity}, for more information on graphic
design.

@subsubsection Documentation

The documentation work line exists to describe what each directory
inside the CentOS Artwork Repository is for and how to produce content
inside them.

The CentOS Artwork Repository documentation is supported by Texinfo, a
documentation system that uses a single source file to produce both
online information and printed output. The repository documentation is
organized under @file{trunk/Manual} directory structure using
repository directories as reference. Directories inside CentOS Artwork
Repository are created based on conceptual idea, so one documentation
entry exists for each directory inside the repository in order to
describe the conceptual ideas such directory is based on.

Directory documentation entries are stored under
@file{trunk/Manual/Directories} directory structure and controlled by
the @code{help} functionality of @command{centos-art.sh} script.
Using the @code{help} functionality you can create, edit and remove
directory documentation in a way you don't need to take care of
updating menus, nodes and cross reference information inside the
manual structure; the functionality takes care of it for you.
However, if you need to write repository documentation that have
nothing to do with repository directories (e.g., Preface, Introduction
and similar) you need to do it manually, there is no functionality to
automate such process yet.

@xref{Directories trunk Manual}, for more information on
documentation.

@subsubsection Localization

The localization work line exists to provide the translation messages
required to produce content in different languages. Among these
contents are: image files, documentation and automation scripts.

Most of localization tasks have been grouped inside the @code{locale}
functionality of @command{centos-art.sh} script which make use of
@command{gettext} and @command{xml2po} programs.

The procedure used to localize content is taken from @command{gettext}
standard specification. Basically, translatable strings are retrived
from source files in order to create Portable Objects and Machine
Objects.  Portable Objects are editable files that contain the
information used by translators to do their work. On the other hand,
Machine Objects are produced to be machine-redable, as its name
implies, and are produced from Portable Objects.

Since @command{gettext} needs to extract translatable strings form
source files in order to let translators to localize them, the type of
source files we can use inside the repository is limitted to the file
types supported by @command{gettext} program. Most of the source files
supported by @command{gettext} are those of programming languages like
C, C++, Bash, Python and Perl just to mention a few ones from the long
list of supported formats. However, formats like SVG, XHTML and
Docbook don't figure as supported in the long list of
@command{gettext} supported source files. 

To translate XML based source files like SVG, XHTML and Docbook we use
the @command{xml2po} program instead. This program comes with
@file{gnome-doc-utils} package and reads one XML based file to extract
translatable strings from it. As result it creates one Portable Object
that is used by @command{xml2po} itself to create the translated XML
based file with the same definition of the source file where
translatable strings were taken from (e.g., if we extract translatable
strings from a SVG file, as result we get the same SVG file but with
translatable strings already localized ---obviously, for this to
happen translators need to localize translatable strings inside the
Portable Object first, localization won't appear as art of magic---).
When using @command{xml2po}, the Machine Object file is used just
temporally to produce the final translated XML based file.

@quotation
@strong{Tip} If you want to have your content localized inside CentOS
Artwork Repository be sure to use source files supported either by
@command{gettext} or @command{xml2po} programs.
@end quotation

@xref{Directories trunk Locales}, for more information.

@subsubsection Automation

The automation work line exists to standardize content production
inside CentOS Artwork Repository. There is no need to type several
tasks time after time if they can be programmed into just one script
that groups them all.  

The automation work line takes place under @file{trunk/Scripts}
directory structure. Here is developed the @command{centos-art.sh}
script, a bash script specially designed to automate most frequent
tasks inside CentOS Artwork Repository. Basically, the
@command{centos-art.sh} script is divided in several functionalities
that perform specific tasks inside the repository. Such
functionalities relay on repository organization to work as expected. 

@quotation
@strong{Tip} If you need to improve the way content is produced, look
inside automation scripts and make your improvement there for everyone
to benefit.
@end quotation

@xref{Directories trunk Scripts}, for more information on automation.

@subsection Connection between directories

In order to produce content correctly inside CentOS Artwork
Repository, it is required that all work lines be connected somehow.
This is the way automation scripts can know what design model and what
translation files to use when specific contents are produced, also
where to save the content produced as result.  This connection between
directories takes place through two path constructions named @emph{The
Master Paths} and @emph{The Auxiliar Paths}.

The master paths point to directories which contain the source files
(e.g., SVG files) required to produce base content (e.g., PNG files).
Each master path inside the repository has several auxiliar paths
associated. 

The auxiliar paths can point either to directories or files. When an
auxiliar path points to a directory, that directory contains
information that modifies somehow the content produced from the master
path (e.g., through translation messages) or provides the output
information of where to store the content produced from master path.
When an auxiliar path points to a file, that file has no other purpose
but document the master path it refers to.

The relation between auxiliar paths and master paths is realized
taking one unique master path as reference.  Master paths define how
auxiliar paths are constructed.  Master paths can have several
auxiliar paths associated, but auxiliar paths can have only one master
path associated.  For example, consider the following path relation
and note how there are constant and variable values in them:

@table @file
@item trunk/Identity/Models/Brands

This directory contains source files (e.g., SVG, XCF, etc.) used to
produce the brand images of The CentOS Project.

Here is where you, as graphic designers, define design models used to
produce the brand images of The CentOS Project.

The path to this directory is considered a master path because it
contains the most critical information (i.e., the information that
can't be absent) required to produce the brand images of The CentOS
Project.

@item trunk/Manual/Directories/trunk/Identity/Models/Brands.texi

This file contains documentation, in Texinfo format, for design models
used to produce the brand images of The CentOS Project. The path to
this file is made of three parts:

@verbatim
            A                         B                C
|-----------------------|----------------------------|---|
trunk/Manual/Directories/trunk/Identity/Models/Brands.texi
|-----------------------|----------------------------|---|

A = The documentation manual source location.
B = The master path we are building documentation for.
C = The file extension used by Texinfo documentation files.
@end verbatim

Here is where you, as documentor, describe construction of desing
models used to produce the brand images of The CentOS Project. In this
description you can include image dimensions, color information, image
location inside CentOS Distribution filesystem, packaging and similar
things.

The path to this directory is considered auxiliar path of
@file{trunk/Identity/Models/Brands} master path.

@item trunk/Locales/Identity/Models/Brands

This directory contains translation files, as @command{gettext}
portable objects, for design models used to produce the brand images
of The CentOS Project. The path to this directory made of two parts: 

@verbatim
      A                 B
|------------|---------------------|
trunk/Locales/Identity/Models/Brands
|------------|---------------------|

A = The translation messages source location.
B = The master path we are building translation messages for.
@end verbatim

Here is where you, as translator, localize translatable strings
retrived in English language from design models used to produce the
brand images of The CentOS Project. If no portable object is found
here the translation tasks are skipped to produce no translation at
all, obviously there is no portable object to retrive translation
messages from.

The path to this directory is considered auxiliar path of
@file{trunk/Identity/Models/Brands} master path.

@item trunk/Manual/Directories/trunk/Locales/Identity/Models/Brands.texi

This file contains documentation, in Texinfo format, for translation
messages retrived from design models used to produce brand images
required by The CentOS Project. The path to this file is made of three
parts:

@verbatim
            A                              B                   C
|-----------------------|------------------------------------|---|
trunk/Manual/Directories/trunk/Locales/Identity/Models/Brands.texi
|-----------------------|------------------------------------|---|

A = The documentation manual source location.
B = The master path we are building documentation for.
C = The file extension used by Texinfo documentation files.
@end verbatim

Here is where you, as documentor, describe localization of those
desing models used to produce brand images required by The CentOS
Project. In this description you can include image dimensions, color
information, image location inside the file system of CentOS
Distribution, packaging and similar things.

The path to this file is considered auxiliar path of
@file{trunk/Identity/Models/Brands} master path.

@item trunk/Identity/Images/Brands

This directory contains the final brand images produced from brand
design models used by The CentOS Project.

Here is where you, as packager, can find the brand images you need to
rebrand the CentOS Distribution.

The path to this directory is considered auxiliar path of
@file{trunk/Identity/Models/Brands} master path.

@item trunk/Manual/Directories/trunk/Identity/Images/Brands.texi

This file should contains documentation, in Texinfo format, about how
to implement final brand images of The CentOS Project.  However, this
documentation entry is rarely used because the related design model
documentation entry already covers implementation of brand images.
The only reason to create this documentation entry is to put in an
admonition that redirect people up to the correct place (i.e., the
related design model coumentation entry).
@end table

The configuration described above for organizing brand component
inside the repository is the one used by direct rendition and can be
used as reference to organize other components inside the repository
that are produced through direct rendition too. Just change the
component name from @file{Brands} to a different one without changing
the path structure around it.

The file organization used by theme rendition, however, is a bit
different from that used by direct rendition. In theme rendition, both
the master paths and the auxiliar paths are built dynamically based on
one design model and one artistic motif specified by you at rendition
time.  As a mnemotechnic resource, you could consider theme rendition
as two independent lists, one of design models and one of artistic
motifs, which are arbitrary combined between themselves in order to
render images in specific ways. For example, consider the organization
used to produce Anaconda images; for CentOS distribution major release
5; using @file{Default} design models and version @file{3} of
@file{Flame} artistic motif:

@table @file
@item trunk/Identity/Themes/Models/Default/Distro/5/Anaconda

This directory contains source files used to produce Anaconda images
for CentOS distribution major release 5. This specific information has
been named the @file{Default} design model. The path to this directory
is made of three parts:

@verbatim
              A                 B           C
|---------------------------|-------|----------------|
trunk/Identity/Themes/Models/Default/Distro/5/Anaconda
|---------------------------|-------|----------------|

A = The theme model source location.
B = The theme model name.
C = The visual manifestation the theme model is created for.
@end verbatim

Here is where you, as graphic designers, define @file{Default} design
models for Anaconda images in major release 5 of CentOS distribution. 

The path to this directory is considered the master path because it
contains the most critical information (i.e., the information that
can't be absent) required to produce Anaconda images for major release
5 of CentOS distribution.

@item trunk/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/5/Anaconda.texi

This file contains documentation, in Texinfo format, for
@file{Default} design models used to produce the Anaconda images
required by major release 5 of CentOS distribution. 

@verbatim
             A                                     B                             C
|-----------------------|------------------------------------------------------|---|
trunk/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/5/Anaconda.texi
|-----------------------|------------------------------------------------------|---|

A = The documentation manual source location.
B = The master path we are building documentation for.
C = The file extension used by Texinfo documentation files.
@end verbatim

Here is where you, as documentor, describe construction of
@file{Default} design models used to produce the Anaconda images
required by major release 5 of CentOS distribution. In this
description you can include image dimensions, color information, image
location inside the file system of CentOS distribution, packaging and
similar things.

The path to this directory is considered auxiliar path of
@file{trunk/Identity/Themes/Models/Default/Distro/5/Anaconda} master path.

@item trunk/Locales/Identity/Themes/Models/Default/Distro/5/Anaconda

This directory contains translation files, as @command{gettext}
portable objects, for Default design models used to produce the
Anaconda images used inside CentOS distribution major release 5. 

Here is where you, as translator, localize translatable strings
retrived in English language from Default design models used to
produce the Anaconda images of CentOS distribution major release 5 to
your own language. If no portable object is found here, content is
produced in English language.

The path to this directory is considered auxiliar to
@file{trunk/Identity/Themes/Models/Default/Distro/5/Anaconda} master
path because provides the language-specific information required to
produce Anaconda Default design models in different languages.

@item trunk/Manual/Directories/trunk/Locales/Identity/Themes/Models/Default/Distro/5/Anaconda.texi

This file contains documentation, in Texinfo format, for translation
messages retrived from Default design models used to produce the
Anaconda images used inside CentOS distribution major release 5. 

Here is where you, as documentor, describe localization of Default
desing models used to produce the Anaconda images used in CentOS
distribution major release 5. In this description you can include
image dimensions, color information, image location inside
distribution filesystem, packaging and similar things.

The path to this file is considered auxiliar to
@file{trunk/Identity/Themes/Models/Default/Distro/5/Anaconda} master
path because provides the language-specific information required to
produce Anaconda Default design models in different languages.

Each master path has its own auxiliar path to store their specific
documentation and whatever the artistic motifs used to produce images
be is somthing irrelevant.

@item trunk/Identity/Themes/Motifs/Flame/3/Distro/5/Anaconda

This directory contains Anaconda final images produced from Anaconda
Default design models used by CentOS distribution major release 5 and
Flame 3 artistic motif. 

Here is where you, as packager, can find the images you need to
rebrand Anaconda in CentOS distribution major release 5.

The path to this directory is considered auxiliar to
@file{trunk/Identity/Themes/Models/Default/Distro/5/Anaconda} master
path because it provides the final images produced from Anaconda
Default design models.

@item trunk/Manual/Directories/trunk/Identity/Themes/Motifs/Flame/3/Distro/5/Anaconda.texi

This directory should contain documentation about how to implement
Anaconda component in CentOS distribution major release 5 would be.
However, since all artistic motifs are produced based on one design
model (@file{trunk/Identity/Themes/Models/Default/Distro/5/Anaconda},
in this case) we may end up duplicating the same documentation in all
artistic motifs documentation entries and there is no need of that.

To avoid duplicating information, all documentation related to theme
components like Anaconda is put in design model documentation entires
(@file{trunk/Manual/Directories/trunk/Locales/Identity/Themes/Models/Default/Distro/5/Anaconda.texi}
in this case).  The only reason to create documentation entries inside
artistic motifs is to put a redirection admonition to link design
model related information.
@end table

The Anaconda component is part of CentOS Distribution visual
manifestation. Inside CentOS Distribution visual manifestation there
are other components Syslinux, Grub, Rhgb, Gdm, Kdm, Gsplash and
Ksplash that share a similar file organization to that described for
Anaconda component. The way each of these components is produced is
described in their own documentation entry.

When one master path is changed, it is required to change the related
auxiliar path related to it, too. This is required in order for master
paths to retain their relation with their auxiliar paths. This way,
automation script are able to know where to retrive translation
messages, where to store final output images and where to look for
documentation. If relation between master paths and auxiliar paths is
lost, there is no way for automation scripts to know where to retrive
the information required by for task automation.

The auxiliar paths should never be modified under no reason but to
satisfy the relation to their master paths.  Liberal change of
auxiliar paths may suppress the conceptual idea they were initially
created for; and certainly, things may stop working the way they
should.

@subsection Syncronizing path information

The master and auxiliar paths concept is very useful to keep
repository organized but introduce some complications.  For instance,
consider what would happen to functionalities like @code{help}, that
rely on master paths to create documentation entries, through auxiliar
paths, if one of those master paths suddenly change after the
documentation entry has been already created for it?

In such cases, functionalities like @code{help} may confuse themselves
if path information is not updated to reflect the appropriate path
relation.  Such functionalities work with master paths as reference;
if a master path is changed, the functionalities won't even note it
because they work with the last master path available in the
repository, no matter what it is. 

In the specific case of documentation (the @code{help} functionality),
the problem mentioned above provokes that older master paths, already
documented, remain inside documentation directory structures as long
as you get your hands into the documentation directory structure
(@file{trunk/Manual}) and change what must be changed to match the new
master path information.

There is no immediate way for @code{help} and similar functionalities
that use master paths as reference, to know when and how the path
information is changed inside the repository. Such information is
available only when files or directories are moved in the repository.
So, is there, at the moment of moving files, when we need to
syncronize paths information between master paths and auxiliar paths
and rename old paths to new paths inside all the files which includes
them (e.g., scalalble vector graphics, documentation files and
translation files files) and commit everything to keep the central
repository up to date.

@quotation
@strong{Warning} Even Subversion can perform some operations using
URLs, there is not support for URLs inside @command{centos-art.sh}
script.  The @command{centos-art.sh} script is designed to work with
local files inside the working copy only. If you need to work on URLs
directly, use Subversion command-line interface instead of
@command{centos-art.sh} script. 
@end quotation

File movement inside the repository is considered a repository change
and it should be recorded as such. In order for this to happen, we
need to add directories and files into the version control system to
make them part of it, commit them, perform the file movement using
version control system commands and finally commit all files related
in the operation. This configuration makes possible for everyone to
know about changes details inside the repository; and if needed,
revert or update them back to a previous revision.

Once all path information has been updated in the filesystem, it is
time to update path information inside all the files involved in the
operation. Considere what would happen to documentation entries
defined in the documentation manual when the target locations they
point to are removed from filesystem. Certainly, that would make
Texinfo to produce an error message when documentation manual is
exported to output files. Something similar could happen to scalable
vector graphics that include artistic motifs background images and
translation messages with path information inside.

So, in order to keep path information syncronized, the
@file{centos-art.sh} script needs to know when such changes happen, in
a way they could be noted and handled without producing errors (e.g.,
replacing old path information to new path information inside all the
files that may include any kind of path information inside).

@subsection Extending repository organization

Occasionly, you may find that new corporate visual identity components
need to be added to the repository. If that is your case, the first
question you need to ask yourself, before start to create directories
blindly all over, is: What is the right place to store it?

The best place to find answers is in The CentOS Community (see page
@url{http://wiki.centos.org/GettingHelp}), but going there with hands
empty is not good idea. It may give the impression you don't really
care about. Instead, consider the following suggestions to find your
own comprehension in order to make your own propositions based on it.

The best advice we probably could offer you, when extending
respository structure, is to bear in mind The CentOS Project Corporate
Identity Structure (@pxref{Directories trunk Identity}). The rest is
just matter of choosing appropriate names.  

To illustrate this desition process let's consider the
@file{trunk/Identity/Themes/Motifs/TreeFlower} directory structure as
example.  It can be read as: the trunk development line of
@emph{TreeFlower} artistic motif; artistic motifs are part of themes;
and themes part of CentOS corporate visual identity.

When building parent directory structures, you may find that reaching
an acceptable location may take some time, and as it uses to happen
most of time; once you've find one, that may be not a definite
solution.  There are many concepts you need to play with, in order to
find a result that match the conceptual idea you try to implement in
the new directory structure. To know which these concepts are, split
directory structures and read their documentation entry from less
specific to more specific.  The concepts used in
@file{trunk/Identity/Themes/Distro/Motifs/TreeFlower} directory
structure are described in the following documentation entries,
respectively:

@verbatim
centos-art help --read turnk
centos-art help --read turnk/Identity
centos-art help --read turnk/Identity/Themes
centos-art help --read turnk/Identity/Themes/Motifs
centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower
@end verbatim

The @file{trunk/Identity/Themes/Motifs/TreeFlower} location has
evolved through several months of contant work and there is no certain
it won't change in the future, even it fixes quite well the concept we
are trying to implement.  Other location concepts can be found in the
same way described above, just change the directory structure to the
one you are trying to know concepts for.