diff --git a/Manual/Directories/branches.texi b/Manual/Directories/branches.texi index 6f5ab47..b4e8f8d 100755 --- a/Manual/Directories/branches.texi +++ b/Manual/Directories/branches.texi @@ -1,20 +1,20 @@ -@subsection Goals +@subheading Goals This directory implements the Subversion's branches concept in a trunk, branches, tags repository structure. -@subsection Description +@subheading Description The @file{branches/} directory structre provides the intermediate space for creating several instances of @file{trunk/} directory structure for parallel development and later merging changes back to @file{trunk/} in the same parallel basis. -@subsection Usage +@subheading Usage The @file{branches/} directory structure is unused, so far. -@subsection See also +@subheading See also @itemize @item @xref{Directories tags}. diff --git a/Manual/Directories/tags.texi b/Manual/Directories/tags.texi index 596aab6..a69c2e9 100755 --- a/Manual/Directories/tags.texi +++ b/Manual/Directories/tags.texi @@ -1,20 +1,20 @@ -@subsection Goals +@subheading Goals This directory implements the Subversion's tags concept in a trunk, branches, tags repository structure. -@subsection Description +@subheading Description The @file{tags/} directory structre provides frozen branches. Generally, we use frozen branches to make check-points in time for development lines under @file{branches/} or @file{trunk/} directory structure. -@subsection Usage +@subheading Usage The @file{tags/} directory structure is unused, so far. -@subsection See also +@subheading See also @itemize @item @xref{Directories branches}. diff --git a/Manual/Directories/trunk.texi b/Manual/Directories/trunk.texi index 0c91ec2..c6818d1 100644 --- a/Manual/Directories/trunk.texi +++ b/Manual/Directories/trunk.texi @@ -1,9 +1,9 @@ -@subsection Goals +@subheading Goals The @file{trunk/} directory structure implements the Subversion's trunk concept in a trunk, branches, tags repository structure. -@subsection Description +@subheading Description The @file{trunk/} directory structure is the main development line inside the CentOS Artwork Repository and organizes the following @@ -73,12 +73,12 @@ here. @xref{Directories trunk Scripts}, for more information. @end table -@subsection Usage +@subheading Usage It seems to be no other use for this directory but to organize the sections described above. -@subsection See also +@subheading See also @itemize @item @xref{Directories branches}. diff --git a/Manual/Directories/trunk/Identity.texi b/Manual/Directories/trunk/Identity.texi index 315f560..9570a55 100644 --- a/Manual/Directories/trunk/Identity.texi +++ b/Manual/Directories/trunk/Identity.texi @@ -1,13 +1,13 @@ -@subsection Goals +@subheading Goals The @file{trunk/Identity} describes what The CentOS Project Corporate Identity is and the components it is made of. -@subsection Description +@subheading Description The CentOS Project Corporate Identity is the ``persona'' of the organization known as The CentOS Project. The CentOS Project -Corporate Identity plays a significant role in the way the CentOS +Corporate Identity plays a significant role in the way The CentOS Project, as organization, presents itself to both internal and external stakeholders. In general terms, The CentOS Project Corporate Identity expresses the values and ambitions of The CentOS Project @@ -20,35 +20,42 @@ CentOS Project organization by means of @emph{Corporate Design}, @float Figure, The CentOS Project Corporate Identity @image{trunk/Identity/Images/Manual/Corporate/monolithic,450pt,,,jpg} -@caption{The CentOS Project - Corporate Identity.} +@caption{The CentOS Project Corporate Identity.} @end float -@subsubsection Corporate Mission +@subsubheading Corporate Mission The CentOS Project exists to provide The CentOS Distribution. Additionally, The CentOS Project provides The CentOS Web and The CentOS Showroom to support and promote the existence of The CentOS Distribution, respectively. -@subsubsection Corporate Design +@subsubheading Corporate Design -The CentOS Project Corporate Design is focused on the effective -communication of visual messages through graphic design. Visual -messages can be considered any information that people can perceive -through the visual sence (i.e., the human eye). The CentOS Project -Corporate Design is very tied to @emph{The CentOS Project Corporate -Structure} which, in turn, is based on @emph{The CentOS Project -Corporate Mission} and @emph{The CentOS Project Release Schema}. +Corporate design is focused on the effective communication of +corporate visual messages. Corporate visual messages are all the +information emitted by a corporation that can be perceived by the +people through their visual sence (i.e., the human eye). In order for +such visual communication to happen, it is required to put the visual +message on medium available for people to see. These kind of media +are know as corporate visual manifestations, since the corporate +manifests its existence through them using corporate design. -The CentOS Project Corporate Design is applied to The CentOS Project -Visual Manifestations. A visual manifestation is any medium, digital -or printed, used by The CentOS Project to communicate its existence -(e.g., @emph{The CentOS Distribution}, @emph{The CentOS Web} and -@emph{The CentOS Showroom}). +The amount of visual manifestations a corporation uses to communicate +its existence is very specific to each corporation itself. Inside The +CentOS Project Corporate Identity, considering @emph{The CentOS +Project Corporate Structure}, @emph{The CentOS Project Corporate +Mission} and @emph{The CentOS Project Release Schema}, the following +visual manifestations were defined: @table @strong @item The CentOS Distribution +The CentOS Distribution visual manifestation covers all actions +related to branding and artwork production required by the The CentOS +Distribution. @xref{Directories trunk Identity Themes Models Default +Distro}. + The CentOS Distribution is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. The CentOS Distribution @@ -62,6 +69,45 @@ active user community including system administrators, network administrators, enterprise users, managers, core Linux contributors and Linux enthusiasts from around the world. +The upstream vendor has released 4 versions of their +@acronym{EL,Enterprise Linux} product that The CentOS Project rebuilds +the freely available SRPMS for. The upstream vendor releases security +updates as required by circumstances. The CentOS Project releases +rebuilds of security updates as soon as possible. Usually within 24 +hours (our stated goal is with 72 hours, but we are usually much +faster). + +The upstream vendor also releases numbered update sets for major +versions of their EL product from 2 to 4 times per year. There are new +ISOs from the upstream vendor provided for these update sets. Update +sets will be completed as soon as possible after the upstream vendor +releases their version @dots{} generally within 2 weeks. The CentOS +Project follows these conventions as well, so CentOS-3.9 correlates +with EL 3 update 9 and CentOS-4.6 correlates with EL 4 update 6, +CentOS-5.1 correlates to EL 5 update 1, etc. + +One thing some people have problems understanding is that if you have +any CentOS-3 product and update it, you will be updated to the latest +CentOS-3.x version. + +The same is true for CentOS-4 and CentOS-5. If you update any CentOS-4 +product, you will be updated to the latest CentOS-4.x version, or to +the latest CentOS-5.x version if you are updating a CentOS-5 system. +This is exactly the same behavior as the upstream product. Let's +assume that the latest EL4 product is update 6. If you install the +upstream original EL4 CDs (the ones before any update set) and upgrade +via @command{yum}, you will have latest update set installed (EL4 +update 6 in our example). Since all updates within a major release +(CentOS-2, CentOS-3, CentOS-4, CentOS-5) always upgrade to the latest +version when updates are performed (thus mimicking upstream behavior), +only the latest version is maintained in each main tree on The CentOS +Mirrors (@url{http://mirrors.centos.org/}). + +There is a CentOS Vault (@url{http://vault.centos.org/}) containing +old CentOS trees. This vault is a picture of the older tree when it +was removed from the main tree, and does not receive updates. It +should only be used for reference. + @item The CentOS Web The CentOS Web exists to support The CentOS Distribution. @@ -96,7 +142,7 @@ could be added in the future, if needed, to cover different areas like building, offices, road transportation and whaterver visual manifestation The CentOS Project thouches to show its existence. -@subsubsection Corporate Communication +@subsubheading Corporate Communication The CentOS Project Corporate Communication is based on @emph{Community Communication} and takes place through the following avenues: @@ -109,12 +155,12 @@ Communication} and takes place through the following avenues: @item The CentOS Wiki (@url{http://wiki.centos.org/}). @end itemize -@subsubsection Corporate Behaviour +@subsubheading Corporate Behaviour The CentOS Project Corporate Behaviour is based on @emph{Community Behaviour} which take place on @emph{Corporate Communication}. -@subsubsection Corporate Structure +@subsubheading Corporate Structure The CentOS Project Corporate Structure is based on a @emph{Monolithic Corporate Visual Identity Structure}. In this configuration, one @@ -187,7 +233,7 @@ lack of uniformity is what introduces the visual contradition we are precisely trying to solve by mean of themes production in the CentOS Artwork Repository. -@subsection Usage +@subheading Usage The @file{trunk/Identity} directory structure organizes most files used to build and implement The CentOS Project Corporate Identity. In @@ -263,7 +309,7 @@ then the files in this location may result very useful to you. @xref{Directories trunk Identity Webenv}, for more information. @end table -@subsection See also +@subheading See also See @url{http://en.wikipedia.org/Corporate_identity} (and related links), for general information on Corporate Identity. diff --git a/Manual/Directories/trunk/Identity/Brushes.texi b/Manual/Directories/trunk/Identity/Brushes.texi index 0683f53..2c8d28c 100755 --- a/Manual/Directories/trunk/Identity/Brushes.texi +++ b/Manual/Directories/trunk/Identity/Brushes.texi @@ -1,10 +1,10 @@ -@subsection Goals +@subheading Goals This section describes how brushes are organized in the repository and how to make them available for you to use in @acronym{GIMP,GNU Image Manipulation Program}. -@subsection Description +@subheading Description A brush is a pixmap or set of pixmaps used for painting through an image manipulation program like GIMP. Inside the repository, we've @@ -97,13 +97,13 @@ without including the file extension (e.g., if we have the @file{centos-flame-3.gbr} brush, its description would be @code{centos-flame-3}). -@subsection Usage +@subheading Usage The way you use brushes is up to your creativeness. However, the way brushes are made available needs to be standardized. That's the reason of organizing brushes in common brushes and theme-specific brushes. -@subsection Common brushes +@subheading Common brushes Common brushes exist to organize brushes that can be used anywhere inside the repository. Inside the repository, common brushes under @@ -115,7 +115,7 @@ Common brushes are always made available under @file{~/.gimp-2.2/brushes} directory after preparing the repository (@pxref{Directories trunk Scripts Functions Prepare}). -@subsection Theme-specific brushes +@subheading Theme-specific brushes Theme-specific brushes exist to organize brushes that can be used inside specific artistic motifs only. Inside the repository, @@ -132,7 +132,7 @@ In order to make theme-specific brushes available under using the @code{theme} functionality of @command{centos-art.sh} script. @c (@pxref{Directories trunk Scripts Functions Theme}). -@subsection See also +@subheading See also @itemize @item @url{file:///usr/share/gimp/2.0/help/en/index.html,The Gimp diff --git a/Manual/Directories/trunk/Identity/Fonts.texi b/Manual/Directories/trunk/Identity/Fonts.texi index ef6730a..99c7266 100644 --- a/Manual/Directories/trunk/Identity/Fonts.texi +++ b/Manual/Directories/trunk/Identity/Fonts.texi @@ -1,79 +1,45 @@ -@subsection Goals +@subheading Goals -This section exists to organize digital typographies used by the -CentOS project. +This section describes how typographies are organized in the +repository and how to make them available for you to use in +@acronym{GIMP,GNU Image Manipulation Program} and Inkscape. -@subsection Description +@subheading Description -@subsection Usage +The CentOS Project Corporate Identity is attached to @samp{DejaVu LGC} +font-family and @samp{Denmark} font-family. -The CentOS corporate identity is attached to @samp{DejaVu LGC} -font-family. Whatever artwork you design for CentOS project, that -requires typography usage, must be done using @samp{DejaVu LGC} -font-family. +@float Figure, DejaVu LGC font family +@image{trunk/Identity/Images/Manual/Fonts/dejavu-lgc,430pt,,,jpg} +@caption{DejaVu-LGC font-family.} +@end float -@table @strong -@item Recommendation-1: - -For screen desings (e.g., anything that final destination will never -be printed on paper or any medium outside computer screens) use -@samp{DejaVu LGC Sans} font-family. - -@item Recommendation-2: - -For non-screen designs (e.g., anything that final desition will be -printed on paper or any other medium outside computer screens) use -@samp{DejaVu LGC Serif} font-family. As convenction files described in -this rule are stored under @samp{Stationery} directories. -@end table - -The only execption for the two recommendations above is the typography -used inside CentOS logo. The CentOS logo is the main visual -representation of the CentOS project so the typography used in it must -be the same always, no matter where it be shown. It also has to be -clear enough to dismiss any confussion between similar typefaces -(e.g., the number one (1) sometimes is confuesed with the letter -@samp{el} (l) or letter @samp{ai} (i)). - -As CentOS logo typography convenction, the word @samp{CentOS} uses -@samp{Denmark} typography as base, both for the word @samp{CentOS} and -the phrase @samp{Community Enterprise Operating System}. The phrase -size of CentOS logo is half the size in poits the word @samp{CentOS} -has and it below @samp{CentOS} word and aligned with it on the left. -The distance between @samp{CentOS} word and phrase @samp{Community -Enterprise Operating System} have the size in points the phrase has. - -When the CentOS release brand is built, use @samp{Denmark} typography -for the release number. The release number size is two times larger -(in height) than default @samp{CentOS} word. The separation between -release number and @samp{CentOS} word is twice the size in points of -separation between @samp{CentOS} word and phrase @samp{Community -Enterprise Operating System}. - -Another component inside CentOS logo is the trademark symbol (TM). -This symbol specifies that the CentOS logo must be consider a product -brand, even it is not a registered one. The trademark symbol uses -DejaVu LGC Sans Regular typography. The trademark symbol is aligned -right-top on the outter side of @samp{CentOS} word. The trademark -symbol must not exceed haf the distance, in points, between -@samp{CentOS} word and the release number on its right. - -It would be very convenient for the CentOS Project and its community -to to make a registered trademark (®) of CentOS logo. To make a -register trademark of CentOS Logo prevents legal complications in the -market place of brands. It grants the consistency, through time, of -CentOS project corporate visual identity. +@float Figure, Denmark font family +@image{trunk/Identity/Images/Manual/Fonts/denmark,430pt,,,jpg} +@caption{Denmark font-family.} +@end float @quotation -@strong{Note} The information about trademarks and corporate identity -is my personal interpretation of -@url{http://en.wikipedia.org/Corporate_identity} and -@url{http://en.wikipedia.org/Trademark} description. If you have -practical experiences with these affairs, please serve yourself to -improve this section with your reasons. +@strong{Caution} +The copyright and license of @samp{Denmark} typography aren't very +specific and that issue may represent a threat to The CentOS Project +Corporate Identity. @end quotation -@subsection See also +The @samp{Denmark} typography is used as base to build The CentOS Logo +(i.e., the main graphic design that connects/identifies all visual +manifestations related to The CentOS Project). If the typography used +to build The CentOS Logo is compromised somehow, the whole corporate +visual identity it represents would be compromised, as well. To +prevent such issues, it would be better for The CentOS Project to move +on from @samp{Denmark} typography to another typography (free, +preferably) that retain the same visual style of @samp{Denmark}, but +intruce a clearer copyright and license notice. + +@subheading Usage + +@itemize +@item @xref{Directories trunk Identity Models Brands}. +@end itemize -@menu -@end menu +@subheading See also diff --git a/Manual/Directories/trunk/Identity/Images.texi b/Manual/Directories/trunk/Identity/Images.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Images.texi +++ b/Manual/Directories/trunk/Identity/Images.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Models.texi b/Manual/Directories/trunk/Identity/Models.texi index 5997904..60cb2e1 100755 --- a/Manual/Directories/trunk/Identity/Models.texi +++ b/Manual/Directories/trunk/Identity/Models.texi @@ -1,10 +1,16 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description + +@itemize +@item ... +@end itemize + +@subheading Usage @table @strong @item Brands @@ -17,17 +23,8 @@ manifestations. @xref{Directories trunk Identity Models Brands}, for more information. @end table -@itemize -@item ... -@end itemize - -@subsection Usage +@subheading See also @itemize @item ... @end itemize - -@subsection See also - -@menu -@end menu diff --git a/Manual/Directories/trunk/Identity/Models/Brands.texi b/Manual/Directories/trunk/Identity/Models/Brands.texi index 9cf9a6e..7e30abf 100644 --- a/Manual/Directories/trunk/Identity/Models/Brands.texi +++ b/Manual/Directories/trunk/Identity/Models/Brands.texi @@ -1,14 +1,64 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description -@subsection Usage +The CentOS logo is the main visual representation of the CentOS +project so the typography used in it must be the same always, no +matter where it be shown. It also has to be clear enough to dismiss +any confussion between similar typefaces (e.g., the number one (1) +sometimes is confuesed with the letter @samp{el} (l) or letter +@samp{ai} (i)). -@subsection See also +As convenction, the word @samp{CentOS} uses @samp{Denmark} typography +as base, both for the word @samp{CentOS} and the phrase +@samp{Community Enterprise Operating System}. The phrase size of +CentOS logo is half the size in poits the word @samp{CentOS} has and +it below @samp{CentOS} word and aligned with it on the left. The +distance between @samp{CentOS} word and phrase @samp{Community +Enterprise Operating System} have the size in points the phrase has. + +@float Figure, The CentOS logo construction +@image{trunk/Identity/Images/Manual/Brands/Logos/a,,,,jpg} +@caption{The CentOS logo construction} +@end float + +When the CentOS release brand is built, use @samp{Denmark} typography +for the release number. The release number size is two times larger +(in height) than default @samp{CentOS} word. The separation between +release number and @samp{CentOS} word is twice the size in points of +separation between @samp{CentOS} word and phrase @samp{Community +Enterprise Operating System}. + +Another component inside CentOS logo is the trademark symbol (TM). +This symbol specifies that the CentOS logo must be consider a product +brand, even it is not a registered one. The trademark symbol uses +DejaVu LGC Sans Regular typography. The trademark symbol is aligned +right-top on the outter side of @samp{CentOS} word. The trademark +symbol must not exceed haf the distance, in points, between +@samp{CentOS} word and the release number on its right. + +It would be very convenient for the CentOS Project and its community +to to make a registered trademark (®) of CentOS logo. To make a +register trademark of CentOS Logo prevents legal complications in the +market place of brands. It grants the consistency, through time, of +CentOS project corporate visual identity. + +@quotation +@strong{Note} The information about trademarks and corporate identity +is my personal interpretation of +@url{http://en.wikipedia.org/Corporate_identity} and +@url{http://en.wikipedia.org/Trademark} description. If you have +practical experiences with these affairs, please serve yourself to +improve this section with your reasons. +@end quotation + +@subheading Usage + +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Palettes.texi b/Manual/Directories/trunk/Identity/Palettes.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Palettes.texi +++ b/Manual/Directories/trunk/Identity/Palettes.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Patterns.texi b/Manual/Directories/trunk/Identity/Patterns.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Patterns.texi +++ b/Manual/Directories/trunk/Identity/Patterns.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes.texi b/Manual/Directories/trunk/Identity/Themes.texi index 2084221..5f0bd58 100644 --- a/Manual/Directories/trunk/Identity/Themes.texi +++ b/Manual/Directories/trunk/Identity/Themes.texi @@ -1,11 +1,11 @@ -@subsection Goals +@subheading Goals The @file{trunk/Identity/Themes/} directory exists to organize production of CentOS themes. -@subsection Description +@subheading Description -@subsubsection Work Flow +@subsubheading Work Flow Initially, we start working themes on their trunk development line (e.g., @file{trunk/Identity/Themes/Motifs/TreeFlower/}), here we @@ -70,7 +70,7 @@ location to fulfill CentOS distribution artwork needs. The same applies to CentOS Webmasters (the persons whom build CentOS websites), and any other visual manifestation required by the project. -@subsection Usage +@subheading Usage In this location themes are organized in ``Models'' ---to store common information--- and ``Motifs''---to store unique information. At @@ -83,7 +83,7 @@ final CentOS themes. CentOS themes can be tagged as ``Default'' or * Directories trunk Identity Themes Motifs:: @end menu -@subsection See also +@subheading See also @menu * Directories trunk Identity:: diff --git a/Manual/Directories/trunk/Identity/Themes/Models.texi b/Manual/Directories/trunk/Identity/Themes/Models.texi index f27933c..cfd9740 100644 --- a/Manual/Directories/trunk/Identity/Themes/Models.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models.texi @@ -1,10 +1,10 @@ -@subsection Goals +@subheading Goals @itemize @item Organize theme models. @end itemize -@subsection Description +@subheading Description Theme models let you modeling characteristics (e.g., dimensions, translation markers, position of each element on the display area, @@ -16,7 +16,7 @@ Theme models serves as a central pool of design templates for themes to use. This way you can produce themes with different artistic motifs but same characteristics. -@subsection Usage +@subheading Usage @table @strong @item Default Design Model @@ -35,7 +35,7 @@ Inside alternative themes you find post-installation visual style only themes are maintained by CentOS Community. @end table -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default.texi index 11bd1f6..99bf17b 100644 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default.texi @@ -1,4 +1,4 @@ -@subsection Goals +@subheading Goals Default Design Models for CentOS Themes provide design models for the following components: @@ -21,7 +21,7 @@ posters, etc.). --- @strong{Removed}(xref:Directories trunk Identity Themes Mode Promo) ---, for more information. @end table -@subsection Description +@subheading Description This directory implements the concept of @emph{Default Design Models for CentOS Themes}. Default Design Models for CentOS Themes provide @@ -36,7 +36,7 @@ release of CentOS Distribution the image produced belongs to. --- @strong{Removed}(xref:Directories trunk Identity Models Tpl Brands) ---, for more information. -@subsection Usage +@subheading Usage The CentOS Project maintains near to four different major releases of CentOS Distribution. Each major release of CentOS Distribution has @@ -83,7 +83,7 @@ Project corporate visual identity. It should be very clear for everyone which major release of CentOS Distribution is being used. @end quotation -@subsection See also +@subheading See also @itemize @item @ref{Directories trunk Identity Themes} diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Concept.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Concept.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Concept.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Concept.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro.texi index ee66a4a..431c69c 100644 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro.texi @@ -1,4 +1,4 @@ -@subsection Goals +@subheading Goals This directory provides design models to produce image files for the following CentOS Distribution components: @@ -55,7 +55,7 @@ progress information while user's graphical session is loading. @xref{Directories trunk Identity Themes Models Default Distro Ksplash}, for more information. @end table -@subsection Description +@subheading Description The CentOS Distribution visual style is controlled by image files. These image files are packaged inside The CentOS Distribution and made @@ -65,7 +65,7 @@ those image files to add the desired visual style first and later, repackage them to make them available inside the final iso files of CentOS Distribution. -@subsection Usage +@subheading Usage This directory provides organizationl structure to store default design models for CentOS Themes of CentOS Distribution and so it @@ -99,7 +99,7 @@ is no longer used. However it could be very useful for historical reasons. Also, someone could feel motivated enough to keep himself documenting it or supporting it for whatever reason. -@subsection See also +@subheading See also @menu * Directories trunk Identity Themes Models Default:: diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi index 9cf9a6e..c10b6dd 100644 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Anaconda.texi @@ -1,14 +1,14 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description -@subsection Usage +@subheading Usage -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Firstboot.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Firstboot.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Firstboot.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Firstboot.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Gdm.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Gdm.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Gdm.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Gdm.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Grub.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Grub.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Grub.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Grub.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Gsplash.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Gsplash.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Gsplash.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Gsplash.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Kdm.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Kdm.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Kdm.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Kdm.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Ksplash.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Ksplash.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Ksplash.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Ksplash.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Rhgb.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Rhgb.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Rhgb.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Rhgb.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Syslinux.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Syslinux.texi index fb39647..e226b31 100755 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Syslinux.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Distro/Syslinux.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Models/Default/Posters.texi b/Manual/Directories/trunk/Identity/Themes/Models/Default/Posters.texi index fb39647..e226b31 100644 --- a/Manual/Directories/trunk/Identity/Themes/Models/Default/Posters.texi +++ b/Manual/Directories/trunk/Identity/Themes/Models/Default/Posters.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Motifs.texi b/Manual/Directories/trunk/Identity/Themes/Motifs.texi index 7b65b5b..e59547e 100644 --- a/Manual/Directories/trunk/Identity/Themes/Motifs.texi +++ b/Manual/Directories/trunk/Identity/Themes/Motifs.texi @@ -1,4 +1,4 @@ -@subsection Goals +@subheading Goals The @file{trunk/Identity/Themes/Motifs} directory exists to: @@ -6,7 +6,7 @@ The @file{trunk/Identity/Themes/Motifs} directory exists to: @item Organize CentOS themes' artistic motifs. @end itemize -@subsection Description +@subheading Description The artistic motif of theme is a graphic design component that provides the visual style of themes, it is used as pattern to connect @@ -64,7 +64,7 @@ trunk/Identity/Themes/Motifs/$ThemeName/ `-- Screenshots @end example -@subsection Usage +@subheading Usage When designing artistic motifs for CentOS, consider the following recommendations: @@ -105,7 +105,7 @@ Share-Alike License 3.0} @end itemize @end itemize -@subsection See also +@subheading See also @menu * Directories trunk Identity Themes:: diff --git a/Manual/Directories/trunk/Identity/Themes/Motifs/Flame.texi b/Manual/Directories/trunk/Identity/Themes/Motifs/Flame.texi index b8f5088..8947136 100644 --- a/Manual/Directories/trunk/Identity/Themes/Motifs/Flame.texi +++ b/Manual/Directories/trunk/Identity/Themes/Motifs/Flame.texi @@ -1,11 +1,11 @@ -@subsection Goals +@subheading Goals This section describes the @emph{Flame} artistic motif. This section may be useful for anyone interested in reproducing the @emph{Flame} artistic motif, or in creating new artistic motifs for The CentOS Project corporate visual identity. -@subsection Description +@subheading Description The @emph{Flame} artistic motif was built using the flame filter of Gimp 2.2 in CentOS 5.5. @@ -103,14 +103,14 @@ The Flame settings we used in our example are saved in the file named directory structure. @ifhtml -@subsection Screenshots +@subheading Screenshots @image{trunk/Identity/Themes/Motifs/Flame/1/Concept/motif-thumb-250,,,,jpg} @image{trunk/Identity/Themes/Motifs/Flame/2/Concept/motif-thumb-250,,,,jpg} @image{trunk/Identity/Themes/Motifs/Flame/3/Concept/motif-thumb-250,,,,jpg} @end ifhtml -@subsection See also +@subheading See also @itemize @item @xref{Directories trunk Identity Themes Motifs}. diff --git a/Manual/Directories/trunk/Identity/Themes/Motifs/Modern.texi b/Manual/Directories/trunk/Identity/Themes/Motifs/Modern.texi index d05a9c3..ac27109 100644 --- a/Manual/Directories/trunk/Identity/Themes/Motifs/Modern.texi +++ b/Manual/Directories/trunk/Identity/Themes/Motifs/Modern.texi @@ -1,24 +1,24 @@ -@subsection Goals +@subheading Goals -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize @ifhtml -@subsection Screenshots +@subheading Screenshots @image{trunk/Identity/Themes/Motifs/Modern/1/Concept/motif-thumb-250,,,,jpg} @end ifhtml -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Motifs/Pipes.texi b/Manual/Directories/trunk/Identity/Themes/Motifs/Pipes.texi index 0bcce68..8e7ddc7 100755 --- a/Manual/Directories/trunk/Identity/Themes/Motifs/Pipes.texi +++ b/Manual/Directories/trunk/Identity/Themes/Motifs/Pipes.texi @@ -1,28 +1,28 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize @ifhtml -@subsection Screenshots +@subheading Screenshots @image{trunk/Identity/Themes/Motifs/Pipes/1/Concept/motif-thumb-250,,,,jpg} @end ifhtml -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Themes/Motifs/TreeFlower.texi b/Manual/Directories/trunk/Identity/Themes/Motifs/TreeFlower.texi index 14d422a..d10f820 100644 --- a/Manual/Directories/trunk/Identity/Themes/Motifs/TreeFlower.texi +++ b/Manual/Directories/trunk/Identity/Themes/Motifs/TreeFlower.texi @@ -1,9 +1,9 @@ -@subsection Goals +@subheading Goals -@subsection Description +@subheading Description @ifhtml -@subsection Screenshots +@subheading Screenshots @image{trunk/Identity/Themes/Motifs/TreeFlower/1/Concept/motif-thumb-250,,,,jpg} @image{trunk/Identity/Themes/Motifs/TreeFlower/2/Concept/motif-thumb-250,,,,jpg} @@ -11,9 +11,9 @@ @image{trunk/Identity/Themes/Motifs/TreeFlower/4/Concept/motif-thumb-250,,,,jpg} @end ifhtml -@subsection Usage +@subheading Usage -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Identity/Webenv.texi b/Manual/Directories/trunk/Identity/Webenv.texi index 14b2e25..57decbb 100755 --- a/Manual/Directories/trunk/Identity/Webenv.texi +++ b/Manual/Directories/trunk/Identity/Webenv.texi @@ -1,10 +1,10 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description The CentOS web environment is formed by a central web application ---to cover base needs (e.g., per-major release information like @@ -65,13 +65,13 @@ the one unique visual style customization changes. At the surface of this issue we can see the need of one specific yum repository to store CentOS web environment customized web applications. -@subsubsection Design model (without ads) +@subsubheading Design model (without ads) -@subsubsection Design model (with ads) +@subsubheading Design model (with ads) -@subsubsection HTML definitions +@subsubheading HTML definitions -@subsubsection Controlling visual style +@subsubheading Controlling visual style Inside CentOS web environment, the visual style is controlled by the following compenents: @@ -88,7 +88,7 @@ trunk/Identity/Themes/Models/Default/Promo/Web/CSS/stylesheet.css @end verbatim @end table -@subsubsection Producing visual style +@subsubheading Producing visual style The visual style of CentOS web environment is defined in the following files: @@ -118,7 +118,7 @@ visual style changes will take effect the next time customization line of CentOS web applications be packaged, uploded, and installed from [webenv] or [webenv-test] repositories. -@subsubsection Navigation +@subsubheading Navigation Inside CentOS web environment, the one-step navegation between web applications is addressed using the web environment navigation bar. @@ -126,7 +126,7 @@ The web environment navigation bar contains links to main applications and is always visible no matter where you are inside the web environment. -@subsubsection Development and release cycle +@subsubheading Development and release cycle The CentOS web environment development and relase cycle is described below: @@ -276,7 +276,7 @@ repository you need to configure it first. @end quotation @end table -@subsubsection The [webenv-test] repository +@subsubheading The [webenv-test] repository @verbatim /etc/yum.repos.d/CentOS-Webenv-test.repo @@ -293,7 +293,7 @@ enabled=1 priority=10 @end verbatim -@subsubsection The [webenv] repository +@subsubheading The [webenv] repository @verbatim /etc/yum.repos.d/CentOS-Webenv.repo @@ -310,18 +310,18 @@ enabled=1 priority=10 @end verbatim -@subsubsection Priority configuration +@subsubheading Priority configuration Both [webenv] and [webenv-test] repositories update packages inside CentOS [base] and CentOS [updates] repositories. -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Manual.texi b/Manual/Directories/trunk/Manual.texi index fb39647..e226b31 100644 --- a/Manual/Directories/trunk/Manual.texi +++ b/Manual/Directories/trunk/Manual.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Scripts.texi b/Manual/Directories/trunk/Scripts.texi index 5d57c7b..13a77f5 100644 --- a/Manual/Directories/trunk/Scripts.texi +++ b/Manual/Directories/trunk/Scripts.texi @@ -1,11 +1,11 @@ -@subsection Goals +@subheading Goals The @file{trunk/Scripts} directory exists to organize the trunk development line of @file{centos-art.sh} automation script. The @file{centos-art.sh} script standardizes tasks you need to do frequently inside CentOS Artwork Repository. -@subsection Description +@subheading Description The best way to understand @file{centos-art.sh} automation script is studying its source code. However, as start point, you may prefer to @@ -141,13 +141,13 @@ variables and functions defined inside function environment. @caption{The actions initialization environment.} @end float -@subsection Usage +@subheading Usage The @file{centos-art.sh} script usage information is described inside each specific function documentation (--- @strong{Removed}(pxref:trunk Scripts Bash Functions) ---). -@subsection See also +@subheading See also @menu * Directories trunk Scripts:: diff --git a/Manual/Directories/trunk/Scripts/Functions.texi b/Manual/Directories/trunk/Scripts/Functions.texi index fade4ea..35141fe 100755 --- a/Manual/Directories/trunk/Scripts/Functions.texi +++ b/Manual/Directories/trunk/Scripts/Functions.texi @@ -1,9 +1,9 @@ -@subsection Goals +@subheading Goals The @file{trunk/Scripts/Bash/Functions} directory exists to organize @file{centos-art.sh} specific functionalities. -@subsection Description +@subheading Description The specific functions of @file{centos-art.sh} script are designed with ``Software Toolbox'' philosophy (@pxref{Toolbox @@ -304,9 +304,9 @@ script specific functionalities. By the way, the @code{greet} functionality doesn't exist inside @file{centos-art.sh} script yet. Would you like to create it? -@subsection Usage +@subheading Usage -@subsubsection Global variables +@subsubheading Global variables The following global variables of @file{centos-art.sh} script, are available for you to use inside specific functions: @@ -504,7 +504,7 @@ If no one of these values is set in @env{EDITOR} environment variable, @file{centos-art.sh} uses @file{/usr/bin/vim} text editor by default. @end defvar -@subsubsection Global functions +@subsubheading Global functions Function scripts stored directly under @file{trunk/Scripts/Bash/Functions/} directory are used to define @@ -1197,7 +1197,7 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk @end quotation @end defun -@subsubsection Specific functions +@subsubheading Specific functions The following specific functions of @file{centos-art.sh} script, are available for you to use: @@ -1214,7 +1214,7 @@ available for you to use: * Directories trunk Scripts Functions Prepare:: @end menu -@subsection See also +@subheading See also @menu * Directories trunk Scripts:: diff --git a/Manual/Directories/trunk/Scripts/Functions/Help.texi b/Manual/Directories/trunk/Scripts/Functions/Help.texi index fb39647..e226b31 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Help.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Help.texi @@ -1,22 +1,22 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description @itemize @item ... @end itemize -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Scripts/Functions/Locale.texi b/Manual/Directories/trunk/Scripts/Functions/Locale.texi index bf264c9..b3abcef 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Locale.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Locale.texi @@ -1,10 +1,10 @@ -@subsection Goals +@subheading Goals @itemize @item ... @end itemize -@subsection Description +@subheading Description This command looks for @samp{.sh} files inside Bash directory and extracts translatable strings from files, using @command{xgettext} @@ -68,7 +68,7 @@ can find such modifications in the following files: @item ... @end itemize -@subsection Usage +@subheading Usage @table @samp @item centos-art locale --edit @@ -79,7 +79,7 @@ environment variable). Use this command to see the command-line interface locale report. @end table -@subsection See also +@subheading See also @menu @end menu diff --git a/Manual/Directories/trunk/Scripts/Functions/Path.texi b/Manual/Directories/trunk/Scripts/Functions/Path.texi index 1274b2d..7520fba 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Path.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Path.texi @@ -1,17 +1,17 @@ -@subsection Goals +@subheading Goals This section exists to organize files related to @code{path} functiontionality. The @code{path} functionality standardizes movement, syncronization, branching, tagging, and general file maintainance inside the repository. -@subsection Description +@subheading Description @emph{''CentOS like trees, has roots, trunk, branches, leaves and flowers. Day by day they work together in freedom, ruled by the laws of nature and open standards, to show the beauty of its existence.''} -@subsubsection Repository layout +@subsubheading Repository layout The repository layout describes organization of files and directories inside the repository. The repository layout provides the standard @@ -55,7 +55,7 @@ single copy of the master sources. This copy is called the source ``repository''; it contains all the information to permit extracting previous versions of those files at any time. -@subsubsection Repository name convenctions +@subsubheading Repository name convenctions Repository name convenctions help us to maintain consistency of names inside the repository. @@ -74,7 +74,7 @@ Repository name convenctions are implemented inside the convenctions to remember, concentrating them in just one single place to look for fixes and improvements. -@subsubsection Repository work flow +@subsubheading Repository work flow Repository work flow describes the steps and time intervals used to produce CentOS corporate visual identity inside CentOS Artwork @@ -146,7 +146,7 @@ location to fulfill CentOS distribution artwork needs. The same applies to CentOS Webmasters (the persons whom build CentOS websites), and any other visual manifestation required by the project. -@subsubsection Parallel directories +@subsubheading Parallel directories Inside CentOS Artwork Repository, parallel directories are simple directory entries built from a common parent directory and placed in a @@ -194,7 +194,7 @@ parent directory structure. Liberal change of parallel directories may suppresses the conceptual idea they were initially created for; and certainly, things may stop working the way they should do. -@subsubsection Syncronizing path information +@subsubheading Syncronizing path information Parallel directories are very useful to keep repository organized but introduce some complications. For instance, consider what would @@ -250,7 +250,7 @@ Texinfo to produce error messages at export time. So, 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. -@subsubsection What is the right place to store it? +@subsubheading What is the right place to store it? Occasionly, you may find that new corporate visual identity components need to be added to the repository. If that is your case, the first @@ -302,7 +302,7 @@ Other location concepts can be found similary as we did above, just change the location we used above by the one you are trying to know concepts for. -@subsection Usage +@subheading Usage @table @command @item centos-art path --copy='SRC' --to='DST' @@ -319,7 +319,7 @@ In this command, @file{SRC} is a working copy (WC) entry. @end table -@subsection See also +@subheading See also @menu * Directories trunk Scripts:: diff --git a/Manual/Directories/trunk/Scripts/Functions/Prepare.texi b/Manual/Directories/trunk/Scripts/Functions/Prepare.texi index f95e79c..70d29d1 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Prepare.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Prepare.texi @@ -1,4 +1,4 @@ -@subsection Goals +@subheading Goals This section exists to organize files related to @file{centos-art.sh} script @samp{prepare} functionality. The @samp{prepare} functionality @@ -6,7 +6,7 @@ of @file{centos-art.sh} script helps you to prepare the workstation configuration you are planning to use as host for your working copy of CentOS Artwork Repository. -@subsection Description +@subheading Description The first time you download CentOS Artwork Repository you need to configure your workstation in order to use @file{centos-art.sh} @@ -24,7 +24,7 @@ the @file{centos-art.sh} script directly, but the absolute path to because @file{centos-art} symbolic link, under @file{~/bin/} directory, has not been created yet. -@subsubsection Packages +@subsubheading Packages Installation of auxiliar RPM packages provides the software required to manipulate files inside the repository (e.g., image files, @@ -58,7 +58,7 @@ sudo}. This reading will be very useful, and with some practice, you will be able to configure your users to have @command{sudo} privileges. -@subsubsection Links +@subsubheading Links Creation of symbolic links helps us to alternate between different implementations of @file{centos-art.sh} script-line (e.g., @@ -91,7 +91,7 @@ structure as you usually do inside @file{trunk/} repository directory structure. As consequence of this configuration, automation scripts cannot be branched under @file{branches/Scripts} directory structure. -@subsubsection Environment variables +@subsubheading Environment variables Definition of environemnt variables helps us to set default values to our user session life. The user session environment variable defintion @@ -184,7 +184,7 @@ The format of @var{TZ} environment variable is described in @end table -@subsubsection Shell Script Files +@subsubheading Shell Script Files The @code{shell} functionality of @file{centos-art.sh} script helps you to maintain bash scripts inside repository. For example, suppose @@ -321,7 +321,7 @@ See file for a complete license description. @end quotation -@subsubsection SVG Files +@subsubheading SVG Files The @code{svg} functionality of @file{centos-art.sh} script helps you to maintain scalable vector graphics (SVG) inside repository. For @@ -381,9 +381,9 @@ To remove unused definitions from several scalable vector graphics files, the @file{centos-art.sh} script uses Inkscape command-line interface, specifically with the @option{--vaccum-defs} option. -@subsubsection XHTML Files +@subsubheading XHTML Files -@subsection Usage +@subheading Usage @table @command @@ -436,7 +436,7 @@ provided at all. @end table -@subsection See also +@subheading See also @menu * Directories trunk Scripts:: diff --git a/Manual/Directories/trunk/Scripts/Functions/Render.texi b/Manual/Directories/trunk/Scripts/Functions/Render.texi index 90b7bd3..e3fc7cf 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Render.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Render.texi @@ -48,7 +48,7 @@ speeds up production of different components like Syslinux, Grub, Gdm, Kdm and Ksplash that require intermediate formats or even several independent files, in order for the final content to be created. -@subsection Renderable identity directory structures +@subheading Renderable identity directory structures Renderable identity directory structures are the starting point of identity rendition. Whenever we want to render a component of CentOS @@ -77,7 +77,7 @@ configuration does one thing only (e.g., to produce untranslated images), but it can be extended (e.g., adding translation files) to achieve different needs (e.g., to produce translated images). -@subsubsection Design template without translation +@subsubheading Design template without translation The design template without translation configuration is based on a renderable identity directory structure with an empty translation @@ -266,7 +266,7 @@ until all design templates be processed. information. @end table -@subsubsection Design template with translation (one-to-one) +@subsubheading Design template with translation (one-to-one) Producing untranslated images is fine in many cases, but not always. Sometimes it is required to produce images in different languages and @@ -337,7 +337,7 @@ trunk/Identity/NewDir/Img/file.png 4 | Remove design template instance. @end verbatim -@subsubsection Design template with translation (optimized) +@subsubheading Design template with translation (optimized) Producing translated images satisfies almost all our production images needs, but there is still a pitfall in them. In order to produce @@ -449,7 +449,7 @@ paragraph-based design template, but @file{03-docs.png} using the list-based design template. @end table -@subsubsection Design template with translation (optimized+flexibility) +@subsubheading Design template with translation (optimized+flexibility) In the production models we've seen so far, there are design templates to produce untranslated images and translation files which combiend @@ -604,7 +604,7 @@ function render_loadConfig { @end table The production flow of ``optimize+flexibility'' configuration@dots{} -@subsection Renderable translation directory structures +@subheading Renderable translation directory structures Translation directory structures are auxiliar structures of renderable identity directory structures. There is one translation directory @@ -634,7 +634,7 @@ from translation templates. Inside renderable translation directory structures, @file{centos-art.sh} can produce text-based files only. -@subsection Copying renderable directory structures +@subheading Copying renderable directory structures A renderable layout is formed by design models, design images, pre-rendition configuration scripts and translations files. This way, @@ -764,13 +764,13 @@ The `render_doCopy' functionality does duplicate directory structures directly involved in rendition process only. Once such directories have been duplicated, the functionality stops thereat. -@subsection Usage +@subheading Usage @itemize @item ... @end itemize -@subsection See also +@subheading See also @menu * Directories trunk Scripts Functions Render Config:: diff --git a/Manual/Directories/trunk/Scripts/Functions/Render/Config.texi b/Manual/Directories/trunk/Scripts/Functions/Render/Config.texi index 680d0af..a160ad1 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Render/Config.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Render/Config.texi @@ -1,9 +1,9 @@ -@subsection Goals +@subheading Goals The @file{trunk/Scripts/Bash/Config} directory exists to oraganize pre-rendering configuration scripts. -@subsection Description +@subheading Description Pre-rendering configuration scripts let you customize the way @command{centos-art.sh} script renders identity and translation @@ -17,7 +17,7 @@ both on identity and translation repository entires. Pre-rendering configuration entries are required for each identity entry, but not for translation entries. -@subsubsection The @file{render.conf.sh} identity model +@subsubheading The @file{render.conf.sh} identity model Inside CentOS Artwork Repository, we consider identity entries to all directories under @file{trunk/Identity} directory. Identity entries can be @@ -61,14 +61,14 @@ extend both image-based and text-based pre-rendering configuration scripts using image-based and text-based post-rendering actions, respectively. -@subsubsection The @file{render.conf.sh} translation model +@subsubheading The @file{render.conf.sh} translation model Translation pre-rendering configuration scripts take precedence before default translation rendering action. Translation pre-rendering actions are useful when default translation rendering action do not fit itself to translation entry rendering requirements. -@subsubsection The @file{render.conf.sh} rendering actions +@subsubheading The @file{render.conf.sh} rendering actions Inside both image-based and text-based identity pre-rendering configuration scripts, we use the @samp{ACTIONS} array variable to @@ -150,7 +150,7 @@ ACTIONS[1]='POST:renderFormats: xpm jpg tif' ACTIONS[2]='LAST:groupByformat: png xpm jpg tif' @end verbatim -@subsection Usage +@subheading Usage Use the following commands to administer both identity and translation pre-rendering configuration scripts: @@ -183,7 +183,7 @@ In the commands above, @samp{path/to/dir} refers to one renderable directory path under @file{trunk/Identity} or @file{trunk/Translations} structures only. -@subsection See also +@subheading See also @menu * Directories trunk Scripts:: diff --git a/Manual/Introduction/authors.texi b/Manual/Introduction/authors.texi index 8747241..f8538b5 100755 --- a/Manual/Introduction/authors.texi +++ b/Manual/Introduction/authors.texi @@ -1,37 +1,37 @@ This section records authoring information of CentOS Artwork -Repository: +Repository along the years: -@subsection Graphic Design +@subheading Graphic Design @itemize @item Guideon de Kok -@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} +@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado}, 2009, 2010, 2011 @item @email{marcus@@moeller.org,Marcus Moeller} @end itemize -@subsection Documentation +@subheading Documentation @itemize -@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} +@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado}, 2009, 2010, 2011 @item @email{ralph@@centos.org,Ralph Angenendt} @end itemize -@subsection Localization +@subheading Localization @itemize -@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} (Spanish) +@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} (Spanish), 2009, 2010, 2011 @end itemize -@subsection Automation +@subheading Automation @itemize -@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado} +@item @email{alain.reguera@@gmail.com,Alain Reguera Delgado}, 2009, 2010, 2011 @end itemize -@subsection Infrastructure +@subheading Infrastructure @itemize @item @email{karan@@centos.org,Karanbirn Singh} @item @email{ralph@@centos.org,Ralph Angenendt} @end itemize -@subsection Packaging +@subheading Packaging @itemize @item @email{karan@@centos.org,Karanbirn Singh} @item @email{ralph@@centos.org,Ralph Angenendt} diff --git a/Manual/Introduction/repo-convenctions.texi b/Manual/Introduction/repo-convenctions.texi index 5b06a9a..13eb51b 100644 --- a/Manual/Introduction/repo-convenctions.texi +++ b/Manual/Introduction/repo-convenctions.texi @@ -14,7 +14,8 @@ independent working copies to interchange data and provides the information required to permit extracting previous versions of files at any time. -@subsection Repository policy +@subheading Repository policy +@cindex 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 @@ -55,7 +56,8 @@ 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 +@subheading Repository organization +@cindex Repository organization The CentOS Artwork Repository uses a @file{trunk}, @file{branches}, and @file{tags} organization. @@ -80,7 +82,8 @@ either from the main or the intermediate lines of development. @xref{Directories tags}, for more information. @end table -@subsection Repository file names +@subheading Repository file names +@cindex Repository file names Inside the CentOS Artwork Repository, file names are all written in lowercase (e.g., @samp{01-welcome.png}, @samp{splash.png}, @@ -88,7 +91,7 @@ lowercase (e.g., @samp{01-welcome.png}, @samp{splash.png}, capitalized (e.g., @samp{Identity}, @samp{Themes}, @samp{Motifs}, @samp{TreeFlower}, etc.). -@subsection Repository work lines +@subheading Repository work lines Inside CentOS Artwork Repository there are four major work lines of production which are: @emph{graphic design}, @emph{documentation}, @@ -101,7 +104,8 @@ content produced in one area depends somehow from content produced in another different area. So, a @emph{content production standard} is required for each available work line. -@subsubsection Graphic design +@subsubheading Graphic design +@cindex Graphic design work line The graphic design work line exists to cover brand design, typography design and themes design mainly. Additionally, some auxiliar areas @@ -167,7 +171,8 @@ itself is controlled by the @code{render} functionality of @xref{Directories trunk Identity}, for more information about The CentOS Corporate Identity and how graphic design fits on it. -@subsubsection Documentation +@subsubheading Documentation +@cindex Documentation work line The documentation work line exists to describe what each directory inside the CentOS Artwork Repository is for, the conceptual ideas @@ -197,7 +202,8 @@ automate such process yet. @xref{Directories trunk Manual}, for more information on documentation. -@subsubsection Localization +@subsubheading Localization +@cindex Localization work line The localization work line exists to provide the translation messages required to produce content in different languages. Translation @@ -256,7 +262,8 @@ Artwork Repository be sure to use source files supported either by @xref{Directories trunk Locales}, for more information. -@subsubsection Automation +@subsubheading Automation +@cindex Automation work line The automation work line exists to standardize content production in CentOS Artwork Repository. There is no need to type several tasks, @@ -280,7 +287,10 @@ to benefit. @xref{Directories trunk Scripts}, for more information on automation. -@subsection Connection between directories +@subheading Connection between directories +@cindex Connection between directories +@cindex Master paths +@cindex Auxiliar paths In order to produce content in CentOS Artwork Repository, it is required that all work lines be connected somehow. This is the way @@ -406,7 +416,8 @@ like Syslinux, Grub, Rhgb, Gdm, Kdm, Gsplash and Ksplash that share a similar file organization to that described above for @file{Anaconda} component. -@subsection Syncronizing path information +@subheading Syncronizing path information +@cindex Syncronizing path information Syncronizing path information is the action that keeps all path information up to date in the repository. This action implies both @@ -472,7 +483,8 @@ exist. The syncronization of path information is aimed to solve these kind of issues. -@subsection Extending repository organization +@subheading Extending repository organization +@cindex Extending repository organization Occasionly, you may find that new components of The CentOS Project Corporate Identity need to be added to the repository in order to work diff --git a/Manual/repository-init.pl b/Manual/repository-init.pl index 1f8a3a1..a794879 100755 --- a/Manual/repository-init.pl +++ b/Manual/repository-init.pl @@ -64,7 +64,7 @@ $SPLIT = 'section'; # This is most useful if you do not want to have section navigation # with -split chapter. There will be chapter navigation panel at the # beginning and at the end of chapters anyway. -$SECTION_NAVIGATION = 0; +$SECTION_NAVIGATION = 1; # Layout control $print_page_head = \&T2H_XHTML_print_page_head; @@ -80,8 +80,6 @@ sub T2H_XHTML_print_page_head my $longtitle = "$Texi2HTML::THISDOC{'title_unformatted'}"; $longtitle .= ": $Texi2HTML::UNFORMATTED{'This'}" if exists $Texi2HTML::UNFORMATTED{'This'}; $T2H_LANG='en'; - @date=localtime(time); - $year=$date[5] += 1900; print $fh < - + @@ -121,15 +119,17 @@ EOT sub T2H_XHTML_print_page_foot { my $fh = shift; + my @date=localtime(time); + my $year=$date[5] += 1900; + my $program_string = program_string(); print $fh <
+

$program_string

-
@@ -240,7 +240,7 @@ sub T2H_XHTML_print_navigation my $fh = shift; my $buttons = shift; my $vertical = shift; - print $fh '
' . "\n"; + print $fh '
' . "\n"; print $fh "" unless $vertical; for my $button (@$buttons) @@ -329,65 +329,59 @@ sub T2H_XHTML_print_navigation print $fh "\n" if $vertical; } print $fh "" unless $vertical; - print $fh "
\n
"; + print $fh "\n"; } # Use icons for navigation. -$ICONS = 1; - -# specify in this array which "buttons" should appear in which order -# in the navigation panel for sections; use ' ' for empty buttons (space) -@SECTION_BUTTONS = - ( - 'Back', 'Top', 'Forward' - ); +$ICONS = 0; # insert here name of icon images for buttons # Icons are used, if $ICONS and resp. value are set %ACTIVE_ICONS = ( - 'Top', 'file:///usr/share/gimp/2.0/help/images/home.png', - 'Contents', '', + 'Top', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-goto-top.png', + 'Contents', 'file:///usr/share/icons/Bluecurve/24x24/stock/help-contents.png', 'Overview', '', - 'Index', '', + 'Index', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-find.png', 'This', '', - 'Back', 'file:///usr/share/gimp/2.0/help/images/prev.png', - 'FastBack', '', - 'Prev', 'file:///usr/share/gimp/2.0/help/images/prev.png', - 'Up', 'file:///usr/share/gimp/2.0/help/images/up.png', - 'Next', 'file:///usr/share/gimp/2.0/help/images/next.png', - 'NodeUp', 'file:///usr/share/gimp/2.0/help/images/up.png', - 'NodeNext', 'file:///usr/share/gimp/2.0/help/images/next.png', - 'NodePrev', 'file:///usr/share/gimp/2.0/help/images/next.png', - 'Following', 'file:///usr/share/gimp/2.0/help/images/next.png', - 'Forward', 'file:///usr/share/gimp/2.0/help/images/next.png', - 'FastForward', '', - 'About' , '', - 'First', '', - 'Last', '', + 'Back', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-back.png', + 'FastBack', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-goto-first.png', + 'Prev', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-back.png', + 'Up', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-up.png', + 'Next', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-forward.png', + 'NodeUp', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-up.png', + 'NodeNext', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-forward.png', + 'NodePrev', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-back.png', + 'Following', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-forward.png', + 'Forward', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-forward.png', + 'FastForward', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-goto-last.png', + 'About' , 'file:///usr/share/icons/Bluecurve/24x24/stock/gtk-about.png', + 'First', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-goto-first.png', + 'Last', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-goto-last.png', ' ', '' ); -# insert here name of icon images for these, if button is inactive +# Insert here name of icon images for these, if button is inactive %PASSIVE_ICONS = ( - 'Top', '', - 'Contents', '', + 'Top', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-goto-top.png', + 'Contents', 'file:///usr/share/icons/Bluecurve/24x24/stock/help-contents.png', 'Overview', '', - 'Index', '', + 'Index', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-find.png', 'This', '', - 'Back', '', - 'FastBack', '', - 'Prev', '', - 'Up', '', - 'Next', '', - 'NodeUp', '', - 'NodeNext', '', - 'NodePrev', '', - 'Following', '', - 'Forward', '', - 'FastForward', '', - 'About', '', - 'First', '', - 'Last', '', + 'Back', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-back.png', + 'FastBack', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-goto-first.png', + 'Prev', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-back.png', + 'Up', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-up.png', + 'Next', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-forward.png', + 'NodeUp', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-up.png', + 'NodeNext', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-forward.png', + 'NodePrev', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-back.png', + 'Following', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-forward.png', + 'Forward', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-go-forward.png', + 'FastForward', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-goto-last.png', + 'About' , 'file:///usr/share/icons/Bluecurve/24x24/stock/gtk-about.png', + 'First', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-goto-first.png', + 'Last', 'file:///usr/share/icons/Bluecurve/24x24/stock/stock-goto-last.png', + ' ', '' ); diff --git a/Manual/repository.css b/Manual/repository.css index ee77833..af7401c 100755 --- a/Manual/repository.css +++ b/Manual/repository.css @@ -31,6 +31,12 @@ /* Texi2html specific definitions. ----------------------------------*/ +div#page-body div#content { + padding-top: 5px; + padding-bottom: 5px; + background-color: #FFF; + } + table { margin-top: 0px; } @@ -42,7 +48,7 @@ div#content table tr th { div#content pre.example { padding: 0.5em 1em; -} + } div#content p img { margin-right: 10px; @@ -50,3 +56,12 @@ div#content p img { padding: 5px; border: 1px solid #DADADA; } + +div#content table.navibar { + margin-top: 20px; + border-bottom: 1px solid #f8f8f8; + } + +div#content p.credits { + font-size: small; + } diff --git a/Manual/repository.info.bz2 b/Manual/repository.info.bz2 index 80a3641..a69c3ff 100644 Binary files a/Manual/repository.info.bz2 and b/Manual/repository.info.bz2 differ diff --git a/Manual/repository.pdf b/Manual/repository.pdf index 930f629..5f6e9ef 100644 Binary files a/Manual/repository.pdf and b/Manual/repository.pdf differ diff --git a/Manual/repository.texi b/Manual/repository.texi index dae0989..47f70f6 100644 --- a/Manual/repository.texi +++ b/Manual/repository.texi @@ -10,7 +10,7 @@ This manuals documents relevant information regarding the deployment, organization, and administration of CentOS Artwork Repository. -Copyright @copyright{} 2009-2011 Alain Reguera Delgado +Copyright @copyright{} 2009, 2010, 2011 The CentOS Project Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or diff --git a/Manual/repository.txt.bz2 b/Manual/repository.txt.bz2 index a00af41..7eb2047 100644 Binary files a/Manual/repository.txt.bz2 and b/Manual/repository.txt.bz2 differ diff --git a/Manual/repository.xhtml.tar.bz2 b/Manual/repository.xhtml.tar.bz2 index bf45848..c71a984 100644 Binary files a/Manual/repository.xhtml.tar.bz2 and b/Manual/repository.xhtml.tar.bz2 differ diff --git a/Manual/repository.xml b/Manual/repository.xml index ca21924..3ef5531 100644 --- a/Manual/repository.xml +++ b/Manual/repository.xml @@ -5,7 +5,7 @@ CentOS Artwork Repository This manuals documents relevant information regarding the deployment, organization, and administration of CentOS Artwork Repository. - Copyright ©right; 2009-2011 Alain Reguera Delgado + Copyright ©right; 2009, 2010, 2011 The CentOS Project Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. @@ -13,7 +13,7 @@ Manual Alain Reguera Delgado This manuals documents relevant information regarding the deployment, organization, and administration of CentOS Artwork Repository. - Copyright ©right; 2009-2011 Alain Reguera Delgado + Copyright ©right; 2009, 2010, 2011 The CentOS Project Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. @@ -24,7 +24,7 @@ CentOS Artwork Repository This manuals documents relevant information regarding the deployment, organization, and administration of CentOS Artwork Repository. - Copyright ©right; 2009-2011 Alain Reguera Delgado + Copyright ©right; 2009, 2010, 2011 The CentOS Project Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. @@ -155,82 +155,64 @@ Introduction
Authors - AuthorsThis section records authoring information of CentOS Artwork Repository: - - - Graphic Design - - • - - Guideon de Kok - - - alain.reguera@gmail.comAlain Reguera Delgado - - - marcus@moeller.orgMarcus Moeller - - - - - - Documentation - - • - - alain.reguera@gmail.comAlain Reguera Delgado - - - ralph@centos.orgRalph Angenendt - - - - - - Localization - - • - - alain.reguera@gmail.comAlain Reguera Delgado (Spanish) - - - - - - Automation - - • - - alain.reguera@gmail.comAlain Reguera Delgado - - - - - - Infrastructure - - • - - karan@centos.orgKaranbirn Singh - - - ralph@centos.orgRalph Angenendt - - - - - - Packaging - - • - - karan@centos.orgKaranbirn Singh - - - ralph@centos.orgRalph Angenendt - - - + AuthorsThis section records authoring information of CentOS Artwork Repository along the years: + Graphic Design + + • + + Guideon de Kok + + + alain.reguera@gmail.comAlain Reguera Delgado, 2009, 2010, 2011 + + + marcus@moeller.orgMarcus Moeller + + + Documentation + + • + + alain.reguera@gmail.comAlain Reguera Delgado, 2009, 2010, 2011 + + + ralph@centos.orgRalph Angenendt + + + Localization + + • + + alain.reguera@gmail.comAlain Reguera Delgado (Spanish), 2009, 2010, 2011 + + + Automation + + • + + alain.reguera@gmail.comAlain Reguera Delgado, 2009, 2010, 2011 + + + Infrastructure + + • + + karan@centos.orgKaranbirn Singh + + + ralph@centos.orgRalph Angenendt + + + Packaging + + • + + karan@centos.orgKaranbirn Singh + + + ralph@centos.orgRalph Angenendt + +
@@ -339,111 +321,85 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh Repository Convenctions Repository convenctionsThe CentOS Artwork Repository is supported by Subversion (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 provides the information required to permit extracting previous versions of files at any time. - - - 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 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 do work the way expected and finally request access to commit them up to the CentOS Artwork Repository (i.e., the source 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 good community citizen. - As a good community citizen one understand of a person who 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 the 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 for you 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 file:///home/centos/artwork/trunk/Scripts/COPYINGtrunk/Scripts/COPYING, for a complete license description. - - - - Repository organization - The CentOS Artwork Repository uses a trunk, branches, and tags organization. - - - trunk - - The trunk directory organizes the main development line of CentOS Artwork Repository. See Directories trunk, for more information. - - - - branches - - The branches directory oranizes intermediate development lines taken from the main development line. See Directories branches, for more information. - - - - tags - - The tags directory organizes frozen development lines taken either from the main or the intermediate lines of development. See Directories tags, for more information. - - -
- - - - Repository file names - Inside the CentOS Artwork Repository, file names are all written in lowercase (e.g., 01-welcome.png, splash.png, anaconda_header.png, etc.) and directory names are all written capitalized (e.g., Identity, Themes, Motifs, TreeFlower, etc.). - - - - Repository work lines - Inside CentOS Artwork Repository there are four major work lines of production which are: graphic design, documentation, localization and 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. So, a content production standard is required for each available work line. - - - Graphic design - The graphic design work line exists to cover brand design, typography design and themes design mainly. Additionally, some auxiliar areas like icon design, illustration design, brushes design, patterns designs and palettes of colors are also included here for completeness. - Inside CentOS Artwork Repository graphic design is performed through Inkscape (http://www.inkscape.org/) and GIMP (http://www.gimp.org/). The Inkscape tool 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 in automation scripts. On the other hand, GIMP is used to create and manipulate rastered images, create brushes, patterns and palettes of colors. - - Tip Combine both Inkscape and GIMP specific functionalities and possibilities to produce very beautiful images. - - The CentOS Project Corporate Visual Identity is made of different visual manifestations (e.g., Distributions, Web sites, Stationery, etc.). Visual manifestations implement the corporate identity concepts by mean of images. To produce these images, we decompose image production in design models and artistic motifs. - Design models provide the structural information of images (i.e., dimension, position of common elements in the visible area, translation markers, etc.) and they are generally produced as scalable vector graphics to take advantage of SVG standard, an XML-based standard. - Artistic motifs provide the visual style (i.e., the background information, the look and feel) some design models need to complete the final image produced by automation scripts. Artistic motifs are generally produced as rastered images. - The result produced from combining one design model with one artistic motif is what we know as a theme. Inside themes directory structure (see Directories trunk Identity Themes), you can find several design models and several artistic motifs independently one another that can be albitrarily combined through theme rendition, a flexible way to produce images for different visual manifestations in very specific visual styles. Inside themes directory structure, theme rendition is performed in trunk/Identity/Themes/Motifs directory structure, the required design models are taken from trunk/Identity/Themes/Models directory structure and the action itself is controlled by the render functionality of centos-art.sh script. - In addition to theme rendition you can find direct rendition, too. Direct rendition is 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. Some of these contents are brands, icons and illustrations. Direct rendition is performed in trunk/Identity/Images, the required design models are taken from trunk/Identity/Models directory structure and the action itself is controlled by the render functionality of centos-art.sh script. - See Directories trunk Identity, for more information about The CentOS Corporate Identity and how graphic design fits on it. - - - - Documentation - The documentation work line exists to describe what each directory inside the CentOS Artwork Repository is for, the conceptual ideas behind them and, if possible, how automation scripts make use of 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 trunk/Manual directory structure and uses the repository directories as reference. Each directory structure in the repository has a documentation entry associated in the documentation manual. Documentation entries are stored under trunk/Manual/Directories directory structure and the action itself is controlled by the help functionality of centos-art.sh script. - The help functionality let you create, edit and delete documentation entries in a way that 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. - See Directories trunk Manual, for more information on documentation. - - - - Localization - The localization work line exists to provide the translation messages required to produce content in different languages. Translation messages inside the repository are stored as portable objects (e.g., .po, .pot) and machine objects (.mo) under trunk/Locales directory structure. - The procedure used to localize content is taken from gettext standard specification. Basically, translatable strings are retrived from source files in order to create portable objects and machine objects for them. These portable objects are editable files that contain the information used by translators to localize the translatable strings retrived from source files. On the other hand, machine objects are produced to be machine-redable only, as its name implies, and are produced from portable objects. - Since gettext needs to extract translatable strings form source files in order to let translators to localize them, we are limitted to use source files supported by gettext program. This is not a limitation at all since gettext supports most popular programming laguages (e.g., C, C++, Java, Bash, Python, Perl, PHP and GNU Awk just to mention a few ones). Nevertheless, formats like SVG, XHTML and Docbook don't figure as supported formats in the list of gettext supported source files. - To translate XML based source files like SVG, XHTML and Docbook we use the xml2po program instead. The xml2po comes with the gnome-doc-utils package and retrives translatable strings from one XML file to produce portable objects for them. - - Note Portable objects produced by xml2po have the same format that portable objects produced by gettext. This make the localization process quite consistent from translators' point of view. No matter what the source file be, the translator will always face the same translation file format (i.e., the portable object format). - - With the portable object in place, the xml2po program is used again to create the final translated XML, just 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 xml2po, the machine object is used as temporal file to produce the final translated XML file. - - Tip If you want to have your content localized inside CentOS Artwork Repository be sure to use source files supported either by gettext or xml2po programs. - - See Directories trunk Locales, for more information. - - - - Automation - The automation work line exists to standardize content production in CentOS Artwork Repository. There is no need to type several tasks, time after time, if they can be programmed into just one executable script. - The automation work line takes place under trunk/Scripts directory structure. Here is developed the centos-art.sh script, a bash script specially designed to automate most frequent tasks (e.g., rendition, documentation and localization) inside the repository. Basically, the centos-art.sh script is divided in several functionalities independent one another that perform specific tasks and relay on repository organization to work as expected. - - Tip If you need to improve the way content is produced, look inside automation scripts and make your improvement there for everyone to benefit. - - See Directories trunk Scripts, for more information on automation. - - - - - Connection between directories - In order to produce content in CentOS Artwork Repository, it is required that all work lines be connected somehow. This is the way automation scripts can know where to retrive the information they need to work with (e.g., design model, translation messages, output location, etc.). We build this kind of connection using two path constructions named master paths and auxiliar paths. - The master path points only to directories that contain the source files (e.g., SVG files) required to produce base content (e.g., PNG files) through automation scripts. Each master path inside the repository may have several auxiliar paths associated, but auxiliar paths can only have one master path 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 master paths (e.g., translation messages) or provides the output information required to know where to store the content produced from master path. When an auxiliar path points to a file, that file has no other purpose but to document the master path it refers to. - The relation between auxiliar paths and master paths is realized combining two path informations which are: the master path itself and one second level directory structure from the repository. Generally, the master path is considered the path identifier and the second level directory structure taken from the repository is considered the common part of the path where the identifier is appended. - - Figure - - Repository policy + 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 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 do work the way expected and finally request access to commit them up to the CentOS Artwork Repository (i.e., the source 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 good community citizen. + As a good community citizen one understand of a person who 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 the 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 for you 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 file:///home/centos/artwork/trunk/Scripts/COPYINGtrunk/Scripts/COPYING, for a complete license description. + Repository organization + Repository organization The CentOS Artwork Repository uses a trunk, branches, and tags organization. + + + trunk + + The trunk directory organizes the main development line of CentOS Artwork Repository. See Directories trunk, for more information. + + + + branches + + The branches directory oranizes intermediate development lines taken from the main development line. See Directories branches, for more information. + + + + tags + + The tags directory organizes frozen development lines taken either from the main or the intermediate lines of development. See Directories tags, for more information. + + +
+ Repository file names + Repository file names Inside the CentOS Artwork Repository, file names are all written in lowercase (e.g., 01-welcome.png, splash.png, anaconda_header.png, etc.) and directory names are all written capitalized (e.g., Identity, Themes, Motifs, TreeFlower, etc.). + Repository work lines + Inside CentOS Artwork Repository there are four major work lines of production which are: graphic design, documentation, localization and 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. So, a content production standard is required for each available work line. + Graphic design + Graphic design work line The graphic design work line exists to cover brand design, typography design and themes design mainly. Additionally, some auxiliar areas like icon design, illustration design, brushes design, patterns designs and palettes of colors are also included here for completeness. + Inside CentOS Artwork Repository graphic design is performed through Inkscape (http://www.inkscape.org/) and GIMP (http://www.gimp.org/). The Inkscape tool 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 in automation scripts. On the other hand, GIMP is used to create and manipulate rastered images, create brushes, patterns and palettes of colors. + + Tip Combine both Inkscape and GIMP specific functionalities and possibilities to produce very beautiful images. + + The CentOS Project Corporate Visual Identity is made of different visual manifestations (e.g., Distributions, Web sites, Stationery, etc.). Visual manifestations implement the corporate identity concepts by mean of images. To produce these images, we decompose image production in design models and artistic motifs. + Design models provide the structural information of images (i.e., dimension, position of common elements in the visible area, translation markers, etc.) and they are generally produced as scalable vector graphics to take advantage of SVG standard, an XML-based standard. + Artistic motifs provide the visual style (i.e., the background information, the look and feel) some design models need to complete the final image produced by automation scripts. Artistic motifs are generally produced as rastered images. + The result produced from combining one design model with one artistic motif is what we know as a theme. Inside themes directory structure (see Directories trunk Identity Themes), you can find several design models and several artistic motifs independently one another that can be albitrarily combined through theme rendition, a flexible way to produce images for different visual manifestations in very specific visual styles. Inside themes directory structure, theme rendition is performed in trunk/Identity/Themes/Motifs directory structure, the required design models are taken from trunk/Identity/Themes/Models directory structure and the action itself is controlled by the render functionality of centos-art.sh script. + In addition to theme rendition you can find direct rendition, too. Direct rendition is 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. Some of these contents are brands, icons and illustrations. Direct rendition is performed in trunk/Identity/Images, the required design models are taken from trunk/Identity/Models directory structure and the action itself is controlled by the render functionality of centos-art.sh script. + See Directories trunk Identity, for more information about The CentOS Corporate Identity and how graphic design fits on it. + Documentation + Documentation work line The documentation work line exists to describe what each directory inside the CentOS Artwork Repository is for, the conceptual ideas behind them and, if possible, how automation scripts make use of 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 trunk/Manual directory structure and uses the repository directories as reference. Each directory structure in the repository has a documentation entry associated in the documentation manual. Documentation entries are stored under trunk/Manual/Directories directory structure and the action itself is controlled by the help functionality of centos-art.sh script. + The help functionality let you create, edit and delete documentation entries in a way that 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. + See Directories trunk Manual, for more information on documentation. + Localization + Localization work line The localization work line exists to provide the translation messages required to produce content in different languages. Translation messages inside the repository are stored as portable objects (e.g., .po, .pot) and machine objects (.mo) under trunk/Locales directory structure. + The procedure used to localize content is taken from gettext standard specification. Basically, translatable strings are retrived from source files in order to create portable objects and machine objects for them. These portable objects are editable files that contain the information used by translators to localize the translatable strings retrived from source files. On the other hand, machine objects are produced to be machine-redable only, as its name implies, and are produced from portable objects. + Since gettext needs to extract translatable strings form source files in order to let translators to localize them, we are limitted to use source files supported by gettext program. This is not a limitation at all since gettext supports most popular programming laguages (e.g., C, C++, Java, Bash, Python, Perl, PHP and GNU Awk just to mention a few ones). Nevertheless, formats like SVG, XHTML and Docbook don't figure as supported formats in the list of gettext supported source files. + To translate XML based source files like SVG, XHTML and Docbook we use the xml2po program instead. The xml2po comes with the gnome-doc-utils package and retrives translatable strings from one XML file to produce portable objects for them. + + Note Portable objects produced by xml2po have the same format that portable objects produced by gettext. This make the localization process quite consistent from translators' point of view. No matter what the source file be, the translator will always face the same translation file format (i.e., the portable object format). + + With the portable object in place, the xml2po program is used again to create the final translated XML, just 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 xml2po, the machine object is used as temporal file to produce the final translated XML file. + + Tip If you want to have your content localized inside CentOS Artwork Repository be sure to use source files supported either by gettext or xml2po programs. + + See Directories trunk Locales, for more information. + Automation + Automation work line The automation work line exists to standardize content production in CentOS Artwork Repository. There is no need to type several tasks, time after time, if they can be programmed into just one executable script. + The automation work line takes place under trunk/Scripts directory structure. Here is developed the centos-art.sh script, a bash script specially designed to automate most frequent tasks (e.g., rendition, documentation and localization) inside the repository. Basically, the centos-art.sh script is divided in several functionalities independent one another that perform specific tasks and relay on repository organization to work as expected. + + Tip If you need to improve the way content is produced, look inside automation scripts and make your improvement there for everyone to benefit. + + See Directories trunk Scripts, for more information on automation. + Connection between directories + Connection between directoriesMaster pathsAuxiliar paths In order to produce content in CentOS Artwork Repository, it is required that all work lines be connected somehow. This is the way automation scripts can know where to retrive the information they need to work with (e.g., design model, translation messages, output location, etc.). We build this kind of connection using two path constructions named master paths and auxiliar paths. + The master path points only to directories that contain the source files (e.g., SVG files) required to produce base content (e.g., PNG files) through automation scripts. Each master path inside the repository may have several auxiliar paths associated, but auxiliar paths can only have one master path 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 master paths (e.g., translation messages) or provides the output information required to know where to store the content produced from master path. When an auxiliar path points to a file, that file has no other purpose but to document the master path it refers to. + The relation between auxiliar paths and master paths is realized combining two path informations which are: the master path itself and one second level directory structure from the repository. Generally, the master path is considered the path identifier and the second level directory structure taken from the repository is considered the common part of the path where the identifier is appended. + + Figure + + - Path construction. - - The path information described above (see Path construction) is used by direct rendition and can be taken as reference to add other components that are equally produced in the repository. To add new components that make use of direct rendition inside the repository, change just the component name used above (e.g., Brands) to that one you want to add, without changing the path structure around it. - The file organization used by theme rendition extends direct rendition by separating design models information from backgrounds information. To better understand this configuration, you can consider it 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. The possibilities of this configuration are endless and let us describe visual manifestations very well. For example, consider the organization used to produce Anaconda images; for CentOS distribution major release 5; using Default design models and version 3 of Flame artistic motif: - - Figure - - Path construction. + + The path information described above (see Path construction) is used by direct rendition and can be taken as reference to add other components that are equally produced in the repository. To add new components that make use of direct rendition inside the repository, change just the component name used above (e.g., Brands) to that one you want to add, without changing the path structure around it. + The file organization used by theme rendition extends direct rendition by separating design models information from backgrounds information. To better understand this configuration, you can consider it 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. The possibilities of this configuration are endless and let us describe visual manifestations very well. For example, consider the organization used to produce Anaconda images; for CentOS distribution major release 5; using Default design models and version 3 of Flame artistic motif: + + Figure + + - Path construction extended. - - The path information described above (see Path construction extended) is used by theme rendition and can be taken as reference to add other components that are equally produced in the repository. - In this configuration we can change both design model name (e.g., Default) and artistic motif name (e.g., Flame/3) to something else in order to achieve a different result. The only limitations impossed are the storage space provided in the server machine and your own creativeness as graphic designer. - - Note A theme ready for implementation may consume from 100 MB to 400 MB of storage space. The exact space consumed by a theme depends on the amount of screen resolutions the theme supports. The more screen resolutions the theme supports, the more storage space demanded for it. - - In this configuration we saw how to build the path information for Anaconda component as part of CentOS Distribution visual manifestation, but that is not the only component we have inside CentOS Distribution visual manifestation. There are other components like Syslinux, Grub, Rhgb, Gdm, Kdm, Gsplash and Ksplash that share a similar file organization to that described above for Anaconda component. - - - - Syncronizing path information - Syncronizing path information is the action that keeps all path information up to date in the repository. This action implies both file movement and file content replacement in this very specific order. File movement is related to duplicate, delete and rename files and directories in the repository. File content replacement is related to replace information, path information in this case, inside files in the repository. - The order followed to syncronize path information is relevant because the versioned nature of the files we are working with. We don't perform file content replacement first because that would imply a repository change which will immediatly demmand a commit in order for actions like duplicate, delete or rename to take place. However, if we perform file movement first, it is possible to commit both file moved and file content replacements as if they were just one change. In this case the file content replacement takes palce in the target location that have been duplicated or renamed, not the one use as source location. This configuration is specially useful when files are renamed (i.e., one file is copied from a source location to a target location and then the source location of it is removed from repository). - - Warning There is no support for URLs actions inside centos-art.sh script. The centos-art.sh script is designed to work with local files inside the working copy only. If you need to perform URL actions directly, use Subversion commands instead. - - When one master path is changed it is required that all related auxiliar paths be changed, too. This is required in order for master paths to retain their relation with auxiliar paths. This way, automation scripts are able to know where to retrive translation messages from, where to store final output images to 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 they need. - The auxiliar paths should never be modified under any reason but to satisfy the relationship with the master path. Liberal change of auxiliar paths may suppress the conceptual idea they were initially created for; and certainly, automation scripts may stop working as expected. The update direction to rename path information must be from master path to auxiliar path and never the opposite. - The relation between master and auxiliar paths is useful to keep repository organized but introduce some complications when we work with files that use master path information as reference to build structural information. This is the case of repository documentation manual source files where inclusions, menus, nodes and cross references are built using master path information as reference. Now, to see what kind of complication we are talking about, consider what would happen to a structural definitions (i.e., inlusions, menus, nodes and cross refereces) already set in the manual from one master path that is suddenly renamed to something different. If the path information is not syncronized, at this point, we lose connection between the master path and the auxiliar path created to store the related documentation entry, as well as the related structural definitions that end up pointing to a master path that no longer exist. - The syncronization of path information is aimed to solve these kind of issues. - - - - Extending repository organization - Occasionly, you may find that new components of The CentOS Project Corporate Identity need to be added to the repository in order to work them out. If that is the case, the first question we need to ask ourselves, 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 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. - When extending respository structure it is very useful to bear in mind The CentOS Project Corporate Identity Structure (see Directories trunk Identity) The CentOS Mission and The CentOS Release Schema. The rest is just matter of choosing appropriate names. It is also worth to know that each directory in the repository responds to a conceptual idea that justifies its existence. - To build a directory structure, you need to define the conceptual idea first and later create the directory. There are some locations inside the repository that already define some concepts you probably want to reuse. For example, trunk/Identity/Themes/Motifs to store theme artistic motifs, trunk/Identity/Themes/Models to store theme design models, trunk/Manual to store documentation files, trunk/Locales to store translation messages, trunk/Scripts to store automation scripts and so on. - To illustrate this desition process let's consider the trunk/Identity/Themes/Motifs/TreeFlower/3 directory structure as example. This directory can be read as: the theme development line of version 3 of TreeFlower artistic motif. Additional, we can identify that artistic motifs are part of themes as well as themes are part of The CentOS Project Corporate Identity. These concepts are better described independently in each documentation entry related to the directory structure as it is respectively shown in the list of commands bellow. - Path construction extended. + + The path information described above (see Path construction extended) is used by theme rendition and can be taken as reference to add other components that are equally produced in the repository. + In this configuration we can change both design model name (e.g., Default) and artistic motif name (e.g., Flame/3) to something else in order to achieve a different result. The only limitations impossed are the storage space provided in the server machine and your own creativeness as graphic designer. + + Note A theme ready for implementation may consume from 100 MB to 400 MB of storage space. The exact space consumed by a theme depends on the amount of screen resolutions the theme supports. The more screen resolutions the theme supports, the more storage space demanded for it. + + In this configuration we saw how to build the path information for Anaconda component as part of CentOS Distribution visual manifestation, but that is not the only component we have inside CentOS Distribution visual manifestation. There are other components like Syslinux, Grub, Rhgb, Gdm, Kdm, Gsplash and Ksplash that share a similar file organization to that described above for Anaconda component. + Syncronizing path information + Syncronizing path information Syncronizing path information is the action that keeps all path information up to date in the repository. This action implies both file movement and file content replacement in this very specific order. File movement is related to duplicate, delete and rename files and directories in the repository. File content replacement is related to replace information, path information in this case, inside files in the repository. + The order followed to syncronize path information is relevant because the versioned nature of the files we are working with. We don't perform file content replacement first because that would imply a repository change which will immediatly demmand a commit in order for actions like duplicate, delete or rename to take place. However, if we perform file movement first, it is possible to commit both file moved and file content replacements as if they were just one change. In this case the file content replacement takes palce in the target location that have been duplicated or renamed, not the one use as source location. This configuration is specially useful when files are renamed (i.e., one file is copied from a source location to a target location and then the source location of it is removed from repository). + + Warning There is no support for URLs actions inside centos-art.sh script. The centos-art.sh script is designed to work with local files inside the working copy only. If you need to perform URL actions directly, use Subversion commands instead. + + When one master path is changed it is required that all related auxiliar paths be changed, too. This is required in order for master paths to retain their relation with auxiliar paths. This way, automation scripts are able to know where to retrive translation messages from, where to store final output images to 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 they need. + The auxiliar paths should never be modified under any reason but to satisfy the relationship with the master path. Liberal change of auxiliar paths may suppress the conceptual idea they were initially created for; and certainly, automation scripts may stop working as expected. The update direction to rename path information must be from master path to auxiliar path and never the opposite. + The relation between master and auxiliar paths is useful to keep repository organized but introduce some complications when we work with files that use master path information as reference to build structural information. This is the case of repository documentation manual source files where inclusions, menus, nodes and cross references are built using master path information as reference. Now, to see what kind of complication we are talking about, consider what would happen to a structural definitions (i.e., inlusions, menus, nodes and cross refereces) already set in the manual from one master path that is suddenly renamed to something different. If the path information is not syncronized, at this point, we lose connection between the master path and the auxiliar path created to store the related documentation entry, as well as the related structural definitions that end up pointing to a master path that no longer exist. + The syncronization of path information is aimed to solve these kind of issues. + Extending repository organization + Extending repository organization Occasionly, you may find that new components of The CentOS Project Corporate Identity need to be added to the repository in order to work them out. If that is the case, the first question we need to ask ourselves, 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 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. + When extending respository structure it is very useful to bear in mind The CentOS Project Corporate Identity Structure (see Directories trunk Identity) The CentOS Mission and The CentOS Release Schema. The rest is just matter of choosing appropriate names. It is also worth to know that each directory in the repository responds to a conceptual idea that justifies its existence. + To build a directory structure, you need to define the conceptual idea first and later create the directory. There are some locations inside the repository that already define some concepts you probably want to reuse. For example, trunk/Identity/Themes/Motifs to store theme artistic motifs, trunk/Identity/Themes/Models to store theme design models, trunk/Manual to store documentation files, trunk/Locales to store translation messages, trunk/Scripts to store automation scripts and so on. + To illustrate this desition process let's consider the trunk/Identity/Themes/Motifs/TreeFlower/3 directory structure as example. This directory can be read as: the theme development line of version 3 of TreeFlower artistic motif. Additional, we can identify that artistic motifs are part of themes as well as themes are part of The CentOS Project Corporate Identity. These concepts are better described independently in each documentation entry related to the directory structure as it is respectively shown in the list of commands bellow. + - The concepts behind other location can be found in the same way described above, just change the path information used above to the one you are trying to know concepts for. - + The concepts behind other location can be found in the same way described above, just change the path information used above to the one you are trying to know concepts for. @@ -774,36 +723,25 @@ centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower/3
The <file>branches</file> Directory Directories branches - - Goals - This directory implements the Subversion's branches concept in a trunk, branches, tags repository structure. - - - - Description - The branches/ directory structre provides the intermediate space for creating several instances of trunk/ directory structure for parallel development and later merging changes back to trunk/ in the same parallel basis. - - - - Usage - The branches/ directory structure is unused, so far. - - - - See also - - • - - See Directories tags. - - - See Directories trunk. - - - Subversion's book (http://svnbook.red-bean.com/). - - - + Goals + This directory implements the Subversion's branches concept in a trunk, branches, tags repository structure. + Description + The branches/ directory structre provides the intermediate space for creating several instances of trunk/ directory structure for parallel development and later merging changes back to trunk/ in the same parallel basis. + Usage + The branches/ directory structure is unused, so far. + See also + + • + + See Directories tags. + + + See Directories trunk. + + + Subversion's book (http://svnbook.red-bean.com/). + +
@@ -814,36 +752,25 @@ centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower/3
The <file>tags</file> Directory Directories tags - - Goals - This directory implements the Subversion's tags concept in a trunk, branches, tags repository structure. - - - - Description - The tags/ directory structre provides frozen branches. Generally, we use frozen branches to make check-points in time for development lines under branches/ or trunk/ directory structure. - - - - Usage - The tags/ directory structure is unused, so far. - - - - See also - - • - - See Directories branches. - - - See Directories trunk. - - - Subversion's book (http://svnbook.red-bean.com/). - - - + Goals + This directory implements the Subversion's tags concept in a trunk, branches, tags repository structure. + Description + The tags/ directory structre provides frozen branches. Generally, we use frozen branches to make check-points in time for development lines under branches/ or trunk/ directory structure. + Usage + The tags/ directory structure is unused, so far. + See also + + • + + See Directories branches. + + + See Directories trunk. + + + Subversion's book (http://svnbook.red-bean.com/). + +
@@ -854,70 +781,59 @@ centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower/3
The <file>trunk</file> Directory Directories trunk - - Goals - The trunk/ directory structure implements the Subversion's trunk concept in a trunk, branches, tags repository structure. - - - - Description - The trunk/ directory structure is the main development line inside the CentOS Artwork Repository and organizes the following work lines: - - - Graphic design - - The graphic design work line exists to cover brand design, typography design and themes design mainly. Additionally, some auxiliar areas like icon design, illustration design, brushes design, patterns designs and palettes of colors are also included here for completeness. - In this section you'll find how to organize and produce gaphic designs in the repository. The graphic design work line is the perfect place to consolidate The CentOS Artwork SIG. If you are interested in producing graphic designs for The CentOS Project, this place is for you. - See Directories trunk Identity, for more information. - - - - Documentation - - The documentation work line exists to describe what each directory inside the CentOS Artwork Repository is for, the conceptual ideas behind them and, if possible, how automation scripts make use of them. - In this section you'll find how to organize and produce the CentOS Artwork Repository Manual (i.e., the documentation manual you're reading right now). If you are interested in producing documentation for the repository, this place is for you. - See Directories trunk Manual, for more information. - - - - Localization - - The localization work line exists to provide the translation messages required to produce content in different languages. Translation messages inside the repository are stored as portable objects (e.g., .po, .pot) and machine objects (.mo) under trunk/Locales directory structure. - In this section you'll find how to organize and produce translation messages for graphic designs, documentation and automation scripts in the repository. This place is perfect to consolidate The CentOS Translation SIG. If you love translating, you'll find lot of messages waiting for you to translate here. - See Directories trunk Locales, for more information. - - - - Automation - - The automation work line exists to standardize content production in CentOS Artwork Repository. There is no need to type several tasks, time after time, if they can be programmed into just one executable script. - In this section you'll find how to organize and extend the centos-art.sh script, a bash scripts specially designed to automate most frequent tasks in the repository (e.g., image rendition, documenting directory structures, translating content, etc.). If you can't resist the idea of automating repeatable tasks, then take a look here. - See Directories trunk Scripts, for more information. - - -
- - - - Usage - It seems to be no other use for this directory but to organize the sections described above. - - - - See also - - • + Goals + The trunk/ directory structure implements the Subversion's trunk concept in a trunk, branches, tags repository structure. + Description + The trunk/ directory structure is the main development line inside the CentOS Artwork Repository and organizes the following work lines: + + + Graphic design + + The graphic design work line exists to cover brand design, typography design and themes design mainly. Additionally, some auxiliar areas like icon design, illustration design, brushes design, patterns designs and palettes of colors are also included here for completeness. + In this section you'll find how to organize and produce gaphic designs in the repository. The graphic design work line is the perfect place to consolidate The CentOS Artwork SIG. If you are interested in producing graphic designs for The CentOS Project, this place is for you. + See Directories trunk Identity, for more information. + + + + Documentation - See Directories branches. + The documentation work line exists to describe what each directory inside the CentOS Artwork Repository is for, the conceptual ideas behind them and, if possible, how automation scripts make use of them. + In this section you'll find how to organize and produce the CentOS Artwork Repository Manual (i.e., the documentation manual you're reading right now). If you are interested in producing documentation for the repository, this place is for you. + See Directories trunk Manual, for more information. + + + Localization - See Directories tags. + The localization work line exists to provide the translation messages required to produce content in different languages. Translation messages inside the repository are stored as portable objects (e.g., .po, .pot) and machine objects (.mo) under trunk/Locales directory structure. + In this section you'll find how to organize and produce translation messages for graphic designs, documentation and automation scripts in the repository. This place is perfect to consolidate The CentOS Translation SIG. If you love translating, you'll find lot of messages waiting for you to translate here. + See Directories trunk Locales, for more information. + + + Automation - Subversion's book (http://svnbook.red-bean.com/). + The automation work line exists to standardize content production in CentOS Artwork Repository. There is no need to type several tasks, time after time, if they can be programmed into just one executable script. + In this section you'll find how to organize and extend the centos-art.sh script, a bash scripts specially designed to automate most frequent tasks in the repository (e.g., image rendition, documenting directory structures, translating content, etc.). If you can't resist the idea of automating repeatable tasks, then take a look here. + See Directories trunk Scripts, for more information. - - + +
+ Usage + It seems to be no other use for this directory but to organize the sections described above. + See also + + • + + See Directories branches. + + + See Directories tags. + + + Subversion's book (http://svnbook.red-bean.com/). + +
@@ -928,188 +844,164 @@ centos-art help --read turnk/Identity/Themes/Motifs/TreeFlower/3
The <file>trunk/Identity</file> Directory Directories trunk Identity - - Goals - The trunk/Identity describes what The CentOS Project Corporate Identity is and the components it is made of. - - - - Description - The CentOS Project Corporate Identity is the “persona” of the organization known as The CentOS Project. The CentOS Project Corporate Identity plays a significant role in the way the CentOS Project, as organization, presents itself to both internal and external stakeholders. In general terms, The CentOS Project Corporate Identity expresses the values and ambitions of The CentOS Project organization, its business, and its characteristics. - The CentOS Project Corporate Identity provides visibility, recognizability, reputation, structure and identification to The CentOS Project organization by means of Corporate Design, Corporate Communication, and Corporate Behaviour. - - Figure - - - The CentOS Project - Corporate Identity. - - - - Corporate Mission - The CentOS Project exists to provide The CentOS Distribution. Additionally, The CentOS Project provides The CentOS Web and The CentOS Showroom to support and promote the existence of The CentOS Distribution, respectively. - - - - Corporate Design - The CentOS Project Corporate Design is focused on the effective communication of visual messages through graphic design. Visual messages can be considered any information that people can perceive through the visual sence (i.e., the human eye). The CentOS Project Corporate Design is very tied to The CentOS Project Corporate Structure which, in turn, is based on The CentOS Project Corporate Mission and The CentOS Project Release Schema. - The CentOS Project Corporate Design is applied to The CentOS Project Visual Manifestations. A visual manifestation is any medium, digital or printed, used by The CentOS Project to communicate its existence (e.g., The CentOS Distribution, The CentOS Web and The CentOS Showroom). - - - The CentOS Distribution - - The CentOS Distribution is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. The CentOS Distribution conforms fully with the upstream vendors redistribution policy and aims to be 100% binary compatible. (The CentOS Project mainly changes packages to remove upstream vendor branding and artwork.) - The CentOS Distribution is developed by a small but growing team of core developers. In turn the core developers are supported by an active user community including system administrators, network administrators, enterprise users, managers, core Linux contributors and Linux enthusiasts from around the world. - - - - The CentOS Web - - The CentOS Web exists to support The CentOS Distribution. - The CentOS Web covers web applications which let The CentOS Project to manifest its existence on the Internet. Through these web applications The CentOS Project provides Corporate Communication. These web applications are free software and come from different providers which distribute their work with predefined visual styles. Frequently, these predefined visual styles have no visual relation among themselves and introduce some visual contraditions when they all are put together. These visual contraditions need to be removed in order to comply with The CentOS Project Corporate Structure guidelines. - - - - The CentOS Showroom - - The CentOS Showroom exists to promote The CentOS Distribution. - The CentOS Showroom covers industrial production of objects branded by The CentOS Project (e.g., clothes, stationery and installation media). These branded objects are for distribution on social events and/or shops. They provide a way of both promotion and monetary incomming to aliviate The CentOS Project expenses (e.g., electrical power, hosting, servers, full-time-developers, etc.), in a similar way as donations do. - - -
- The visual manifestation described above seems to be enough for what The CentOS Project is, by now. However, other visual manifestations could be added in the future, if needed, to cover different areas like building, offices, road transportation and whaterver visual manifestation The CentOS Project thouches to show its existence. - - - - Corporate Communication - The CentOS Project Corporate Communication is based on Community Communication and takes place through the following avenues: - - • - - The CentOS Chat (#centos, #centos-social, #centos-devel on irc.freenode.net) - - - The CentOS Mailing Lists (http://lists.centos.org/). - - - The CentOS Forums (http://forums.centos.org/). - - - The CentOS Wiki (http://wiki.centos.org/). - - - - - - Corporate Behaviour - The CentOS Project Corporate Behaviour is based on Community Behaviour which take place on Corporate Communication. - - - - Corporate Structure - The CentOS Project Corporate Structure is based on a Monolithic Corporate Visual Identity Structure. In this configuration, one unique name and one unique visual style is used in all visual manifestation of The CentOS Project. - In a monolithic corporate visual identity structure, internal and external stakeholders use to feel a strong sensation of uniformity, orientation, and identification with the organization. No matter if you are visiting web sites, using the distribution, or acting on social events, the one unique name and one unique visual style connects them all to say: Hey! we are all part of The CentOS Project. - Other corporate structures for The CentOS Project have been considered as well. Such is the case of producing one different visual style for each major release of The CentOS Distribution. This structure isn't inconvenient at all, but some visual contradictions could be introduced if it isn't applied correctly and we need to be aware of it. To apply it correctly, we need to know what The CentOS Project is made of. - The CentOS Project, as organization, is mainly made of (but not limited to) three visual manifestions: Distribution, Web and Showroom. Inside the Distribution visual manifestations, The CentOS Project maintains near to four different major releases of CentOS Distribution, parallely in time. However, inside The CentOS Web visual manifestations, the content is produced for no specific release information (e.g., there is no a complete web site for each major release of The CentOS Distribution individually, but one web site to cover them all). Likewise, the content produced in The CentOS Showroom is created for no release-specific at all, but for The CentOS Project in general. - In order to produce the correct corporate structure for The CentOS Project we need to concider all the visual manifestations The CentOS Project is made of, not just one of them. If one different visual style is used for each major release of The CentOS Distribution, which one of those different visual styles would be used to cover the remaining visual manifestations The CentOS Project is made of (e.g., The CentOS Web and The CentOS Showroom)? - Probably you are thinking, that's right, but The CentOS Brand connects them all already, why would we need to join them up into the same visual style too, isn't it more work to do, and harder to maintain? - Harder to maintain, more work to do, probably. Specially when you consider that The CentOS Project has proven stability and consistency through time and, that, certainly, didn't come through swinging magical wands or something but hardly working out to automate tasks and providing maintainance through time. Said that, we consider that The CentOS Project Corporate Structure should be consequent with such stability and consistency tradition. It is true that The CentOS Brand does connect all the visual manifestations it is present on, but that connection would be stronger if one unique visual style backups it. In fact, whatever thing you do to strength the visual connection among The CentOS Project visual manifestations would be very good in favor of The CentOS Project recognition. - Obviously, having just one visual style in all visual manifestations for eternity would be a very boring thing and would give the idea of a visually dead project. So, there is no problem on creating a brand new visual style for each new major release of The CentOS Distribution, in order to refresh The CentOS Distribution visual style; the problem is in not propagating the brand new visual style created for the new release of The CentOS Distribution to all other visual manifestations The CentOS Project is made of, in a way The CentOS Project could be recognized no matter what visual manifestation be in front of us. Such lack of uniformity is what introduces the visual contradition we are precisely trying to solve by mean of themes production in the CentOS Artwork Repository. - - - - - Usage - The trunk/Identity directory structure organizes most files used to build and implement The CentOS Project Corporate Identity. In that sake, the following work lines are available: - - - Brushes - - This work line provides brushes for GIMP. When you prepare the repository, brushes in this location are made available immediatly for you to use in the “Brushes” panel of GIMP. - See Directories trunk Identity Brushes, for more information. - - - - Fonts - - This work line provides the typography information required by all different visual manifestations of The CentOS Project. When you prepare the repository, fonts in this location are made available immediatly for you to use in GIMP and Inkscape. - See Directories trunk Identity Fonts, for more information. - - - - Images - - This work line provides output location for final images that don't need to use background images (e.g., brands, icons, illustrations, etc.). - See Directories trunk Identity Images, for more information. - - - - Models - - This work line provides design models for final images that don't need to use background images (e.g., brands, icons, illustrations, etc.). - See Directories trunk Identity Models, for more information. - - - - Palettes - - This work line provides palettes of colors for GIMP and Inkscape. When you prepare the repository, palettes of colors in this location are made available immediatly for you to use in the “Palettes” panel of GIMP and Inkscape. - See Directories trunk Identity Palettes, for more information. - - - - Patterns - - This work line provides patterns for GIMP. When you prepare the repository, patterns in this location are made available immediatly for you to use in the “Patterns” panel of GIMP. - See Directories trunk Identity Patterns, for more information. - - - - Themes - - This work line provides theme design models and theme artistic motifs for The CentOS Project. If you are interested in creating brand new visual styles for The CentOS Project this is the place for you. - See Directories trunk Identity Themes, for more information. - - - - Webenv - - This work line provides the HTML/XHTML and CSS standard definitions used by The CentOS Web visual manifestation. If you are a web developer and plan to improve The CentOS Web visual manifestation, then the files in this location may result very useful to you. - See Directories trunk Identity Webenv, for more information. - - -
- - - - See also - See http://en.wikipedia.org/Corporate_identity (and related links), for general information on Corporate Identity. - Specially useful has been, and still is, the book Corporate Identity by Wally Olins (1989). This book provides many conceptual ideas we've used as base to build The CentOS Artwork Repository. - -
- - - Directories trunk Identity Brushes - Directories trunk Identity Fonts - Directories trunk Identity - Directories -
- The <file>trunk/Identity/Brushes</file> Directory - Directories trunk Identity Brushes - - Goals - This section describes how brushes are organized in the repository and how to make them available for you to use in GIMPGNU Image Manipulation Program. - - - - Description - A brush is a pixmap or set of pixmaps used for painting through an image manipulation program like GIMP. Inside the repository, we've organized brushes in common brushes and theme-specific brushes. In both cases, brushes are initially created in .xcf format and later exported to any of the brush formats recognized by GIMP (e.g., .gbr or .gih) using the same name of its source file. - - Figure - - Goals + The trunk/Identity describes what The CentOS Project Corporate Identity is and the components it is made of. + Description + The CentOS Project Corporate Identity is the “persona” of the organization known as The CentOS Project. The CentOS Project Corporate Identity plays a significant role in the way The CentOS Project, as organization, presents itself to both internal and external stakeholders. In general terms, The CentOS Project Corporate Identity expresses the values and ambitions of The CentOS Project organization, its business, and its characteristics. + The CentOS Project Corporate Identity provides visibility, recognizability, reputation, structure and identification to The CentOS Project organization by means of Corporate Design, Corporate Communication, and Corporate Behaviour. + + Figure + + + The CentOS Project Corporate Identity. + + Corporate Mission + The CentOS Project exists to provide The CentOS Distribution. Additionally, The CentOS Project provides The CentOS Web and The CentOS Showroom to support and promote the existence of The CentOS Distribution, respectively. + Corporate Design + Corporate design is focused on the effective communication of corporate visual messages. Corporate visual messages are all the information emitted by a corporation that can be perceived by the people through their visual sence (i.e., the human eye). In order for such visual communication to happen, it is required to put the visual message on medium available for people to see. These kind of media are know as corporate visual manifestations, since the corporate manifests its existence through them using corporate design. + The amount of visual manifestations a corporation uses to communicate its existence is very specific to each corporation itself. Inside The CentOS Project Corporate Identity, considering The CentOS Project Corporate Structure, The CentOS Project Corporate Mission and The CentOS Project Release Schema, the following visual manifestations were defined: + + + The CentOS Distribution + + The CentOS Distribution visual manifestation covers all actions related to branding and artwork production required by the The CentOS Distribution. See Directories trunk Identity Themes Models Default Distro. + The CentOS Distribution is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. The CentOS Distribution conforms fully with the upstream vendors redistribution policy and aims to be 100% binary compatible. (The CentOS Project mainly changes packages to remove upstream vendor branding and artwork.) + The CentOS Distribution is developed by a small but growing team of core developers. In turn the core developers are supported by an active user community including system administrators, network administrators, enterprise users, managers, core Linux contributors and Linux enthusiasts from around the world. + The upstream vendor has released 4 versions of their ELEnterprise Linux product that The CentOS Project rebuilds the freely available SRPMS for. The upstream vendor releases security updates as required by circumstances. The CentOS Project releases rebuilds of security updates as soon as possible. Usually within 24 hours (our stated goal is with 72 hours, but we are usually much faster). + The upstream vendor also releases numbered update sets for major versions of their EL product from 2 to 4 times per year. There are new ISOs from the upstream vendor provided for these update sets. Update sets will be completed as soon as possible after the upstream vendor releases their version &dots; generally within 2 weeks. The CentOS Project follows these conventions as well, so CentOS-3.9 correlates with EL 3 update 9 and CentOS-4.6 correlates with EL 4 update 6, CentOS-5.1 correlates to EL 5 update 1, etc. + One thing some people have problems understanding is that if you have any CentOS-3 product and update it, you will be updated to the latest CentOS-3.x version. + The same is true for CentOS-4 and CentOS-5. If you update any CentOS-4 product, you will be updated to the latest CentOS-4.x version, or to the latest CentOS-5.x version if you are updating a CentOS-5 system. This is exactly the same behavior as the upstream product. Let's assume that the latest EL4 product is update 6. If you install the upstream original EL4 CDs (the ones before any update set) and upgrade via yum, you will have latest update set installed (EL4 update 6 in our example). Since all updates within a major release (CentOS-2, CentOS-3, CentOS-4, CentOS-5) always upgrade to the latest version when updates are performed (thus mimicking upstream behavior), only the latest version is maintained in each main tree on The CentOS Mirrors (http://mirrors.centos.org/). + There is a CentOS Vault (http://vault.centos.org/) containing old CentOS trees. This vault is a picture of the older tree when it was removed from the main tree, and does not receive updates. It should only be used for reference. + + + + The CentOS Web + + The CentOS Web exists to support The CentOS Distribution. + The CentOS Web covers web applications which let The CentOS Project to manifest its existence on the Internet. Through these web applications The CentOS Project provides Corporate Communication. These web applications are free software and come from different providers which distribute their work with predefined visual styles. Frequently, these predefined visual styles have no visual relation among themselves and introduce some visual contraditions when they all are put together. These visual contraditions need to be removed in order to comply with The CentOS Project Corporate Structure guidelines. + + + + The CentOS Showroom + + The CentOS Showroom exists to promote The CentOS Distribution. + The CentOS Showroom covers industrial production of objects branded by The CentOS Project (e.g., clothes, stationery and installation media). These branded objects are for distribution on social events and/or shops. They provide a way of both promotion and monetary incomming to aliviate The CentOS Project expenses (e.g., electrical power, hosting, servers, full-time-developers, etc.), in a similar way as donations do. + + +
+ The visual manifestation described above seems to be enough for what The CentOS Project is, by now. However, other visual manifestations could be added in the future, if needed, to cover different areas like building, offices, road transportation and whaterver visual manifestation The CentOS Project thouches to show its existence. + Corporate Communication + The CentOS Project Corporate Communication is based on Community Communication and takes place through the following avenues: + + • + + The CentOS Chat (#centos, #centos-social, #centos-devel on irc.freenode.net) + + + The CentOS Mailing Lists (http://lists.centos.org/). + + + The CentOS Forums (http://forums.centos.org/). + + + The CentOS Wiki (http://wiki.centos.org/). + + + Corporate Behaviour + The CentOS Project Corporate Behaviour is based on Community Behaviour which take place on Corporate Communication. + Corporate Structure + The CentOS Project Corporate Structure is based on a Monolithic Corporate Visual Identity Structure. In this configuration, one unique name and one unique visual style is used in all visual manifestation of The CentOS Project. + In a monolithic corporate visual identity structure, internal and external stakeholders use to feel a strong sensation of uniformity, orientation, and identification with the organization. No matter if you are visiting web sites, using the distribution, or acting on social events, the one unique name and one unique visual style connects them all to say: Hey! we are all part of The CentOS Project. + Other corporate structures for The CentOS Project have been considered as well. Such is the case of producing one different visual style for each major release of The CentOS Distribution. This structure isn't inconvenient at all, but some visual contradictions could be introduced if it isn't applied correctly and we need to be aware of it. To apply it correctly, we need to know what The CentOS Project is made of. + The CentOS Project, as organization, is mainly made of (but not limited to) three visual manifestions: Distribution, Web and Showroom. Inside the Distribution visual manifestations, The CentOS Project maintains near to four different major releases of CentOS Distribution, parallely in time. However, inside The CentOS Web visual manifestations, the content is produced for no specific release information (e.g., there is no a complete web site for each major release of The CentOS Distribution individually, but one web site to cover them all). Likewise, the content produced in The CentOS Showroom is created for no release-specific at all, but for The CentOS Project in general. + In order to produce the correct corporate structure for The CentOS Project we need to concider all the visual manifestations The CentOS Project is made of, not just one of them. If one different visual style is used for each major release of The CentOS Distribution, which one of those different visual styles would be used to cover the remaining visual manifestations The CentOS Project is made of (e.g., The CentOS Web and The CentOS Showroom)? + Probably you are thinking, that's right, but The CentOS Brand connects them all already, why would we need to join them up into the same visual style too, isn't it more work to do, and harder to maintain? + Harder to maintain, more work to do, probably. Specially when you consider that The CentOS Project has proven stability and consistency through time and, that, certainly, didn't come through swinging magical wands or something but hardly working out to automate tasks and providing maintainance through time. Said that, we consider that The CentOS Project Corporate Structure should be consequent with such stability and consistency tradition. It is true that The CentOS Brand does connect all the visual manifestations it is present on, but that connection would be stronger if one unique visual style backups it. In fact, whatever thing you do to strength the visual connection among The CentOS Project visual manifestations would be very good in favor of The CentOS Project recognition. + Obviously, having just one visual style in all visual manifestations for eternity would be a very boring thing and would give the idea of a visually dead project. So, there is no problem on creating a brand new visual style for each new major release of The CentOS Distribution, in order to refresh The CentOS Distribution visual style; the problem is in not propagating the brand new visual style created for the new release of The CentOS Distribution to all other visual manifestations The CentOS Project is made of, in a way The CentOS Project could be recognized no matter what visual manifestation be in front of us. Such lack of uniformity is what introduces the visual contradition we are precisely trying to solve by mean of themes production in the CentOS Artwork Repository. + Usage + The trunk/Identity directory structure organizes most files used to build and implement The CentOS Project Corporate Identity. In that sake, the following work lines are available: + + + Brushes + + This work line provides brushes for GIMP. When you prepare the repository, brushes in this location are made available immediatly for you to use in the “Brushes” panel of GIMP. + See Directories trunk Identity Brushes, for more information. + + + + Fonts + + This work line provides the typography information required by all different visual manifestations of The CentOS Project. When you prepare the repository, fonts in this location are made available immediatly for you to use in GIMP and Inkscape. + See Directories trunk Identity Fonts, for more information. + + + + Images + + This work line provides output location for final images that don't need to use background images (e.g., brands, icons, illustrations, etc.). + See Directories trunk Identity Images, for more information. + + + + Models + + This work line provides design models for final images that don't need to use background images (e.g., brands, icons, illustrations, etc.). + See Directories trunk Identity Models, for more information. + + + + Palettes + + This work line provides palettes of colors for GIMP and Inkscape. When you prepare the repository, palettes of colors in this location are made available immediatly for you to use in the “Palettes” panel of GIMP and Inkscape. + See Directories trunk Identity Palettes, for more information. + + + + Patterns + + This work line provides patterns for GIMP. When you prepare the repository, patterns in this location are made available immediatly for you to use in the “Patterns” panel of GIMP. + See Directories trunk Identity Patterns, for more information. + + + + Themes + + This work line provides theme design models and theme artistic motifs for The CentOS Project. If you are interested in creating brand new visual styles for The CentOS Project this is the place for you. + See Directories trunk Identity Themes, for more information. + + + + Webenv + + This work line provides the HTML/XHTML and CSS standard definitions used by The CentOS Web visual manifestation. If you are a web developer and plan to improve The CentOS Web visual manifestation, then the files in this location may result very useful to you. + See Directories trunk Identity Webenv, for more information. + + +
+ See also + See http://en.wikipedia.org/Corporate_identity (and related links), for general information on Corporate Identity. + Specially useful has been, and still is, the book Corporate Identity by Wally Olins (1989). This book provides many conceptual ideas we've used as base to build The CentOS Artwork Repository. +
+ + + Directories trunk Identity Brushes + Directories trunk Identity Fonts + Directories trunk Identity + Directories +
+ The <file>trunk/Identity/Brushes</file> Directory + Directories trunk Identity Brushes + Goals + This section describes how brushes are organized in the repository and how to make them available for you to use in GIMPGNU Image Manipulation Program. + Description + A brush is a pixmap or set of pixmaps used for painting through an image manipulation program like GIMP. Inside the repository, we've organized brushes in common brushes and theme-specific brushes. In both cases, brushes are initially created in .xcf format and later exported to any of the brush formats recognized by GIMP (e.g., .gbr or .gih) using the same name of its source file. + + Figure + + - Brush file format and directory structure. - - In order for both common brushes and theme-specific brushes to be loaded by GIMP, related .gbr and .gih brush files need to be stored under ~/.gimp-2.2/brushes directory. This location is out of CentOS Artwork Repository and provides no version control by itself. This way, brushes aren't exported to this location but into the repository directory structure which is versioned. Later, we create symbolic links in ~/.gimp-2.2/brushes to connect file brushes inside the repository and, this way, provide the configuration needed by GIMP to use the brush files produced inside the repository. - - Warning When brushes are added to or removed from the repository, you need to update your working copy and all information related to brushes inside your workstation (e.g., brush links in ~/.gimp-2.2/brushes and the Brushes panel in GIMP). Otherwise, you may end up with broken links or brushes in the repository that wouldn't be available for you to use in GIMP. - - Inside the repository, common brushes and theme-specific brushes are created individually in different locations, but they all are linked from one unique location (i.e., ~/.gimp-2.2/brushes). This configuration may provoke brush overlapping if a name convenction is not implemented correctly. In that sake, file names used for brushes inside the repository must be unique, no matter where they be. - As file name convenction inside the repository, brushes are named using lowercase letters, numbers, minus characters and dot characters, only. Additionally, when links are built, we use one suffix for those brushes retrived from trunk/Identity/Brushes and another suffix for those brushes retrivided from theme-specific directories. Using both the brush file name and the suffix information, it is possible to build unique names for links under ~/.gimp-2.2/brushes directory, scalably. - - Figure - - Brush file format and directory structure. + + In order for both common brushes and theme-specific brushes to be loaded by GIMP, related .gbr and .gih brush files need to be stored under ~/.gimp-2.2/brushes directory. This location is out of CentOS Artwork Repository and provides no version control by itself. This way, brushes aren't exported to this location but into the repository directory structure which is versioned. Later, we create symbolic links in ~/.gimp-2.2/brushes to connect file brushes inside the repository and, this way, provide the configuration needed by GIMP to use the brush files produced inside the repository. + + Warning When brushes are added to or removed from the repository, you need to update your working copy and all information related to brushes inside your workstation (e.g., brush links in ~/.gimp-2.2/brushes and the Brushes panel in GIMP). Otherwise, you may end up with broken links or brushes in the repository that wouldn't be available for you to use in GIMP. + + Inside the repository, common brushes and theme-specific brushes are created individually in different locations, but they all are linked from one unique location (i.e., ~/.gimp-2.2/brushes). This configuration may provoke brush overlapping if a name convenction is not implemented correctly. In that sake, file names used for brushes inside the repository must be unique, no matter where they be. + As file name convenction inside the repository, brushes are named using lowercase letters, numbers, minus characters and dot characters, only. Additionally, when links are built, we use one suffix for those brushes retrived from trunk/Identity/Brushes and another suffix for those brushes retrivided from theme-specific directories. Using both the brush file name and the suffix information, it is possible to build unique names for links under ~/.gimp-2.2/brushes directory, scalably. + + Figure + + - Common brushes path relation. - - - Figure - - Common brushes path relation. + + + Figure + + - Theme-specific brushes path relation. - - Brushes produced with GIMP has a description field associated that is shown in the Brushes panel of GIMP. This description is set when the brush is created as .xcf file and can be updated when it is exported either to .gbr or .gih format. It wouldn't be too useful to have two or more brushes using the same description so, we also make description of brush files unique, too. In that sake, we use the same name schema used to name brush links as description but without including the file extension (e.g., if we have the centos-flame-3.gbr brush, its description would be centos-flame-3). - - - - Usage - The way you use brushes is up to your creativeness. However, the way brushes are made available needs to be standardized. That's the reason of organizing brushes in common brushes and theme-specific brushes. - - - - Common brushes - Common brushes exist to organize brushes that can be used anywhere inside the repository. Inside the repository, common brushes under trunk/Identity/Brushes are mainly used to hold brand information related to The CentOS Project (e.g., symbols, logos, trademarks, etc.). - Common brushes are always made available under ~/.gimp-2.2/brushes directory after preparing the repository (see Directories trunk Scripts Functions Prepare). - - - - Theme-specific brushes - Theme-specific brushes exist to organize brushes that can be used inside specific artistic motifs only. Inside the repository, theme-specific brushes are stored in a directory named Brushes which is stored in the first directory level under the artistic motif directory structure. Each artistic motif inside the repository has its own Brushes directory and uses it to store brushes that can be considered auxiliars to that artistic motif construction. - Theme-specific brushes aren't made available under ~/.gimp-2.2/brushes directory after preparing the repository. In order to make theme-specific brushes available under ~/.gimp-2.2./brushes it is required to activate/deactivate them using the theme functionality of centos-art.sh script. + Theme-specific brushes path relation. + + Brushes produced with GIMP has a description field associated that is shown in the Brushes panel of GIMP. This description is set when the brush is created as .xcf file and can be updated when it is exported either to .gbr or .gih format. It wouldn't be too useful to have two or more brushes using the same description so, we also make description of brush files unique, too. In that sake, we use the same name schema used to name brush links as description but without including the file extension (e.g., if we have the centos-flame-3.gbr brush, its description would be centos-flame-3). + Usage + The way you use brushes is up to your creativeness. However, the way brushes are made available needs to be standardized. That's the reason of organizing brushes in common brushes and theme-specific brushes. + Common brushes + Common brushes exist to organize brushes that can be used anywhere inside the repository. Inside the repository, common brushes under trunk/Identity/Brushes are mainly used to hold brand information related to The CentOS Project (e.g., symbols, logos, trademarks, etc.). + Common brushes are always made available under ~/.gimp-2.2/brushes directory after preparing the repository (see Directories trunk Scripts Functions Prepare). + Theme-specific brushes + Theme-specific brushes exist to organize brushes that can be used inside specific artistic motifs only. Inside the repository, theme-specific brushes are stored in a directory named Brushes which is stored in the first directory level under the artistic motif directory structure. Each artistic motif inside the repository has its own Brushes directory and uses it to store brushes that can be considered auxiliars to that artistic motif construction. + Theme-specific brushes aren't made available under ~/.gimp-2.2/brushes directory after preparing the repository. In order to make theme-specific brushes available under ~/.gimp-2.2./brushes it is required to activate/deactivate them using the theme functionality of centos-art.sh script. - - - - See also - - • - - file:///usr/share/gimp/2.0/help/en/index.htmlThe Gimp Manual, specifically the section related to file:///usr/share/gimp/2.0/help/en/gimp-concepts-brushes.htmlBrushes. - - - + See also + + • + + file:///usr/share/gimp/2.0/help/en/index.htmlThe Gimp Manual, specifically the section related to file:///usr/share/gimp/2.0/help/en/gimp-concepts-brushes.htmlBrushes. + +
@@ -1188,47 +1067,34 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Fonts</file> Directory Directories trunk Identity Fonts - - Goals - This section exists to organize digital typographies used by the CentOS project. - - - - Description - - - - Usage - The CentOS corporate identity is attached to DejaVu LGC font-family. Whatever artwork you design for CentOS project, that requires typography usage, must be done using DejaVu LGC font-family. - - - Recommendation-1: - - For screen desings (e.g., anything that final destination will never be printed on paper or any medium outside computer screens) use DejaVu LGC Sans font-family. - - - - Recommendation-2: - - For non-screen designs (e.g., anything that final desition will be printed on paper or any other medium outside computer screens) use DejaVu LGC Serif font-family. As convenction files described in this rule are stored under Stationery directories. - - -
- The only execption for the two recommendations above is the typography used inside CentOS logo. The CentOS logo is the main visual representation of the CentOS project so the typography used in it must be the same always, no matter where it be shown. It also has to be clear enough to dismiss any confussion between similar typefaces (e.g., the number one (1) sometimes is confuesed with the letter el (l) or letter ai (i)). - As CentOS logo typography convenction, the word CentOS uses Denmark typography as base, both for the word CentOS and the phrase Community Enterprise Operating System. The phrase size of CentOS logo is half the size in poits the word CentOS has and it below CentOS word and aligned with it on the left. The distance between CentOS word and phrase Community Enterprise Operating System have the size in points the phrase has. - When the CentOS release brand is built, use Denmark typography for the release number. The release number size is two times larger (in height) than default CentOS word. The separation between release number and CentOS word is twice the size in points of separation between CentOS word and phrase Community Enterprise Operating System. - Another component inside CentOS logo is the trademark symbol (TM). This symbol specifies that the CentOS logo must be consider a product brand, even it is not a registered one. The trademark symbol uses DejaVu LGC Sans Regular typography. The trademark symbol is aligned right-top on the outter side of CentOS word. The trademark symbol must not exceed haf the distance, in points, between CentOS word and the release number on its right. - It would be very convenient for the CentOS Project and its community to to make a registered trademark (®) of CentOS logo. To make a register trademark of CentOS Logo prevents legal complications in the market place of brands. It grants the consistency, through time, of CentOS project corporate visual identity. - - Note The information about trademarks and corporate identity is my personal interpretation of http://en.wikipedia.org/Corporate_identity and http://en.wikipedia.org/Trademark description. If you have practical experiences with these affairs, please serve yourself to improve this section with your reasons. - - - - - See also - - - + Goals + This section describes how typographies are organized in the repository and how to make them available for you to use in GIMPGNU Image Manipulation Program and Inkscape. + Description + The CentOS Project Corporate Identity is attached to DejaVu LGC font-family and Denmark font-family. + + Figure + + + DejaVu-LGC font-family. + + + Figure + + + Denmark font-family. + + + Caution The copyright and license of Denmark typography aren't very specific and that issue may represent a threat to The CentOS Project Corporate Identity. + + The Denmark typography is used as base to build The CentOS Logo (i.e., the main graphic design that connects/identifies all visual manifestations related to The CentOS Project). If the typography used to build The CentOS Logo is compromised somehow, the whole corporate visual identity it represents would be compromised, as well. To prevent such issues, it would be better for The CentOS Project to move on from Denmark typography to another typography (free, preferably) that retain the same visual style of Denmark, but intruce a clearer copyright and license notice. + Usage + + • + + See Directories trunk Identity Models Brands. + + + See also
@@ -1239,41 +1105,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Images</file> Directory Directories trunk Identity Images - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -1284,50 +1139,37 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Models</file> Directory Directories trunk Identity Models - - Goals - - • - - ... - - - - - - Description - - - Brands - - The CentOS Brand provides the one unique name or trademark that connects the producer with their products. In this case, the producer is The CentOS Project and the products are The CentOS Project visual manifestations. - See Directories trunk Identity Models Brands, for more information. - - -
- - • - - ... - - - - - - Usage - - • + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + + Brands - ... + The CentOS Brand provides the one unique name or trademark that connects the producer with their products. In this case, the producer is The CentOS Project and the products are The CentOS Project visual manifestations. + See Directories trunk Identity Models Brands, for more information. - - - - - See also - - - + +
+ See also + + • + + ... + +
@@ -1338,29 +1180,32 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Models/Brands</file> Directory Directories trunk Identity Models Brands - - Goals - - • - - ... - - - - - - Description - - - - Usage - - - - See also - - - + Goals + + • + + ... + + + Description + The CentOS logo is the main visual representation of the CentOS project so the typography used in it must be the same always, no matter where it be shown. It also has to be clear enough to dismiss any confussion between similar typefaces (e.g., the number one (1) sometimes is confuesed with the letter el (l) or letter ai (i)). + As convenction, the word CentOS uses Denmark typography as base, both for the word CentOS and the phrase Community Enterprise Operating System. The phrase size of CentOS logo is half the size in poits the word CentOS has and it below CentOS word and aligned with it on the left. The distance between CentOS word and phrase Community Enterprise Operating System have the size in points the phrase has. + + Figure + + + The CentOS logo construction + + When the CentOS release brand is built, use Denmark typography for the release number. The release number size is two times larger (in height) than default CentOS word. The separation between release number and CentOS word is twice the size in points of separation between CentOS word and phrase Community Enterprise Operating System. + Another component inside CentOS logo is the trademark symbol (TM). This symbol specifies that the CentOS logo must be consider a product brand, even it is not a registered one. The trademark symbol uses DejaVu LGC Sans Regular typography. The trademark symbol is aligned right-top on the outter side of CentOS word. The trademark symbol must not exceed haf the distance, in points, between CentOS word and the release number on its right. + It would be very convenient for the CentOS Project and its community to to make a registered trademark (®) of CentOS logo. To make a register trademark of CentOS Logo prevents legal complications in the market place of brands. It grants the consistency, through time, of CentOS project corporate visual identity. + + Note The information about trademarks and corporate identity is my personal interpretation of http://en.wikipedia.org/Corporate_identity and http://en.wikipedia.org/Trademark description. If you have practical experiences with these affairs, please serve yourself to improve this section with your reasons. + + Usage + See also + +
@@ -1371,41 +1216,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Palettes</file> Directory Directories trunk Identity Palettes - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -1416,41 +1250,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Patterns</file> Directory Directories trunk Identity Patterns - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -1461,61 +1284,48 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes</file> Directory Directories trunk Identity Themes - - Goals - The trunk/Identity/Themes/ directory exists to organize production of CentOS themes. - - - - Description - - Work Flow - Initially, we start working themes on their trunk development line (e.g., trunk/Identity/Themes/Motifs/TreeFlower/), here we organize information that cannot be produced automatically (i.e., background images, concepts, color information, screenshots, etc.). - Later, when theme trunk development line is considered “ready” for implementation (e.g., all required backgrounds have been designed), we create a branch for it (e.g., branches/Identity/Themes/Motifs/TreeFlower/1/). Once the branch has been created, we forget that branch and continue working the trunk development line while others (e.g., an artwork quality assurance team) test the new branch for tunning it up. - Once the branch has been tunned up, and considered “ready” for release, it is freezed under tags/ directory (e.g., tags/Identity/Themes/Motifs/TreeFower/1.0/) for packagers, webmasters, promoters, and anyone who needs images from that CentOS theme the tag was created for. - Both branches and tags, inside CentOS Artwork Repository, use numerical values to identify themselves under the same location. Branches start at one (i.e., 1) and increment one unit for each branch created from the same trunk development line. Tags start at zero (i.e., 0) and increment one unit for each tag created from the same branch development line. - - Convenction Do not freeze trunk development lines using tags directly. If you think you need to freeze a trunk development line, create a branch for it and then freeze that branch instead. - - The trunk development line may introduce problems we cannot see immediatly. Certainly, the high changable nature of trunk development line complicates finding and fixing such problems. On the other hand, the branched development lines provide a more predictable area where only fixes/corrections to current content are commited up to repository. - If others find and fix bugs inside the branched development line, we could merge such changes/experiences back to trunk development line (not visversa) in order for future branches, created from trunk, to benefit. - Time intervals used to create branches and tags may vary, just as different needs may arrive. For example, consider the release schema of CentOS distribution: one major release every 2 years, security updates every 6 months, support for 7 years long. Each time a CentOS distribution is released, specially if it is a major release, there is a theme need in order to cover CentOS distribution artwork requirements. At this point, is where CentOS Artwork Repository comes up to scene. - Before releasing a new major release of CentOS distribution we create a branch for one of several theme development lines available inside the CentOS Artwork Repository, perform quality assurance on it, and later, freeze that branch using tags. Once a the theme branch has been frozen (under tags/ directory), CentOS Packagers (the persons whom build CentOS distribution) can use that frozen branch as source location to fulfill CentOS distribution artwork needs. The same applies to CentOS Webmasters (the persons whom build CentOS websites), and any other visual manifestation required by the project. - - - - - Usage - In this location themes are organized in “Models” —to store common information— and “Motifs”—to store unique information. At rendering time, both motifs and models are combined to produce the final CentOS themes. CentOS themes can be tagged as “Default” or “Alternative”. CentOS themes are maintained by CentOS community. - - - Directories trunk Identity Themes Models - Directories trunk Identity Themes Models - - - - Directories trunk Identity Themes Motifs - Directories trunk Identity Themes Motifs - - - - - - - See also - - - Directories trunk Identity - Directories trunk Identity - - - - Directories trunk - Directories trunk - - - - + Goals + The trunk/Identity/Themes/ directory exists to organize production of CentOS themes. + Description + Work Flow + Initially, we start working themes on their trunk development line (e.g., trunk/Identity/Themes/Motifs/TreeFlower/), here we organize information that cannot be produced automatically (i.e., background images, concepts, color information, screenshots, etc.). + Later, when theme trunk development line is considered “ready” for implementation (e.g., all required backgrounds have been designed), we create a branch for it (e.g., branches/Identity/Themes/Motifs/TreeFlower/1/). Once the branch has been created, we forget that branch and continue working the trunk development line while others (e.g., an artwork quality assurance team) test the new branch for tunning it up. + Once the branch has been tunned up, and considered “ready” for release, it is freezed under tags/ directory (e.g., tags/Identity/Themes/Motifs/TreeFower/1.0/) for packagers, webmasters, promoters, and anyone who needs images from that CentOS theme the tag was created for. + Both branches and tags, inside CentOS Artwork Repository, use numerical values to identify themselves under the same location. Branches start at one (i.e., 1) and increment one unit for each branch created from the same trunk development line. Tags start at zero (i.e., 0) and increment one unit for each tag created from the same branch development line. + + Convenction Do not freeze trunk development lines using tags directly. If you think you need to freeze a trunk development line, create a branch for it and then freeze that branch instead. + + The trunk development line may introduce problems we cannot see immediatly. Certainly, the high changable nature of trunk development line complicates finding and fixing such problems. On the other hand, the branched development lines provide a more predictable area where only fixes/corrections to current content are commited up to repository. + If others find and fix bugs inside the branched development line, we could merge such changes/experiences back to trunk development line (not visversa) in order for future branches, created from trunk, to benefit. + Time intervals used to create branches and tags may vary, just as different needs may arrive. For example, consider the release schema of CentOS distribution: one major release every 2 years, security updates every 6 months, support for 7 years long. Each time a CentOS distribution is released, specially if it is a major release, there is a theme need in order to cover CentOS distribution artwork requirements. At this point, is where CentOS Artwork Repository comes up to scene. + Before releasing a new major release of CentOS distribution we create a branch for one of several theme development lines available inside the CentOS Artwork Repository, perform quality assurance on it, and later, freeze that branch using tags. Once a the theme branch has been frozen (under tags/ directory), CentOS Packagers (the persons whom build CentOS distribution) can use that frozen branch as source location to fulfill CentOS distribution artwork needs. The same applies to CentOS Webmasters (the persons whom build CentOS websites), and any other visual manifestation required by the project. + Usage + In this location themes are organized in “Models” —to store common information— and “Motifs”—to store unique information. At rendering time, both motifs and models are combined to produce the final CentOS themes. CentOS themes can be tagged as “Default” or “Alternative”. CentOS themes are maintained by CentOS community. + + + Directories trunk Identity Themes Models + Directories trunk Identity Themes Models + + + + Directories trunk Identity Themes Motifs + Directories trunk Identity Themes Motifs + + + + See also + + + Directories trunk Identity + Directories trunk Identity + + + + Directories trunk + Directories trunk + + +
@@ -1526,45 +1336,34 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models</file> Directory Directories trunk Identity Themes Models - - Goals - - • - - Organize theme models. + Goals + + • + + Organize theme models. + + + Description + Theme models let you modeling characteristics (e.g., dimensions, translation markers, position of each element on the display area, etc.) common to all themes. Theme models let you reduce the time needed when propagating artistic motifs to different visual manifestations. + Theme models serves as a central pool of design templates for themes to use. This way you can produce themes with different artistic motifs but same characteristics. + Usage + + + Default Design Model + + Default Design Models for CentOS Themes provide the common structural information (e.g., image dimensions, translation markers, trademark position, etc.) the centos-art script uses to produce images when no other design model is specified. - - - - - Description - Theme models let you modeling characteristics (e.g., dimensions, translation markers, position of each element on the display area, etc.) common to all themes. Theme models let you reduce the time needed when propagating artistic motifs to different visual manifestations. - Theme models serves as a central pool of design templates for themes to use. This way you can produce themes with different artistic motifs but same characteristics. - - - - Usage -
- - Default Design Model - - Default Design Models for CentOS Themes provide the common structural information (e.g., image dimensions, translation markers, trademark position, etc.) the centos-art script uses to produce images when no other design model is specified. - - - - Alternative Design Models - - CentOS alternative theme models exist for people how want to use a different visual style on their installations of CentOS distribution. As the visual style is needed for a system already installed components like Anaconda are not required inside alternative themes. Inside alternative themes you find post-installation visual style only (i.e. Backgrounds, Display Managers, Grub, etc.). CentOS alternative themes are maintained by CentOS Community. - - -
- - - - See also - - - + + + Alternative Design Models + + CentOS alternative theme models exist for people how want to use a different visual style on their installations of CentOS distribution. As the visual style is needed for a system already installed components like Anaconda are not required inside alternative themes. Inside alternative themes you find post-installation visual style only (i.e. Backgrounds, Display Managers, Grub, etc.). CentOS alternative themes are maintained by CentOS Community. + + + + See also + +
@@ -1575,81 +1374,70 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default</file> Directory Directories trunk Identity Themes Models Default - - Goals - Default Design Models for CentOS Themes provide design models for the following components: - - - Distribution - - Design models for CentOS Distribution (e.g., Anaconda, Firstboot, Gdm, Grub, Gsplash, Kdm, Ksplash, Rhgb and Syslinux, etc.). See Directories trunk Identity Themes Models Default Distro, for more information. - - - - Concept - - Design models to illustrate Artistic Motifs Concepts. See Directories trunk Identity Themes Models Default Concept, for more information. - - - - Promotion - - Design models for CentOS Promotion stuff (e.g., installation media, posters, etc.). — Removed(xref:Directories trunk Identity Themes Models Default Promo) —, for more information. - - -
- - - - Description - This directory implements the concept of Default Design Models for CentOS Themes. Default Design Models for CentOS Themes provide the common structural information (e.g., image dimensions, translation markers, trademark position, etc.) the centos-art script uses to produce images when no other design model is specified. - Deisgn models in this directory do use the CentOS Release Brand. The CentOS Release Brand is a combination of both The CentOS Type and The CentOS Release Schema used to illustrate the major release of CentOS Distribution the image produced belongs to. — Removed(xref:Directories trunk Identity Models Tpl Brands) —, for more information. - - - - Usage - The CentOS Project maintains near to four different major releases of CentOS Distribution. Each major release of CentOS Distribution has internal differences that make them unique and, at the same time, each CentOS Distribution individually is tagged into the one unique visual manifestation (i.e., Distribution). So, how could we implement the monolithic visual structure in one visual manifestation that has internal difference? - To answer this question we broke the question in two parts and later combined the resultant answers to build a possible solution. - - - How to remark the internal differences visually? - - Merge both The CentOS Project Release Schema into The CentOS Project Trademark to build The CentOS Project Release Trademark. The CentOS Project Release Trademark remarks two things: first, it remarks the image is from The CentOS Project and second, it remarks which major release of CentOS Distribution does the image belongs to. — Removed(xref:Directories trunk Identity Models Tpl Brands) —, for more information on how to develop and improve The CentOS Project Brand. - - - - How to remark the visual resemblance? - - Use a common artistic motifs as background for all CentOS Distribution images. See Directories trunk Identity Themes Motifs, for more information. - - - - So, combining answers above, we could conclude that: - - In order to implement the CentOS Monolithic Visual Structure on CentOS Distribution visual manifestations, a CentOS Release Trademark and a background information based on one unique artistic motif should be used in all remarkable images The CentOS Distribution visual manifestation is made of. - - -
- - Important Remarking the CentOS Release Schema inside each major release of CentOS Distribution —or similar visual manifestations— takes high attention inside The CentOS Project corporate visual identity. It should be very clear for everyone which major release of CentOS Distribution is being used. - - - - - See also - - • + Goals + Default Design Models for CentOS Themes provide design models for the following components: + + + Distribution - Directories trunk Identity Themes + Design models for CentOS Distribution (e.g., Anaconda, Firstboot, Gdm, Grub, Gsplash, Kdm, Ksplash, Rhgb and Syslinux, etc.). See Directories trunk Identity Themes Models Default Distro, for more information. + + + Concept - Directories trunk Identity Themes Models + Design models to illustrate Artistic Motifs Concepts. See Directories trunk Identity Themes Models Default Concept, for more information. + + + Promotion - Directories trunk Identity Themes Motifs + Design models for CentOS Promotion stuff (e.g., installation media, posters, etc.). — Removed(xref:Directories trunk Identity Themes Models Default Promo) —, for more information. - - + +
+ Description + This directory implements the concept of Default Design Models for CentOS Themes. Default Design Models for CentOS Themes provide the common structural information (e.g., image dimensions, translation markers, trademark position, etc.) the centos-art script uses to produce images when no other design model is specified. + Deisgn models in this directory do use the CentOS Release Brand. The CentOS Release Brand is a combination of both The CentOS Type and The CentOS Release Schema used to illustrate the major release of CentOS Distribution the image produced belongs to. — Removed(xref:Directories trunk Identity Models Tpl Brands) —, for more information. + Usage + The CentOS Project maintains near to four different major releases of CentOS Distribution. Each major release of CentOS Distribution has internal differences that make them unique and, at the same time, each CentOS Distribution individually is tagged into the one unique visual manifestation (i.e., Distribution). So, how could we implement the monolithic visual structure in one visual manifestation that has internal difference? + To answer this question we broke the question in two parts and later combined the resultant answers to build a possible solution. + + + How to remark the internal differences visually? + + Merge both The CentOS Project Release Schema into The CentOS Project Trademark to build The CentOS Project Release Trademark. The CentOS Project Release Trademark remarks two things: first, it remarks the image is from The CentOS Project and second, it remarks which major release of CentOS Distribution does the image belongs to. — Removed(xref:Directories trunk Identity Models Tpl Brands) —, for more information on how to develop and improve The CentOS Project Brand. + + + + How to remark the visual resemblance? + + Use a common artistic motifs as background for all CentOS Distribution images. See Directories trunk Identity Themes Motifs, for more information. + + + + So, combining answers above, we could conclude that: + + In order to implement the CentOS Monolithic Visual Structure on CentOS Distribution visual manifestations, a CentOS Release Trademark and a background information based on one unique artistic motif should be used in all remarkable images The CentOS Distribution visual manifestation is made of. + + +
+ + Important Remarking the CentOS Release Schema inside each major release of CentOS Distribution —or similar visual manifestations— takes high attention inside The CentOS Project corporate visual identity. It should be very clear for everyone which major release of CentOS Distribution is being used. + + See also + + • + + Directories trunk Identity Themes + + + Directories trunk Identity Themes Models + + + Directories trunk Identity Themes Motifs + +
@@ -1660,41 +1448,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Concept</file> Directory Directories trunk Identity Themes Models Default Concept - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -1705,91 +1482,80 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Distro</file> Directory Directories trunk Identity Themes Models Default Distro - - Goals - This directory provides design models to produce image files for the following CentOS Distribution components: - - - Syslinux - - Contains design models for syslinux, the program used to boot the CentOS Distribution installation media. See Directories trunk Identity Themes Models Default Distro Syslinux, for more information. - - - - Anaconda - - Contains design models for Anaconda, the program used to install CentOS Distribution. See Directories trunk Identity Themes Models Default Distro Anaconda, for more information. - - - - Firstboot - - Contains design models for the first boot program used to configure the maching onece installed. See Directories trunk Identity Themes Models Default Distro Firstboot, for more information. - - - - Rhgb - - Contains design models for CentOS Graphical Boot, the program used to show the boot process from Grub to Display Manager. See Directories trunk Identity Themes Models Default Distro Rhgb, for more information. - - - - Gdm - - Contains design models for GNOME Display Manager, the program used to log into the manchine once installed and configured. See Directories trunk Identity Themes Models Default Distro Gdm, for more information. - - - - Kdm - - Contains design models for KDE Display Manager, the program used to log into the manchine once installed and configured. See Directories trunk Identity Themes Models Default Distro Kdm, for more information. - - - - Grub - - Contains design models for GRUB (Grand Unified Boot Loader), the program used to boot the machine into an operating system. See Directories trunk Identity Themes Models Default Distro Kdm, for more information. - - - - Gsplash - - Contains design models for GNOME splash, the program used to show the progress information while user's graphical session is loading. See Directories trunk Identity Themes Models Default Distro Gsplash, for more information. - - - - Ksplash - - Contains design models for KDE splash, the program used to show the progress information while user's graphical session is loading. See Directories trunk Identity Themes Models Default Distro Ksplash, for more information. - - -
- - - - Description - The CentOS Distribution visual style is controlled by image files. These image files are packaged inside The CentOS Distribution and made visible once such packages are installed and executed. The way to go for changing The CentOS Distribution visual style is changing all those image files to add the desired visual style first and later, repackage them to make them available inside the final iso files of CentOS Distribution. - - - - Usage - This directory provides organizationl structure to store default design models for CentOS Themes of CentOS Distribution and so it should be considered to be used. - When a new component is added to CentOS Distribution, this is the directory you need to go for specifying design models for image files inside such component. - The procedure to follow is creatig a directory for each component using its very same name (e.g., the directory Anaconda stores image files for Anaconda component, the installer program). Inside the directory, you need to create one scalable vector graphic for each image file inside the component you want to produce images for. This, in order to set image dimensions, image file-name, position of trademarks in the final image, translation markers and whatever common information you need to have specified in them when rendered by centos-art script. - Sometimes, between major releases, image files inside packages can be added, removed or just change their names. In order to describe such image files variations, the design models directory structure is organized in the same way the file variations are introduced (i.e., through The CentOS Project Release Schema). So, each major release of CentOS Distribution does have its own design model directory structure in this directory. - When a whole package is removed from one or all CentOS Distribution major releases, the design models directory structure releated to it is no longer used. However it could be very useful for historical reasons. Also, someone could feel motivated enough to keep himself documenting it or supporting it for whatever reason. - - - - See also - - - Directories trunk Identity Themes Models Default - Directories trunk Identity Themes Models Default - - - - + Goals + This directory provides design models to produce image files for the following CentOS Distribution components: + + + Syslinux + + Contains design models for syslinux, the program used to boot the CentOS Distribution installation media. See Directories trunk Identity Themes Models Default Distro Syslinux, for more information. + + + + Anaconda + + Contains design models for Anaconda, the program used to install CentOS Distribution. See Directories trunk Identity Themes Models Default Distro Anaconda, for more information. + + + + Firstboot + + Contains design models for the first boot program used to configure the maching onece installed. See Directories trunk Identity Themes Models Default Distro Firstboot, for more information. + + + + Rhgb + + Contains design models for CentOS Graphical Boot, the program used to show the boot process from Grub to Display Manager. See Directories trunk Identity Themes Models Default Distro Rhgb, for more information. + + + + Gdm + + Contains design models for GNOME Display Manager, the program used to log into the manchine once installed and configured. See Directories trunk Identity Themes Models Default Distro Gdm, for more information. + + + + Kdm + + Contains design models for KDE Display Manager, the program used to log into the manchine once installed and configured. See Directories trunk Identity Themes Models Default Distro Kdm, for more information. + + + + Grub + + Contains design models for GRUB (Grand Unified Boot Loader), the program used to boot the machine into an operating system. See Directories trunk Identity Themes Models Default Distro Kdm, for more information. + + + + Gsplash + + Contains design models for GNOME splash, the program used to show the progress information while user's graphical session is loading. See Directories trunk Identity Themes Models Default Distro Gsplash, for more information. + + + + Ksplash + + Contains design models for KDE splash, the program used to show the progress information while user's graphical session is loading. See Directories trunk Identity Themes Models Default Distro Ksplash, for more information. + + +
+ Description + The CentOS Distribution visual style is controlled by image files. These image files are packaged inside The CentOS Distribution and made visible once such packages are installed and executed. The way to go for changing The CentOS Distribution visual style is changing all those image files to add the desired visual style first and later, repackage them to make them available inside the final iso files of CentOS Distribution. + Usage + This directory provides organizationl structure to store default design models for CentOS Themes of CentOS Distribution and so it should be considered to be used. + When a new component is added to CentOS Distribution, this is the directory you need to go for specifying design models for image files inside such component. + The procedure to follow is creatig a directory for each component using its very same name (e.g., the directory Anaconda stores image files for Anaconda component, the installer program). Inside the directory, you need to create one scalable vector graphic for each image file inside the component you want to produce images for. This, in order to set image dimensions, image file-name, position of trademarks in the final image, translation markers and whatever common information you need to have specified in them when rendered by centos-art script. + Sometimes, between major releases, image files inside packages can be added, removed or just change their names. In order to describe such image files variations, the design models directory structure is organized in the same way the file variations are introduced (i.e., through The CentOS Project Release Schema). So, each major release of CentOS Distribution does have its own design model directory structure in this directory. + When a whole package is removed from one or all CentOS Distribution major releases, the design models directory structure releated to it is no longer used. However it could be very useful for historical reasons. Also, someone could feel motivated enough to keep himself documenting it or supporting it for whatever reason. + See also + + + Directories trunk Identity Themes Models Default + Directories trunk Identity Themes Models Default + + +
@@ -1800,29 +1566,18 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Distro/Anaconda</file> Directory Directories trunk Identity Themes Models Default Distro Anaconda - - Goals - - • - - ... - - - - - - Description - - - - Usage - - - - See also - - - + Goals + + • + + ... + + + Description + Usage + See also + +
@@ -1833,41 +1588,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Distro/Firstboot</file> Directory Directories trunk Identity Themes Models Default Distro Firstboot - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -1878,41 +1622,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Distro/Gdm</file> Directory Directories trunk Identity Themes Models Default Distro Gdm - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -1923,41 +1656,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Distro/Grub</file> Directory Directories trunk Identity Themes Models Default Distro Grub - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -1968,41 +1690,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Distro/Gsplash</file> Directory Directories trunk Identity Themes Models Default Distro Gsplash - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -2013,41 +1724,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Distro/Kdm</file> Directory Directories trunk Identity Themes Models Default Distro Kdm - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -2058,41 +1758,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Distro/Ksplash</file> Directory Directories trunk Identity Themes Models Default Distro Ksplash - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -2103,41 +1792,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Distro/Rhgb</file> Directory Directories trunk Identity Themes Models Default Distro Rhgb - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -2148,41 +1826,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Distro/Syslinux</file> Directory Directories trunk Identity Themes Models Default Distro Syslinux - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -2193,41 +1860,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Models/Default/Posters</file> Directory Directories trunk Identity Themes Models Default Posters - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -2238,41 +1894,37 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Motifs</file> Directory Directories trunk Identity Themes Motifs - - Goals - The trunk/Identity/Themes/Motifs directory exists to: - - • + Goals + The trunk/Identity/Themes/Motifs directory exists to: + + • + + Organize CentOS themes' artistic motifs. + + + Description + The artistic motif of theme is a graphic design component that provides the visual style of themes, it is used as pattern to connect all visual manifestations inside one unique theme. + Artistic motifs are based on conceptual ideas. Conceptual ideas bring the motivation, they are fuel for the engines of human imagination. Good conceptual ideas may produce good motivation to produce almost anything, and art works don't escape from it. + + + TreeFlower - Organize CentOS themes' artistic motifs. + CentOS like trees, has roots, trunk, branches, leaves and flowers. Day by day they work together in freedom, ruled by the laws of nature and open standards, to show the beauty of its existence. - - - - - Description - The artistic motif of theme is a graphic design component that provides the visual style of themes, it is used as pattern to connect all visual manifestations inside one unique theme. - Artistic motifs are based on conceptual ideas. Conceptual ideas bring the motivation, they are fuel for the engines of human imagination. Good conceptual ideas may produce good motivation to produce almost anything, and art works don't escape from it. -
- - TreeFlower - - CentOS like trees, has roots, trunk, branches, leaves and flowers. Day by day they work together in freedom, ruled by the laws of nature and open standards, to show the beauty of its existence. - - - - Modern - - Modern, squares and circles flowing up. - - -
- If you have new conceptual ideas for CentOS, then you can say that you want to create a new artistic motif for CentOS. To create a new artistic motif you need to create a directory under Identity/Themes/Motifs/ using a name coherent with your conceptual idea. That name will be the name of your artistic motif. If possible, when creating new conceptual ideas for CentOS, think about what CentOS means for you, what does it makes you feel, take your time, think deep, and share; you can improve the idea as time goes on. - Once you have defined a name for your theme, you need to create the motif structure of your theme. The motif structure is the basic direcotry structure you'll use to work your ideas. Here is where you organize your graphic design projects. - To add a new motif structure to CentOS Artwork Repository, you need to use the centos-art command line in the Identity/Themes/Motifs/ directory as described below: - centos-art add --motif=ThemeName - The previous command will create the basic structure of themes for you. The basic structure produced by centos-art command is illustrated in the following figure: - trunk/Identity/Themes/Motifs/$ThemeName/ + + + Modern + + Modern, squares and circles flowing up. + + + + If you have new conceptual ideas for CentOS, then you can say that you want to create a new artistic motif for CentOS. To create a new artistic motif you need to create a directory under Identity/Themes/Motifs/ using a name coherent with your conceptual idea. That name will be the name of your artistic motif. If possible, when creating new conceptual ideas for CentOS, think about what CentOS means for you, what does it makes you feel, take your time, think deep, and share; you can improve the idea as time goes on. + Once you have defined a name for your theme, you need to create the motif structure of your theme. The motif structure is the basic direcotry structure you'll use to work your ideas. Here is where you organize your graphic design projects. + To add a new motif structure to CentOS Artwork Repository, you need to use the centos-art command line in the Identity/Themes/Motifs/ directory as described below: + centos-art add --motif=ThemeName + The previous command will create the basic structure of themes for you. The basic structure produced by centos-art command is illustrated in the following figure: + trunk/Identity/Themes/Motifs/$ThemeName/ |-- Backgrounds | |-- Img | `-- Tpl @@ -2281,77 +1933,70 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes | `-- Tpl |-- Palettes `-- Screenshots - - - - Usage - When designing artistic motifs for CentOS, consider the following recommendations: - - • - - Give a unique (case-sensitive) name to your Motif. This name is used as value wherever theme variable ($THEME) or translation marker (=THEME=) is. Optionally, you can add a description about inspiration and concepts behind your work. - - - Use the location trunk/Identity/Themes/Motifs/$THEME/ to store your work. If it doesn't exist create it. Note that this require you to have previous commit access in CentOS Artwork Repository. - - - The CentOS Project is using the blue color (#204c8d) as base color for its corporate visual identity. Use such base corporate color information as much as possible in your artistic motif designs. - - - Try to make your design fit one of the theme models. - - - Feel free to make your art enterprise-level and beautiful. - - - Add the following information on your artwork (both in a visible design area and document metadata): - - • - - The name (or logo) of your artistic motif. - - - The copyright sentence: Copyright (C) YEAR YOURNAME - - - The license under which the work is released. All CentOS Art works are released under http://creativecommons.org/licenses/by-sa/3.0/Creative Common Share-Alike License 3.0 (http://creativecommons.org/licenses/by-sa/3.0/). - - - - - - - - See also - - - Directories trunk Identity Themes - Directories trunk Identity Themes - - - - Directories trunk Identity - Directories trunk Identity - - - - Directories trunk - Directories trunk - - - - The Backgrounds/ directory is used to organize artistic motif background images and the projects used to build those images. - Background images are linked (using the import feature of Inkscape) inside almost all theme art works. This structure let you make centralized changes on the visual identity and propagate them quickly to other areas. - In this configuration you design background images for different screen resolutions based on the theme artistic motif. - You may create different artistic motifs propositions based on the same conceptual idea. The conceptual idea is what defines a theme. Artistic motifs are interpretations of that idea. - Inside this directory artistic motifs are organized by name (e.g., TreeFlower, Modern, etc.). - Each artistic motif directory represents just one unique artistic motif. - The artistic motif is graphic design used as common pattern to connect all visual manifestations inside one unique theme. The artistic motif is based on a conceptual idea. Artistic motifs provide visual style to themes. - Designing artistic motifs is for anyone interested in creating beautiful themes for CentOS. When building a theme for CentOS, the first design you need to define is the artistic motif. - Inside CentOS Artwork Repository, theme visual styles (a.k.a., artistic motifs) and theme visual structures (a.k.a., design models) are two different working lines. When you design an artistic motif for CentOS you concentrate on its visual style, and eventualy, use the centos-art command line interface to render the visual style, you are currently producing, against an already-made theme model in order to produce the final result. Final images are stored under Motifs/ directory using the model name, and the model directory structure as reference. - The artistic motif base structure is used by centos-art to produce images automatically. This section describes each directory of CentOS artistic motif base structure. - The Backgrounds/ directory is probably the core component, inside Motifs/ directory structure. Inside Backgrounds/ directory you produce background images used by almost all theme models (e.g., Distribution, Websites, Promotion, etc.). The Backgrounds/ directory can contain subdirectories to help you organize the design process. - + Usage + When designing artistic motifs for CentOS, consider the following recommendations: + + • + + Give a unique (case-sensitive) name to your Motif. This name is used as value wherever theme variable ($THEME) or translation marker (=THEME=) is. Optionally, you can add a description about inspiration and concepts behind your work. + + + Use the location trunk/Identity/Themes/Motifs/$THEME/ to store your work. If it doesn't exist create it. Note that this require you to have previous commit access in CentOS Artwork Repository. + + + The CentOS Project is using the blue color (#204c8d) as base color for its corporate visual identity. Use such base corporate color information as much as possible in your artistic motif designs. + + + Try to make your design fit one of the theme models. + + + Feel free to make your art enterprise-level and beautiful. + + + Add the following information on your artwork (both in a visible design area and document metadata): + + • + + The name (or logo) of your artistic motif. + + + The copyright sentence: Copyright (C) YEAR YOURNAME + + + The license under which the work is released. All CentOS Art works are released under http://creativecommons.org/licenses/by-sa/3.0/Creative Common Share-Alike License 3.0 (http://creativecommons.org/licenses/by-sa/3.0/). + + + + + See also + + + Directories trunk Identity Themes + Directories trunk Identity Themes + + + + Directories trunk Identity + Directories trunk Identity + + + + Directories trunk + Directories trunk + + + + The Backgrounds/ directory is used to organize artistic motif background images and the projects used to build those images. + Background images are linked (using the import feature of Inkscape) inside almost all theme art works. This structure let you make centralized changes on the visual identity and propagate them quickly to other areas. + In this configuration you design background images for different screen resolutions based on the theme artistic motif. + You may create different artistic motifs propositions based on the same conceptual idea. The conceptual idea is what defines a theme. Artistic motifs are interpretations of that idea. + Inside this directory artistic motifs are organized by name (e.g., TreeFlower, Modern, etc.). + Each artistic motif directory represents just one unique artistic motif. + The artistic motif is graphic design used as common pattern to connect all visual manifestations inside one unique theme. The artistic motif is based on a conceptual idea. Artistic motifs provide visual style to themes. + Designing artistic motifs is for anyone interested in creating beautiful themes for CentOS. When building a theme for CentOS, the first design you need to define is the artistic motif. + Inside CentOS Artwork Repository, theme visual styles (a.k.a., artistic motifs) and theme visual structures (a.k.a., design models) are two different working lines. When you design an artistic motif for CentOS you concentrate on its visual style, and eventualy, use the centos-art command line interface to render the visual style, you are currently producing, against an already-made theme model in order to produce the final result. Final images are stored under Motifs/ directory using the model name, and the model directory structure as reference. + The artistic motif base structure is used by centos-art to produce images automatically. This section describes each directory of CentOS artistic motif base structure. + The Backgrounds/ directory is probably the core component, inside Motifs/ directory structure. Inside Backgrounds/ directory you produce background images used by almost all theme models (e.g., Distribution, Websites, Promotion, etc.). The Backgrounds/ directory can contain subdirectories to help you organize the design process.
@@ -2362,50 +2007,42 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Motifs/Flame</file> Directory Directories trunk Identity Themes Motifs Flame - - Goals - This section describes the Flame artistic motif. This section may be useful for anyone interested in reproducing the Flame artistic motif, or in creating new artistic motifs for The CentOS Project corporate visual identity. - - - - Description - The Flame artistic motif was built using the flame filter of Gimp 2.2 in CentOS 5.5. - The flame filter of Gimp can produce stunning, randomly generated fractal patterns. The flame filter of Gimp gives us a great oportunity to reduce the time used to produce new artistic motifs, because of its “randomly generated” nature. Once the artistic motif be created, it is propagated through all visual manifestations of CentOS Project corporate visual identity using the centos-art.sh script (see Directories trunk Scripts) inside the CentOS Artwork Repository. - To set the time intervals between each new visual style production, we could reuse the CentOS distribution major release schema. I.e., we could produce a new visual style, every two years, based on a new “randomly generated” flame pattern, and publish the whole corporate visual identity (i.e., distribution stuff, promotion stuff, websites stuff, etc.) with the new major release of CentOS distribution all together at once. - Producing a new visual style is not one day's task. Once we have defined the artistic motif, we need to propagate it through all visual manifestations of The CentOS Project corporate visual identity. When we say that we could produce one new visual style every two years we really mean: to work two years long in order to propagate a new visual style to all visual manifestations of The CentOS Project corporate visual identity. - Obviously, in order to propagate one visual style to all different visual manifestations of The CentOS Project corporate visual identity, we need first to know which the visual manifestations are. To define which visual manifestations are inside The CentOS Project corporate visual identity is one of the goals the CentOS Artwork Repository and this documentation manual are both aimed to satisfy. - Once we define which the visual manifestation are, it is possible to define how to produce them, and this way, organize the automation process. Such automation process is one of the goals of centos-art.sh script. - With the combination of both CentOS Artwork Repository and centos-art.sh scripts we define work lines where translators, programmers, and graphic designers work together to distribute and reduce the amount of time employed to produce The CentOS Project monolithic corporate identity. - From a monolithic corporate visual identity point of view, notice that we are producing a new visual style for the same theme (i.e., Flame). It would be another flame design but still a flame design. This idea is very important to be aware of, because we are somehow “refreshing” the theme, not changing it at all. - This way, as we are “refreshing” the theme, we still keep oursleves inside the monolithic conception we are trying to be attached to (i.e., one unique name, and one unique visual style for all visual manifestations). - Producing artistic motifs is a creative process that may consume long time, specially for people without experienced knowledge on graphic design land. Using “randomly generated” conception to produce artistic motifs could be, practically, a way for anyone to follow in order to produce maintainable artistic motifs in few steps. - Due to the “randomly generated” nature of Flame filter, we find that Flame pattern is not always the same when we use Flame filter interface. - Using the same pattern design for each visual manifestation is essential in order to maintain the visual connection among all visual manifestations inside the same theme. Occasionally, we may introduce pattern variations in opacity, size, or even position but never change the pattern design itself, nor the color information used by images considered part of the same theme. - - Important When we design background images, which are considered part of the same theme, it is essential to use the same design pattern always. This is what makes theme images to be visually connected among themeselves, and so, the reason we use to define the word “theme” as: a set of images visually connected among themeselves. - - In order for us to reproduce the same flame pattern always, Flame filter interface provides the Save and Open options. The Save option brings up a file save dialog that allows you to save the current Flame settings for the plug-in, so that you can recreate them later. The Open option brings up a file selector that allows you to open a previously saved Flame settings file. - The Flame settings we used in our example are saved in the file named 800x600.xcf-flame.def, inside the Backgrounds/Xcf directory structure. - - - - See also - - • - - See Directories trunk Identity Themes Motifs. - - - See Directories trunk Identity Themes. - - - See Directories trunk Identity. - - - See Directories trunk. - - - + Goals + This section describes the Flame artistic motif. This section may be useful for anyone interested in reproducing the Flame artistic motif, or in creating new artistic motifs for The CentOS Project corporate visual identity. + Description + The Flame artistic motif was built using the flame filter of Gimp 2.2 in CentOS 5.5. + The flame filter of Gimp can produce stunning, randomly generated fractal patterns. The flame filter of Gimp gives us a great oportunity to reduce the time used to produce new artistic motifs, because of its “randomly generated” nature. Once the artistic motif be created, it is propagated through all visual manifestations of CentOS Project corporate visual identity using the centos-art.sh script (see Directories trunk Scripts) inside the CentOS Artwork Repository. + To set the time intervals between each new visual style production, we could reuse the CentOS distribution major release schema. I.e., we could produce a new visual style, every two years, based on a new “randomly generated” flame pattern, and publish the whole corporate visual identity (i.e., distribution stuff, promotion stuff, websites stuff, etc.) with the new major release of CentOS distribution all together at once. + Producing a new visual style is not one day's task. Once we have defined the artistic motif, we need to propagate it through all visual manifestations of The CentOS Project corporate visual identity. When we say that we could produce one new visual style every two years we really mean: to work two years long in order to propagate a new visual style to all visual manifestations of The CentOS Project corporate visual identity. + Obviously, in order to propagate one visual style to all different visual manifestations of The CentOS Project corporate visual identity, we need first to know which the visual manifestations are. To define which visual manifestations are inside The CentOS Project corporate visual identity is one of the goals the CentOS Artwork Repository and this documentation manual are both aimed to satisfy. + Once we define which the visual manifestation are, it is possible to define how to produce them, and this way, organize the automation process. Such automation process is one of the goals of centos-art.sh script. + With the combination of both CentOS Artwork Repository and centos-art.sh scripts we define work lines where translators, programmers, and graphic designers work together to distribute and reduce the amount of time employed to produce The CentOS Project monolithic corporate identity. + From a monolithic corporate visual identity point of view, notice that we are producing a new visual style for the same theme (i.e., Flame). It would be another flame design but still a flame design. This idea is very important to be aware of, because we are somehow “refreshing” the theme, not changing it at all. + This way, as we are “refreshing” the theme, we still keep oursleves inside the monolithic conception we are trying to be attached to (i.e., one unique name, and one unique visual style for all visual manifestations). + Producing artistic motifs is a creative process that may consume long time, specially for people without experienced knowledge on graphic design land. Using “randomly generated” conception to produce artistic motifs could be, practically, a way for anyone to follow in order to produce maintainable artistic motifs in few steps. + Due to the “randomly generated” nature of Flame filter, we find that Flame pattern is not always the same when we use Flame filter interface. + Using the same pattern design for each visual manifestation is essential in order to maintain the visual connection among all visual manifestations inside the same theme. Occasionally, we may introduce pattern variations in opacity, size, or even position but never change the pattern design itself, nor the color information used by images considered part of the same theme. + + Important When we design background images, which are considered part of the same theme, it is essential to use the same design pattern always. This is what makes theme images to be visually connected among themeselves, and so, the reason we use to define the word “theme” as: a set of images visually connected among themeselves. + + In order for us to reproduce the same flame pattern always, Flame filter interface provides the Save and Open options. The Save option brings up a file save dialog that allows you to save the current Flame settings for the plug-in, so that you can recreate them later. The Open option brings up a file selector that allows you to open a previously saved Flame settings file. + The Flame settings we used in our example are saved in the file named 800x600.xcf-flame.def, inside the Backgrounds/Xcf directory structure. + See also + + • + + See Directories trunk Identity Themes Motifs. + + + See Directories trunk Identity Themes. + + + See Directories trunk Identity. + + + See Directories trunk. + +
@@ -2416,35 +2053,24 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Motifs/Modern</file> Directory Directories trunk Identity Themes Motifs Modern - - Goals - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -2455,41 +2081,30 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Motifs/Pipes</file> Directory Directories trunk Identity Themes Motifs Pipes - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -2500,23 +2115,12 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Themes/Motifs/TreeFlower</file> Directory Directories trunk Identity Themes Motifs TreeFlower - - Goals - - - - Description - - - - Usage - - - - See also - - - + Goals + Description + Usage + See also + +
@@ -2527,113 +2131,89 @@ trunk/Identity/Themes/Motifs/THEMENAME/THEMEVERSION/Brushes
The <file>trunk/Identity/Webenv</file> Directory Directories trunk Identity Webenv - - Goals - - • - - ... - - - - - - Description - The CentOS web environment is formed by a central web application —to cover base needs (e.g., per-major release information like release notes, lifetime, downloads, documentation, support, security advisories, bugs, etc.)— and many different free web applications —to cover specific needs (e.g., wiki, mailing lists, etc.)—. - The CentOS web environment is addressed to solve the following issues: - - • - - One unique name and one unique visual style to all web applications used inside the web environment. - - - One-step navigation to web applications inside the environment. - + Goals + + • + + ... + + + Description + The CentOS web environment is formed by a central web application —to cover base needs (e.g., per-major release information like release notes, lifetime, downloads, documentation, support, security advisories, bugs, etc.)— and many different free web applications —to cover specific needs (e.g., wiki, mailing lists, etc.)—. + The CentOS web environment is addressed to solve the following issues: + + • + + One unique name and one unique visual style to all web applications used inside the web environment. + + + One-step navigation to web applications inside the environment. + + + High degree of customization to change the visual style of all web applications with few changes (e.g, updating just two or three images plus common style sheet [CSS] definitions). + + + The CentOS project is attached to a monolithic corporate visual identity (see Directories trunk Identity), where all visual manifestations have one unique name and one unique visual style. This way, the CentOS web environment has one unique name (the CentOS brand) and one unique visual style (the CentOS default theme) for all its visual manifestations, the web applications in this case. + Since a maintainance point of view, achiving the one unique visual style inside CentOS web environment is not a simple task. The CentOS web environment is built upon many different web applications which have different visual styles and different internal ways to customize their own visual styles. For example: MoinMoin, the web application used to support the CentOS wiki (http://wiki.centos.org/) is highly customizable but Mailman (in its 2.x.x serie), the web application used to support the CentOS mailing list, doesn't supportThe theme support of Mailman may be introduced in mailman-3.x.x release. a customization system that separates presentation from logic, similar to that used by MoinMoin. + This visual style diversity complicates our goal of one unique visual style for all web applications. So, if we want one unique visual style for all web applications used, it is innevitable to modify the web applications in order to implement the CentOS one unique visual style customization in them. Direct modification of upstream applications is not convenient because upstream applications come with their one visual style and administrators take the risk of loosing all customization changes the next time the application be updated (since not all upstream web applications, used in CentOS web environment, separate presentation from logic). + To solve the “one unique visual style” issue, installation and actualization of web applications —used inside CentOS web environment— need to be independent from upstream web applications development line; in a way that CentOS web environment administrators can install and update web applications freely without risk of loosing the one unique visual style customization changes. + At the surface of this issue we can see the need of one specific yum repository to store CentOS web environment customized web applications. + Design model (without ads) + Design model (with ads) + HTML definitions + Controlling visual style + Inside CentOS web environment, the visual style is controlled by the following compenents: + + + Webenv header background - High degree of customization to change the visual style of all web applications with few changes (e.g, updating just two or three images plus common style sheet [CSS] definitions). - - - The CentOS project is attached to a monolithic corporate visual identity (see Directories trunk Identity), where all visual manifestations have one unique name and one unique visual style. This way, the CentOS web environment has one unique name (the CentOS brand) and one unique visual style (the CentOS default theme) for all its visual manifestations, the web applications in this case. - Since a maintainance point of view, achiving the one unique visual style inside CentOS web environment is not a simple task. The CentOS web environment is built upon many different web applications which have different visual styles and different internal ways to customize their own visual styles. For example: MoinMoin, the web application used to support the CentOS wiki (http://wiki.centos.org/) is highly customizable but Mailman (in its 2.x.x serie), the web application used to support the CentOS mailing list, doesn't supportThe theme support of Mailman may be introduced in mailman-3.x.x release. a customization system that separates presentation from logic, similar to that used by MoinMoin. - This visual style diversity complicates our goal of one unique visual style for all web applications. So, if we want one unique visual style for all web applications used, it is innevitable to modify the web applications in order to implement the CentOS one unique visual style customization in them. Direct modification of upstream applications is not convenient because upstream applications come with their one visual style and administrators take the risk of loosing all customization changes the next time the application be updated (since not all upstream web applications, used in CentOS web environment, separate presentation from logic). - To solve the “one unique visual style” issue, installation and actualization of web applications —used inside CentOS web environment— need to be independent from upstream web applications development line; in a way that CentOS web environment administrators can install and update web applications freely without risk of loosing the one unique visual style customization changes. - At the surface of this issue we can see the need of one specific yum repository to store CentOS web environment customized web applications. - - - Design model (without ads) - - - - Design model (with ads) - - - - HTML definitions - - - - Controlling visual style - Inside CentOS web environment, the visual style is controlled by the following compenents: -
- - Webenv header background - - - - - - CSS definitions - - + + + CSS definitions + + - - -
- - - - Producing visual style - The visual style of CentOS web environment is defined in the following files: - + + + Producing visual style + The visual style of CentOS web environment is defined in the following files: + - As graphic designer you use 1024x250.xcf file to produce 1024x250-bg.png file. Later, inside 1024x250.svg file, you use the 1024x250-bg.png file as background layer to draw your vectorial design. When you consider you artwork ready, use the centos-art.sh script, as described below, to produce the visual style controller images of CentOS web environment. - As graphic designer you use 1024x250.xcf file to produce 1024x250-bg.png file. Later, inside 1024x250.svg file, you use the 1024x250-bg.png file as background layer to draw your vectorial design. When you consider you artwork ready, use the centos-art.sh script, as described below, to produce the visual style controller images of CentOS web environment. + - Once you have rendered required image files, changing the visual style of CentOS web environment is a matter of replacing old image files with new ones, inside webenv repository file system structure. The visual style changes will take effect the next time customization line of CentOS web applications be packaged, uploded, and installed from [webenv] or [webenv-test] repositories. - - - - Navigation - Inside CentOS web environment, the one-step navegation between web applications is addressed using the web environment navigation bar. The web environment navigation bar contains links to main applications and is always visible no matter where you are inside the web environment. - - - - Development and release cycle - The CentOS web environment development and relase cycle is described below: - - - Download - - The first action is download the source code of web applications we want to use inside CentOS web environment. - - Important The source location from which web application are downloaded is very important. Use SRPMs from CentOS [base] and [updates] repositories as first choise, and third party repositories (e.g. RPMForge, EPEL, etc.) as last resource. - - - - - Prepare - - Once web application source code has been downloaded, our duty is organize its files inside webenv version controlled repository. - When preparing the structure keep in mind that different web applications have different visual styles, and also different ways to implement it. A convenient way to organize the file system structure would be create one development line for each web application we use inside CentOS web environment. For example, consider the following file system structure: - Once you have rendered required image files, changing the visual style of CentOS web environment is a matter of replacing old image files with new ones, inside webenv repository file system structure. The visual style changes will take effect the next time customization line of CentOS web applications be packaged, uploded, and installed from [webenv] or [webenv-test] repositories. + Navigation + Inside CentOS web environment, the one-step navegation between web applications is addressed using the web environment navigation bar. The web environment navigation bar contains links to main applications and is always visible no matter where you are inside the web environment. + Development and release cycle + The CentOS web environment development and relase cycle is described below: +
+ + Download + + The first action is download the source code of web applications we want to use inside CentOS web environment. + + Important The source location from which web application are downloaded is very important. Use SRPMs from CentOS [base] and [updates] repositories as first choise, and third party repositories (e.g. RPMForge, EPEL, etc.) as last resource. + + + + + Prepare + + Once web application source code has been downloaded, our duty is organize its files inside webenv version controlled repository. + When preparing the structure keep in mind that different web applications have different visual styles, and also different ways to implement it. A convenient way to organize the file system structure would be create one development line for each web application we use inside CentOS web environment. For example, consider the following file system structure: + - - - - Customize - - Once web applications have been organized inside the version controlled repository file system, use subversion to create the CentOS customization development line of web applications source code. For example, using the above file system structure, you can create the customization development line of webapp1-0.0.1/ with the following command: - + + + Customize + + Once web applications have been organized inside the version controlled repository file system, use subversion to create the CentOS customization development line of web applications source code. For example, using the above file system structure, you can create the customization development line of webapp1-0.0.1/ with the following command: + - The command above creates the following structure: - The command above creates the following structure: + - In the above structure, the webapp1-0.0.1-webenv/ directory is the place where you customize the visual style of webapp1-0.0.1/ web application. - - Tip Use the diff command of Subversion between CentOS customization and upstream development lines to know what you are changing exactly. - - - - - Build packages - - When web application has been customized, build the web application RPM and SRPM using the source location with -webenv prefix. - In the above structure, the webapp1-0.0.1-webenv/ directory is the place where you customize the visual style of webapp1-0.0.1/ web application. + + Tip Use the diff command of Subversion between CentOS customization and upstream development lines to know what you are changing exactly. + + + + + Build packages + + When web application has been customized, build the web application RPM and SRPM using the source location with -webenv prefix. + - - - - Release for testing - - When the customized web application has been packaged, make packages available for testing and quality assurance. This can be achives using a [webenv-test] yum repository. - - Note The [webenv-test] repository is not shipped inside CentOS distribution default yum configuraiton. In order to use [webenv-test] repository you need to configure it first. - - If some problem is found to install/update/use the customized version of web application, the problem is notified somewhere (a bugtracker maybe) and the customization face is repated in order to fix the problem. To release the new package add a number after -webenv prefix. For example, if some problem is found in webapp1-0.0.1-webenv.rpm, when it be fixed the new package will be named webapp1-0.0.1-webenv-1.rpm. If a problem is found in webapp1-0.0.1-webenv-1.rpm, when it be fixed the new package will be named webapp1-0.0.1-webenv-2.rpm, and so on. - The “customization — release for testing” process is repeated until CentOS quality assurance team considers the package is ready for production. - - - - Release for production - - When customized web application packages are considered ready for production they are moved from [webenv-test] to [webenv] repository. This action is commited by CentOS quality assurance team. - - Note The [webenv] repository is not shipped inside CentOS distribution default yum configuraiton. In order to use [webenv] repository you need to configure it first. - - - -
- - - - The [webenv-test] repository - + + + Release for testing + + When the customized web application has been packaged, make packages available for testing and quality assurance. This can be achives using a [webenv-test] yum repository. + + Note The [webenv-test] repository is not shipped inside CentOS distribution default yum configuraiton. In order to use [webenv-test] repository you need to configure it first. + + If some problem is found to install/update/use the customized version of web application, the problem is notified somewhere (a bugtracker maybe) and the customization face is repated in order to fix the problem. To release the new package add a number after -webenv prefix. For example, if some problem is found in webapp1-0.0.1-webenv.rpm, when it be fixed the new package will be named webapp1-0.0.1-webenv-1.rpm. If a problem is found in webapp1-0.0.1-webenv-1.rpm, when it be fixed the new package will be named webapp1-0.0.1-webenv-2.rpm, and so on. + The “customization — release for testing” process is repeated until CentOS quality assurance team considers the package is ready for production. + + + + Release for production + + When customized web application packages are considered ready for production they are moved from [webenv-test] to [webenv] repository. This action is commited by CentOS quality assurance team. + + Note The [webenv] repository is not shipped inside CentOS distribution default yum configuraiton. In order to use [webenv] repository you need to configure it first. + + + + + The [webenv-test] repository + - - - - - The [webenv] repository - The [webenv] repository + - - - - - Priority configuration - Both [webenv] and [webenv-test] repositories update packages inside CentOS [base] and CentOS [updates] repositories. - - - - - Usage - - • - - ... - - - - - - See also - - - + Priority configuration + Both [webenv] and [webenv-test] repositories update packages inside CentOS [base] and CentOS [updates] repositories. + Usage + + • + + ... + + + See also + +
@@ -2814,41 +2377,30 @@ priority=10
The <file>trunk/Manual</file> Directory Directories trunk Manual - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -2859,28 +2411,24 @@ priority=10
The <file>trunk/Scripts</file> Directory Directories trunk Scripts - - Goals - The trunk/Scripts directory exists to organize the trunk development line of centos-art.sh automation script. The centos-art.sh script standardizes tasks you need to do frequently inside CentOS Artwork Repository. - - - - Description - The best way to understand centos-art.sh automation script is studying its source code. However, as start point, you may prefer to read an introductory resume before diving into the source code details. - The centos-art.sh script is written in Bash. Most tasks, inside centos-art.sh script, have been organized in many specific functionalities that you can invoke from the centos-art command-line interface. - When you type the centos-art command in your terminal, the operating system trys to execute that command. In order to execute the command, the operating system needs to know where it is, so the operating system uses the PATH environment variable to look for that command location. If your system was prepared to use CentOS Artwork Repository correctly (— Removed(pxref:trunk Scripts Bash Functions Verify) —), you should have a symbolic link inside ~/bin/ directory that points to the centos-art.sh script file. As ~/bin/ directory is, by default, inside PATH environment variable, the execution of centos-art command runs the centos-art.sh script. - When centos-art.sh script is executed, the first it does is executing the trunk/Scripts/Bash/initEnvironment.sh script to initialize global variables (e.g., gettext variables) and global function scripts. Global function scripts are located inside trunk/Scripts/Bash/Functions directory and their file names begin with cli. Global function scripts provide common functionalities that can be used anywhere inside centos-art.sh script execution environment. - Once global variables and function scripts have been loaded, centos-art.sh script executes the cli global function from cli.sh function script to retrive command-line arguments and define some default values that may be used later by specific function scripts (— Removed(pxref:trunk Scripts Bash Functions) —). - As convenction, the centos-art.sh command-line arguments have the following format: - Goals + The trunk/Scripts directory exists to organize the trunk development line of centos-art.sh automation script. The centos-art.sh script standardizes tasks you need to do frequently inside CentOS Artwork Repository. + Description + The best way to understand centos-art.sh automation script is studying its source code. However, as start point, you may prefer to read an introductory resume before diving into the source code details. + The centos-art.sh script is written in Bash. Most tasks, inside centos-art.sh script, have been organized in many specific functionalities that you can invoke from the centos-art command-line interface. + When you type the centos-art command in your terminal, the operating system trys to execute that command. In order to execute the command, the operating system needs to know where it is, so the operating system uses the PATH environment variable to look for that command location. If your system was prepared to use CentOS Artwork Repository correctly (— Removed(pxref:trunk Scripts Bash Functions Verify) —), you should have a symbolic link inside ~/bin/ directory that points to the centos-art.sh script file. As ~/bin/ directory is, by default, inside PATH environment variable, the execution of centos-art command runs the centos-art.sh script. + When centos-art.sh script is executed, the first it does is executing the trunk/Scripts/Bash/initEnvironment.sh script to initialize global variables (e.g., gettext variables) and global function scripts. Global function scripts are located inside trunk/Scripts/Bash/Functions directory and their file names begin with cli. Global function scripts provide common functionalities that can be used anywhere inside centos-art.sh script execution environment. + Once global variables and function scripts have been loaded, centos-art.sh script executes the cli global function from cli.sh function script to retrive command-line arguments and define some default values that may be used later by specific function scripts (— Removed(pxref:trunk Scripts Bash Functions) —). + As convenction, the centos-art.sh command-line arguments have the following format: + - In the above example, centos-art is the command you use to invoke centos-art.sh script. The arg1 is required and represents the functionality you want to perform (e.g., , , , , etc.). The remaining arguments are modifiers to . The definition is required and represets, specifically, the action inside the functionality you want to perform. The and on, are optional. - Once command-line arguments have been retrived, the centos-art.sh script loads specific functionalities using the cli_getFunctions.sh function script. Only one specific functionality can be loaded at one script execution I.e., you run centos-art.sh script to run just one functionality. - - Figure - - In the above example, centos-art is the command you use to invoke centos-art.sh script. The arg1 is required and represents the functionality you want to perform (e.g., , , , , etc.). The remaining arguments are modifiers to . The definition is required and represets, specifically, the action inside the functionality you want to perform. The and on, are optional. + Once command-line arguments have been retrived, the centos-art.sh script loads specific functionalities using the cli_getFunctions.sh function script. Only one specific functionality can be loaded at one script execution I.e., you run centos-art.sh script to run just one functionality. + + Figure + + - The functionalities initialization environment. - - Functionalities are implemented by means of actions. Once the functionality has been initiazalized, actions initialization take place for that functionality. Actions initialization model is very similar to functions initialization model. But with the difference, that actions are loaded inside function environment, and so, share variables and functions defined inside function environment. - - Figure - - The functionalities initialization environment. + + Functionalities are implemented by means of actions. Once the functionality has been initiazalized, actions initialization take place for that functionality. Actions initialization model is very similar to functions initialization model. But with the difference, that actions are loaded inside function environment, and so, share variables and functions defined inside function environment. + + Figure + + - The actions initialization environment. - - - - - Usage - The centos-art.sh script usage information is described inside each specific function documentation (— Removed(pxref:trunk Scripts Bash Functions) —). - - - - See also - - - Directories trunk Scripts - Directories trunk Scripts - - - - Directories trunk Scripts Functions - Directories trunk Scripts Functions - + The actions initialization environment. + + Usage + The centos-art.sh script usage information is described inside each specific function documentation (— Removed(pxref:trunk Scripts Bash Functions) —). + See also + + + Directories trunk Scripts + Directories trunk Scripts + + + + Directories trunk Scripts Functions + Directories trunk Scripts Functions + - - - + +
@@ -2981,34 +2522,30 @@ centos-art function path/to/dir --options
The <file>trunk/Scripts/Functions</file> Directory Directories trunk Scripts Functions - - Goals - The trunk/Scripts/Bash/Functions directory exists to organize centos-art.sh specific functionalities. - - - - Description - The specific functions of centos-art.sh script are designed with “Software Toolbox” philosophy (see Toolbox introductioncoreutils.info) in mind: each program “should do one thing well”. Inside centos-art.sh script, each specific functionality is considered a program that should do one thing well. Of course, if you find that they still don't do it, feel free to improve them in order for them to do so. - The specific functions of centos-art.sh script are organized inside specific directories under trunk/Scripts/Bash/Functions location. Each specific function directory should be named as the function it represents, with the first letter in uppercase. For example, if the function name is render, the specific function directory for it would be trunk/Scripts/Bash/Functions/Render. - To better understand how specific functions of centos-art.sh script are designed, lets create one function which only goal is to output different kind of greetings to your screen. - When we create specific functions for centos-art.sh script it is crucial to know what these functions will do exactly and if there is any function that already does what we intend to do. If there is no one, it is good time to create them then. Otherwise, if functionalities already available don't do what you exactly expect, contact their authors and work together to improve them. - - Tip Join CentOS developers mailing list centos-art@centos.org to share your ideas. - - It is also worth to know what global functions and variables do we have available inside centos-art.sh script, so advantage can be taken from them. Global variables are defined inside global function scripts. Global functions scripts are stored immediatly under trunk/Scripts/Bash/Functions directory, in files begining with cli prefix. - OK, let's begin with our functionality example. - What function name do we use? Well, lets use greet. Note that hello word is not a verb; but an expression, a kind of greeting, an interjection specifically. In contrast, greet is a verb and describes what we do when we say Hello!, Hi!, and similar expressions. - So far, we've gathered the following function information: - Goals + The trunk/Scripts/Bash/Functions directory exists to organize centos-art.sh specific functionalities. + Description + The specific functions of centos-art.sh script are designed with “Software Toolbox” philosophy (see Toolbox introductioncoreutils.info) in mind: each program “should do one thing well”. Inside centos-art.sh script, each specific functionality is considered a program that should do one thing well. Of course, if you find that they still don't do it, feel free to improve them in order for them to do so. + The specific functions of centos-art.sh script are organized inside specific directories under trunk/Scripts/Bash/Functions location. Each specific function directory should be named as the function it represents, with the first letter in uppercase. For example, if the function name is render, the specific function directory for it would be trunk/Scripts/Bash/Functions/Render. + To better understand how specific functions of centos-art.sh script are designed, lets create one function which only goal is to output different kind of greetings to your screen. + When we create specific functions for centos-art.sh script it is crucial to know what these functions will do exactly and if there is any function that already does what we intend to do. If there is no one, it is good time to create them then. Otherwise, if functionalities already available don't do what you exactly expect, contact their authors and work together to improve them. + + Tip Join CentOS developers mailing list centos-art@centos.org to share your ideas. + + It is also worth to know what global functions and variables do we have available inside centos-art.sh script, so advantage can be taken from them. Global variables are defined inside global function scripts. Global functions scripts are stored immediatly under trunk/Scripts/Bash/Functions directory, in files begining with cli prefix. + OK, let's begin with our functionality example. + What function name do we use? Well, lets use greet. Note that hello word is not a verb; but an expression, a kind of greeting, an interjection specifically. In contrast, greet is a verb and describes what we do when we say Hello!, Hi!, and similar expressions. + So far, we've gathered the following function information: + - The greet.sh function script is the first file centos-art.sh script loads when the greet functionality is called using commands like centos-art greet --hello='World'. The greet.sh function script contains the greet function definition. - Inside centos-art.sh script, as convenction, each function script has one top commentary, followed by one blank line, and then one function defintion below it only. - Inside centos-art.sh script functions, top commentaries have the following components: the functionality description, one-line for copyright note with your personal information, the license under which the function source code is released —the centos-art.sh script is released as GPL, so do all its functions—, the $Id$ keyword of Subversion is later expanded by svn propset command. - In our greet function example, top commentary for greet.sh function script would look like the following: - The greet.sh function script is the first file centos-art.sh script loads when the greet functionality is called using commands like centos-art greet --hello='World'. The greet.sh function script contains the greet function definition. + Inside centos-art.sh script, as convenction, each function script has one top commentary, followed by one blank line, and then one function defintion below it only. + Inside centos-art.sh script functions, top commentaries have the following components: the functionality description, one-line for copyright note with your personal information, the license under which the function source code is released —the centos-art.sh script is released as GPL, so do all its functions—, the $Id$ keyword of Subversion is later expanded by svn propset command. + In our greet function example, top commentary for greet.sh function script would look like the following: + - After top commentary, separated by one blank line, the greet function definition would look like the following: - After top commentary, separated by one blank line, the greet function definition would look like the following: + - The first definition inside greet function, are global variables that will be available along greet function execution environment. This time we didn't use global variable definitions for greet function execution environment, so we left that section empty. - Later, we call greet_getActions function to define the command-line interface of greet functionality. The command-line interface of greet functionality defines what and how actions are performed, based on arguments combination passed to centos-art.sh script. - The first definition inside greet function, are global variables that will be available along greet function execution environment. This time we didn't use global variable definitions for greet function execution environment, so we left that section empty. + Later, we call greet_getActions function to define the command-line interface of greet functionality. The command-line interface of greet functionality defines what and how actions are performed, based on arguments combination passed to centos-art.sh script. + - The ACTIONNAM global variable is defined in cli.sh function script and contains the value passed before the equal sign (i.e., =) in the second command-line argument of centos-art.sh script. For example, if the second command-line argument is , the value of ACTIONNAM variable would be --hello. Using this configuration let us deside which action to perform based on the action name passed to centos-art.sh script as second argument. - The greet function definition makes available two valid greetings through and options. If no one of them is provided as second command-line argument, the * case is evaluated instead. - The * case and its two lines further on should always be present in _getActions.sh function scripts, no matter what specific functionality you are creating. This convenction helps the user to find out documentation about current functionality in use, when no valid action is provided. - The greet_doHello and greet_doBye function definitions are the core of greet specific functionality. In such function definitions we set what our greet function really does: to output different kinds of greetings. - The ACTIONNAM global variable is defined in cli.sh function script and contains the value passed before the equal sign (i.e., =) in the second command-line argument of centos-art.sh script. For example, if the second command-line argument is , the value of ACTIONNAM variable would be --hello. Using this configuration let us deside which action to perform based on the action name passed to centos-art.sh script as second argument. + The greet function definition makes available two valid greetings through and options. If no one of them is provided as second command-line argument, the * case is evaluated instead. + The * case and its two lines further on should always be present in _getActions.sh function scripts, no matter what specific functionality you are creating. This convenction helps the user to find out documentation about current functionality in use, when no valid action is provided. + The greet_doHello and greet_doBye function definitions are the core of greet specific functionality. In such function definitions we set what our greet function really does: to output different kinds of greetings. + - The greet_doHello function definition is stored in greet_doHello.sh function script. - The greet_doHello function definition is stored in greet_doHello.sh function script. + - The greet_doBye function definition is stored in the greet_doBye.sh function script. - Both greet_doHello.sh and greet_doBye.sh function scripts are stored inside greet function directory path (i.e. trunk/Scripts/Bash/Functions/Greet). - The ACTIONVAL global variable is defined in cli.sh function script and contains the value passed after the equal sign (i.e., =) in the second command-line argument of centos-art.sh script. For example, if the second command-line argument is , the value of ACTIONVAL variable would be World without quotes. - Let's see how greet specific functionality files are organzied under greet function directory. To see file organization we use the tree command: - The greet_doBye function definition is stored in the greet_doBye.sh function script. + Both greet_doHello.sh and greet_doBye.sh function scripts are stored inside greet function directory path (i.e. trunk/Scripts/Bash/Functions/Greet). + The ACTIONVAL global variable is defined in cli.sh function script and contains the value passed after the equal sign (i.e., =) in the second command-line argument of centos-art.sh script. For example, if the second command-line argument is , the value of ACTIONVAL variable would be World without quotes. + Let's see how greet specific functionality files are organzied under greet function directory. To see file organization we use the tree command: + - To try the greet specific functionality we've just created, pass the function name (i.e., greet) as first argument to centos-art.sh script, and any of the valid options as second argument. Some examples are illustrated below: - To try the greet specific functionality we've just created, pass the function name (i.e., greet) as first argument to centos-art.sh script, and any of the valid options as second argument. Some examples are illustrated below: + - The word World in the examples above can be anything. In fact, change it to have a little fun. - Now that we have a specific function that works as we expect, it is time to document it. To document greet specific functionality, we use its directory path and the manual functionality (— Removed(pxref:trunk Scripts Bash Functions Manual) —) of centos-art.sh script, just as the following command illustrates: - The word World in the examples above can be anything. In fact, change it to have a little fun. + Now that we have a specific function that works as we expect, it is time to document it. To document greet specific functionality, we use its directory path and the manual functionality (— Removed(pxref:trunk Scripts Bash Functions Manual) —) of centos-art.sh script, just as the following command illustrates: + - To have a well documented function helps user to understand how your function really works, and how it should be used. When no valid action is passed to a function, the centos-art.sh script uses the function documentation entry as vehicle to communicate which the valid functions are. When no documentation entry exists for a function, the centos-art.sh script informs that no documentation entry exists for such function and requests user to create it right at that time. - Now that we have documented our function, it is time to translate its output messages to different languages. To translate specific functionality output messages to different languages we use the locale functionality (— Removed(pxref:trunk Scripts Bash Functions Locale) —) of centos-art.sh script, just as the following command illustrates: - To have a well documented function helps user to understand how your function really works, and how it should be used. When no valid action is passed to a function, the centos-art.sh script uses the function documentation entry as vehicle to communicate which the valid functions are. When no documentation entry exists for a function, the centos-art.sh script informs that no documentation entry exists for such function and requests user to create it right at that time. + Now that we have documented our function, it is time to translate its output messages to different languages. To translate specific functionality output messages to different languages we use the locale functionality (— Removed(pxref:trunk Scripts Bash Functions Locale) —) of centos-art.sh script, just as the following command illustrates: + - - Warning To translate output messages in different languages, your system locale information —as in LANG environment variable— must be set to that locale you want to produce translated messages for. For example, if you want to produce translated messages for Spanish language, your system locale information must be set to es_ES.UTF-8, or similar, first. - - Well, it seems that our example is rather complete by now. - In greet function example we've described so far, we only use cli_printMessage global function in action specific function definitions in order to print messages, but more interesting things can be achieved inside action specific function definitions. For example, if you pass a directory path as action value in second argument, you could retrive a list of files from therein, and process them. If the list of files turns too long or you just want to control which files to process, you could add the third argument in the form and reduce the amount of files to process using a regular expression pattern. - The greet function described in this section may serve you as an introduction to understand how specific functionalities work inside centos-art.sh script. With some of luck this introduction will also serve you as motivation to create your own centos-art.sh script specific functionalities. - By the way, the greet functionality doesn't exist inside centos-art.sh script yet. Would you like to create it? - - - - Usage - - Global variables - The following global variables of centos-art.sh script, are available for you to use inside specific functions: - - TEXTDOMAIN - Variable - TEXTDOMAIN - - - Default domain used to retrieve translated messages. This value is set in initFunctions.sh and shouldn't be changed. - - - - TEXTDOMAINDIR - Variable - TEXTDOMAINDIR - - - Default directory used to retrieve translated messages. This value is set in initFunctions.sh and shouldn't be changed. - - - - FUNCNAM - Variable - FUNCNAM - - - Define function name. - Function names associate sets of actions. There is one set of actions for each unique function name inside centos-art.sh script. - Dunction names are passed as first argument in centos-art.sh command-line interface. For example, in the command centos-art render --entry=path/to/dir --filter=regex, the ACTION passed to centos-art.sh script is . - When first argument is not provided, the centos-art.sh script immediatly ends its execution. - - - - FUNCDIR - Variable - FUNCDIR - - - - FUNCDIRNAME - Variable - FUNCDIRNAME - - - - FUNCSCRIPT - Variable - FUNCSCRIPT - - - - FUNCCONFIG - Variable - FUNCCONFIG - - - - ACTIONNAM - Variable - ACTIONNAM - - - Define action name. - Each action name identifies an specific action to perform, inside an specific function. - Action name names aare passed as second argument in centos-art.sh command-line interface. For example, in the command centos-art render --entry=path/to/dir --filter=regex, the ACTIONNAM passed to centos-art.sh script is . - When second argument is not provided, the centos-art.sh script immediatly ends its execution. - - - - ACTIONVAL - Variable - ACTIONVAL - - - Define action value. - Action values are associated to just one action name. Action values contain the working copy entry over which its associated action will be performed in. Working copy entries can be files or directories inside the working copy. - - - - REGEX - Variable - REGEX - - - Define regular expression used as pattern to build the list of files to process. - By default, REGEX variable is set to .+ to match all files. - Functions that need to build a list of files to process use the option to redefine REGEX variable default value, and so, control the amount of files to process. - - - - ARGUMENTS - Variable - ARGUMENTS - - - Define optional arguments. - Optional arguments, inside centos-art.sh script, are considered as all command-line arguments passed to centos-art.sh script, from third argument position on. For example, in the command centos-art render --entry=path/to/dir --filter=regex , the optional arguments are from --filter=regex argument on. - Optional arguments are parsed using getopt command through the following base construction: - + Warning To translate output messages in different languages, your system locale information —as in LANG environment variable— must be set to that locale you want to produce translated messages for. For example, if you want to produce translated messages for Spanish language, your system locale information must be set to es_ES.UTF-8, or similar, first. + + Well, it seems that our example is rather complete by now. + In greet function example we've described so far, we only use cli_printMessage global function in action specific function definitions in order to print messages, but more interesting things can be achieved inside action specific function definitions. For example, if you pass a directory path as action value in second argument, you could retrive a list of files from therein, and process them. If the list of files turns too long or you just want to control which files to process, you could add the third argument in the form and reduce the amount of files to process using a regular expression pattern. + The greet function described in this section may serve you as an introduction to understand how specific functionalities work inside centos-art.sh script. With some of luck this introduction will also serve you as motivation to create your own centos-art.sh script specific functionalities. + By the way, the greet functionality doesn't exist inside centos-art.sh script yet. Would you like to create it? + Usage + Global variables + The following global variables of centos-art.sh script, are available for you to use inside specific functions: + + TEXTDOMAIN + Variable + TEXTDOMAIN + + + Default domain used to retrieve translated messages. This value is set in initFunctions.sh and shouldn't be changed. + + + + TEXTDOMAINDIR + Variable + TEXTDOMAINDIR + + + Default directory used to retrieve translated messages. This value is set in initFunctions.sh and shouldn't be changed. + + + + FUNCNAM + Variable + FUNCNAM + + + Define function name. + Function names associate sets of actions. There is one set of actions for each unique function name inside centos-art.sh script. + Dunction names are passed as first argument in centos-art.sh command-line interface. For example, in the command centos-art render --entry=path/to/dir --filter=regex, the ACTION passed to centos-art.sh script is . + When first argument is not provided, the centos-art.sh script immediatly ends its execution. + + + + FUNCDIR + Variable + FUNCDIR + + + + FUNCDIRNAME + Variable + FUNCDIRNAME + + + + FUNCSCRIPT + Variable + FUNCSCRIPT + + + + FUNCCONFIG + Variable + FUNCCONFIG + + + + ACTIONNAM + Variable + ACTIONNAM + + + Define action name. + Each action name identifies an specific action to perform, inside an specific function. + Action name names aare passed as second argument in centos-art.sh command-line interface. For example, in the command centos-art render --entry=path/to/dir --filter=regex, the ACTIONNAM passed to centos-art.sh script is . + When second argument is not provided, the centos-art.sh script immediatly ends its execution. + + + + ACTIONVAL + Variable + ACTIONVAL + + + Define action value. + Action values are associated to just one action name. Action values contain the working copy entry over which its associated action will be performed in. Working copy entries can be files or directories inside the working copy. + + + + REGEX + Variable + REGEX + + + Define regular expression used as pattern to build the list of files to process. + By default, REGEX variable is set to .+ to match all files. + Functions that need to build a list of files to process use the option to redefine REGEX variable default value, and so, control the amount of files to process. + + + + ARGUMENTS + Variable + ARGUMENTS + + + Define optional arguments. + Optional arguments, inside centos-art.sh script, are considered as all command-line arguments passed to centos-art.sh script, from third argument position on. For example, in the command centos-art render --entry=path/to/dir --filter=regex , the optional arguments are from --filter=regex argument on. + Optional arguments are parsed using getopt command through the following base construction: + - Optional arguments provide support to command options inside centos-art.sh script. For instance, consider the Subversion (svn) command, where there are many options (e.g., , , , etc), and inside each option there are several modifiers (e.g., --revision, --message, --username, etc.) that can be combined one another in their short or long variants. - The ARGUMENTS variable is used to store arguments passed from command-line for later use inside centos-art.sh script. Storing arguments is specially useful when we want to run a command with some specific options from them. Consider the following command: - Optional arguments provide support to command options inside centos-art.sh script. For instance, consider the Subversion (svn) command, where there are many options (e.g., , , , etc), and inside each option there are several modifiers (e.g., --revision, --message, --username, etc.) that can be combined one another in their short or long variants. + The ARGUMENTS variable is used to store arguments passed from command-line for later use inside centos-art.sh script. Storing arguments is specially useful when we want to run a command with some specific options from them. Consider the following command: + - In the above command, the , and options are specific to svn copy command. In such cases, options are not interpreted by centos-art.sh script itself. Instead, the centos-art.sh script uses getopt to retrive them and store them in the ARGUMENTS variable for later use, as described in the following command: - In the above command, the , and options are specific to svn copy command. In such cases, options are not interpreted by centos-art.sh script itself. Instead, the centos-art.sh script uses getopt to retrive them and store them in the ARGUMENTS variable for later use, as described in the following command: + - When getopt parses ARGUMENTS, we may use short options (e.g., ) or long options (e.g., ). When we use short options, arguments are separated by one space from the option (e.g., ). When we use long options arguments are separated by an equal sign (=) (e.g., ). - In order for getopt to parse ARGUMENTS correctly, it is required to provide the short and long definition of options that will be passed or at least supported by the command performing the final action the function script exists for. - As convenction, inside centos-art.sh script, short option definitions are set in the ARGSS variable; and long option definitions are set in the ARGSL variable. - When you define short and long options, it may be needed to define which of these option arguments are required and which not. To define an option argument as required, you need to set one colon : after the option definition (e.g., ). On the other hand, to define an option argument as not required, you need to set two colons :: after the option definition (e.g., ). - - - - EDITOR - Variable - EDITOR - - - Default text editor. - The centos-art.sh script uses default text EDITOR to edit pre-commit subversion messages, translation files, configuration files, script files, and similar text-based files. - If EDITOR environment variable is not set, centos-art.sh script uses /usr/bin/vim as default text editor. Otherwise, the following values are recognized by centos-art.sh script: - - • - - /usr/bin/vim - - - /usr/bin/emacs - - - /usr/bin/nano - - - If no one of these values is set in EDITOR environment variable, centos-art.sh uses /usr/bin/vim text editor by default. - - - - - - Global functions - Function scripts stored directly under trunk/Scripts/Bash/Functions/ directory are used to define global functions. Global functions can be used inside action specific functionalities and or even be reused inside themselves. This section provides introductory information to global functions you can use inside centos-art.sh script. - - cli_checkActionArguments - Function - cli_checkActionArguments - - - Validate action value (ACTIONVAL) variable. - The action value variable can take one of the following values: - - - Path to one directory inside the local working copy, - - - Path to one file inside the local working copy, - - - If another value different from that specified above is passed to action value variable, the centos-art.sh script prints an error message and ends script execution. - - - - cli_checkFiles - Function - cli_checkFiles - FILE - [ - TYPE - ] - - - Verify file existence. - cli_checkFiles receives a FILE absolute path and performs file verification as specified in TYPE. When TYPE is not specified, cli_checkFiles verifies FILE existence, no matter what kind of file it be. If TYPE is specified, use one of the following values: - - - - - - Ends script execution if FILE is not a directory. - When you verify directories with cli_checkFiles, if directory doesn't exist, centos-art.sh script asks you for confirmation in order to create that directory. If you answer positively, centos-art.sh script creates that directory and continues script flows normally. Otherwise, if you answer negatively, centos-art.sh ends script execution with an error and documentation message. - - - - - - - Ends script execution if FILE is not a regular file. - - - - - - - Ends script execution if FILE is not a symbolic link. - - - - - - - Ends script execution if FILE is not executable. - - - - - - Ends script execution if FILE is neither a regular file nor a symbolic link. - - - - - - Ends script execution if FILE is neither a regular file nor a directory. - - - - - - Ends script execution if FILE is not inside the working copy. - - -
- As default behaviour, if FILE passes all verifications, centos-art.sh script continues with its normal flow. - - - - cli_commitRepoChanges - Function - cli_commitRepoChanges - [ - LOCATION - ] - - - Syncronize changes between repository and working copy. - The cli_commitRepoChanges function brings changes from the central repository down to the working copy—using svn update—, checks the working copy changes—using svn status command—, prints status report—using both svn update and svn status commands output, and finally, commits recent changes from the working copy up to the repository—using svn commit command—. - Previous to commit the working copy changes up to the central repository, the cli_commitRepoChanges function asks you to verify changes—using svn diff command—, and later, another confirmation question is shown to be sure you really want to commit changes up to central repository. - If LOCATION argument is not specified, the value of ACTIONVAL variable is used as reference instead. - - Figure - - When getopt parses ARGUMENTS, we may use short options (e.g., ) or long options (e.g., ). When we use short options, arguments are separated by one space from the option (e.g., ). When we use long options arguments are separated by an equal sign (=) (e.g., ). + In order for getopt to parse ARGUMENTS correctly, it is required to provide the short and long definition of options that will be passed or at least supported by the command performing the final action the function script exists for. + As convenction, inside centos-art.sh script, short option definitions are set in the ARGSS variable; and long option definitions are set in the ARGSL variable. + When you define short and long options, it may be needed to define which of these option arguments are required and which not. To define an option argument as required, you need to set one colon : after the option definition (e.g., ). On the other hand, to define an option argument as not required, you need to set two colons :: after the option definition (e.g., ). + + + + EDITOR + Variable + EDITOR + + + Default text editor. + The centos-art.sh script uses default text EDITOR to edit pre-commit subversion messages, translation files, configuration files, script files, and similar text-based files. + If EDITOR environment variable is not set, centos-art.sh script uses /usr/bin/vim as default text editor. Otherwise, the following values are recognized by centos-art.sh script: + + • + + /usr/bin/vim + + + /usr/bin/emacs + + + /usr/bin/nano + + + If no one of these values is set in EDITOR environment variable, centos-art.sh uses /usr/bin/vim text editor by default. + + + Global functions + Function scripts stored directly under trunk/Scripts/Bash/Functions/ directory are used to define global functions. Global functions can be used inside action specific functionalities and or even be reused inside themselves. This section provides introductory information to global functions you can use inside centos-art.sh script. + + cli_checkActionArguments + Function + cli_checkActionArguments + + + Validate action value (ACTIONVAL) variable. + The action value variable can take one of the following values: + + + Path to one directory inside the local working copy, + + + Path to one file inside the local working copy, + + + If another value different from that specified above is passed to action value variable, the centos-art.sh script prints an error message and ends script execution. + + + + cli_checkFiles + Function + cli_checkFiles + FILE + [ + TYPE + ] + + + Verify file existence. + cli_checkFiles receives a FILE absolute path and performs file verification as specified in TYPE. When TYPE is not specified, cli_checkFiles verifies FILE existence, no matter what kind of file it be. If TYPE is specified, use one of the following values: + + + + + + Ends script execution if FILE is not a directory. + When you verify directories with cli_checkFiles, if directory doesn't exist, centos-art.sh script asks you for confirmation in order to create that directory. If you answer positively, centos-art.sh script creates that directory and continues script flows normally. Otherwise, if you answer negatively, centos-art.sh ends script execution with an error and documentation message. + + + + + + + Ends script execution if FILE is not a regular file. + + + + + + + Ends script execution if FILE is not a symbolic link. + + + + + + + Ends script execution if FILE is not executable. + + + + + + Ends script execution if FILE is neither a regular file nor a symbolic link. + + + + + + Ends script execution if FILE is neither a regular file nor a directory. + + + + + + Ends script execution if FILE is not inside the working copy. + + +
+ As default behaviour, if FILE passes all verifications, centos-art.sh script continues with its normal flow. + + + + cli_commitRepoChanges + Function + cli_commitRepoChanges + [ + LOCATION + ] + + + Syncronize changes between repository and working copy. + The cli_commitRepoChanges function brings changes from the central repository down to the working copy—using svn update—, checks the working copy changes—using svn status command—, prints status report—using both svn update and svn status commands output, and finally, commits recent changes from the working copy up to the repository—using svn commit command—. + Previous to commit the working copy changes up to the central repository, the cli_commitRepoChanges function asks you to verify changes—using svn diff command—, and later, another confirmation question is shown to be sure you really want to commit changes up to central repository. + If LOCATION argument is not specified, the value of ACTIONVAL variable is used as reference instead. + + Figure + + Bringing changes from the repository into the working copy --> Checking changes in the working copy @@ -3419,68 +2949,68 @@ Deleted 0 file from the working copy. Added 0 file from the working copy. ---------------------------------------------------------------------- ]]> - The cli_commitRepoChanges function output. - - Call the cli_commitRepoChanges function before or/and after calling functions that modify files or directories inside the working copy as you may need to. - - - - cli_doParseArguments - Function - cli_doParseArguments - - - Redefine arguments (ARGUMENTS) global variable using getopt command output. For more information about how to use cli_doParseArguments function, see ARGUMENTS variable description above. - - - - cli_doParseArgumentsReDef - Function - cli_doParseArgumentsReDef - $ - @ - - - Initialize/reset arguments (ARGUMENTS) global variable using positional parameters variable ($@) as reference. - When we work inside function definitions, positional parameters are reset to the last function definition positional parameters. If you need to redefine positional parameters from one specific function, you need to call cli_doParseArgumentsReDef with the positional parameters variable ($@), set as first argument, to that specific function you want to redefine positional parameters at. - - - - cli_getArguments - Function - cli_getArguments - - - Initialize function name (FUNCNAM), action name (ACTIONNAM), and action value (ACTIONVAL) global variables, using positional parameters passed in $@ variable. - The cli_getArguments function is called from cli.sh function script, using cli function positional parameters (i.e., the positional parameters passed as arguments in the command-line) as first function argument. - Once command-line positional parameters are accesible to centos-art.sh script execution evironment, cli_getArguments uses regular expression to retrive action variables from first and second argument. The first argument defines the value used as function name (FUNCNAM), and the second argument defines both values used as action name (ACTIONNAM) and action value (ACTIONVAL), respectively. - The first argument is a word in lower case. This word specifies the name of the functionality you want to use (e.g., render to render images, manual to work on documentation, and so on.) - The second argument has a long option style (e.g., --option=value). The --option represents the action name (ACTIONNAM), and the characters inbetween the equal sign (=) and the first space character, are considered as the action value (ACTIONVAL). In order to provide action values with space characters inbetween you need to enclose action value with quotes like in --option='This is long value with spaces inbetween'. Generally, action values are used to specify paths over which the action name acts on. - Once action related variables (i.e., FUNCNAM, ACTIONNAM, and ACTIONVAL) are defined and validated, cli_getArguments shifts the positional arguments to remove the first two arguments passed (i.e., those used to retrive action related variables) and redefine the arguments (ARGUMENTS) global variable with the new positional parameters information. - - - - cli_getFunctions - Function - cli_getFunctions - - - Initialize funtionalities supported by centos-art.sh script. - Functionalities supported by centos-art.sh script are organized in functionality directories under trunk/Scripts/Bash/Functions/ directory. Each functionality directory stores function scripts to the functionality such directory was created for. Function scripts contain function definitions. Function definitions contain several commands focused on achieving one specific task only (i.e., the one such functionality was created for). - In order for centos-art.sh script to recognize a functionality, such functionality needs to be stored under trunk/Scripts/Bash/Functions/ in a directory written capitalized (i.e., the whole name is written in lowercase except the first character which is in uppercase). The directory where one specific functionality is stored is known as the functionality directory. - Inside each functionality directory, the functionalty itself is implemented through function scripts. Function scripts are organized in files independently one another and written in camelCase format with the function name as prefix. Separation between prefix and description is done using underscore (_) character. - In order for centos-art.sh script to load functionalities correctly, function definition inside function scripts should be set using the function reserved word, just as in the following example: - The cli_commitRepoChanges function output. + + Call the cli_commitRepoChanges function before or/and after calling functions that modify files or directories inside the working copy as you may need to. + + + + cli_doParseArguments + Function + cli_doParseArguments + + + Redefine arguments (ARGUMENTS) global variable using getopt command output. For more information about how to use cli_doParseArguments function, see ARGUMENTS variable description above. + + + + cli_doParseArgumentsReDef + Function + cli_doParseArgumentsReDef + $ + @ + + + Initialize/reset arguments (ARGUMENTS) global variable using positional parameters variable ($@) as reference. + When we work inside function definitions, positional parameters are reset to the last function definition positional parameters. If you need to redefine positional parameters from one specific function, you need to call cli_doParseArgumentsReDef with the positional parameters variable ($@), set as first argument, to that specific function you want to redefine positional parameters at. + + + + cli_getArguments + Function + cli_getArguments + + + Initialize function name (FUNCNAM), action name (ACTIONNAM), and action value (ACTIONVAL) global variables, using positional parameters passed in $@ variable. + The cli_getArguments function is called from cli.sh function script, using cli function positional parameters (i.e., the positional parameters passed as arguments in the command-line) as first function argument. + Once command-line positional parameters are accesible to centos-art.sh script execution evironment, cli_getArguments uses regular expression to retrive action variables from first and second argument. The first argument defines the value used as function name (FUNCNAM), and the second argument defines both values used as action name (ACTIONNAM) and action value (ACTIONVAL), respectively. + The first argument is a word in lower case. This word specifies the name of the functionality you want to use (e.g., render to render images, manual to work on documentation, and so on.) + The second argument has a long option style (e.g., --option=value). The --option represents the action name (ACTIONNAM), and the characters inbetween the equal sign (=) and the first space character, are considered as the action value (ACTIONVAL). In order to provide action values with space characters inbetween you need to enclose action value with quotes like in --option='This is long value with spaces inbetween'. Generally, action values are used to specify paths over which the action name acts on. + Once action related variables (i.e., FUNCNAM, ACTIONNAM, and ACTIONVAL) are defined and validated, cli_getArguments shifts the positional arguments to remove the first two arguments passed (i.e., those used to retrive action related variables) and redefine the arguments (ARGUMENTS) global variable with the new positional parameters information. + + + + cli_getFunctions + Function + cli_getFunctions + + + Initialize funtionalities supported by centos-art.sh script. + Functionalities supported by centos-art.sh script are organized in functionality directories under trunk/Scripts/Bash/Functions/ directory. Each functionality directory stores function scripts to the functionality such directory was created for. Function scripts contain function definitions. Function definitions contain several commands focused on achieving one specific task only (i.e., the one such functionality was created for). + In order for centos-art.sh script to recognize a functionality, such functionality needs to be stored under trunk/Scripts/Bash/Functions/ in a directory written capitalized (i.e., the whole name is written in lowercase except the first character which is in uppercase). The directory where one specific functionality is stored is known as the functionality directory. + Inside each functionality directory, the functionalty itself is implemented through function scripts. Function scripts are organized in files independently one another and written in camelCase format with the function name as prefix. Separation between prefix and description is done using underscore (_) character. + In order for centos-art.sh script to load functionalities correctly, function definition inside function scripts should be set using the function reserved word, just as in the following example: + - The above function definition is just a convenction we use, in order to make identification of function names easier read and automate by centos-art.sh script initialization commands, once centos-art.sh script determines which functionality directory to use. Specifically, in order to initialize and export functions, centos-art.sh script executes all function scripts inside the functionality directory, and later grep on them using a regular expression pattern, where the function reserved word is used as reference to retrive the function names and export them to centos-art.sh script execution environment, and so, make function definitions —from function scripts inside the functionality directory— available for further calls. - If the functionality specified in the command-line first argument doesn't have a functionality directory, centos-art.sh script considers the functionality provided in the command-line as invalid functionality and immediatly stops script execution with an error message. - In order to keep visual consistency among function scripts, please consider using the following function script design model as template for your own function scripts: - The above function definition is just a convenction we use, in order to make identification of function names easier read and automate by centos-art.sh script initialization commands, once centos-art.sh script determines which functionality directory to use. Specifically, in order to initialize and export functions, centos-art.sh script executes all function scripts inside the functionality directory, and later grep on them using a regular expression pattern, where the function reserved word is used as reference to retrive the function names and export them to centos-art.sh script execution environment, and so, make function definitions —from function scripts inside the functionality directory— available for further calls. + If the functionality specified in the command-line first argument doesn't have a functionality directory, centos-art.sh script considers the functionality provided in the command-line as invalid functionality and immediatly stops script execution with an error message. + In order to keep visual consistency among function scripts, please consider using the following function script design model as template for your own function scripts: + - - - - cli_getCountryCodes - Function - cli_getCountryCodes - [ - FILTER - ] - - - Output country codes supported by centos-art.sh script. - The cli_getCountryCodes function outputs a list with country codes as defined in ISO3166 standard. When FILTER is provided, cli_getCountryCodes outputs country codes that match FILTER regular expression pattern. - - - - cli_getCountryName - Function - cli_getCountryName - [ - FILTER - ] - - - Outputs country name supported by centos-art.sh script. - The cli_getCountryName function reads one language locale code in the format LL_CC and outputs the name of its related country as in ISO3166. If filter is specified, cli_getCountryName returns the country name that matches the locale code specified in FILTER, exactly. - - - - cli_getCurrentLocale - Function - cli_getCurrentLocale - - - Output current locale used by centos-art.sh script. - The cli_getCurrentLocale function uses LANG environment variable to build a locale pattern that is later applied to cli_getLocales function output in order to return the current locale that centos-art.sh script works with. - The current locale information, returned by cli_getCurrentLocale, is output from more specific to less specific. For example, if en_GB locale exists in cli_getLocales function output, the en_GB locale would take precedence before en locale. - Locale precedence selection is quite important in order to define the locale type we use for message translations. For example, if en_GB is used, we are also saying that the common language specification for English language (i.e., en) is no longer used. Instead, we are using English non-common country-specific language specifications like en_AU, en_BW, en_GB, en_US, etc., for message translations. - Use cli_getCurrentLocale function to know what current locale information to use inside centos-art.sh script. - - - - cli_getFilesList - Function - cli_getFilesList - [ - LOCATION - ] - - - Output list of files to process. - The cli_getFilesList function uses LOCATION variable as source location to build a list of files just as specified by regular expression (REGEX) global variable. Essentially, what the cli_getFilesList function does is using find command to look for files in the location (LOCATION) just as posix-egrep regular expression (REGEX) specifies. - If LOCATION is not specified when cli_getFilesList function is called, the action value (ACTIONVAL) global variable is used as location value instead. - By default, if the regular expression (REGEX) global variable is not redefined after its first definition in the cli function, all files that match default regular expression value (i.e., .+) will be added to the list of files to process. Otherwise, if you redefine the regular expression global variable after its first definition in the cli function and before calling cli_getFilesList function, the last value you specifed is used instead. - When you need to customize the regular expression (REGEX) global variable value inside a function, do not redefine the global variable (at least you be absolutly convinced you need to). Instead, set the regular expression global variable as local to the function you need a customized regular expression value for. If we don't redefine the regular expression global variable as local to the function, or use another name for the regular expression variable (which is not very convenient in order to keep the amount of names to remember low), you may experiment undesired concantenation issues that make your regular expression to be something different from that you expect them to be, specially if the function where you are doing the variable redefinition is called several times during the same script execution. - As result, the cli_getFilesList re-defines the value of FILES variable with the list of files the find command returned. As example, consider the following construction: - + + + cli_getCountryCodes + Function + cli_getCountryCodes + [ + FILTER + ] + + + Output country codes supported by centos-art.sh script. + The cli_getCountryCodes function outputs a list with country codes as defined in ISO3166 standard. When FILTER is provided, cli_getCountryCodes outputs country codes that match FILTER regular expression pattern. + + + + cli_getCountryName + Function + cli_getCountryName + [ + FILTER + ] + + + Outputs country name supported by centos-art.sh script. + The cli_getCountryName function reads one language locale code in the format LL_CC and outputs the name of its related country as in ISO3166. If filter is specified, cli_getCountryName returns the country name that matches the locale code specified in FILTER, exactly. + + + + cli_getCurrentLocale + Function + cli_getCurrentLocale + + + Output current locale used by centos-art.sh script. + The cli_getCurrentLocale function uses LANG environment variable to build a locale pattern that is later applied to cli_getLocales function output in order to return the current locale that centos-art.sh script works with. + The current locale information, returned by cli_getCurrentLocale, is output from more specific to less specific. For example, if en_GB locale exists in cli_getLocales function output, the en_GB locale would take precedence before en locale. + Locale precedence selection is quite important in order to define the locale type we use for message translations. For example, if en_GB is used, we are also saying that the common language specification for English language (i.e., en) is no longer used. Instead, we are using English non-common country-specific language specifications like en_AU, en_BW, en_GB, en_US, etc., for message translations. + Use cli_getCurrentLocale function to know what current locale information to use inside centos-art.sh script. + + + + cli_getFilesList + Function + cli_getFilesList + [ + LOCATION + ] + + + Output list of files to process. + The cli_getFilesList function uses LOCATION variable as source location to build a list of files just as specified by regular expression (REGEX) global variable. Essentially, what the cli_getFilesList function does is using find command to look for files in the location (LOCATION) just as posix-egrep regular expression (REGEX) specifies. + If LOCATION is not specified when cli_getFilesList function is called, the action value (ACTIONVAL) global variable is used as location value instead. + By default, if the regular expression (REGEX) global variable is not redefined after its first definition in the cli function, all files that match default regular expression value (i.e., .+) will be added to the list of files to process. Otherwise, if you redefine the regular expression global variable after its first definition in the cli function and before calling cli_getFilesList function, the last value you specifed is used instead. + When you need to customize the regular expression (REGEX) global variable value inside a function, do not redefine the global variable (at least you be absolutly convinced you need to). Instead, set the regular expression global variable as local to the function you need a customized regular expression value for. If we don't redefine the regular expression global variable as local to the function, or use another name for the regular expression variable (which is not very convenient in order to keep the amount of names to remember low), you may experiment undesired concantenation issues that make your regular expression to be something different from that you expect them to be, specially if the function where you are doing the variable redefinition is called several times during the same script execution. + As result, the cli_getFilesList re-defines the value of FILES variable with the list of files the find command returned. As example, consider the following construction: + - - - - cli_getLangCodes - Function - cli_getLangCodes - [ - FILTER - ] - - - Outputs language codes supported by centos-art.sh script. - cli_getLangCodes function outputs a list of language codes as defined in ISO639 standard. When FILTER is provided, cli_getLangCodes outputs language codes that match FILTER regular expression pattern. - - - - cli_getLangName - Function - cli_getLangName - [ - FILTER - ] - - - Outputs language names supported by centos-art.sh script. - cli_getLangName function reads one language locale code in the format LL_CC and outputs the language related name as in ISO639. If filter is specified, cli_getLangName returns the language name that matches the locale code specified in FILTER, exactly. - - - - cli_getLocales - Function - cli_getLocales - - - Output locale codes supported by centos-art.sh script. - Occasionally, you use cli_getLocales function to add locale information in non-common country-specific language (LL_CC) format for those languages (e.g., bn_IN, pt_BR, etc.) which locale differences cannot be solved using common language specifications (LL) into one unique common locale specification (e.g., bn, pt, etc.). - - - - cli_getRepoName - Function - cli_getRepoName - NAME - TYPE - - - Sanitate file names. - Inside centos-art.sh script, specific functionalities rely both in cli_getRepoName and repository file system organization to achieve their goals. Consider cli_getRepoName function as central place to manage file name convenctions for other functions inside centos-art.sh script. - - Important cli_getRepoName function doesn't verify file or directory existence, for that purpose use cli_checkFiles function instead. - - The NAME variable contains the file name or directory name you want to sanitate. - The TYPE variable specifies what type of sanitation you want to perform on NAME. The TYPE can be one of the following values: - - - - - - Sanitate directory NAMEs. - - - - - - - Sanitate regular file NAMEs. - - -
- Use cli_getRepoName function to sanitate file names and directory names before their utilization. - Use cli_getRepoName when you need to change file name convenctions inside centos-art.sh script. - When we change file name convenctions inside cli_getRepoName what we are really changing is the way functions interpret repository file system organization. Notice that when we change a file name (e.g., a function name), it is necessary to update all files where such file name is placed on. This may require a massive substitution inside the repository, each time we change name convenctions in the repository (— Removed(pxref:trunk Scripts Bash Functions Path) —, for more information). - - - - cli_getRepoStatus - Function - cli_getRepoStatus - [ - LOCATION - ] - - - Request repository status. - This function requests the status of a LOCATION inside the working copy using the svn status command and returns the first character in the output line, just as described in svn help status. If LOCATION is not a regular file or a directory, inside the working copy, the centos-art.sh script prints a message and ends its execution. - Use this function to perform verifications based a repository LOCATION status. - - - - cli_getTemporalFile - Function - cli_getTemporalFile - NAME - - - Output absolute path to temporal file NAME. - The cli_getTemporalFile function uses /tmp directory as source location to store temporal files, the centos-art.sh script name, and a random identification string to let you run more than one centos-art.sh script simultaneously on the same user session. For example, due the following temporal file defintion: - + + + cli_getLangCodes + Function + cli_getLangCodes + [ + FILTER + ] + + + Outputs language codes supported by centos-art.sh script. + cli_getLangCodes function outputs a list of language codes as defined in ISO639 standard. When FILTER is provided, cli_getLangCodes outputs language codes that match FILTER regular expression pattern. + + + + cli_getLangName + Function + cli_getLangName + [ + FILTER + ] + + + Outputs language names supported by centos-art.sh script. + cli_getLangName function reads one language locale code in the format LL_CC and outputs the language related name as in ISO639. If filter is specified, cli_getLangName returns the language name that matches the locale code specified in FILTER, exactly. + + + + cli_getLocales + Function + cli_getLocales + + + Output locale codes supported by centos-art.sh script. + Occasionally, you use cli_getLocales function to add locale information in non-common country-specific language (LL_CC) format for those languages (e.g., bn_IN, pt_BR, etc.) which locale differences cannot be solved using common language specifications (LL) into one unique common locale specification (e.g., bn, pt, etc.). + + + + cli_getRepoName + Function + cli_getRepoName + NAME + TYPE + + + Sanitate file names. + Inside centos-art.sh script, specific functionalities rely both in cli_getRepoName and repository file system organization to achieve their goals. Consider cli_getRepoName function as central place to manage file name convenctions for other functions inside centos-art.sh script. + + Important cli_getRepoName function doesn't verify file or directory existence, for that purpose use cli_checkFiles function instead. + + The NAME variable contains the file name or directory name you want to sanitate. + The TYPE variable specifies what type of sanitation you want to perform on NAME. The TYPE can be one of the following values: + + + + + + Sanitate directory NAMEs. + + + + + + + Sanitate regular file NAMEs. + + +
+ Use cli_getRepoName function to sanitate file names and directory names before their utilization. + Use cli_getRepoName when you need to change file name convenctions inside centos-art.sh script. + When we change file name convenctions inside cli_getRepoName what we are really changing is the way functions interpret repository file system organization. Notice that when we change a file name (e.g., a function name), it is necessary to update all files where such file name is placed on. This may require a massive substitution inside the repository, each time we change name convenctions in the repository (— Removed(pxref:trunk Scripts Bash Functions Path) —, for more information). + + + + cli_getRepoStatus + Function + cli_getRepoStatus + [ + LOCATION + ] + + + Request repository status. + This function requests the status of a LOCATION inside the working copy using the svn status command and returns the first character in the output line, just as described in svn help status. If LOCATION is not a regular file or a directory, inside the working copy, the centos-art.sh script prints a message and ends its execution. + Use this function to perform verifications based a repository LOCATION status. + + + + cli_getTemporalFile + Function + cli_getTemporalFile + NAME + + + Output absolute path to temporal file NAME. + The cli_getTemporalFile function uses /tmp directory as source location to store temporal files, the centos-art.sh script name, and a random identification string to let you run more than one centos-art.sh script simultaneously on the same user session. For example, due the following temporal file defintion: + - If FILE name is instance.svg and the unique random string is f16f7b51-ac12-4b7f-9e66-72df847f12de, the final temporal file, built from previous temporal file definition, would be: - If FILE name is instance.svg and the unique random string is f16f7b51-ac12-4b7f-9e66-72df847f12de, the final temporal file, built from previous temporal file definition, would be: + - When you use the cli_getTemporalFile function to create temporal files, be sure to remove temporal files created once you've ended up with them. For example, consider the following construction: - When you use the cli_getTemporalFile function to create temporal files, be sure to remove temporal files created once you've ended up with them. For example, consider the following construction: + - Use the cli_getTemporalFile function whenever you need to create temporal files inside centos-art.sh script. - - - - cli_getThemeName - Function - cli_getThemeName - - - Output theme name. - In order for cli_getThemeName function to extract theme name correctly, the ACTIONVAL variable must contain a directory path under trunk/Identity/Themes/Motifs/ directory structure. Otherwise, cli_getThemeName returns an empty string. - - - - cli_printMessage - Function - cli_printMessage - MESSAGE - [ - FORMAT - ] - - - Define standard output message definition supported by centos-art.sh script. - When FORMAT is not specified, cli_printMessage outputs information just as it was passed in MESSAGE variable. Otherwise, FORMAT can take one of the following values: - - - - - To print heading messages. - Use the cli_getTemporalFile function whenever you need to create temporal files inside centos-art.sh script. + + + + cli_getThemeName + Function + cli_getThemeName + + + Output theme name. + In order for cli_getThemeName function to extract theme name correctly, the ACTIONVAL variable must contain a directory path under trunk/Identity/Themes/Motifs/ directory structure. Otherwise, cli_getThemeName returns an empty string. + + + + cli_printMessage + Function + cli_printMessage + MESSAGE + [ + FORMAT + ] + + + Define standard output message definition supported by centos-art.sh script. + When FORMAT is not specified, cli_printMessage outputs information just as it was passed in MESSAGE variable. Otherwise, FORMAT can take one of the following values: +
+ + + + To print heading messages. + - - - - - - To print warning messages. - + + + + + To print warning messages. + - - - - - - To print note messages. - + + + + + To print note messages. + - - - - - - To print Updating messages on two-columns format. - + + + + + To print Updating messages on two-columns format. + - - - - - - To print Removing messages on two-columns format. - + + + + + To print Removing messages on two-columns format. + - - - - - - To print Checking messages on two-columns format. - + + + + + To print Checking messages on two-columns format. + - - - - - - To print Creating messages on two-columns format. - + + + + + To print Creating messages on two-columns format. + - - - - - - To print Saved as messages on two-columns format. - + + + + + To print Saved as messages on two-columns format. + - - - - - - To print Linked to messages on two-columns format. - + + + + + To print Linked to messages on two-columns format. + - - - - - - To print Moved to messages on two-columns format. - + + + + + To print Moved to messages on two-columns format. + - - - - - - To print Translation messages on two-columns format. - + + + + + To print Translation messages on two-columns format. + - - - - - - To print Configuration messages on two-columns format. - + + + + + To print Configuration messages on two-columns format. + - - - - - - To print response messages on one-column format. - + + + + + To print response messages on one-column format. + $MESSAGE ]]> - - - - - - To print request messages on one-column format. Request messages output messages with one colon (:) and without trailing newline (\n) at message end. - + + + + + To print request messages on one-column format. Request messages output messages with one colon (:) and without trailing newline (\n) at message end. + - - - - - - To print yes or no request messages on one-column format. If something different from y is answered (when using en_US.UTF-8 locale), script execution ends immediatly. - + + + + + To print yes or no request messages on one-column format. If something different from y is answered (when using en_US.UTF-8 locale), script execution ends immediatly. + - When we use centos-art.sh script in a locale different from en_US.UTF-8, confirmation answer may be different from y. For example, if you use es_ES.UTF-8 locale, the confirmation question would look like: - When we use centos-art.sh script in a locale different from en_US.UTF-8, confirmation answer may be different from y. For example, if you use es_ES.UTF-8 locale, the confirmation question would look like: + - and the confirmation answer would be s, as it is on Spanish sí word. - Definition of which confirmation word to use is set on translation messages for your specific locale information. — Removed(xref:trunk Scripts Bash Functions Locale) —, for more information about locale-specific translation messages. - - - - - - To standardize to know more, run the following command: messages. When the option is used, the MESSAGE value should be set to "$(caller)". caller is a Bash builtin that returns the context of the current subroutine call. option uses caller builtin output to build documentation entries dynamically. - and the confirmation answer would be s, as it is on Spanish sí word. + Definition of which confirmation word to use is set on translation messages for your specific locale information. — Removed(xref:trunk Scripts Bash Functions Locale) —, for more information about locale-specific translation messages. + + + + + + To standardize to know more, run the following command: messages. When the option is used, the MESSAGE value should be set to "$(caller)". caller is a Bash builtin that returns the context of the current subroutine call. option uses caller builtin output to build documentation entries dynamically. + - Use option after errors and for intentional script termination. - - - - - - To standardize regular messages on one-column format. - When MESSAGE contains a colon inside (e.g., description: message), the cli_printMessage function outputs MESSAGE on two-columns format. - - -
- Use cli_printMessage function whenever you need to output information from centos-art.sh script. - - Tip To improve two-columns format, change the following file: - Use option after errors and for intentional script termination. + + + + + + To standardize regular messages on one-column format. + When MESSAGE contains a colon inside (e.g., description: message), the cli_printMessage function outputs MESSAGE on two-columns format. + + + + Use cli_printMessage function whenever you need to output information from centos-art.sh script. + + Tip To improve two-columns format, change the following file: + - - - - - - - Specific functions - The following specific functions of centos-art.sh script, are available for you to use: - + + + + Specific functions + The following specific functions of centos-art.sh script, are available for you to use: + - - Directories trunk Scripts Functions Locale - Directories trunk Scripts Functions Locale - + + Directories trunk Scripts Functions Locale + Directories trunk Scripts Functions Locale + - - - Directories trunk Scripts Functions Path - Directories trunk Scripts Functions Path - - - - Directories trunk Scripts Functions Render - Directories trunk Scripts Functions Render - - - - Directories trunk Scripts Functions Render Config - Directories trunk Scripts Functions Render Config - + + + Directories trunk Scripts Functions Path + Directories trunk Scripts Functions Path + + + + Directories trunk Scripts Functions Render + Directories trunk Scripts Functions Render + + + + Directories trunk Scripts Functions Render Config + Directories trunk Scripts Functions Render Config + - - - Directories trunk Scripts Functions Prepare - Directories trunk Scripts Functions Prepare - - - - - - - - See also - - - Directories trunk Scripts - Directories trunk Scripts - + + + Directories trunk Scripts Functions Prepare + Directories trunk Scripts Functions Prepare + + + + See also + + + Directories trunk Scripts + Directories trunk Scripts + - - - + +
@@ -3978,41 +3500,30 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
The <file>trunk/Scripts/Functions/Help</file> Directory Directories trunk Scripts Functions Help - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - + Goals + + • + + ... + + + Description + + • + + ... + + + Usage + + • + + ... + + + See also + +
@@ -4023,70 +3534,59 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
The <file>trunk/Scripts/Functions/Locale</file> Directory Directories trunk Scripts Functions Locale - - Goals - - • - - ... - - - - - - Description - This command looks for .sh files inside Bash directory and extracts translatable strings from files, using xgettext command, in order to create a portable object template (centos-art.sh.pot) file for them. - With the centos-art.sh.pot file up to date, the centos-art command removes the temporal list of files sotred inside /tmp directory and checks the current language of your user's session to create a portable object file for it, in the location $CLI_LANG/$CLI_LANG.po. - The CLI_LANG variable discribes the locale language used to output messages inside centos-art command. The locale language used inside centos-art command is taken from the LANG environment variable. The CLI_LANG variable has the LL_CC format, where LL is a language code from the ISO-639 standard, and CC a country code from the ISO-3166 standard. - The LANG environment variable is set when you do log in to your system. If you are using a graphical session, change language to your native language and do login. That would set and exoprt the LANG environment variable to the correct value. On the other side, if you are using a text session edit your ~/.bash_profile file to set and export the LANG environment variable to your native locale as defines the locale -a command output; do logout, and do login again. - At this point, the LANG environment variable has the appropriate value you need, in order to translate centos-art.sh messages to your native language (the one set in LANG environment variable). - With the $CLI_LANG/$CLI_LANG.po file up to date, the centos-art opens it for you to update translation strings. The centos-art command uses the value of EDITOR environment variable to determine your favorite text editor. If no value is defined on EDITOR, the /usr/bin/vim text editor is used as default. - When you finishd PO file edition and quit text editor, the centos-art command creates the related machine object in the location $CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo. - At this point, all translations you made in the PO file should be available to your language when runing centos-art.sh script. - In order to make the centos-art.sh internationalization, the centos-art.sh script was modified as described in the gettext info documentation (info gettext). You can find such modifications in the following files: - - • - - trunk/Scripts/Bash/initFunctions.sh - - - trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh - + Goals + + • + + ... + + + Description + This command looks for .sh files inside Bash directory and extracts translatable strings from files, using xgettext command, in order to create a portable object template (centos-art.sh.pot) file for them. + With the centos-art.sh.pot file up to date, the centos-art command removes the temporal list of files sotred inside /tmp directory and checks the current language of your user's session to create a portable object file for it, in the location $CLI_LANG/$CLI_LANG.po. + The CLI_LANG variable discribes the locale language used to output messages inside centos-art command. The locale language used inside centos-art command is taken from the LANG environment variable. The CLI_LANG variable has the LL_CC format, where LL is a language code from the ISO-639 standard, and CC a country code from the ISO-3166 standard. + The LANG environment variable is set when you do log in to your system. If you are using a graphical session, change language to your native language and do login. That would set and exoprt the LANG environment variable to the correct value. On the other side, if you are using a text session edit your ~/.bash_profile file to set and export the LANG environment variable to your native locale as defines the locale -a command output; do logout, and do login again. + At this point, the LANG environment variable has the appropriate value you need, in order to translate centos-art.sh messages to your native language (the one set in LANG environment variable). + With the $CLI_LANG/$CLI_LANG.po file up to date, the centos-art opens it for you to update translation strings. The centos-art command uses the value of EDITOR environment variable to determine your favorite text editor. If no value is defined on EDITOR, the /usr/bin/vim text editor is used as default. + When you finishd PO file edition and quit text editor, the centos-art command creates the related machine object in the location $CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo. + At this point, all translations you made in the PO file should be available to your language when runing centos-art.sh script. + In order to make the centos-art.sh internationalization, the centos-art.sh script was modified as described in the gettext info documentation (info gettext). You can find such modifications in the following files: + + • + + trunk/Scripts/Bash/initFunctions.sh + + + trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh + + + trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh + + + + • + + ... + + + Usage + + + centos-art locale --edit - trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh + Use this command to translate command-line interface output messages in the current system locale you are using (as specified in LANG environment variable). - - - • + + + centos-art locale --list - ... + Use this command to see the command-line interface locale report. - - - - - Usage -
- - centos-art locale --edit - - Use this command to translate command-line interface output messages in the current system locale you are using (as specified in LANG environment variable). - - - - centos-art locale --list - - Use this command to see the command-line interface locale report. - - -
- - - - See also - - - + + + See also + +
@@ -4097,123 +3597,94 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
The <file>trunk/Scripts/Functions/Path</file> Directory Directories trunk Scripts Functions Path - - Goals - This section exists to organize files related to path functiontionality. The path functionality standardizes movement, syncronization, branching, tagging, and general file maintainance inside the repository. - - - - Description - ”CentOS like trees, has roots, trunk, branches, leaves and flowers. Day by day they work together in freedom, ruled by the laws of nature and open standards, to show the beauty of its existence.” - - - Repository layout - The repository layout describes organization of files and directories inside the repository. The repository layout provides the standard backend required for automation scripts to work correctly. If such layout changes unexpectedly, automation scripts may confuse themselves and stop doing what we expect from them to do. - As convenction, inside CentOS Artwork Repository, we organize files and directories related to CentOS corporate visual identity under three top level directories named: trunk/, branches/, and tags/. - The trunk/ directory (see Directories trunk) organizes the main development line of CentOS corporate visual identity. Inside trunk/ directory structure, the CentOS corporate visual identity concepts are implemented using directories. There is one directory level for each relevant concept inside the repository. The trunk/ directory structure is mainly used to perform development tasks related to CentOS corporate visual identity. - The branches/ directory () oranizes parallel development lines to trunk/ directory. The branches/ directory is used to set points in time where develpment lines are devided one from another taking separte and idependent lives that share a common past from the point they were devided on. The branches/ directory is mainly used to perform quality assurance tasks related to CentOS corporate visual identity. - The tags/ directory (see Directories tags) organizes parallel frozen lines to branches/ directory. The parallel frozen lines are immutable, nothing change inside them once they has been created. The tags/ directory is mainly used to publish final releases of CentOS corporate visual identity. - The CentOS Artwork Repository layout is firmly grounded on a Subversion base. Subversion (http://subversion.tigris.org) is 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. Subversion keeps a single copy of the master sources. This copy is called the source “repository”; it contains all the information to permit extracting previous versions of those files at any time. - - - - Repository name convenctions - Repository name convenctions help us to maintain consistency of names inside the repository. - Repository name convenctions are applied to files and directories inside the repository layout. As convenction, inside the repository layout, file names are all written in lowercase (01-welcome.png, splash.png, anaconda_header.png, etc.) and directory names are all written capitalized (e.g., Identity, Themes, Motifs, TreeFlower, etc.). - Repository name convenctions are implemented inside the cli_getRepoName function of centos-art.sh script. With cli_getRepoName function we reduce the amount of commands and convenctions to remember, concentrating them in just one single place to look for fixes and improvements. - - - - Repository work flow - Repository work flow describes the steps and time intervals used to produce CentOS corporate visual identity inside CentOS Artwork Repository. - To illustrate repository work flow let's consider themes' development cycle. - Initially, we start working themes on their trunk development line (e.g., trunk/Identity/Themes/Motifs/TreeFlower/), here we organize information that cannot be produced automatically (i.e., background images, concepts, color information, screenshots, etc.). - Later, when theme trunk development line is considered “ready” for implementation (e.g., all required backgrounds have been designed), we create a branch for it (e.g., branches/Identity/Themes/Motifs/TreeFlower/1/). Once the branch has been created, we forget that branch and continue working the trunk development line while others (e.g., an artwork quality assurance team) test the new branch for tunning it up. - Once the branch has been tunned up, and considered “ready” for release, it is freezed under tags/ directory (e.g., tags/Identity/Themes/Motifs/TreeFower/1.0/) for packagers, webmasters, promoters, and anyone who needs images from that CentOS theme the tag was created for. - Both branches and tags, inside CentOS Artwork Repository, use numerical values to identify themselves under the same location. Branches start at one (i.e., 1) and increment one unit for each branch created from the same trunk development line. Tags start at zero (i.e., 0) and increment one unit for each tag created from the same branch development line. - - Convenction Do not freeze trunk development lines using tags directly. If you think you need to freeze a trunk development line, create a branch for it and then freeze that branch instead. - - The trunk development line may introduce problems we cannot see immediatly. Certainly, the high changable nature of trunk development line complicates finding and fixing such problems. On the other hand, the branched development lines provide a more predictable area where only fixes/corrections to current content are commited up to repository. - If others find and fix bugs inside the branched development line, we could merge such changes/experiences back to trunk development line (not visversa) in order for future branches, created from trunk, to benefit. - Time intervals used to create branches and tags may vary, just as different needs may arrive. For example, consider the release schema of CentOS distribution: one major release every 2 years, security updates every 6 months, support for 7 years long. Each time a CentOS distribution is released, specially if it is a major release, there is a theme need in order to cover CentOS distribution artwork requirements. At this point, is where CentOS Artwork Repository comes up to scene. - Before releasing a new major release of CentOS distribution we create a branch for one of several theme development lines available inside the CentOS Artwork Repository, perform quality assurance on it, and later, freeze that branch using tags. Once a the theme branch has been frozen (under tags/ directory), CentOS Packagers (the persons whom build CentOS distribution) can use that frozen branch as source location to fulfill CentOS distribution artwork needs. The same applies to CentOS Webmasters (the persons whom build CentOS websites), and any other visual manifestation required by the project. - - - - Parallel directories - Inside CentOS Artwork Repository, parallel directories are simple directory entries built from a common parent directory and placed in a location different to that, the common parent directory is placed on. Parallel directories are useful to create branches, tags, translations, documentation, pre-rendering configuration script, and similar directory structures. - Parallel directories take their structure from one unique parent directory. Inside CentOS Artwork Repository, this unique parent directory is under trunk/Identity location. The trunk/Identity location must be considered the reference for whatever information you plan to create inside the repository. - In some circumstances, parallel directories may be created removing uncommon information from their paths. Uncommon path information refers to those directory levels in the path which are not common for other parallel directories. For example, when rendering trunk/Identity/Themes/Motifs/TreeFlower/Distro directory structure, the centos-art.sh script removes the Motifs/TreeFlower/ directory levels from path, in order to build the parallel directory used to retrived translations, and pre-rendering configuration scripts required by render functionality. - Another example of parallel directory is the documentation structure created by manual functionality. This time, centos-art.sh script uses parallel directory information with uncommon directory levels to build the documentation entry required by Texinfo documentation system, inside the repository. - Othertimes, parallel directories may add uncommon information to their paths. This is the case we use to create branches and tags. When we create branches and tags, a numerical identifier is added to parallel directory structure path. The place where the numerical identifier is set on is relevant to corporate visual identity structure and should be carefully considered where it will be. - When one parent directory changes, all their related parallel directories need to be changed too. This is required in order for parallel directories to retain their relation with the parent directory structure. In the other hand, parallel directories should never be modified under no reason but to satisfy the relation to their parent directory structure. Liberal change of parallel directories may suppresses the conceptual idea they were initially created for; and certainly, things may stop working the way they should do. - - - - Syncronizing path information - Parallel directories are very useful to keep repository organized but introduce some complications. For instance, consider what would happen to functionalities like manual (trunk Scripts Bash Functions Manual) that rely on parent directory structures to create documentation entries (using parallel directory structures) if one of those parent directory structures suddenly changes after the documentation entry has been already created for it? - In such cases, functionalities like manual may confuse themselves if path information is not updated to reflect the relation with its parent directory. Such functionalities work with parent directory structure as reference; if a parent directory changes, the functionalities dont't even note it because they work with the last parent directory structure available in the repository, no matter what it is. - In the specific case of documentation (the manual functionality), the problem mentioned above provokes that older parent directories, already documented, remain inside documentation directory structures as long as you get your hands into the documentation directory structure (trunk/Manuals) and change what must be changed to match the new parent directory structure. - There is no immediate way for manual, and similar functionalities that use parent directories as reference, to know when and how directory movements take place inside the repository. Such information is available only when the file movement itself takes place inside the repository. So, is there, at the moment of moving files, when we need to syncronize parallel directories with their unique parent directory structure. - - Warning There is not support for URL reference inside centos-art.sh script. The centos-art.sh script is designed to work with local files inside the working copy only. - - As CentOS Artwork Repository is built over a version control system, file movements inside the repository are considered repository changes. In order for these repository changes to be versioned, we need to, firstly, add changes into the version control system, commit them, and later, perform movement actions using version control system commands. 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. - Finally, once all path information has been corrected, it is time to take care of information inside the files. For instance, considere what would happen if you make a reference to a documentation node, and later the documentation node you refere to is deleted. That would make Texinfo to produce error messages at export time. So, the centos-art.sh script needs to know when such changes happen, in a way they could be noted and handled without producing errors. - - - - What is the right place to store it? - 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 CentOS Community different free support vains (see: http://wiki.centos.org/GettingHelp) are the best place to find answers to your question, 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 and so, make your propositions based on it. - When we are looking for the correct place to store new files, to bear in mind the corporate visual identity structure used inside the CentOS Artwork Repository (see Directories trunk Identity) would be probaly the best advice we could offer, the rest is just matter of choosing appropriate names. To illustrate this desition process let's consider the trunk/Identity/Themes/Motifs/TreeFlower directory as example. It is the trunk development line of TreeFlower artistic motif. Artistic motifs are considered part of themes, which in turn are considered 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 it, that may be not a definite solution. There are many concepts that you need to play with, in order to find a result that match the conceptual idea you try to implement in the new directory location. To know which these concepts are, split the location in words and read its documentation entry from less specific to more specific. - For example, the trunk/Identity/Themes/Motifs/TreeFlower location 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. The concepts used in trunk/Identity/Themes/Distro/Motifs/TreeFlower location are described in the following commands, respectively: - Goals + This section exists to organize files related to path functiontionality. The path functionality standardizes movement, syncronization, branching, tagging, and general file maintainance inside the repository. + Description + ”CentOS like trees, has roots, trunk, branches, leaves and flowers. Day by day they work together in freedom, ruled by the laws of nature and open standards, to show the beauty of its existence.” + Repository layout + The repository layout describes organization of files and directories inside the repository. The repository layout provides the standard backend required for automation scripts to work correctly. If such layout changes unexpectedly, automation scripts may confuse themselves and stop doing what we expect from them to do. + As convenction, inside CentOS Artwork Repository, we organize files and directories related to CentOS corporate visual identity under three top level directories named: trunk/, branches/, and tags/. + The trunk/ directory (see Directories trunk) organizes the main development line of CentOS corporate visual identity. Inside trunk/ directory structure, the CentOS corporate visual identity concepts are implemented using directories. There is one directory level for each relevant concept inside the repository. The trunk/ directory structure is mainly used to perform development tasks related to CentOS corporate visual identity. + The branches/ directory () oranizes parallel development lines to trunk/ directory. The branches/ directory is used to set points in time where develpment lines are devided one from another taking separte and idependent lives that share a common past from the point they were devided on. The branches/ directory is mainly used to perform quality assurance tasks related to CentOS corporate visual identity. + The tags/ directory (see Directories tags) organizes parallel frozen lines to branches/ directory. The parallel frozen lines are immutable, nothing change inside them once they has been created. The tags/ directory is mainly used to publish final releases of CentOS corporate visual identity. + The CentOS Artwork Repository layout is firmly grounded on a Subversion base. Subversion (http://subversion.tigris.org) is 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. Subversion keeps a single copy of the master sources. This copy is called the source “repository”; it contains all the information to permit extracting previous versions of those files at any time. + Repository name convenctions + Repository name convenctions help us to maintain consistency of names inside the repository. + Repository name convenctions are applied to files and directories inside the repository layout. As convenction, inside the repository layout, file names are all written in lowercase (01-welcome.png, splash.png, anaconda_header.png, etc.) and directory names are all written capitalized (e.g., Identity, Themes, Motifs, TreeFlower, etc.). + Repository name convenctions are implemented inside the cli_getRepoName function of centos-art.sh script. With cli_getRepoName function we reduce the amount of commands and convenctions to remember, concentrating them in just one single place to look for fixes and improvements. + Repository work flow + Repository work flow describes the steps and time intervals used to produce CentOS corporate visual identity inside CentOS Artwork Repository. + To illustrate repository work flow let's consider themes' development cycle. + Initially, we start working themes on their trunk development line (e.g., trunk/Identity/Themes/Motifs/TreeFlower/), here we organize information that cannot be produced automatically (i.e., background images, concepts, color information, screenshots, etc.). + Later, when theme trunk development line is considered “ready” for implementation (e.g., all required backgrounds have been designed), we create a branch for it (e.g., branches/Identity/Themes/Motifs/TreeFlower/1/). Once the branch has been created, we forget that branch and continue working the trunk development line while others (e.g., an artwork quality assurance team) test the new branch for tunning it up. + Once the branch has been tunned up, and considered “ready” for release, it is freezed under tags/ directory (e.g., tags/Identity/Themes/Motifs/TreeFower/1.0/) for packagers, webmasters, promoters, and anyone who needs images from that CentOS theme the tag was created for. + Both branches and tags, inside CentOS Artwork Repository, use numerical values to identify themselves under the same location. Branches start at one (i.e., 1) and increment one unit for each branch created from the same trunk development line. Tags start at zero (i.e., 0) and increment one unit for each tag created from the same branch development line. + + Convenction Do not freeze trunk development lines using tags directly. If you think you need to freeze a trunk development line, create a branch for it and then freeze that branch instead. + + The trunk development line may introduce problems we cannot see immediatly. Certainly, the high changable nature of trunk development line complicates finding and fixing such problems. On the other hand, the branched development lines provide a more predictable area where only fixes/corrections to current content are commited up to repository. + If others find and fix bugs inside the branched development line, we could merge such changes/experiences back to trunk development line (not visversa) in order for future branches, created from trunk, to benefit. + Time intervals used to create branches and tags may vary, just as different needs may arrive. For example, consider the release schema of CentOS distribution: one major release every 2 years, security updates every 6 months, support for 7 years long. Each time a CentOS distribution is released, specially if it is a major release, there is a theme need in order to cover CentOS distribution artwork requirements. At this point, is where CentOS Artwork Repository comes up to scene. + Before releasing a new major release of CentOS distribution we create a branch for one of several theme development lines available inside the CentOS Artwork Repository, perform quality assurance on it, and later, freeze that branch using tags. Once a the theme branch has been frozen (under tags/ directory), CentOS Packagers (the persons whom build CentOS distribution) can use that frozen branch as source location to fulfill CentOS distribution artwork needs. The same applies to CentOS Webmasters (the persons whom build CentOS websites), and any other visual manifestation required by the project. + Parallel directories + Inside CentOS Artwork Repository, parallel directories are simple directory entries built from a common parent directory and placed in a location different to that, the common parent directory is placed on. Parallel directories are useful to create branches, tags, translations, documentation, pre-rendering configuration script, and similar directory structures. + Parallel directories take their structure from one unique parent directory. Inside CentOS Artwork Repository, this unique parent directory is under trunk/Identity location. The trunk/Identity location must be considered the reference for whatever information you plan to create inside the repository. + In some circumstances, parallel directories may be created removing uncommon information from their paths. Uncommon path information refers to those directory levels in the path which are not common for other parallel directories. For example, when rendering trunk/Identity/Themes/Motifs/TreeFlower/Distro directory structure, the centos-art.sh script removes the Motifs/TreeFlower/ directory levels from path, in order to build the parallel directory used to retrived translations, and pre-rendering configuration scripts required by render functionality. + Another example of parallel directory is the documentation structure created by manual functionality. This time, centos-art.sh script uses parallel directory information with uncommon directory levels to build the documentation entry required by Texinfo documentation system, inside the repository. + Othertimes, parallel directories may add uncommon information to their paths. This is the case we use to create branches and tags. When we create branches and tags, a numerical identifier is added to parallel directory structure path. The place where the numerical identifier is set on is relevant to corporate visual identity structure and should be carefully considered where it will be. + When one parent directory changes, all their related parallel directories need to be changed too. This is required in order for parallel directories to retain their relation with the parent directory structure. In the other hand, parallel directories should never be modified under no reason but to satisfy the relation to their parent directory structure. Liberal change of parallel directories may suppresses the conceptual idea they were initially created for; and certainly, things may stop working the way they should do. + Syncronizing path information + Parallel directories are very useful to keep repository organized but introduce some complications. For instance, consider what would happen to functionalities like manual (trunk Scripts Bash Functions Manual) that rely on parent directory structures to create documentation entries (using parallel directory structures) if one of those parent directory structures suddenly changes after the documentation entry has been already created for it? + In such cases, functionalities like manual may confuse themselves if path information is not updated to reflect the relation with its parent directory. Such functionalities work with parent directory structure as reference; if a parent directory changes, the functionalities dont't even note it because they work with the last parent directory structure available in the repository, no matter what it is. + In the specific case of documentation (the manual functionality), the problem mentioned above provokes that older parent directories, already documented, remain inside documentation directory structures as long as you get your hands into the documentation directory structure (trunk/Manuals) and change what must be changed to match the new parent directory structure. + There is no immediate way for manual, and similar functionalities that use parent directories as reference, to know when and how directory movements take place inside the repository. Such information is available only when the file movement itself takes place inside the repository. So, is there, at the moment of moving files, when we need to syncronize parallel directories with their unique parent directory structure. + + Warning There is not support for URL reference inside centos-art.sh script. The centos-art.sh script is designed to work with local files inside the working copy only. + + As CentOS Artwork Repository is built over a version control system, file movements inside the repository are considered repository changes. In order for these repository changes to be versioned, we need to, firstly, add changes into the version control system, commit them, and later, perform movement actions using version control system commands. 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. + Finally, once all path information has been corrected, it is time to take care of information inside the files. For instance, considere what would happen if you make a reference to a documentation node, and later the documentation node you refere to is deleted. That would make Texinfo to produce error messages at export time. So, the centos-art.sh script needs to know when such changes happen, in a way they could be noted and handled without producing errors. + What is the right place to store it? + 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 CentOS Community different free support vains (see: http://wiki.centos.org/GettingHelp) are the best place to find answers to your question, 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 and so, make your propositions based on it. + When we are looking for the correct place to store new files, to bear in mind the corporate visual identity structure used inside the CentOS Artwork Repository (see Directories trunk Identity) would be probaly the best advice we could offer, the rest is just matter of choosing appropriate names. To illustrate this desition process let's consider the trunk/Identity/Themes/Motifs/TreeFlower directory as example. It is the trunk development line of TreeFlower artistic motif. Artistic motifs are considered part of themes, which in turn are considered 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 it, that may be not a definite solution. There are many concepts that you need to play with, in order to find a result that match the conceptual idea you try to implement in the new directory location. To know which these concepts are, split the location in words and read its documentation entry from less specific to more specific. + For example, the trunk/Identity/Themes/Motifs/TreeFlower location 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. The concepts used in trunk/Identity/Themes/Distro/Motifs/TreeFlower location are described in the following commands, respectively: + - Other location concepts can be found similary as we did above, just change the location we used above by the one you are trying to know concepts for. - - - - - Usage - - - centos-art path --copy='SRC' --to='DST' - - Copy to and schedule for addition (with history). In this command, SRC and DST are both working copy (WC) entries. - - - - centos-art path --delete='SRC' - - Delete . In order for this command to work the file or directory you intend to delete should be under version control first. In this command, SRC is a working copy (WC) entry. - - -
- - - - See also - - - Directories trunk Scripts - Directories trunk Scripts - - - - Directories trunk Scripts Functions - Directories trunk Scripts Functions - - - - + Other location concepts can be found similary as we did above, just change the location we used above by the one you are trying to know concepts for. + Usage + + + centos-art path --copy='SRC' --to='DST' + + Copy to and schedule for addition (with history). In this command, SRC and DST are both working copy (WC) entries. + + + + centos-art path --delete='SRC' + + Delete . In order for this command to work the file or directory you intend to delete should be under version control first. In this command, SRC is a working copy (WC) entry. + + +
+ See also + + + Directories trunk Scripts + Directories trunk Scripts + + + + Directories trunk Scripts Functions + Directories trunk Scripts Functions + + +
@@ -4224,100 +3695,85 @@ centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/
The <file>trunk/Scripts/Functions/Prepare</file> Directory Directories trunk Scripts Functions Prepare - - Goals - This section exists to organize files related to centos-art.sh script prepare functionality. The prepare functionality of centos-art.sh script helps you to prepare the workstation configuration you are planning to use as host for your working copy of CentOS Artwork Repository. - - - - Description - The first time you download CentOS Artwork Repository you need to configure your workstation in order to use centos-art.sh script. These preliminar configurations are based mainly on auxiliar RPM packages installation, symbolic links creations, and environment variables definitions. The prepare functionality of centos-art.sh script guides you through this preliminar configuration process. - If this is the first time you run centos-art.sh script, the appropriate way to use its prepare functionality is not using the centos-art.sh script directly, but the absolute path to centos-art.sh script instead (i.e., ~/artwork/trunk/Scripts/Bash/centos-art.sh). This is necessary because centos-art symbolic link, under ~/bin/ directory, has not been created yet. - - - Packages - Installation of auxiliar RPM packages provides the software required to manipulate files inside the repository (e.g., image files, documentation files, translation files, script files, etc.). Most of RPM packages centos-art.sh script uses are shipped with CentOS distribution, and can be installed from CentOS base repository. The only exception is inkscape, the package we use to manipulate SVG files. The inkscape package is not inside CentOS distribution so it needs to be installed from third party repositories. - - Note Configuration of third party repositories inside CentOS distribution is described in CentOS wiki, specifically in the following URL: http://wiki.centos.org/AdditionalResources/Repositories - - Before installing packages, the centos-art.sh script uses sudo to request root privileges to execute yum installation functionality. If your user isn't defined as a privileged user—at least to run yum commands— inside /etc/sudoers configuration file, you will not be able to perform package installation tasks as set in centos-art.sh script prepare functionality. - Setting sudo privileges to users is an administrative task you have to do by yourself. If you don't have experience with sudo command, please read its man page running the command: man sudo. This reading will be very useful, and with some practice, you will be able to configure your users to have sudo privileges. - - - - Links - Creation of symbolic links helps us to alternate between different implementations of centos-art.sh script-line (e.g., centos-art.sh, for Bash implementation; centos-art.py, for Python implementation; centos-art.pl, for Perl implementation; and so on for other implementations). The centos-art.sh script-line definition takes place inside your personal binary (~/bin/) directory in order to make the script implementation —the one that centos-art links to— available to PATH environment variable. - Creation of symbolic links helps us to reuse components from repository working copy. For example, color information files maintained inside your working copy must never be duplicated inside program-specific configuration directories that uses them in your workstation (e.g., Gimp, Inkscape, etc.). Instead, a symbolic link must be created for each one of them, from program-specific configuration directories to files in the working copy. In this configuration, when someone commits changes to color information files up to central repository, they—the changes committed— will be immediatly available to your programs the next time you update your working copy —the place inside your workstation those color information files are stored—. - Creation of symbolic links helps us to make centos-art.sh script functionalities available outside trunk/ repository directory structure, but at its same level in repository tree. This is useful if you need to use the “render” functionality of centos-art.sh under branches/ repository directory structure as you usually do inside trunk/ repository directory structure. As consequence of this configuration, automation scripts cannot be branched under branches/Scripts directory structure. - - - - Environment variables - Definition of environemnt variables helps us to set default values to our user session life. The user session environment variable defintion takes place in the user's ~/.bash_profile file. The prepare functionality of centos-art.sh script doesn't modify your ~/.bash_profile file. - The prepare functionality of centos-art.sh script evaluates the following environment variables: - - - EDITOR - - Default text editor. - The centos-art.sh script uses default text EDITOR to edit pre-commit subversion messages, translation files, configuration files, script files, and similar text-based files. - If EDITOR environment variable is not set, centos-art.sh script uses /usr/bin/vim as default text editor. Otherwise, the following values are recognized by centos-art.sh script: - - • - - /usr/bin/vim - - - /usr/bin/emacs - - - /usr/bin/nano - - - If no one of these values is set in EDITOR environment variable, centos-art.sh uses /usr/bin/vim text editor by default. - - - - TEXTDOMAIN - - Default domain used to retrieve translated messages. This variable is set in initFunctions.sh and shouldn't be changed. - - - - TEXTDOMAINDIR + Goals + This section exists to organize files related to centos-art.sh script prepare functionality. The prepare functionality of centos-art.sh script helps you to prepare the workstation configuration you are planning to use as host for your working copy of CentOS Artwork Repository. + Description + The first time you download CentOS Artwork Repository you need to configure your workstation in order to use centos-art.sh script. These preliminar configurations are based mainly on auxiliar RPM packages installation, symbolic links creations, and environment variables definitions. The prepare functionality of centos-art.sh script guides you through this preliminar configuration process. + If this is the first time you run centos-art.sh script, the appropriate way to use its prepare functionality is not using the centos-art.sh script directly, but the absolute path to centos-art.sh script instead (i.e., ~/artwork/trunk/Scripts/Bash/centos-art.sh). This is necessary because centos-art symbolic link, under ~/bin/ directory, has not been created yet. + Packages + Installation of auxiliar RPM packages provides the software required to manipulate files inside the repository (e.g., image files, documentation files, translation files, script files, etc.). Most of RPM packages centos-art.sh script uses are shipped with CentOS distribution, and can be installed from CentOS base repository. The only exception is inkscape, the package we use to manipulate SVG files. The inkscape package is not inside CentOS distribution so it needs to be installed from third party repositories. + + Note Configuration of third party repositories inside CentOS distribution is described in CentOS wiki, specifically in the following URL: http://wiki.centos.org/AdditionalResources/Repositories + + Before installing packages, the centos-art.sh script uses sudo to request root privileges to execute yum installation functionality. If your user isn't defined as a privileged user—at least to run yum commands— inside /etc/sudoers configuration file, you will not be able to perform package installation tasks as set in centos-art.sh script prepare functionality. + Setting sudo privileges to users is an administrative task you have to do by yourself. If you don't have experience with sudo command, please read its man page running the command: man sudo. This reading will be very useful, and with some practice, you will be able to configure your users to have sudo privileges. + Links + Creation of symbolic links helps us to alternate between different implementations of centos-art.sh script-line (e.g., centos-art.sh, for Bash implementation; centos-art.py, for Python implementation; centos-art.pl, for Perl implementation; and so on for other implementations). The centos-art.sh script-line definition takes place inside your personal binary (~/bin/) directory in order to make the script implementation —the one that centos-art links to— available to PATH environment variable. + Creation of symbolic links helps us to reuse components from repository working copy. For example, color information files maintained inside your working copy must never be duplicated inside program-specific configuration directories that uses them in your workstation (e.g., Gimp, Inkscape, etc.). Instead, a symbolic link must be created for each one of them, from program-specific configuration directories to files in the working copy. In this configuration, when someone commits changes to color information files up to central repository, they—the changes committed— will be immediatly available to your programs the next time you update your working copy —the place inside your workstation those color information files are stored—. + Creation of symbolic links helps us to make centos-art.sh script functionalities available outside trunk/ repository directory structure, but at its same level in repository tree. This is useful if you need to use the “render” functionality of centos-art.sh under branches/ repository directory structure as you usually do inside trunk/ repository directory structure. As consequence of this configuration, automation scripts cannot be branched under branches/Scripts directory structure. + Environment variables + Definition of environemnt variables helps us to set default values to our user session life. The user session environment variable defintion takes place in the user's ~/.bash_profile file. The prepare functionality of centos-art.sh script doesn't modify your ~/.bash_profile file. + The prepare functionality of centos-art.sh script evaluates the following environment variables: +
+ + EDITOR + + Default text editor. + The centos-art.sh script uses default text EDITOR to edit pre-commit subversion messages, translation files, configuration files, script files, and similar text-based files. + If EDITOR environment variable is not set, centos-art.sh script uses /usr/bin/vim as default text editor. Otherwise, the following values are recognized by centos-art.sh script: + + • - Default directory used to retrieve translated messages. This variable is set in initFunctions.sh and shouldn't be changed. + /usr/bin/vim - - - LANG - Default locale information. - This variable is initially set in the configuration process of CentOS distribution installer (i.e., Anaconda), specifically in the Language step; or once installed using the system-config-language tool. - The centos-art.sh script uses the LANG environment variable to know in which language the script messages are printed out. + /usr/bin/emacs - - - TZ - Default time zone representation. - This variable is initially set in the configuration process of CentOS distribution installer (i.e., Anaconda), specifically in the Date and time step; or once installed using the system-config-date tool. - The centos-art.sh script doesn't use the TZ environment variable information at all. Instead, this variable is used by the system shell to show the time information according to your phisical location on planet Earth. - Inside your computer, the time information is firstly set in the BIOS clock (which may need correction), and later in the configuration process of CentOS distribution installer (or later, by any of the related configuration tools inside CentOS distribution). Generally, setting time information is a straight-forward task and configuration tools available do cover most relevant location. However, if you need a time precision not provided by the configuration tools available inside CentOS distribution then, using TZ variable may be necessary. - - Convenction In order to keep changes syncronized between central repository and its working copies: configure both repository server and workstations (i.e., the place where each working copy is set on) to use Coordinated Universal Time (UTC) as base time representation. Later, correct the time information for your specific location using time zone correction. - - The format of TZ environment variable is described in tzset(3) manual page. + /usr/bin/nano - -
- - - - Shell Script Files - The shell functionality of centos-art.sh script helps you to maintain bash scripts inside repository. For example, suppose you've created many functionalities for centos-art.sh script, and you want to use a common copyright and license note for consistency in all your script files. If you have a bunch of files, doing this one by one wouldn't be a big deal. In contrast, if the amount of files grows, updating the copyright and license note for all of them would be a task rather tedious. The shell functionality exists to solve maintainance tasks just as the one previously mentioned. - When you use shell functionality to update copyright inside script files, it is required that your script files contain (at least) the following top commentary structure: - + If no one of these values is set in EDITOR environment variable, centos-art.sh uses /usr/bin/vim text editor by default. + + + + TEXTDOMAIN + + Default domain used to retrieve translated messages. This variable is set in initFunctions.sh and shouldn't be changed. + + + + TEXTDOMAINDIR + + Default directory used to retrieve translated messages. This variable is set in initFunctions.sh and shouldn't be changed. + + + + LANG + + Default locale information. + This variable is initially set in the configuration process of CentOS distribution installer (i.e., Anaconda), specifically in the Language step; or once installed using the system-config-language tool. + The centos-art.sh script uses the LANG environment variable to know in which language the script messages are printed out. + + + + TZ + + Default time zone representation. + This variable is initially set in the configuration process of CentOS distribution installer (i.e., Anaconda), specifically in the Date and time step; or once installed using the system-config-date tool. + The centos-art.sh script doesn't use the TZ environment variable information at all. Instead, this variable is used by the system shell to show the time information according to your phisical location on planet Earth. + Inside your computer, the time information is firstly set in the BIOS clock (which may need correction), and later in the configuration process of CentOS distribution installer (or later, by any of the related configuration tools inside CentOS distribution). Generally, setting time information is a straight-forward task and configuration tools available do cover most relevant location. However, if you need a time precision not provided by the configuration tools available inside CentOS distribution then, using TZ variable may be necessary. + + Convenction In order to keep changes syncronized between central repository and its working copies: configure both repository server and workstations (i.e., the place where each working copy is set on) to use Coordinated Universal Time (UTC) as base time representation. Later, correct the time information for your specific location using time zone correction. + + The format of TZ environment variable is described in tzset(3) manual page. + + + + Shell Script Files + The shell functionality of centos-art.sh script helps you to maintain bash scripts inside repository. For example, suppose you've created many functionalities for centos-art.sh script, and you want to use a common copyright and license note for consistency in all your script files. If you have a bunch of files, doing this one by one wouldn't be a big deal. In contrast, if the amount of files grows, updating the copyright and license note for all of them would be a task rather tedious. The shell functionality exists to solve maintainance tasks just as the one previously mentioned. + When you use shell functionality to update copyright inside script files, it is required that your script files contain (at least) the following top commentary structure: + - Relevant lines in the above structure are lines from 5 to 9. Everything else in the file is left immutable. - When you are updating copyright through shell functionality, the centos-art.sh script replaces everything in-between line 5 —the first one matching ^# Copyright .+$ string— and line 9—the first long dash separator matching ^# -+$— with the content of copyright template instance. - - Caution Be sure to add the long dash separator that matches ^# -+$ regular expression before the function definition. Otherwise, if the Copyright line is present but no long dash separator exists, centos-art.sh will remove anything in-between the Copyright line and the end of file. This way you may lost your function definitions entirely. - - The copyright template instance is created from one copyright template stored in the Config/tpl_forCopyright.sed file. The template instance is created once, and later removed when no longer needed. At this moment, when template instance is created, the centos-art.sh script takes advantage of automation in order to set copyright full name and date dynamically. - When you use shell functionality to update copyright, the first thing shell functionality does is requesting copyright information to user, and later, if values were left empty (i.e., no value was typed before pressing RET key), the shell functionality uses its own default values. - When shell functionality uses its own default values, the final copyright note looks like the following: - Relevant lines in the above structure are lines from 5 to 9. Everything else in the file is left immutable. + When you are updating copyright through shell functionality, the centos-art.sh script replaces everything in-between line 5 —the first one matching ^# Copyright .+$ string— and line 9—the first long dash separator matching ^# -+$— with the content of copyright template instance. + + Caution Be sure to add the long dash separator that matches ^# -+$ regular expression before the function definition. Otherwise, if the Copyright line is present but no long dash separator exists, centos-art.sh will remove anything in-between the Copyright line and the end of file. This way you may lost your function definitions entirely. + + The copyright template instance is created from one copyright template stored in the Config/tpl_forCopyright.sed file. The template instance is created once, and later removed when no longer needed. At this moment, when template instance is created, the centos-art.sh script takes advantage of automation in order to set copyright full name and date dynamically. + When you use shell functionality to update copyright, the first thing shell functionality does is requesting copyright information to user, and later, if values were left empty (i.e., no value was typed before pressing RET key), the shell functionality uses its own default values. + When shell functionality uses its own default values, the final copyright note looks like the following: + - Relevant lines in the above structure are lines from 5 to 22. Pay attention how the copyright line was built, and how the license was added into the top comment where previously was just three dots. Everything else in the file was left immutable. - To change copyright information (i.e., full name or year information), run the shell functionality over the root directory containing the script files you want to update copyright in and enter the appropriate information when it be requested. You can run the shell functionality as many times as you need to. - To change copyright license (i.e., the text in-between lines 7 and 20), you need to edit the Config/tpl_forCopyright.sed file, set the appropriate information, and run the shell functionality once again for changes to take effect over the files you specify. - - Important The centos-art.sh script is released as: - Relevant lines in the above structure are lines from 5 to 22. Pay attention how the copyright line was built, and how the license was added into the top comment where previously was just three dots. Everything else in the file was left immutable. + To change copyright information (i.e., full name or year information), run the shell functionality over the root directory containing the script files you want to update copyright in and enter the appropriate information when it be requested. You can run the shell functionality as many times as you need to. + To change copyright license (i.e., the text in-between lines 7 and 20), you need to edit the Config/tpl_forCopyright.sed file, set the appropriate information, and run the shell functionality once again for changes to take effect over the files you specify. + + Important The centos-art.sh script is released as: + - Do not change the license information under which centos-art.sh script is released. Instead, if you think a different license must be used, please share your reasons at centos-devel@centos-art.shCentOS Developers mailing list. - See file file:///home/centos/artwork/trunk/Scripts/COPYINGtrunk/Scripts/COPYING, for a complete license description. - - - - - SVG Files - The svg functionality of centos-art.sh script helps you to maintain scalable vector graphics (SVG) inside repository. For example, suppose you've been working in CentOS default design models under trunk/Identity/Themes/Models/, and you want to set common metadata to all of them, and later remove all unused SVG defintions from *.svg files. Doing so file by file may be a tedious task, so the centos-art.sh script provides the svg functionality to aid you maintain such actions. - The metadata used is defined by Inkscape 0.46 using the SVG standard markup. The centos-art.sh script replaces everything in-between <metadata and </metadata> tags with a predefined metadata template we've set for this purpose. - The metadata template was created using the metadata information of a file which, using Inkscape 0.46, all metadata fields were set. This created a complete markup representation of how SVG metadata would look like. Later, we replaced every single static value with a translation marker in the form =SOMETEXT=, where SOMETEXT is the name of its main opening tag. Later, we transform the metadata template into a sed replacement set of commads escaping new lines at the end of each line. - With metadata template in place, the centos-art.sh script uses it to create a metadata template instance for the file being processed currently. The metadata template instance contains the metadata portion of sed replacement commands with translation markers already traduced. In this action, instance creation, is where we take advantage of automation and generate metadata values like title, date, keywords, source, identifier, and relation dynamically, based on the file path centos-art.sh script is currently creating metadata information for. - With metadata template instance in place, the centos-art.sh script uses it to replace real values inside all .svg files under the current location you're running the centos-art.sh script on. Default behaviour is to ask user to enter each metadatum required, one by one. If user leaves metadatum empty, by pressing RET key, centos-art.sh uses its default value. - Many of the no-longer-used gradients, patterns, and markers (more precisely, those which you edited manually) remain in the corresponding palettes and can be reused for new objects. However if you want to optimize your document, use the Vacuum Defs command in File menu. It will remove any gradients, patterns, or markers which are not used by anything in the document, making the file smaller. - If you have one or two couple of files, removing unused definitions using the graphical interface may be enough to you. In contrast, if you have dozens or even houndreds of scalable vector graphics files to maintain it is not a fun task to use the graphical interface to remove unused definitions editing those files one by one. - To remove unused definitions from several scalable vector graphics files, the centos-art.sh script uses Inkscape command-line interface, specifically with the option. - - - - XHTML Files - - - - - Usage - - - centos-art prepare --packages - - Verify required packages your workstation needs in order to run the centos-art.sh script correctly. If there are missing packages, the centos-art.sh script asks you to confirm their installation. When installing packages, the centos-art.sh script uses the yum application in order to achieve the task. - In case all packages required by centos-art.sh script are already installed in your workstation, the message The required packages are already installed. is output for you to know. - - - - centos-art prepare --links - - Verify required links your workstation needs in order to run the centos-art command correctly. If any required link is missing, the centos-art.sh script asks you to confirm their installation. To install required links, the centos-art.sh script uses the ln command. - In case all links required by centos-art.sh script are already created in your workstation, the message The required links are already installed. is output for you to know. - In case a regular file exists with the same name of a required link, the centos-art.sh script outputs the Already exists as regular file. message when listing required links that will be installed. Of course, as there is already a regular file where must be a link, no link is created. In such cases the centos-art.sh script will fall into a continue installation request for that missing link. To end this continue request you can answer No, or remove the existent regular file to let centos-art.sh script install the link on its place. - - - - centos-art prepare --environment - centos-art prepare --environment --filter='regex' - - Output a brief description of environment variables used by centos-art.sh script. - If --filter option is provided, output is reduced as defined in the regex regular expression value. If --filter option is specified but regex value is not, the centos-art.sh script outputs information as if --filter option had not been provided at all. - - -
- - - - See also - - - Directories trunk Scripts - Directories trunk Scripts - - - - Directories trunk Scripts Functions - Directories trunk Scripts Functions - - - - + Do not change the license information under which centos-art.sh script is released. Instead, if you think a different license must be used, please share your reasons at centos-devel@centos-art.shCentOS Developers mailing list. + See file file:///home/centos/artwork/trunk/Scripts/COPYINGtrunk/Scripts/COPYING, for a complete license description. + + SVG Files + The svg functionality of centos-art.sh script helps you to maintain scalable vector graphics (SVG) inside repository. For example, suppose you've been working in CentOS default design models under trunk/Identity/Themes/Models/, and you want to set common metadata to all of them, and later remove all unused SVG defintions from *.svg files. Doing so file by file may be a tedious task, so the centos-art.sh script provides the svg functionality to aid you maintain such actions. + The metadata used is defined by Inkscape 0.46 using the SVG standard markup. The centos-art.sh script replaces everything in-between <metadata and </metadata> tags with a predefined metadata template we've set for this purpose. + The metadata template was created using the metadata information of a file which, using Inkscape 0.46, all metadata fields were set. This created a complete markup representation of how SVG metadata would look like. Later, we replaced every single static value with a translation marker in the form =SOMETEXT=, where SOMETEXT is the name of its main opening tag. Later, we transform the metadata template into a sed replacement set of commads escaping new lines at the end of each line. + With metadata template in place, the centos-art.sh script uses it to create a metadata template instance for the file being processed currently. The metadata template instance contains the metadata portion of sed replacement commands with translation markers already traduced. In this action, instance creation, is where we take advantage of automation and generate metadata values like title, date, keywords, source, identifier, and relation dynamically, based on the file path centos-art.sh script is currently creating metadata information for. + With metadata template instance in place, the centos-art.sh script uses it to replace real values inside all .svg files under the current location you're running the centos-art.sh script on. Default behaviour is to ask user to enter each metadatum required, one by one. If user leaves metadatum empty, by pressing RET key, centos-art.sh uses its default value. + Many of the no-longer-used gradients, patterns, and markers (more precisely, those which you edited manually) remain in the corresponding palettes and can be reused for new objects. However if you want to optimize your document, use the Vacuum Defs command in File menu. It will remove any gradients, patterns, or markers which are not used by anything in the document, making the file smaller. + If you have one or two couple of files, removing unused definitions using the graphical interface may be enough to you. In contrast, if you have dozens or even houndreds of scalable vector graphics files to maintain it is not a fun task to use the graphical interface to remove unused definitions editing those files one by one. + To remove unused definitions from several scalable vector graphics files, the centos-art.sh script uses Inkscape command-line interface, specifically with the option. + XHTML Files + Usage + + + centos-art prepare --packages + + Verify required packages your workstation needs in order to run the centos-art.sh script correctly. If there are missing packages, the centos-art.sh script asks you to confirm their installation. When installing packages, the centos-art.sh script uses the yum application in order to achieve the task. + In case all packages required by centos-art.sh script are already installed in your workstation, the message The required packages are already installed. is output for you to know. + + + + centos-art prepare --links + + Verify required links your workstation needs in order to run the centos-art command correctly. If any required link is missing, the centos-art.sh script asks you to confirm their installation. To install required links, the centos-art.sh script uses the ln command. + In case all links required by centos-art.sh script are already created in your workstation, the message The required links are already installed. is output for you to know. + In case a regular file exists with the same name of a required link, the centos-art.sh script outputs the Already exists as regular file. message when listing required links that will be installed. Of course, as there is already a regular file where must be a link, no link is created. In such cases the centos-art.sh script will fall into a continue installation request for that missing link. To end this continue request you can answer No, or remove the existent regular file to let centos-art.sh script install the link on its place. + + + + centos-art prepare --environment + centos-art prepare --environment --filter='regex' + + Output a brief description of environment variables used by centos-art.sh script. + If --filter option is provided, output is reduced as defined in the regex regular expression value. If --filter option is specified but regex value is not, the centos-art.sh script outputs information as if --filter option had not been provided at all. + + +
+ See also + + + Directories trunk Scripts + Directories trunk Scripts + + + + Directories trunk Scripts Functions + Directories trunk Scripts Functions + + +
@@ -4463,25 +3905,21 @@ Copyright (C) 1989, 1991 Free Software Foundation, Inc. In order to render content inside renderable directory structures you can use the render functionality of centos-art.sh script. The render functionality takes one design template (a.k.a., design model) from the template directory related and creates an instance of it in order to apply translation messages, if any. Later, using the translated design template instance, the command renders the final content based on whether the design template instance is a SVG file or XHTML file. If the design template instace is a SVG file, the final content produced is a PNG image. On the other hand, if the design template instance is a XHTML file, the final content produced is a XHTML file. The rendition flow described so far is known as the centos-art.sh script base-rendition flow and take place both in direct rendition and theme rendition. Besides the base-rendition flow, the centos-art provides post-rendition and last-rendition flows. The post-rendition flow is applied to files produced as result of base-rendition flow under the same directory structure. For example, you can use post-rendition action to convert the PNG base output into different outputs formats (e.g., JPG, PDF, etc.) before passing to process the next file in the same directory structure. The last-rendition flow, on the other hand, is applied to all files produced as result of both base-rendition and post-rendition flows in the same directory structure, just before passing to process a different directory structure. For example, the Preview.png image from Ksplash component is made of three images. In order to build the Preview.png image through centos-art.sh we need to wait for all the three images the Preview.png image is made of to be rendered in order to combine them all together into just one image (i.e., the Preview.png image). This is something we can't do using post-rendition flow. Inside trunk/Identity directory structure, you can find that base-rendition, post-rendition and last-rendition flows can be combined to build directory-specific rendition. The directory-specific rendition exists to process specific renderable directories in very specific ways. Using directory-specific rendition speeds up production of different components like Syslinux, Grub, Gdm, Kdm and Ksplash that require intermediate formats or even several independent files, in order for the final content to be created. - - - Renderable identity directory structures - Renderable identity directory structures are the starting point of identity rendition. Whenever we want to render a component of CentOS corporate visual identity, we need to point centos-art.sh to a renderable identity directory structure. If such renderable identity directory structure doesn't exist, then it is good time to create it. - Inside the working copy, one renderable identity directory structures represents one visual manifestation of CentOS corporate visual identity, or said differently, each visual manifestation of CentOS corporate visual identity should have one renderable identity directory structure. - Inside renderable identity directory structures, centos-art.sh can render both image-based and text-based files. Specification of whether a renderable identity directory structure produces image-based or text-based content is a configuration action that takes place in the pre-rendition configuration script of that renderable identity directory structure. - Inside renderable identity directory structures, content production is organized in different configurations. A content production configuration is a unique combination of the components that make an identity directory structure renderable. One content production configuration does one thing only (e.g., to produce untranslated images), but it can be extended (e.g., adding translation files) to achieve different needs (e.g., to produce translated images). - - - Design template without translation - The design template without translation configuration is based on a renderable identity directory structure with an empty translation directory structure. In this configuration, one design template produces one untranslated file. Both design templates and final untranslated files share the same file name, but they differ one another in file-type and file-extension. - For example, to produce images without translations (there is no much use in producing text-based files without translations), consider the following configuration: - - - One renderable identity directory structure: - - In this example we used Identity/Path/To/Dir as the identity component we want to produce untranslated images for. Identity components can be either under trunk/ or branches/ directory structure. - The identity component (i.e., Identity/Path/To/Dir, in this case) is also the bond component we use to connect the identity directory structures with their respective auxiliar directories (i.e., translation directory structres and pre-rendition configuration structures). The bond component is the path convenction that centos-art.sh uses to know where to look for related translations, configuration scripts and whatever auxiliar thing a renderable directory structure may need to have. - Renderable identity directory structures + Renderable identity directory structures are the starting point of identity rendition. Whenever we want to render a component of CentOS corporate visual identity, we need to point centos-art.sh to a renderable identity directory structure. If such renderable identity directory structure doesn't exist, then it is good time to create it. + Inside the working copy, one renderable identity directory structures represents one visual manifestation of CentOS corporate visual identity, or said differently, each visual manifestation of CentOS corporate visual identity should have one renderable identity directory structure. + Inside renderable identity directory structures, centos-art.sh can render both image-based and text-based files. Specification of whether a renderable identity directory structure produces image-based or text-based content is a configuration action that takes place in the pre-rendition configuration script of that renderable identity directory structure. + Inside renderable identity directory structures, content production is organized in different configurations. A content production configuration is a unique combination of the components that make an identity directory structure renderable. One content production configuration does one thing only (e.g., to produce untranslated images), but it can be extended (e.g., adding translation files) to achieve different needs (e.g., to produce translated images). + Design template without translation + The design template without translation configuration is based on a renderable identity directory structure with an empty translation directory structure. In this configuration, one design template produces one untranslated file. Both design templates and final untranslated files share the same file name, but they differ one another in file-type and file-extension. + For example, to produce images without translations (there is no much use in producing text-based files without translations), consider the following configuration: +
+ + One renderable identity directory structure: + + In this example we used Identity/Path/To/Dir as the identity component we want to produce untranslated images for. Identity components can be either under trunk/ or branches/ directory structure. + The identity component (i.e., Identity/Path/To/Dir, in this case) is also the bond component we use to connect the identity directory structures with their respective auxiliar directories (i.e., translation directory structres and pre-rendition configuration structures). The bond component is the path convenction that centos-art.sh uses to know where to look for related translations, configuration scripts and whatever auxiliar thing a renderable directory structure may need to have. + | trunk/Identity/Path/To/Dir <-- Renderable identity directory structure. @@ -4491,46 +3929,46 @@ trunk/Identity/Path/To/Dir <-- Renderable identity directory structure. `-- file.png <-- Final image-based file produced from design template file. ]]> - Inside design template directory, design template files are based on SVGScalable Vector Graphics and use the extension .svg. Design template files can be organized using several directory levels to create a simple but extensible configuration, specially if translated images are not required. - In order for SVGScalable Vector Graphics files to be considered “design template” files, they should be placed under the design template directory and to have set a CENTOSARTWORK object id inside. - The CENTOSARTWORK word itself is a convenction name we use to define which object/design area, inside a design template, the centos-art.sh script will use to export as PNGPortable Network Graphic image at rendition time. Whithout such object id specification, the centos-art.sh script cannot know what object/design area you (as designer) want to export as PNGPortable Network Graphic image file. - - Note At rendition time, the content of Img/ directory structure is produced by centos-art.sh automatically. - - When a renderable identity directory structure is configured to produce image-based content, centos-art.sh produces PNGPortable Network Graphics files with the .png extension. Once the base image format has been produced, it is possible for centos-art.sh to use it in order to automatically create other image formats that may be needed (— Removed(pxref:trunk Scripts Bash Functions Render Config) —). - Inside the working copy, you can find an example of “design template without translation” configuration at trunk/Identity/Models/. - See Directories trunk Identity, for more information. - - - - One translation directory structure: - - In order for an identity entry to be considered an identity renderable directory structure, it should have a translation entry. The content of the translation entry is relevant to determine how to process the identity renderable directory entry. - If the translation entry is empty (i.e., there is no file inside it), centos-art.sh interprets the identity renderable directory structure as a “design templates without translation” configuration. - Inside design template directory, design template files are based on SVGScalable Vector Graphics and use the extension .svg. Design template files can be organized using several directory levels to create a simple but extensible configuration, specially if translated images are not required. + In order for SVGScalable Vector Graphics files to be considered “design template” files, they should be placed under the design template directory and to have set a CENTOSARTWORK object id inside. + The CENTOSARTWORK word itself is a convenction name we use to define which object/design area, inside a design template, the centos-art.sh script will use to export as PNGPortable Network Graphic image at rendition time. Whithout such object id specification, the centos-art.sh script cannot know what object/design area you (as designer) want to export as PNGPortable Network Graphic image file. + + Note At rendition time, the content of Img/ directory structure is produced by centos-art.sh automatically. + + When a renderable identity directory structure is configured to produce image-based content, centos-art.sh produces PNGPortable Network Graphics files with the .png extension. Once the base image format has been produced, it is possible for centos-art.sh to use it in order to automatically create other image formats that may be needed (— Removed(pxref:trunk Scripts Bash Functions Render Config) —). + Inside the working copy, you can find an example of “design template without translation” configuration at trunk/Identity/Models/. + See Directories trunk Identity, for more information. + + + + One translation directory structure: + + In order for an identity entry to be considered an identity renderable directory structure, it should have a translation entry. The content of the translation entry is relevant to determine how to process the identity renderable directory entry. + If the translation entry is empty (i.e., there is no file inside it), centos-art.sh interprets the identity renderable directory structure as a “design templates without translation” configuration. + | trunk/Translations/Identity/Path/To/Dir `-- (empty) ]]> - If the translation entry is not empty, centos-art.sh can interpret the identity renderable directory structure as one of the following configurations: “design template with translation (one-to-one)” or “design template with translation (optimized)”. Which one of these configurations is used depends on the value assigned to the matching list (MATCHINGLIST) variable in the pre-rendition configuration script of the renderable identity directory structure we are producing images for. - If the matching list variable is empty (as it is by default), then “design template with translation (one-to-one)” configuration is used. In this configuration it is required that both design templates and translation files have the same file names. This way, one translation files is applied to one design template, to produce one translated image. - If the matching list variable is not empty (because you redefine it in the pre-rendition configuration script), then “design template with translation (optimized)” configuration is used instead. In this configuration, design templates and translation files don't need to have the same names since such name relationship between them is specified in the matching list properly. - — Removed(xref:trunk Translations) —, for more information. - - - - One pre-rendition configuration script: - - In order to make an identity directory structure renderable, a pre-rendition configuration script should exist for it. The pre-rendition configuration script specifies what type of rendition does centos-art.sh will perform over the identity directory structure and how does it do that. - If the translation entry is not empty, centos-art.sh can interpret the identity renderable directory structure as one of the following configurations: “design template with translation (one-to-one)” or “design template with translation (optimized)”. Which one of these configurations is used depends on the value assigned to the matching list (MATCHINGLIST) variable in the pre-rendition configuration script of the renderable identity directory structure we are producing images for. + If the matching list variable is empty (as it is by default), then “design template with translation (one-to-one)” configuration is used. In this configuration it is required that both design templates and translation files have the same file names. This way, one translation files is applied to one design template, to produce one translated image. + If the matching list variable is not empty (because you redefine it in the pre-rendition configuration script), then “design template with translation (optimized)” configuration is used instead. In this configuration, design templates and translation files don't need to have the same names since such name relationship between them is specified in the matching list properly. + — Removed(xref:trunk Translations) —, for more information. + + + + One pre-rendition configuration script: + + In order to make an identity directory structure renderable, a pre-rendition configuration script should exist for it. The pre-rendition configuration script specifies what type of rendition does centos-art.sh will perform over the identity directory structure and how does it do that. + | trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir `-- render.conf.sh ]]> - In this configuration the pre-rendition configuration script (render.conf.sh) would look like the following: - In this configuration the pre-rendition configuration script (render.conf.sh) would look like the following: + - Since translation directory structure is empty, centos-art.sh assumes a “design template without translation” configuration to produce untranslated images. - To produce untranslated images, centos-art.sh takes one design template and creates one temporal instance from it. Later, centos-art.sh uses the temporal design template instance as source file to export the final untranslated image. The action of exporting images from SVGScalable Vector Graphics to PNGPortable Network Graphics is possible thanks to Inkscape's command-line interface and the CENTOSARTWORK object id we previously set inside design templates. - Since translation directory structure is empty, centos-art.sh assumes a “design template without translation” configuration to produce untranslated images. + To produce untranslated images, centos-art.sh takes one design template and creates one temporal instance from it. Later, centos-art.sh uses the temporal design template instance as source file to export the final untranslated image. The action of exporting images from SVGScalable Vector Graphics to PNGPortable Network Graphics is possible thanks to Inkscape's command-line interface and the CENTOSARTWORK object id we previously set inside design templates. + - Finally, when the untranslated image has been created, the temporal design template instance is removed. At this point, centos-art.sh takes the next design template and repeats the whole production flow once again (design template by design template), until all design templates be processed. - — Removed(xref:trunk Scripts Bash Functions Render Config) —, for more information. - - -
- - - - Design template with translation (one-to-one) - Producing untranslated images is fine in many cases, but not always. Sometimes it is required to produce images in different languages and that is something that untrasnlated image production cannot achieve. However, if we fill its empty translation entry with translation files (one for each design template) we extend the production flow from untranslated image production to translated image production. - In order for centos-art.sh to produce images correctly, each design template should have one translation file and each translation file should have one design template. Otherwise, if there is a missing design template or a missing translation file, centos-art.sh will not produce the final image related to the missing component. - In order for centos-art.sh to know which is the relation between translation files and design templates the translation directory structure is taken as reference. For example, the trunk/Translations/Identity/Path/To/Dir/file.sed translation file does match trunk/Identity/Path/To/Dir/Tpl/file.svg design template, but it doesn't match trunk/Identity/Path/To/Dir/File.svg or trunk/Identity/Path/To/Dir/Tpl/File.svg or trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg design templates. - The pre-rendition configuration script used to produce untranslated images is the same we use to produce translated images. There is no need to modify it. So, as we are using the same pre-rendition configuration script, we can say that translated image production is somehow an extended/improved version of untranslated image production. - - Note If we use no translation file in the translation entry (i.e., an empty directory), centos-art.sh assumes the untranslated image production. If we fill the translation entry with translation files, centos-art.sh assumes the translated image production. - - To produce final images, centos-art.sh applies one translation file to one design template and produce a translated design template instance. Later, centos-art.sh uses the translated template instance to produce the translated image. Finally, when the translated image has been produced, centos-art.sh removes the translated design template instance. This production flow is repeated for each translation file available in the translatio entry. - Finally, when the untranslated image has been created, the temporal design template instance is removed. At this point, centos-art.sh takes the next design template and repeats the whole production flow once again (design template by design template), until all design templates be processed. + — Removed(xref:trunk Scripts Bash Functions Render Config) —, for more information. + + + + Design template with translation (one-to-one) + Producing untranslated images is fine in many cases, but not always. Sometimes it is required to produce images in different languages and that is something that untrasnlated image production cannot achieve. However, if we fill its empty translation entry with translation files (one for each design template) we extend the production flow from untranslated image production to translated image production. + In order for centos-art.sh to produce images correctly, each design template should have one translation file and each translation file should have one design template. Otherwise, if there is a missing design template or a missing translation file, centos-art.sh will not produce the final image related to the missing component. + In order for centos-art.sh to know which is the relation between translation files and design templates the translation directory structure is taken as reference. For example, the trunk/Translations/Identity/Path/To/Dir/file.sed translation file does match trunk/Identity/Path/To/Dir/Tpl/file.svg design template, but it doesn't match trunk/Identity/Path/To/Dir/File.svg or trunk/Identity/Path/To/Dir/Tpl/File.svg or trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg design templates. + The pre-rendition configuration script used to produce untranslated images is the same we use to produce translated images. There is no need to modify it. So, as we are using the same pre-rendition configuration script, we can say that translated image production is somehow an extended/improved version of untranslated image production. + + Note If we use no translation file in the translation entry (i.e., an empty directory), centos-art.sh assumes the untranslated image production. If we fill the translation entry with translation files, centos-art.sh assumes the translated image production. + + To produce final images, centos-art.sh applies one translation file to one design template and produce a translated design template instance. Later, centos-art.sh uses the translated template instance to produce the translated image. Finally, when the translated image has been produced, centos-art.sh removes the translated design template instance. This production flow is repeated for each translation file available in the translatio entry. + - - - - Design template with translation (optimized) - Producing translated images satisfies almost all our production images needs, but there is still a pitfall in them. In order to produce translated images as in the “one-to-one” configuration describes previously, it is required that one translation file has one design template. That's useful in many cases, but what would happen if we need to apply many different translation files to the same design template? Should we have to duplicate the same design template file for each translation file, in order to satisfy the “one-to-one” relation? What if we need to assign translation files to design templates arbitrarily? - Certenly, that's something the “one-to-one” configuration cannot handle. So, that's why we had to “optimize” it. The optimized configuration consists on using a matching list (MATCHINGLIST) variable that specifies the relationship between translation files and design templates in an arbitrary way. Using such matching list between translation files and design templates let us use as many assignment combinations as translation files and design templates we are working with. - The MATCHINGLIST variable is set in the pre-rendition configuration script of the component we want to produce images for. By default, the MATCHINGLIST variable is empty which means no matching list is used. Otherwise, if MATCHINGLIST variable has a value different to empty value then, centos-art.sh interprets the matching list in order to know how translation files are applied to design templates. - For example, consider the following configuration: - - - One entry under trunk/Identity/: - - In this configuration we want to produce three images using a paragraph-based style, controlled by paragraph.svg design template; and one image using a list-based style, controlled by list.svg design template. - Design template with translation (optimized) + Producing translated images satisfies almost all our production images needs, but there is still a pitfall in them. In order to produce translated images as in the “one-to-one” configuration describes previously, it is required that one translation file has one design template. That's useful in many cases, but what would happen if we need to apply many different translation files to the same design template? Should we have to duplicate the same design template file for each translation file, in order to satisfy the “one-to-one” relation? What if we need to assign translation files to design templates arbitrarily? + Certenly, that's something the “one-to-one” configuration cannot handle. So, that's why we had to “optimize” it. The optimized configuration consists on using a matching list (MATCHINGLIST) variable that specifies the relationship between translation files and design templates in an arbitrary way. Using such matching list between translation files and design templates let us use as many assignment combinations as translation files and design templates we are working with. + The MATCHINGLIST variable is set in the pre-rendition configuration script of the component we want to produce images for. By default, the MATCHINGLIST variable is empty which means no matching list is used. Otherwise, if MATCHINGLIST variable has a value different to empty value then, centos-art.sh interprets the matching list in order to know how translation files are applied to design templates. + For example, consider the following configuration: +
+ + One entry under trunk/Identity/: + + In this configuration we want to produce three images using a paragraph-based style, controlled by paragraph.svg design template; and one image using a list-based style, controlled by list.svg design template. + - - - - One entry under trunk/Translations/: - - In order to produce translated images we need to have one translation file for each translated image we want to produce. Notice how translation names do match final image file names, but how translation names do not match design template names. When we use matching list there is no need for translation files to match the names of design templates, such name relation is set inside the matching list itself. - + + + One entry under trunk/Translations/: + + In order to produce translated images we need to have one translation file for each translated image we want to produce. Notice how translation names do match final image file names, but how translation names do not match design template names. When we use matching list there is no need for translation files to match the names of design templates, such name relation is set inside the matching list itself. + - - - - One entry under trunk/trunk/Scripts/Bash/Functions/Render/Config/: - - In order to produce different translated images using specific design templates, we need to specify the relation between translation files and design templates in a way that centos-art.sh could know exactly what translation file to apply to what design template. This relation between translation files and design templates is set using the matching list MATCHINGLIST variable inside the pre-rendition configuration script of the component we want to produce images for. - + + + One entry under trunk/trunk/Scripts/Bash/Functions/Render/Config/: + + In order to produce different translated images using specific design templates, we need to specify the relation between translation files and design templates in a way that centos-art.sh could know exactly what translation file to apply to what design template. This relation between translation files and design templates is set using the matching list MATCHINGLIST variable inside the pre-rendition configuration script of the component we want to produce images for. + - In this configuration the pre-rendition configuration script (render.conf.sh) would look like the following: - In this configuration the pre-rendition configuration script (render.conf.sh) would look like the following: + - As result, centos-art.sh will produce 01-welcome.png, 02-donate.png and 04-support.png using the paragraph-based design template, but 03-docs.png using the list-based design template. - - -
- - - - Design template with translation (optimized+flexibility) - In the production models we've seen so far, there are design templates to produce untranslated images and translation files which combiend with design templates produce translated images. That may seems like all our needs are covered, doesn't it? Well, it almost does. - Generally, we use design templates to define how final images will look like. Generally, each renderable directory structure has one Tpl/ directory where we organize design templates for that identity component. So, we can say that there is only one unique design template definition for each identity component; or what is the same, said differently, identity components can be produced in one way only, the way its own design template directory specifies. This is not enough for theme production. It is a limitation, indeed. - Initially, to create one theme, we created one renderable directory structure for each theme component. When we found ourselves with many themes, and components inside them, it was obvious that the same design model was duplicated inside each theme. As design models were independently one another, if we changed one theme's design model, that change was useless to other themes. So, in order to reuse design model changes, we unified design models into one common directory structure. - With design models unified in a common structure, another problem rose up. As design models also had the visual style of theme components, there was no difference between themes, so there was no apparent need to have an independent theme directory structure for each different theme. So, it was also needed to separate visual styles from design models. - At this point there are two independent worklines: one directory structure to store design models (the final image characteristics [i.e., dimensions, translation markers, etc.]) and one directory structure to store visual styles (the final image visual style [i.e., the image look and feel]). So, it is possible to handle both different design models and different visual styles independtly one another and later create combinations among them using centos-art.sh. - For example, consider the following configuration: - - - One entry under trunk/Identity/Themes/Models/: - - The design model entry exists to organize design model files (similar to design templates). Both design models and design templates are very similar; they both should have the CENTOSARTWORK export id present to identify the exportation area, translation marks, etc. However, design models do use dynamic backgrounds inclusion while design templates don't. - As result, centos-art.sh will produce 01-welcome.png, 02-donate.png and 04-support.png using the paragraph-based design template, but 03-docs.png using the list-based design template. + + +
+ Design template with translation (optimized+flexibility) + In the production models we've seen so far, there are design templates to produce untranslated images and translation files which combiend with design templates produce translated images. That may seems like all our needs are covered, doesn't it? Well, it almost does. + Generally, we use design templates to define how final images will look like. Generally, each renderable directory structure has one Tpl/ directory where we organize design templates for that identity component. So, we can say that there is only one unique design template definition for each identity component; or what is the same, said differently, identity components can be produced in one way only, the way its own design template directory specifies. This is not enough for theme production. It is a limitation, indeed. + Initially, to create one theme, we created one renderable directory structure for each theme component. When we found ourselves with many themes, and components inside them, it was obvious that the same design model was duplicated inside each theme. As design models were independently one another, if we changed one theme's design model, that change was useless to other themes. So, in order to reuse design model changes, we unified design models into one common directory structure. + With design models unified in a common structure, another problem rose up. As design models also had the visual style of theme components, there was no difference between themes, so there was no apparent need to have an independent theme directory structure for each different theme. So, it was also needed to separate visual styles from design models. + At this point there are two independent worklines: one directory structure to store design models (the final image characteristics [i.e., dimensions, translation markers, etc.]) and one directory structure to store visual styles (the final image visual style [i.e., the image look and feel]). So, it is possible to handle both different design models and different visual styles independtly one another and later create combinations among them using centos-art.sh. + For example, consider the following configuration: + + + One entry under trunk/Identity/Themes/Models/: + + The design model entry exists to organize design model files (similar to design templates). Both design models and design templates are very similar; they both should have the CENTOSARTWORK export id present to identify the exportation area, translation marks, etc. However, design models do use dynamic backgrounds inclusion while design templates don't. + | trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/ |-- paragraph.svg `-- list.svg ]]> - Inisde design models, dynamic backgrounds are required in order for different artistic motifs to reuse common design models. Firstly, in order to create dynamic backgrounds inside design models, we import a bitmap to cover design model's background and later, update design model's path information to replace fixed values to dynamic values. - - - - One entry under trunk/Identity/Themes/Motifs/: - - The artistic motif entry defines the visual style we want to produce images for, only. Final images (i.e., those built from combining both design models and artistic motif backrounds) are not stored here, but under branches directory structure. In the artistic motif entry, we only define those images that cannot be produced automatically by centos-art.sh (e.g., Backgrounds, Color information, Screenshots, etc.). - Inisde design models, dynamic backgrounds are required in order for different artistic motifs to reuse common design models. Firstly, in order to create dynamic backgrounds inside design models, we import a bitmap to cover design model's background and later, update design model's path information to replace fixed values to dynamic values. + + + + One entry under trunk/Identity/Themes/Motifs/: + + The artistic motif entry defines the visual style we want to produce images for, only. Final images (i.e., those built from combining both design models and artistic motif backrounds) are not stored here, but under branches directory structure. In the artistic motif entry, we only define those images that cannot be produced automatically by centos-art.sh (e.g., Backgrounds, Color information, Screenshots, etc.). + | trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/ @@ -4710,13 +4139,13 @@ trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/ `-- Xcf `-- 510x300.xcf ]]> - - - - One entry under trunk/Translations/: - - The translation entry specifies, by means of translation files, the language-specific information we want to produce image for. When we create the translation entry we don't use the name of neither design model nor artistic motif, just the design model component we want to produce images for. - + + + One entry under trunk/Translations/: + + The translation entry specifies, by means of translation files, the language-specific information we want to produce image for. When we create the translation entry we don't use the name of neither design model nor artistic motif, just the design model component we want to produce images for. + | trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/ @@ -4730,18 +4159,18 @@ trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/ |-- 02-donate.sed `-- 03-docs.sed ]]> - - - - One entry under trunk/Scripts/Bash/Functions/Render/Config/: - - There is one pre-rendition configuration script for each theme component. So, each time a theme component is rendered, its pre-rendition configuration script is evaluated to teach centos-art.sh how to render the component. - + + + One entry under trunk/Scripts/Bash/Functions/Render/Config/: + + There is one pre-rendition configuration script for each theme component. So, each time a theme component is rendered, its pre-rendition configuration script is evaluated to teach centos-art.sh how to render the component. + - In this configuration the pre-rendition configuration script (render.conf.sh) would look like the following: - In this configuration the pre-rendition configuration script (render.conf.sh) would look like the following: + - - -
- The production flow of “optimize+flexibility” configuration&dots; - - - - - Renderable translation directory structures - Translation directory structures are auxiliar structures of renderable identity directory structures. There is one translation directory structure for each renderable identity directory structure. Inside translation directory structures we organize translation files used by renderable identity directory structures that produce translated images. Renderable identity directory structures that produce untranslated images don't use translation files, but they do use a translation directory structure, an empty translation directory structure, to be precise. - In order to aliviate production of translation file, we made translation directory structures renderable adding a template (Tpl/) directory structure to handle common content inside translation files. This way, we work on translation templates and later use centos-art.sh to produce specific translation files (based on translation templates) for different information (e.g., languages, release numbers, architectures, etc.). - If for some reason, translation files get far from translation templates and translation templates become incovenient to produce such translation files then, care should be taken to avoid replacing the content of translation files with the content of translation templates when centos-art.sh is executed to produce translation files from translation templates. - Inside renderable translation directory structures, centos-art.sh can produce text-based files only. - - - - Copying renderable directory structures - A renderable layout is formed by design models, design images, pre-rendition configuration scripts and translations files. This way, when we say to duplicate rendition stuff we are saying to duplicate these four directory structures (i.e., design models, design images, pre-rendition configuration scripts, and related translations files). - When we duplicate directories, inside `trunk/Identity' directory structure, we need to be aware of renderable layout described above and the source location used to perform the duplication action. The source location is relevant to centos-art.sh script in order to determine the required auxiliar information inside directory structures that need to be copied too (otherwise we may end up with orphan directory structures unable to be rendered, due the absence of required information). - In order for a renderable directory structure to be valid, the new directory structure copied should match the following conditions: - - - To have a unique directory structure under trunk/Identity, organized by any one of the above organizational designs above. - - - To have a unique directory structure under trunk/Translations to store translation files. - - - To have a unique directory structure under trunk/Scripts/Bash/Functions/Render/Config to set pre-rendition configuration script. - - - As convenction, the render_doCopy function uses trunk/Identity directory structure as source location. Once the trunk/Identity directory structure has been specified and verified, the related path information is built from it and copied automatically to the new location specified by FLAG_TO variable. - Design templates + No translation: - Command: - centos-art render –copy=trunk/Identity/Path/To/Dir –to=trunk/Identity/NewPath/To/Dir - Sources: - trunk/Identity/Path/To/Dir - trunk/Translations/Identity/Path/To/Dir - trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir - Targets: - trunk/Identity/NewPath/To/Dir - trunk/Translations/Identity/NewPath/To/Dir - trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir - Renderable layout 2: - Command: - centos-art render –copy=trunk/Identity/Themes/Motifs/TreeFlower \ –to=trunk/Identity/Themes/Motifs/NewPath/To/Dir - Sources: - trunk/Identity/Themes/Motifs/TreeFlower - trunk/Translations/Identity/Themes - trunk/Translations/Identity/Themes/Motifs/TreeFlower - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower - Targets: - trunk/Identity/Themes/Motifs/NewPath/To/Dir - trunk/Translations/Identity/Themes - trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir - Notice that design models are not included in source or target locations. This is intentional. In “Renderable layout 2”, design models live by their own, they just exist, they are there, available for any artistic motif to use. By default `Themes/Models/Default' design model directory structure is used, but other design models directory structures (under Themes/Models/) can be created and used changing the value of THEMEMODEL variable inside the pre-rendition configuration script of the artistic motif source location you want to produce. - Notice how translations and pre-rendition configuration scripts may both be equal in source and target. This is because such structures are common to all artistic motifs (the default values to use when no specific values are provided). - - The common directory structures are not copied or deleted. We cannot copy a directory structure to itself. - - The common directory structures represent the default value to use when no specific translations and/or pre-rendition configuration script are provided inside source location. - - The specific directory structures, if present, are both copiable and removable. This is, when you perform a copy or delete action from source, that source specific auxiliar directories are transfered in the copy action to a new location (that specified by FLAG_TO variable). - - When translations and/or pre-rendition configuration scripts are found inside the source directory structure, the centos-art.sh script loads common auxiliar directories first and later specific auxiliar directories. This way, identity rendition of source locations can be customized idividually over the base of common default values. - - The specific auxiliar directories are optional. - - The common auxiliar directories should be present always. This is, in order to provide the information required by render functionality (i.e., to make it functional in the more basic level of its existence). - Notice how the duplication process is done from `trunk/Identity' on, not the oposite. If you try to duplicate a translation structure (or similar auxiliar directory structures like pre-rendition configuration scripts), the `trunk/Identity' for that translation is not created. This limitation is impossed by the fact that many `trunk/Identity' directory structures may reuse/share the same translation directory structure. We cannot delete one translation (or similar) directory structures while a related `trunk/Identity/' directory structure is still in need of it. - The `render_doCopy' functionality does duplicate directory structures directly involved in rendition process only. Once such directories have been duplicated, the functionality stops thereat. - - - - Usage - - • - - ... - - - - - See also - - - Directories trunk Scripts Functions Render Config - Directories trunk Scripts Functions Render Config - - - - + + + The production flow of “optimize+flexibility” configuration&dots; + Renderable translation directory structures + Translation directory structures are auxiliar structures of renderable identity directory structures. There is one translation directory structure for each renderable identity directory structure. Inside translation directory structures we organize translation files used by renderable identity directory structures that produce translated images. Renderable identity directory structures that produce untranslated images don't use translation files, but they do use a translation directory structure, an empty translation directory structure, to be precise. + In order to aliviate production of translation file, we made translation directory structures renderable adding a template (Tpl/) directory structure to handle common content inside translation files. This way, we work on translation templates and later use centos-art.sh to produce specific translation files (based on translation templates) for different information (e.g., languages, release numbers, architectures, etc.). + If for some reason, translation files get far from translation templates and translation templates become incovenient to produce such translation files then, care should be taken to avoid replacing the content of translation files with the content of translation templates when centos-art.sh is executed to produce translation files from translation templates. + Inside renderable translation directory structures, centos-art.sh can produce text-based files only. + Copying renderable directory structures + A renderable layout is formed by design models, design images, pre-rendition configuration scripts and translations files. This way, when we say to duplicate rendition stuff we are saying to duplicate these four directory structures (i.e., design models, design images, pre-rendition configuration scripts, and related translations files). + When we duplicate directories, inside `trunk/Identity' directory structure, we need to be aware of renderable layout described above and the source location used to perform the duplication action. The source location is relevant to centos-art.sh script in order to determine the required auxiliar information inside directory structures that need to be copied too (otherwise we may end up with orphan directory structures unable to be rendered, due the absence of required information). + In order for a renderable directory structure to be valid, the new directory structure copied should match the following conditions: + + + To have a unique directory structure under trunk/Identity, organized by any one of the above organizational designs above. + + + To have a unique directory structure under trunk/Translations to store translation files. + + + To have a unique directory structure under trunk/Scripts/Bash/Functions/Render/Config to set pre-rendition configuration script. + + + As convenction, the render_doCopy function uses trunk/Identity directory structure as source location. Once the trunk/Identity directory structure has been specified and verified, the related path information is built from it and copied automatically to the new location specified by FLAG_TO variable. + Design templates + No translation: + Command: - centos-art render –copy=trunk/Identity/Path/To/Dir –to=trunk/Identity/NewPath/To/Dir + Sources: - trunk/Identity/Path/To/Dir - trunk/Translations/Identity/Path/To/Dir - trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir + Targets: - trunk/Identity/NewPath/To/Dir - trunk/Translations/Identity/NewPath/To/Dir - trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir + Renderable layout 2: + Command: - centos-art render –copy=trunk/Identity/Themes/Motifs/TreeFlower \ –to=trunk/Identity/Themes/Motifs/NewPath/To/Dir + Sources: - trunk/Identity/Themes/Motifs/TreeFlower - trunk/Translations/Identity/Themes - trunk/Translations/Identity/Themes/Motifs/TreeFlower - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower + Targets: - trunk/Identity/Themes/Motifs/NewPath/To/Dir - trunk/Translations/Identity/Themes - trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes - trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir + Notice that design models are not included in source or target locations. This is intentional. In “Renderable layout 2”, design models live by their own, they just exist, they are there, available for any artistic motif to use. By default `Themes/Models/Default' design model directory structure is used, but other design models directory structures (under Themes/Models/) can be created and used changing the value of THEMEMODEL variable inside the pre-rendition configuration script of the artistic motif source location you want to produce. + Notice how translations and pre-rendition configuration scripts may both be equal in source and target. This is because such structures are common to all artistic motifs (the default values to use when no specific values are provided). + - The common directory structures are not copied or deleted. We cannot copy a directory structure to itself. + - The common directory structures represent the default value to use when no specific translations and/or pre-rendition configuration script are provided inside source location. + - The specific directory structures, if present, are both copiable and removable. This is, when you perform a copy or delete action from source, that source specific auxiliar directories are transfered in the copy action to a new location (that specified by FLAG_TO variable). + - When translations and/or pre-rendition configuration scripts are found inside the source directory structure, the centos-art.sh script loads common auxiliar directories first and later specific auxiliar directories. This way, identity rendition of source locations can be customized idividually over the base of common default values. + - The specific auxiliar directories are optional. + - The common auxiliar directories should be present always. This is, in order to provide the information required by render functionality (i.e., to make it functional in the more basic level of its existence). + Notice how the duplication process is done from `trunk/Identity' on, not the oposite. If you try to duplicate a translation structure (or similar auxiliar directory structures like pre-rendition configuration scripts), the `trunk/Identity' for that translation is not created. This limitation is impossed by the fact that many `trunk/Identity' directory structures may reuse/share the same translation directory structure. We cannot delete one translation (or similar) directory structures while a related `trunk/Identity/' directory structure is still in need of it. + The `render_doCopy' functionality does duplicate directory structures directly involved in rendition process only. Once such directories have been duplicated, the functionality stops thereat. + Usage + + • + + ... + + + See also + + + Directories trunk Scripts Functions Render Config + Directories trunk Scripts Functions Render Config + + + @@ -4842,21 +4257,15 @@ function render_loadConfig {
The <file>trunk/Scripts/Functions/Render/Config</file> Directory Directories trunk Scripts Functions Render Config - - Goals - The trunk/Scripts/Bash/Config directory exists to oraganize pre-rendering configuration scripts. - - - - Description - Pre-rendering configuration scripts let you customize the way centos-art.sh script renders identity and translation repository entries. Pre-rendering configuration scripts are render.conf.sh files with render_loadConfig function definition inside. - There is one render.conf.sh file for each pre-rendering configuration entry. Pre-rendering configuration entries can be based both on identity and translation repository entires. Pre-rendering configuration entries are required for each identity entry, but not for translation entries. - - - The <file>render.conf.sh</file> identity model - Inside CentOS Artwork Repository, we consider identity entries to all directories under trunk/Identity directory. Identity entries can be image-based or text-based. When you render image-based identity entries you need to use image-based pre-rendering configuration scripts. Likewise, when you render text-based identity entries you need to use text-based pre-rendering configuration scripts. - Inside identity pre-rendering configuration scripts, image-based pre-rendering configuration scripts look like the following: - Goals + The trunk/Scripts/Bash/Config directory exists to oraganize pre-rendering configuration scripts. + Description + Pre-rendering configuration scripts let you customize the way centos-art.sh script renders identity and translation repository entries. Pre-rendering configuration scripts are render.conf.sh files with render_loadConfig function definition inside. + There is one render.conf.sh file for each pre-rendering configuration entry. Pre-rendering configuration entries can be based both on identity and translation repository entires. Pre-rendering configuration entries are required for each identity entry, but not for translation entries. + The render.conf.sh identity model + Inside CentOS Artwork Repository, we consider identity entries to all directories under trunk/Identity directory. Identity entries can be image-based or text-based. When you render image-based identity entries you need to use image-based pre-rendering configuration scripts. Likewise, when you render text-based identity entries you need to use text-based pre-rendering configuration scripts. + Inside identity pre-rendering configuration scripts, image-based pre-rendering configuration scripts look like the following: + - Inside identity pre-rendering configuration scripts, text-based pre-rendering configuration scripts look like the following: - Inside identity pre-rendering configuration scripts, text-based pre-rendering configuration scripts look like the following: + - When using identity pre-rendering configuration scripts, you can extend both image-based and text-based pre-rendering configuration scripts using image-based and text-based post-rendering actions, respectively. - - - - The <file>render.conf.sh</file> translation model - Translation pre-rendering configuration scripts take precedence before default translation rendering action. Translation pre-rendering actions are useful when default translation rendering action do not fit itself to translation entry rendering requirements. - - - - The <file>render.conf.sh</file> rendering actions - Inside both image-based and text-based identity pre-rendering configuration scripts, we use the ACTIONS array variable to define the way centos-art.sh script performs identity rendering. Identity rendering is organized by one BASE action, and optional POST and LAST rendering actions. - The BASE action specifies what kind of rendering does the centos-art.sh script will perform with the files related to the pre-rendering configuration script. The BASE action is required. Possible values to BASE action are either renderImage or renderText only. - To specify the BASE action you need to set the BASE: string followed by one of the possible values. For example, if you want to render images, consider the following definition of BASE action: - When using identity pre-rendering configuration scripts, you can extend both image-based and text-based pre-rendering configuration scripts using image-based and text-based post-rendering actions, respectively. + The render.conf.sh translation model + Translation pre-rendering configuration scripts take precedence before default translation rendering action. Translation pre-rendering actions are useful when default translation rendering action do not fit itself to translation entry rendering requirements. + The render.conf.sh rendering actions + Inside both image-based and text-based identity pre-rendering configuration scripts, we use the ACTIONS array variable to define the way centos-art.sh script performs identity rendering. Identity rendering is organized by one BASE action, and optional POST and LAST rendering actions. + The BASE action specifies what kind of rendering does the centos-art.sh script will perform with the files related to the pre-rendering configuration script. The BASE action is required. Possible values to BASE action are either renderImage or renderText only. + To specify the BASE action you need to set the BASE: string followed by one of the possible values. For example, if you want to render images, consider the following definition of BASE action: + - Only one BASE action must be specified. If more than one BASE action is specified, the last one is used. If no BASE action is specified at all, an error is triggered and the centos-art.sh script ends its execution. - The POST action specifies which action to apply for each file rendered (at the rendering time). This action is optional. You can set many different POST actions to apply many different actions over the same already rendered file. Possible values to POST action are renderFormats, renderSyslinux, renderGrub, etc. - To specify the POST action, you need to use set the POST: followed by the function name of the action you want to perform. The exact form depends on your needs. For example, consider the following example to produce xpm, jpg, and tif images, based on already rendered png image, and also organize the produced files in directories named as their own extensions: - Only one BASE action must be specified. If more than one BASE action is specified, the last one is used. If no BASE action is specified at all, an error is triggered and the centos-art.sh script ends its execution. + The POST action specifies which action to apply for each file rendered (at the rendering time). This action is optional. You can set many different POST actions to apply many different actions over the same already rendered file. Possible values to POST action are renderFormats, renderSyslinux, renderGrub, etc. + To specify the POST action, you need to use set the POST: followed by the function name of the action you want to perform. The exact form depends on your needs. For example, consider the following example to produce xpm, jpg, and tif images, based on already rendered png image, and also organize the produced files in directories named as their own extensions: + - In the previous example, file organization takes place at the moment of rendering, just after producing the png base file and before going to the next file in the list of files to render. If you don't want to organized the produced files in directories named as their own extensions, just remove the POST:groupByFormat action line: - In the previous example, file organization takes place at the moment of rendering, just after producing the png base file and before going to the next file in the list of files to render. If you don't want to organized the produced files in directories named as their own extensions, just remove the POST:groupByFormat action line: + - The LAST action specifies which actions to apply once the last file in the list of files to process has been rendered. The LAST action is optional. Possible values for LAST actions may be groupByFormat, renderGdmTgz, etc. - - Note — Removed(xref:trunk Scripts Bash Functions Render) —, to know more about possible values for BASE, POST and LAST action definitions. - - To specify the LAST action, you need to set the LAST: string followed by the function name of the action you want to perform. For example, consider the following example if you want to render all files first and organize them later: - The LAST action specifies which actions to apply once the last file in the list of files to process has been rendered. The LAST action is optional. Possible values for LAST actions may be groupByFormat, renderGdmTgz, etc. + + Note — Removed(xref:trunk Scripts Bash Functions Render) —, to know more about possible values for BASE, POST and LAST action definitions. + + To specify the LAST action, you need to set the LAST: string followed by the function name of the action you want to perform. For example, consider the following example if you want to render all files first and organize them later: + - - - - - Usage - Use the following commands to administer both identity and translation pre-rendering configuration scripts: - - - centos-art config --create='path/to/dir/' - - Use this command to create path/to/dir related pre-rendering configuration script. - - - - centos-art config --edit='path/to/dir/' - - Use this command to edit path/to/dir related pre-rendering configuration script. - - - - centos-art config --read='path/to/dir/' - - Use this command to read path/to/dir related pre-rendering configuration script. - - - - centos-art config --remove='path/to/dir/' - - Use this command to remove path/to/dir related pre-rendering configuration script. - - -
- In the commands above, path/to/dir refers to one renderable directory path under trunk/Identity or trunk/Translations structures only. - - - - See also - - - Directories trunk Scripts - Directories trunk Scripts - - - - Directories trunk Scripts Functions - Directories trunk Scripts Functions - - - - Directories trunk Scripts Functions Render - Directories trunk Scripts Functions Render - - - + Usage + Use the following commands to administer both identity and translation pre-rendering configuration scripts: + + + centos-art config --create='path/to/dir/' + + Use this command to create path/to/dir related pre-rendering configuration script. + + + + centos-art config --edit='path/to/dir/' + + Use this command to edit path/to/dir related pre-rendering configuration script. + + + + centos-art config --read='path/to/dir/' + + Use this command to read path/to/dir related pre-rendering configuration script. + + + + centos-art config --remove='path/to/dir/' + + Use this command to remove path/to/dir related pre-rendering configuration script. + + +
+ In the commands above, path/to/dir refers to one renderable directory path under trunk/Identity or trunk/Translations structures only. + See also + + + Directories trunk Scripts + Directories trunk Scripts + + + + Directories trunk Scripts Functions + Directories trunk Scripts Functions + + + + Directories trunk Scripts Functions Render + Directories trunk Scripts Functions Render + + + -