| <?xml version="1.0"?> |
| <!DOCTYPE texinfo PUBLIC "-//GNU//DTD TexinfoML V4.8//EN" "http://www.gnu.org/software/texinfo/dtd/4.8/texinfo.dtd"> |
| <texinfo xml:lang="en"> |
| <setfilename>repository.xml</setfilename> |
| <settitle>CentOS Artwork Repository</settitle> |
| |
| <para>This manuals documents relevant information regarding the deployment, organization, and administration of CentOS Artwork Repository.</para> |
| <para>Copyright ©right; 2009-2011 Alain Reguera Delgado</para> |
| <para>Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. |
| </para> |
| <titlepage> |
| <booktitle>CentOS Artwork Repository</booktitle> |
| <booksubtitle>Manual</booksubtitle> |
| <author>Alain Reguera Delgado</author> |
| <para>This manuals documents relevant information regarding the deployment, organization, and administration of CentOS Artwork Repository.</para> |
| <para>Copyright ©right; 2009-2011 Alain Reguera Delgado</para> |
| <para>Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.</para> |
| </titlepage> |
| <contents></contents> |
| |
| <node> |
| <nodename>Top</nodename> |
| <nodeup>(dir)</nodeup> |
| <unnumbered> |
| <title>CentOS Artwork Repository</title> |
| <para>This manuals documents relevant information regarding the deployment, organization, and administration of CentOS Artwork Repository.</para> |
| <para>Copyright ©right; 2009-2011 Alain Reguera Delgado</para> |
| <para>Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.</para> |
| <menu> |
| <menuentry> |
| <menunode>Introduction</menunode> |
| <menutitle>Introduction</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories</menunode> |
| <menutitle>Directories</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Index</menunode> |
| <menutitle>Index</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>List of Figures</menunode> |
| <menutitle>List of Figures</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| |
| </unnumbered> |
| </node> |
| <node> |
| <nodename>Introduction</nodename> |
| <nodenext>Directories</nodenext> |
| <nodeprev>Top</nodeprev> |
| <nodeup>Top</nodeup> |
| <chapter> |
| <title>Introduction</title> |
| <para><indexterm index="cp">Introduction</indexterm>Welcome to CentOS Artwork Repository Manual.</para> |
| <para>The CentOS Artwork Repository Manual describes how The CentOS Project Corporate Visual Identity is organized and produced inside the CentOS Artwork Repository (<uref><urefurl>https://projects.centos.org/svn/artwork/</urefurl></uref>). If you are looking for a comprehensive, task-oriented guide for understanding how The CentOS Project Corporate Visual Identity is produced, this is the manual for you.</para> |
| <para>This manual discusses the following intermedite topics:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>The CentOS Brand</para> |
| </item> |
| <item> |
| <para>The CentOS Corporate Visual Structure</para> |
| </item> |
| <item> |
| <para>The CentOS Corporate Visual Style</para> |
| </item> |
| </itemize> |
| <para>This manual is organized in the same way of CentOS Artwork Repository directory structure. In the CentOS Artwork Repository we use directories to store conceptual ideas of The CentOS Project Corporate Visual Identity. For this manual sake, each directory in CentOS Artwork Repository has its own documentation section to describe the related conceptual ideas it is based on.</para> |
| <para>This manual uses Texinfo as base documentation system. The Texinfo documentation structure is controlled by the <code>help</code> functionality of <command>centos-art.sh</command> script. Through this functionality you can create documentation sections for each directory structure inside the repository and edit those already created, as well. See <xref><xrefnodename>Directories trunk Scripts Functions Help</xrefnodename></xref>, for more information on how to use the <command>help</command> functionality of <command>centos-art.sh</command> script.</para> |
| <para>This guide assumes you have a basic understanding of your CentOS system. If you need help with CentOS, refer to the help page on the CentOS Wiki (<uref><urefurl>http://wiki.centos.org/Help</urefurl></uref>) for a list of different places you can find help.</para> |
| <menu> |
| <menuentry> |
| <menunode>History</menunode> |
| <menutitle>History</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Authors</menunode> |
| <menutitle>Authors</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Copying Conditions</menunode> |
| <menutitle>Copying Conditions</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Convenctions</menunode> |
| <menutitle>Convenctions</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Feedback</menunode> |
| <menutitle>Feedback</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </chapter> |
| </node> |
| <node> |
| <nodename>History</nodename> |
| <nodenext>Authors</nodenext> |
| <nodeup>Introduction</nodeup> |
| <section> |
| <title>History</title> |
| <para><indexterm index="cp">History</indexterm>This section records noteworthy changes of CentOS Artwork Repository.</para> |
| <subheading>2008</subheading> |
| <para>The CentOS Artwork Repository started at CentOS Developers mailing list (<email><emailaddress>centos-devel@centos.org</emailaddress></email>) during a discussion about how to automate the slide images of Anaconda. In such discussion, Ralph Angenendt rose up his hand to ask: Do you have something to show?</para> |
| <para>To answer the question, Alain Reguera Delgado posted a bash script to produce slide images in different languages —together with the proposition of creating a Subversion centralized repository where translations and image production could be distributed inside The CentOS Community—.</para> |
| <para>Karanbirn Sighn considered the idea intresting and provides the infrastructure to support the effort. This way both the CentOS Artwork SIG and the CentOS Artwork Repository were created.</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><uref><urefurl>https://projects.centos.org/svn/artwork/</urefurl></uref></para> |
| </item> |
| <item> |
| <para><uref><urefurl>https://projects.centos.org/trac/artwork/</urefurl></uref></para> |
| </item> |
| </itemize> |
| <para>Once the CentOS Artwork Repository was available, Alain Reguera Delagdo uploaded the bash script for rendering Anaconda slides and Ralph Angenendt documented the script very well.</para> |
| <para>Once the rendition script and its documentation were available online, translators started to download working copies of CentOS Artwork Repository to produce slide images in their own languages.</para> |
| <subheading>2009</subheading> |
| <para>The rendition script is designed to take one SVG file, apply one SED file with replacement command inside to produce one SVG translated instance that is used to produce one translated PNG image by means of Inkscape program. The rendition script was named <command>render.sh</command> and it is copied to each directory structure that requires such process to produce images.</para> |
| <para>Furthermore, functionalies are centralized in a common placed and linked from different directory structures. There is no need to have the same code in different directory structures if can have it in just one place and then create links to it.</para> |
| <para>Start to implement concepts about corporate identity. As referece it is used Wikipedia (<uref><urefurl>http://en.wikipedia.org/Corporate_identity</urefurl></uref>) and the book <emph>Corporate Identity</emph> by Wally Olins (1989). The main goal of <command>render.sh</command> becomes to: automate production of a monolithic corporate visual identity structure based on The CentOS Mission and The CentOS Release Schema.</para> |
| <para>Around March, Alain Reguera Delgado is out of Internet for an undefined amount of time, but continues developing the idea of CentOS Artwork Repository and the rendition script off-line.</para> |
| <para>Most of the work I propose from this time on is my own responsability. I keep myself thinking to be part of the CentOS Artwork SIG and in that sake, I use the personal pronoun <emph>we</emph> to refer what I do as part of the group hoping someday to share this work with you again and improve it together.</para> |
| <para>The CentOS Artwork Repository documentation starts to take form in &latex; format.</para> |
| <subheading>2010</subheading> |
| <para>The <command>render.sh</command> is removed from the repository directory structures and the <command>centos-art.sh</command> script is used instead. The <command>centos-art.sh</command> is created to be a command-line interface that automate most frequent tasks inside the repository and can be called anywhere inside the repository or outside it; whenever it points to a directory structure inside the repository. At the very first moments of using <command>centos-art.sh</command> command-line, it used to have the following using form:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art function --action=path/to/dir |
| ]]></verbatim> |
| <para>Inside the rendition script, functionalities started to get identified and separated one another. For example, when images are rendered, there is no need to load manual functionality. There are now common functionalities and specific functionalities. Common functionalities are loaded when the script is initiated and are available to specific functionalities.</para> |
| <para>Start using <command>getopt</command> to handle command-line options.</para> |
| <para>The repository directory structure is optimized to continue implementing corporate identity concepts and the <command>centos-art</command> command-line.</para> |
| <subheading>2011</subheading> |
| <para>The `trunk/Translation' directory structure is removed. The `trunk/Locales' directory structure is used instead to store locale information.</para> |
| <para>The `.sed' translation files are no longer used, scalable vector graphics are used instead. Translation messages take place by means of xml2po and gettext. With xml2po translatable strings are retrived from `.svg' files and stored inside gettext `.pot' and `.po' files for translators to edit. Finally, xml2po is used again to build the temporal design model translated instance which the final `.png' image is built from.</para> |
| <para>Inside <command>centos-art.sh</command>, update command-line arguments and options parsing. Keep using <command>getopt</command> to parse options passed in the command-line, but change the way <command>centos-art.sh</command> is called from. The following form is used:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art function path/to/dir --options |
| ]]></verbatim> |
| <para>Start using verbs to name the <command>centos-art.sh</command> functionalities.</para> |
| <para>Organize <command>centos-art.sh</command> functionalities in “administrative” functions and “productive” functions. Administrative functions cover actions like: copying, deleting and renaming directory structures. Also, preparing your workstation for using <command>centos-art</command> command-line, make backups of the distribution theme currently installed, installing themes created inside The CentOS Artwork repository and restoring themes from backup. On the other hand, productive functions cover actions like: content rendition, content localization, content documentation and content maintainance.</para> |
| </section> |
| </node> |
| <node> |
| <nodename>Authors</nodename> |
| <nodenext>Copying Conditions</nodenext> |
| <nodeprev>History</nodeprev> |
| <nodeup>Introduction</nodeup> |
| <section> |
| <title>Authors</title> |
| <para><indexterm index="cp">Authors</indexterm>This section records authoring information of CentOS Artwork Repository, in alphabetical order.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Ralph Angenendt <ralph@centos.org> |
| Marcus Moeller <marcus@moeller.org> |
| Alain Reguera Delgado <al@localhost>, 2009, 2010, 2011 |
| Karanbirn Singh <karan@centos.org> |
| ]]></verbatim> |
| </section> |
| </node> |
| <node> |
| <nodename>Copying Conditions</nodename> |
| <nodenext>Convenctions</nodenext> |
| <nodeprev>Authors</nodeprev> |
| <nodeup>Introduction</nodeup> |
| <section> |
| <title>Copying Conditions</title> |
| <para><indexterm index="cp">Copying conditions</indexterm>Inside the CentOS Artwork Repository you can find content branded by The CentOS Project and content not branded at all. Contents branded by The CentOS Project contain either The CentOS Trademark, The CentOS Logo or The CentOS Symbol. Content branded by The CentOS Project cannot be redistributed without previous conversation with The CentOS Project. However, you can study and modify both content branded by The CentOS Project and content not branded at all in the sake of proposing improvements to The CentOS Project corporate visual identity.</para> |
| <para>If you are using the CentOS Artwork Repository for producing your own corporate visual identity, you should remove all The CentOS Trademarks from your contents and rename the repository to something other than CentOS Artwork Repository.</para> |
| <para>The CentOS Artwork Repository organizes files in a very specific way to implement The CentOS Project corporate visual identity. This very specific organization of files is part of <command>centos-art.sh</command> script, a bash script that automates most of the frequent tasks inside the repository.</para> |
| |
| <subsection> |
| <title>The <command>centos-art.sh</command> script</title> |
| <para>The <command>centos-art.sh</command> script and the organization of files it needs to work are not in the public domain; they are copyrighted and there are restrictions on their distribution, but these restrictions are designed to permit everything that a good cooperating citizen would want to do. What is not allowed is to try to prevent others from further sharing any version of this program that they might get from you.</para> |
| <para>Specifically, we want to make sure that you have the right to give away copies of <command>centos-art.sh</command> script, that you receive source code or else can get it if you want it, that you can change this program or use pieces of it in new free programs, and that you know you can do these things.</para> |
| <para>To make sure that everyone has such rights, we have to forbid you to deprive anyone else of these rights. For example, if you distribute copies of the <command>centos-art.sh</command> script, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must tell them their rights.</para> |
| <para>Also, for our own protection, we must make certain that everyone finds out that there is no warranty for the <command>centos-art.sh</command> script. If this program is modified by someone else and passed on, we want their recipients to know that what they have is not what we distributed, so that any problems introduced by others will not reflect on our reputation.</para> |
| <para>The precise conditions of the license for the <command>centos-art.sh</command> script are found in the General Public Licenses that accompany it (see <file>trunk/COPYING</file> file). This manual specifically is covered by the GNU Free Documentation License.</para> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Convenctions</nodename> |
| <nodenext>Feedback</nodenext> |
| <nodeprev>Copying Conditions</nodeprev> |
| <nodeup>Introduction</nodeup> |
| <section> |
| <title>Document Convenctions</title> |
| <para><indexterm index="cp">Document convenctions</indexterm>In this manual the personal pronoun <emph>we</emph> is used to repesent <emph>The CentOS Artwork SIG</emph>. This is, the group of persons building the CentOS Artwork Repository.</para> |
| <para>In this manual, certain words are represented in different fonts, typefaces, sizes, and weights. This highlighting is systematic; different words are represented in the same style to indicate their inclusion in a specific category. The types of words that are represented this way include the following:</para> |
| <table> |
| <tableitem> |
| <tableterm><command>command</command></tableterm> |
| <item> |
| <para>Linux commands (and other operating system commands, when used) are represented this way. This style should indicate to you that you can type the word or phrase on the command line and press Enter to invoke a command. Sometimes a command contains words that would be displayed in a different style on their own (such as file names). In these cases, they are considered to be part of the command, so the entire phrase is displayed as a command. For example:</para> |
| <para>Use the <command>centos-art identity --render='path/to/dir'</command> command to produce contents inside the <file>trunk/Identity</file> directory structure.</para> |
| </item> |
| </tableitem> |
| </table> |
| <table> |
| <tableitem> |
| <tableterm><file>file name</file></tableterm> |
| <item> |
| <para>File names, directory names, paths, and RPM package names are represented this way. This style indicates that a particular file or directory exists with that name on your system. Examples:</para> |
| <para>The <file>init.sh</file> file in <file>trunk/Scripts/Bash/Cli/</file> directory is the initialization script, written in Bash, used to automate most of tasks in the repository.</para> |
| <para>The <command>centos-art</command> command uses the <file>ImageMagick</file> RPM package to convert images from PNG format to other formats.</para> |
| </item> |
| </tableitem> |
| </table> |
| <table> |
| <tableitem> |
| <tableterm><key><key>key</key></key></tableterm> |
| <item> |
| <para>A key on the keyboard is shown in this style. For example:</para> |
| <para>To use <key>TAB</key> completion to list particular files in a directory, type <command>ls</command>, then a character, and finally the Tab key. Your terminal displays the list of files in the working directory that begin with that character.</para> |
| </item> |
| </tableitem> |
| </table> |
| <table> |
| <tableitem> |
| <tableterm><key><key>key-combination</key></key></tableterm> |
| <item> |
| <para>A combination of keystrokes is represented in this way. For example:</para> |
| <para>The <key>Ctrl-Alt-Backspace</key> key combination exits your graphical session and returns you to the graphical login screen or the console.</para> |
| </item> |
| </tableitem> |
| </table> |
| <table> |
| <tableitem> |
| <tableterm><code><code>computer output</code></code></tableterm> |
| <item> |
| <para>Text in this style indicates text displayed to a shell prompt such as error messages and responses to commands. For example:</para> |
| <para>The <command>ls</command> command displays the contents of a directory. For example:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Config manual_renameEntry.sh |
| manual_copyEntry.sh manual_restoreCrossReferences.sh |
| manual_deleteCrossReferences.sh manual_searchIndex.sh |
| ]]></verbatim> |
| <para>The output returned in response to the command (in this case, the contents of the directory) is shown in this style.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>Additionally, we use several different strategies to draw your attention to certain pieces of information. In order of urgency, these items are marked as a note, tip, important, caution, or warning. For example:</para> |
| <quotation> |
| <para><strong>Note</strong> Remember that Linux is case sensitive. In other words, a rose is not a ROSE is not a rOsE.</para> |
| </quotation> |
| <quotation> |
| <para><strong>Tip</strong> The directory <file>/usr/share/doc/</file> contains additional documentation for packages installed on your system.</para> |
| </quotation> |
| <quotation> |
| <para><strong>Important</strong> If you modify the DHCP configuration file, the changes do not take effect until you restart the DHCP daemon.</para> |
| </quotation> |
| <quotation> |
| <para><strong>Caution</strong> Do not perform routine tasks as root — use a regular user account unless you need to use the root account for system administration tasks.</para> |
| </quotation> |
| <quotation> |
| <para><strong>Warning</strong> Be careful to remove only the necessary partitions. Removing other partitions could result in data loss or a corrupted system environment.</para> |
| </quotation> |
| </section> |
| </node> |
| <node> |
| <nodename>Feedback</nodename> |
| <nodeprev>Convenctions</nodeprev> |
| <nodeup>Introduction</nodeup> |
| <section> |
| <title>Send in Your Feedback</title> |
| <para><indexterm index="cp">Feedback</indexterm>If you find an error in the <emph>CentOS Artwork Repository Manual</emph>, or if you have thought of a way to make this manual better, we would like to hear from you! Create a new ticket in The CentOS Artwork SIG web site (<uref><urefurl>https://projects.centos.org/trac/artwork/</urefurl></uref>).</para> |
| <para>If you have a suggestion for improving the documentation, try to be as specific as possible. If you have found an error, include the section number and some of the surrounding text so we can find it easily.</para> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories</nodename> |
| <nodenext>Index</nodenext> |
| <nodeprev>Introduction</nodeprev> |
| <nodeup>Top</nodeup> |
| <chapter> |
| <title>The Repository Directories</title> |
| <para><indexterm index="cp">Repository directories</indexterm>The CentOS Artwork Repository uses directories to organize files and describe conceptual idea about corporate identity. Such conceptual ideas are explained in each directory related documentation entry.</para> |
| <para>In this chapter you'll learn what each directory inside The CentOS Artwork Repository is for and so, how you can make use of them. For that purpose, the following list of directories is available for you to explore:</para> |
| <menu> |
| <menuentry> |
| <menunode>Directories branches</menunode> |
| <menutitle>Directories branches</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories tags</menunode> |
| <menutitle>Directories tags</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk</menunode> |
| <menutitle>Directories trunk</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity</menunode> |
| <menutitle>Directories trunk Identity</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Brands</menunode> |
| <menutitle>Directories trunk Identity Brands</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Colors</menunode> |
| <menutitle>Directories trunk Identity Colors</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Fonts</menunode> |
| <menutitle>Directories trunk Identity Fonts</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Icons</menunode> |
| <menutitle>Directories trunk Identity Icons</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Isolinux</menunode> |
| <menutitle>Directories trunk Identity Isolinux</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models</menunode> |
| <menutitle>Directories trunk Identity Models</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Css</menunode> |
| <menutitle>Directories trunk Identity Models Css</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Html</menunode> |
| <menutitle>Directories trunk Identity Models Html</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Img Promo Web</menunode> |
| <menutitle>Directories trunk Identity Models Img Promo Web</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Tpl</menunode> |
| <menutitle>Directories trunk Identity Models Tpl</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Tpl Brands</menunode> |
| <menutitle>Directories trunk Identity Models Tpl Brands</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Tpl Promo Web</menunode> |
| <menutitle>Directories trunk Identity Models Tpl Promo Web</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Xcf</menunode> |
| <menutitle>Directories trunk Identity Models Xcf</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Release</menunode> |
| <menutitle>Directories trunk Identity Release</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes</menunode> |
| <menutitle>Directories trunk Identity Themes</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models</menunode> |
| <menutitle>Directories trunk Identity Themes Models</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Alternative</menunode> |
| <menutitle>Directories trunk Identity Themes Models Alternative</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Concept</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Concept</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Distro</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Distro</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Distro Anaconda</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Distro Anaconda</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Distro Firstboot</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Distro Firstboot</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Distro Gdm</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Distro Gdm</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Distro Grub</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Distro Grub</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Distro Gsplash</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Distro Gsplash</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Distro Kdm</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Distro Kdm</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Distro Ksplash</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Distro Ksplash</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Distro Rhgb</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Distro Rhgb</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Distro Syslinux</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Distro Syslinux</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Promo</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Promo</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default Web</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default Web</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs Flame</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs Flame</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs Modern</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs Modern</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs Modern Backgrounds</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs Modern Backgrounds</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs Modern Backgrounds Img</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs Modern Backgrounds Img</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs Modern Backgrounds Tpl</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs Modern Backgrounds Tpl</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs Modern Backgrounds Xcf</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs Modern Backgrounds Xcf</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs Modern Palettes</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs Modern Palettes</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs TreeFlower</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs TreeFlower</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs TreeFlower Backgrounds</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs TreeFlower Backgrounds</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Widgets</menunode> |
| <menutitle>Directories trunk Identity Widgets</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales</menunode> |
| <menutitle>Directories trunk Locales</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales Identity</menunode> |
| <menutitle>Directories trunk Locales Identity</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales Identity Brands</menunode> |
| <menutitle>Directories trunk Locales Identity Brands</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales Identity Brands Tpl</menunode> |
| <menutitle>Directories trunk Locales Identity Brands Tpl</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales Identity Fonts</menunode> |
| <menutitle>Directories trunk Locales Identity Fonts</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales Identity Models</menunode> |
| <menutitle>Directories trunk Locales Identity Models</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales Identity Release</menunode> |
| <menutitle>Directories trunk Locales Identity Release</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales Identity Themes</menunode> |
| <menutitle>Directories trunk Locales Identity Themes</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales Identity Themes Backgrounds</menunode> |
| <menutitle>Directories trunk Locales Identity Themes Backgrounds</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales Identity Themes Distro Anaconda Progress</menunode> |
| <menutitle>Directories trunk Locales Identity Themes Distro Anaconda Progress</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Locales Identity Widgets</menunode> |
| <menutitle>Directories trunk Locales Identity Widgets</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Manual</menunode> |
| <menutitle>Directories trunk Manual</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts</menunode> |
| <menutitle>Directories trunk Scripts</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions</menunode> |
| <menutitle>Directories trunk Scripts Functions</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Help</menunode> |
| <menutitle>Directories trunk Scripts Functions Help</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Html</menunode> |
| <menutitle>Directories trunk Scripts Functions Html</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Identity</menunode> |
| <menutitle>Directories trunk Scripts Functions Identity</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Locale</menunode> |
| <menutitle>Directories trunk Scripts Functions Locale</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Manual</menunode> |
| <menutitle>Directories trunk Scripts Functions Manual</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Path</menunode> |
| <menutitle>Directories trunk Scripts Functions Path</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Render</menunode> |
| <menutitle>Directories trunk Scripts Functions Render</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Render Config</menunode> |
| <menutitle>Directories trunk Scripts Functions Render Config</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Shell</menunode> |
| <menutitle>Directories trunk Scripts Functions Shell</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Svg</menunode> |
| <menutitle>Directories trunk Scripts Functions Svg</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Verify</menunode> |
| <menutitle>Directories trunk Scripts Functions Verify</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </chapter> |
| </node> |
| <node> |
| <nodename>Directories branches</nodename> |
| <nodenext>Directories tags</nodenext> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>branches</file> Directory</title> |
| <para><indexterm index="cp">Directories branches</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This directory implements the Subversion's branches concept in a trunk, branches, tags repository structure.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>The <file>branches/</file> directory structre provides the intermediate space for creating several instances of <file>trunk/</file> directory structure for parallel development and later merging changes back to <file>trunk/</file> in the same parallel basis.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>The <file>branches/</file> directory structure is unused, so far.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>See <xref><xrefnodename>Directories tags</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>Subversion's book (<uref><urefurl>http://svnbook.red-bean.com/</urefurl></uref>).</para> |
| </item> |
| </itemize> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories tags</nodename> |
| <nodenext>Directories trunk</nodenext> |
| <nodeprev>Directories branches</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>tags</file> Directory</title> |
| <para><indexterm index="cp">Directories tags</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This directory implements the Subversion's tags concept in a trunk, branches, tags repository structure.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>The <file>tags/</file> directory structre provides frozen branches. Generally, we use frozen branches to make check-points in time for development lines under <file>branches/</file> or <file>trunk/</file> directory structure.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>The <file>tags/</file> directory structure is unused, so far.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>See <xref><xrefnodename>Directories branches</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>Subversion's book (<uref><urefurl>http://svnbook.red-bean.com/</urefurl></uref>).</para> |
| </item> |
| </itemize> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk</nodename> |
| <nodenext>Directories trunk Identity</nodenext> |
| <nodeprev>Directories tags</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This directory implements the Subversion's trunk concept in a trunk, branches, tags repository structure.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>The <file>trunk/</file> directory structure is the main development line inside the CentOS Artwork Repository and organizes the following sections:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Identity</strong></tableterm> |
| <item> |
| <para>This section organizes image production in different formats and some non-image formats like XHTML and text files, as well. This is the perfect place to consolidate <emph>The CentOS Artwork SIG</emph>. If you are interested in producing art works for The CentOS Project, this place is for you.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Manual</strong></tableterm> |
| <item> |
| <para>This section organizes the <emph>CentOS Artwork Repository Manual</emph> (i.e., the documentation manual you're reading right now). If you are interested on improving The CentOS Artwork Repository Manual, in this place you'll find the Texinfo documentation structure you need to work with.</para> |
| <para>See <xref><xrefnodename>Directories trunk Manual</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Scripts</strong></tableterm> |
| <item> |
| <para>This section organizes production of automation 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.</para> |
| <para>See <xref><xrefnodename>Directories trunk Scripts</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Locales</strong></tableterm> |
| <item> |
| <para>This section organizes production of translation messages for <emph>Identity</emph>, <emph>Documentation</emph> and <emph>Scripts</emph>. This place is perfect to consolidate <emph>The CentOS Translation SIG</emph>. If you love translating, you'll find lot of messages waiting for you to translate here.</para> |
| <para>See <xref><xrefnodename>Directories trunk Locales</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>It seems to be no other use for this directory but to organize the sections described above.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>See <xref><xrefnodename>Directories branches</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>See <xref><xrefnodename>Directories tags</xrefnodename></xref>.</para> |
| </item> |
| <item> |
| <para>Subversion's book (<uref><urefurl>http://svnbook.red-bean.com/</urefurl></uref>).</para> |
| </item> |
| </itemize> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity</nodename> |
| <nodenext>Directories trunk Identity Brands</nodenext> |
| <nodeprev>Directories trunk</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>The <file>trunk/Identity</file> directory structure implements <emph>The CentOS Project Corporate Identity</emph>.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>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 visual identity expresses the values and ambitions of the CentOS Project organization, its business, and its characteristics.</para> |
| <para>The CentOS Project corporate identity provides visibility, recognizability, reputation, structure and identification to The CentOS Project organization by means of <emph>Corporate Design</emph>, <emph>Corporate Communication</emph>, and <emph>Corporate Behaviour</emph>.</para> |
| |
| <subsubsection> |
| <title>Corporate Design</title> |
| <para>The CentOS Project corporate design is applied to every single visual manifestations The CentOS Project as organization wants to express its existence. Examples of the most relevant visual manifestations inside The CentOS Project are <emph>The CentOS Distribution</emph>, <emph>The CentOS Web</emph> and <emph>The CentOS Stationery</emph>.</para> |
| <para>The CentOS Project corporate design is organized in the following work-lines:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>The CentOS Brand</strong></tableterm> |
| <item> |
| <para>The CentOS Brand is the 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.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Brands</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>The CentOS Colors</strong></tableterm> |
| <item> |
| <para>The CentOS Fonts provides the color information used along The CentOS Project visual manifestations.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Colors</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>The CentOS Fonts</strong></tableterm> |
| <item> |
| <para>The CentOS Fonts provides the typography information used along The CentOS Project visual manifestations.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Fonts</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>The CentOS Themes</strong></tableterm> |
| <item> |
| <para>The CentOS Themes provides structural information and visual style information, as well, used along The CentOS Project visual manifestations.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity Themes</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Corporate Communication</title> |
| <para>The CentOS Project corporate communication is based on community communication. In that sake, the following media are available for corporate communication:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>The CentOS Mailing Lists (<uref><urefurl>http://lists.centos.org/</urefurl></uref>).</para> |
| </item> |
| <item> |
| <para>The CentOS Forums (<uref><urefurl>http://forums.centos.org/</urefurl></uref>).</para> |
| </item> |
| </itemize> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Corporate Behaviour</title> |
| <para>The CentOS Project corporate behaviour is based on community behaviour.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Corporate Structure</title> |
| <para>The CentOS Project corporate structure is based on a <emph>monolithic</emph> corporate visual identity structure. In this structure, we use one unique name (The CentOS Brand) and one unique visual style (The CentOS Theme) in all The CentOS Project visual manifestations.</para> |
| <para>Inside 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: <emph>Hey! we are all part of The CentOS Project</emph>.</para> |
| <para>Other corporate structures have been considered as well, but they introduce visual contradictions we need to be aware of. In that sake, lets describe the idea of: <emph>Producing one different visual style for each major release of The CentOS Distribution</emph>.</para> |
| <para>The CentOS Project maintains near to four different major releases of The CentOS Distribution parallely in time and that fact makes one part of The CentOS Project structural design, but just one part, not the complete structural design. 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.</para> |
| <para>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. Would we end up with four different visual styles, one for each distribution? In that case, why The CentOS Distribution we use shows one visual style, The CentOS Web sites another and The CentOS Stationery even another completly different one? Isn't them all part of the same project?</para> |
| <para>Probably you be 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?</para> |
| <para>Harder to maintain, more work to do, it is 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 wangs or something but hardly working out to automate tasks and so providing maintainance through time. Said that, we consider that The CentOS Project visual structure should be consequent with such stability and consistency tradition. It is true 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.</para> |
| <para>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 does is in not propagating the brand new visual style created for the new release of 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.</para> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>The <file>trunk/</file> directory structure is organized in <emph>renderable</emph> and <emph>non-renderable</emph> directories. Generally, renderable directories contain two non-renderable directories inside, one to store design templates (the <file>Tpl/</file> directory), and other to store the content produced (the <file>Img/</file> directory).</para> |
| <para>In order to produce content inside rendereble directories, you can use the following command:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art render trunk/Identity/Path/To/Dir |
| ]]></verbatim> |
| <quotation> |
| <para><strong>Warning</strong> If the <command>centos-art</command> command-line is not found in your workstation, it is probably because you haven't prepared it for using The CentOS Artwork Repository yet. See <xref><xrefnodename>Directories trunk Scripts Functions Verify</xrefnodename></xref>, for more information.</para> |
| </quotation> |
| <para>This command takes one design template from the template directory and creates an instance of it in order to apply translation messages on it, if any. Later, using the design template instance, the command renders the final content based on whether the design template instance is a SVG file or a Docbook 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 Docbook file, the final content produced is a XHTML file. Final content is stored in the image directory using the design template directory paths as referece. The rendition flow described so far is known as the <emph>base-rendition</emph> flow.</para> |
| <para>Besides the base-rendition flow, the <command>centos-art</command> provides the <emph>post-rendition</emph> and <emph>last-rendition</emph> 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 (e.g., JPG, PDF, etc.) before passing to process the next file in the same directory structure. The last-rendition flow 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 <file>Preview.png</file> image from Ksplash component is made of three images. In order to build the <file>Preview.png</file> image through <command>centos-art</command> we need to wait for all the three images the <file>Preview.png</file> image is made of to be rendered, so we can combine them all together into just one image (i.e., the <file>Preview.png</file> image). This is something we can't do using post-rendition flow.</para> |
| <para>Inside <file>trunk/Identity</file> directory structure, you can find that base-rendition, post-rendition and last-rendition flows can be combined to build <emph>directory-specific</emph> rendition. The directory-specific rendition exists to automatically 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 to reach its final construction. Directory-specific rendition is a way to programmatically describe how specific art works are built in and organized inside The CentOS Artwork Repository. Such descriptions have been added to <command>centos-art</command> command-line to let you produce them all with just one single command, as fast as your machine can be able to handle it.</para> |
| <para>See <xref><xrefnodename>Directories trunk Scripts Functions Identity</xrefnodename></xref>, for more information about the <command>identity</command> functionality of <command>centos-art</command> command-line interface.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <para>See <uref><urefurl>http://en.wikipedia.org/Corporate_identity</urefurl></uref> (and related links), for general information on corporate identity.</para> |
| <para>Specially useful has been, and still be, the book <emph>Corporate Identity</emph> by Wally Olins (1989). This book provides many conceptual ideas we've used as base to build The CentOS Artwork Repository.</para> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Brands</nodename> |
| <nodenext>Directories trunk Identity Colors</nodenext> |
| <nodeprev>Directories trunk Identity</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Brands</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Brands</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Colors</nodename> |
| <nodenext>Directories trunk Identity Fonts</nodenext> |
| <nodeprev>Directories trunk Identity Brands</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Colors</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Colors</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Fonts</nodename> |
| <nodenext>Directories trunk Identity Icons</nodenext> |
| <nodeprev>Directories trunk Identity Colors</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Fonts</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Fonts</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This section exists to organize digital typographies used by the CentOS project.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>The CentOS corporate identity is attached to <samp>DejaVu LGC</samp> font-family. Whatever artwork you design for CentOS project, that requires typography usage, must be done using <samp>DejaVu LGC</samp> font-family.</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Recommendation-1:</strong></tableterm> |
| <item> |
| <para>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</samp> font-family.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Recommendation-2:</strong></tableterm> |
| <item> |
| <para>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</samp> font-family. As convenction files described in this rule are stored under <samp>Stationery</samp> directories.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>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</samp> (l) or letter <samp>ai</samp> (i)).</para> |
| <para>As CentOS logo typography convenction, the word <samp>CentOS</samp> uses <samp>Denmark</samp> typography as base, both for the word <samp>CentOS</samp> and the phrase <samp>Community Enterprise Operating System</samp>. The phrase size of CentOS logo is half the size in poits the word <samp>CentOS</samp> has and it below <samp>CentOS</samp> word and aligned with it on the left. The distance between <samp>CentOS</samp> word and phrase <samp>Community Enterprise Operating System</samp> have the size in points the phrase has.</para> |
| <para>When the CentOS release brand is built, use <samp>Denmark</samp> typography for the release number. The release number size is two times larger (in height) than default <samp>CentOS</samp> word. The separation between release number and <samp>CentOS</samp> word is twice the size in points of separation between <samp>CentOS</samp> word and phrase <samp>Community Enterprise Operating System</samp>.</para> |
| <para>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</samp> word. The trademark symbol must not exceed haf the distance, in points, between <samp>CentOS</samp> word and the release number on its right.</para> |
| <para>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.</para> |
| <quotation> |
| <para><strong>Note</strong> The information about trademarks and corporate identity is my personal interpretation of <uref><urefurl>http://en.wikipedia.org/Corporate_identity</urefurl></uref> and <uref><urefurl>http://en.wikipedia.org/Trademark</urefurl></uref> description. If you have practical experiences with these affairs, please serve yourself to improve this section with your reasons.</para> |
| </quotation> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Icons</nodename> |
| <nodenext>Directories trunk Identity Isolinux</nodenext> |
| <nodeprev>Directories trunk Identity Fonts</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Icons</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Icons</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Isolinux</nodename> |
| <nodenext>Directories trunk Identity Models</nodenext> |
| <nodeprev>Directories trunk Identity Icons</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Isolinux</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Isolinux</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models</nodename> |
| <nodenext>Directories trunk Identity Models Css</nodenext> |
| <nodeprev>Directories trunk Identity Isolinux</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This section exists to organize design models.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>Design models are representative designs useful to understand how to build artworks.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Html</menunode> |
| <menutitle>Directories trunk Identity Models Html</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Css</menunode> |
| <menutitle>Directories trunk Identity Models Css</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Tpl</menunode> |
| <menutitle>Directories trunk Identity Models Tpl</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Xcf</menunode> |
| <menutitle>Directories trunk Identity Models Xcf</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Css</nodename> |
| <nodenext>Directories trunk Identity Models Html</nodenext> |
| <nodeprev>Directories trunk Identity Models</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Css</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Css</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This directory exists to provide common style sheets (CSS) definitions to HTML design models.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Html</nodename> |
| <nodenext>Directories trunk Identity Models Img Promo Web</nodenext> |
| <nodeprev>Directories trunk Identity Models Css</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Html</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Html</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Img Promo Web</nodename> |
| <nodenext>Directories trunk Identity Models Tpl</nodenext> |
| <nodeprev>Directories trunk Identity Models Html</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Img/Promo/Web</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Img Promo Web</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>Provide images related to CentOS web interface.</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Tpl Promo Web</menunode> |
| <menutitle>Directories trunk Identity Models Tpl Promo Web</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Tpl</nodename> |
| <nodenext>Directories trunk Identity Models Tpl Brands</nodenext> |
| <nodeprev>Directories trunk Identity Models Img Promo Web</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Tpl</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Tpl</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Tpl Brands</nodename> |
| <nodenext>Directories trunk Identity Models Tpl Promo Web</nodenext> |
| <nodeprev>Directories trunk Identity Models Tpl</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Tpl/Brands</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Tpl Brands</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Tpl Promo Web</nodename> |
| <nodenext>Directories trunk Identity Models Xcf</nodenext> |
| <nodeprev>Directories trunk Identity Models Tpl Brands</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Tpl/Promo/Web</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Tpl Promo Web</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>Organize scalable vector graphics (svg) to help describe the CentOS web environment.</para> |
| </subsection> |
| |
| <subsection> |
| <title>The CentOS web environment</title> |
| <para>Inside CentOS corporate identity, the CentOS web environment is considered a promotion component. 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.)—.</para> |
| <para>The CentOS web environment is addressed to solve the following issues:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>One unique name and one unique visual style to all web applications used inside the web environment.</para> |
| </item> |
| <item> |
| <para>One-step navigation to web applications inside the environment.</para> |
| </item> |
| <item> |
| <para>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).</para> |
| </item> |
| </itemize> |
| <para>The CentOS project is attached to a monolithic corporate visual identity (see <xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>), 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.</para> |
| <para>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 (<uref><urefurl>http://wiki.centos.org/</urefurl></uref>) is highly customizable but Mailman (in its 2.x.x serie), the web application used to support the CentOS mailing list, doesn't support<footnote><para>The theme support of Mailman may be introduced in mailman-3.x.x release.</para></footnote> a customization system that separates presentation from logic, similar to that used by MoinMoin.</para> |
| <para>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).</para> |
| <para>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.</para> |
| <para>At the surface of this issue we can see the need of one specific yum repository to store CentOS web environment customized web applications.</para> |
| |
| <subsubsection> |
| <title>Design model (without ads)</title> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Design model (with ads)</title> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>HTML definitions</title> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Controlling visual style</title> |
| <para>Inside CentOS web environment, the visual style is controlled by the following compenents:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Webenv header background</strong></tableterm> |
| <item> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>CSS definitions</strong></tableterm> |
| <item> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Themes/Models/Default/Promo/Web/CSS/stylesheet.css |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| </table> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Producing visual style</title> |
| <para>The visual style of CentOS web environment is defined in the following files:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Xcf/1024x250.xcf |
| trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250.png |
| trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Img/1024x250-bg.png |
| trunk/Identity/Themes/Motifs/$THEME/Backgrounds/Tpl/1024x250.svg |
| ]]></verbatim> |
| <para>As graphic designer you use <file>1024x250.xcf</file> file to produce <file>1024x250-bg.png</file> file. Later, inside <file>1024x250.svg</file> file, you use the <file>1024x250-bg.png</file> file as background layer to draw your vectorial design. When you consider you artwork ready, use the <command>centos-art.sh</command> script, as described below, to produce the visual style controller images of CentOS web environment.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art render --entry=trunk/Identity/Themes/Motifs/$THEME/Backgrounds --filter='1024x250' |
| ]]></verbatim> |
| <para>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.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Navigation</title> |
| <para>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.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Development and release cycle</title> |
| <para>The CentOS web environment development and relase cycle is described below:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Download</strong></tableterm> |
| <item> |
| <para>The first action is download the source code of web applications we want to use inside CentOS web environment.</para> |
| <quotation> |
| <para><strong>Important</strong> The source location from which web application are downloaded is very important. Use SRPMs from CentOS <strong>[base]</strong> and <strong>[updates]</strong> repositories as first choise, and third party repositories (e.g. RPMForge, EPEL, etc.) as last resource.</para> |
| </quotation> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Prepare</strong></tableterm> |
| <item> |
| <para>Once web application source code has been downloaded, our duty is organize its files inside <samp>webenv</samp> version controlled repository.</para> |
| <para>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:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| https://projects.centos.org/svn/webenv/trunk/ |
| |-- WebApp1/ |
| | |-- Sources/ |
| | | `-- webapp1-0.0.1/ |
| | |-- Rpms/ |
| | | `-- webapp1-0.0.1.rpm |
| | |-- Srpms/ |
| | | `-- webapp1-0.0.1.srpm |
| | `-- Specs/ |
| | `-- webapp1-0.0.1.spec |
| |-- WebApp2/ |
| `-- WebAppN/ |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Customize</strong></tableterm> |
| <item> |
| <para>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 <file>webapp1-0.0.1/</file> with the following command:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| svn cp trunk/WebApp1/Sources/webapp1-0.0.1 trunk/WebApp1/Sources/webapp1-0.0.1-webenv |
| ]]></verbatim> |
| <para>The command above creates the following structure:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| https://projects.centos.org/svn/webenv/trunk/ |
| |-- WebApp1/ |
| | |-- Sources/ |
| | | |-- webapp1-0.0.1/ |
| | | `-- webapp1-0.0.1-webenv/ |
| | |-- Rpms/ |
| | | `-- webapp1-0.0.1.rpm |
| | |-- Srpms/ |
| | | `-- webapp1-0.0.1.srpm |
| | `-- Specs/ |
| | `-- webapp1-0.0.1.spec |
| |-- WebApp2/ |
| `-- WebAppN/ |
| ]]></verbatim> |
| <para>In the above structure, the <file>webapp1-0.0.1-webenv/</file> directory is the place where you customize the visual style of <file>webapp1-0.0.1/</file> web application.</para> |
| <quotation> |
| <para><strong>Tip</strong> Use the <command>diff</command> command of Subversion between CentOS customization and upstream development lines to know what you are changing exactly.</para> |
| </quotation> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Build packages</strong></tableterm> |
| <item> |
| <para>When web application has been customized, build the web application RPM and SRPM using the source location with <samp>-webenv</samp> prefix.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| https://projects.centos.org/svn/webenv/trunk/ |
| |-- WebApp1/ |
| | |-- Sources/ |
| | | |-- webapp1-0.0.1/ |
| | | `-- webapp1-0.0.1-webenv/ |
| | |-- Rpms/ |
| | | |-- webapp1-0.0.1.rpm |
| | | `-- webapp1-0.0.1-webenv.rpm |
| | |-- Srpms/ |
| | | |-- webapp1-0.0.1.srpm |
| | | `-- webapp1-0.0.1-webenv.srpm |
| | `-- Specs/ |
| | |-- webapp1-0.0.1.spec |
| | `-- webapp1-0.0.1-webenv.spec |
| |-- WebApp2/ |
| `-- WebAppN/ |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Release for testing</strong></tableterm> |
| <item> |
| <para>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.</para> |
| <quotation> |
| <para><strong>Note</strong> 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.</para> |
| </quotation> |
| <para>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 <samp>-webenv</samp> prefix. For example, if some problem is found in <file>webapp1-0.0.1-webenv.rpm</file>, when it be fixed the new package will be named <file>webapp1-0.0.1-webenv-1.rpm</file>. If a problem is found in <file>webapp1-0.0.1-webenv-1.rpm</file>, when it be fixed the new package will be named <file>webapp1-0.0.1-webenv-2.rpm</file>, and so on.</para> |
| <para>The “customization — release for testing” process is repeated until CentOS quality assurance team considers the package is ready for production.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Release for production</strong></tableterm> |
| <item> |
| <para>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.</para> |
| <quotation> |
| <para><strong>Note</strong> The [webenv] repository is not shipped inside CentOS distribution default yum configuraiton. In order to use [webenv] repository you need to configure it first.</para> |
| </quotation> |
| </item> |
| </tableitem> |
| </table> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>The [webenv-test] repository</title> |
| <verbatim xml:space="preserve"><![CDATA[ |
| /etc/yum.repos.d/CentOS-Webenv-test.repo |
| ]]></verbatim> |
| <verbatim xml:space="preserve"><![CDATA[ |
| [webenv-test] |
| name=CentOS-$releasever - Webenv-test |
| mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv-test |
| #baseurl=http://mirror.centos.org/centos/$releasever/webenv-test/$basearch/ |
| gpgcheck=1 |
| gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever |
| enabled=1 |
| priority=10 |
| ]]></verbatim> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>The [webenv] repository</title> |
| <verbatim xml:space="preserve"><![CDATA[ |
| /etc/yum.repos.d/CentOS-Webenv.repo |
| ]]></verbatim> |
| <verbatim xml:space="preserve"><![CDATA[ |
| [webenv] |
| name=CentOS-$releasever - Webenv |
| mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=webenv |
| #baseurl=http://mirror.centos.org/centos/$releasever/webenv/$basearch/ |
| gpgcheck=1 |
| gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever |
| enabled=1 |
| priority=10 |
| ]]></verbatim> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Priority configuration</title> |
| <para>Both [webenv] and [webenv-test] repositories update packages inside CentOS [base] and CentOS [updates] repositories.</para> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Identity Models Img Promo Web</menunode> |
| <menutitle>Directories trunk Identity Models Img Promo Web</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Models Xcf</nodename> |
| <nodenext>Directories trunk Identity Release</nodenext> |
| <nodeprev>Directories trunk Identity Models Tpl Promo Web</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Models/Xcf</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Models Xcf</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Release</nodename> |
| <nodenext>Directories trunk Identity Themes</nodenext> |
| <nodeprev>Directories trunk Identity Models Xcf</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Release</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Release</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes</nodename> |
| <nodenext>Directories trunk Identity Themes Models</nodenext> |
| <nodeprev>Directories trunk Identity Release</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>The <file>trunk/Identity/Themes/</file> directory exists to organize production of CentOS themes.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>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.</para> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models</menunode> |
| <menutitle>Directories trunk Identity Themes Models</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Identity</menunode> |
| <menutitle>Directories trunk Identity</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk</menunode> |
| <menutitle>Directories trunk</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models</nodename> |
| <nodenext>Directories trunk Identity Themes Models Alternative</nodenext> |
| <nodeprev>Directories trunk Identity Themes</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>Organize theme models.</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>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.</para> |
| <para>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.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>Inside the framework location above, you find theme models organized by name. You can add your own theme models to the structure by adding a directory to the list. By default you have the `See <xref><xrefnodename>Directories trunk Identity Themes Models Default</xrefnodename><xrefinfoname>Default</xrefinfoname></xref>,' and `See <xref><xrefnodename>Directories trunk Identity Themes Models Alternative</xrefnodename><xrefinfoname>Alternative</xrefinfoname></xref>,' ready-to-use theme models.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Alternative</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Alternative</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Alternative</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>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.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Concept</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Alternative</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>Default Design Models for CentOS Themes provide design models for the following components:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Distribution</strong></tableterm> |
| <item> |
| <para>Design models for CentOS Distribution (e.g., Anaconda, Firstboot, Gdm, Grub, Gsplash, Kdm, Ksplash, Rhgb and Syslinux, etc.). See <xref><xrefnodename>Directories trunk Identity Themes Models Default Distro</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Concept</strong></tableterm> |
| <item> |
| <para>Design models to illustrate Artistic Motifs Concepts. See <xref><xrefnodename>Directories trunk Identity Themes Models Default Concept</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Promotion</strong></tableterm> |
| <item> |
| <para>Design models for CentOS Promotion stuff (e.g., installation media, posters, etc.). See <xref><xrefnodename>Directories trunk Identity Themes Models Default Promo</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>This directory implements the concept of <emph>Default Design Models for CentOS Themes</emph>. Default Design Models for CentOS Themes provide the common structural information (e.g., image dimensions, translation markers, trademark position, etc.) the <command>centos-art</command> script uses to produce images when no other design model is specified.</para> |
| <para>Deisgn models in this directory do use the <emph>CentOS Release Brand</emph>. 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. See <xref><xrefnodename>Directories trunk Identity Models Tpl Brands</xrefnodename></xref>, for more information.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>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?</para> |
| <para>To answer this question we broke the question in two parts and later combined the resultant answers to build a possible solution.</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>How to remark the internal differences visually?</strong></tableterm> |
| <item> |
| <para>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. See <xref><xrefnodename>Directories trunk Identity Models Tpl Brands</xrefnodename></xref>, for more information on how to develop and improve The CentOS Project Brand.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>How to remark the visual resemblance?</strong></tableterm> |
| <item> |
| <para>Use a common artistic motifs as background for all CentOS Distribution images. See <xref><xrefnodename>Directories trunk Identity Themes Motifs</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>So, combining answers above, we could conclude that:</strong></tableterm> |
| <item> |
| <para>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.</para> |
| </item> |
| </tableitem> |
| </table> |
| <quotation> |
| <para><strong>Important</strong> Remarking the CentOS Release Schema inside each major release of CentOS Distribution —or similar visual manifestations— takes <emph>high attention</emph> inside The CentOS Project corporate visual identity. It should be very clear for everyone which major release of CentOS Distribution is being used.</para> |
| </quotation> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity Themes</xrefnodename></xref></para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity Themes Models</xrefnodename></xref></para> |
| </item> |
| <item> |
| <para><xref><xrefnodename>Directories trunk Identity Themes Motifs</xrefnodename></xref></para> |
| </item> |
| </itemize> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Concept</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Distro</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Concept</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Concept</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Distro</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Distro Anaconda</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Concept</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Distro</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Distro</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This directory provides design models to produce image files for the following CentOS Distribution components:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Syslinux</strong></tableterm> |
| <item> |
| <para>Contains design models for syslinux, the program used to boot the CentOS Distribution installation media. See <xref><xrefnodename>Directories trunk Identity Themes Models Default Distro Syslinux</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Anaconda</strong></tableterm> |
| <item> |
| <para>Contains design models for Anaconda, the program used to install CentOS Distribution. See <xref><xrefnodename>Directories trunk Identity Themes Models Default Distro Anaconda</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Firstboot</strong></tableterm> |
| <item> |
| <para>Contains design models for the first boot program used to configure the maching onece installed. See <xref><xrefnodename>Directories trunk Identity Themes Models Default Distro Firstboot</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Rhgb</strong></tableterm> |
| <item> |
| <para>Contains design models for CentOS Graphical Boot, the program used to show the boot process from Grub to Display Manager. See <xref><xrefnodename>Directories trunk Identity Themes Models Default Distro Rhgb</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Gdm</strong></tableterm> |
| <item> |
| <para>Contains design models for GNOME Display Manager, the program used to log into the manchine once installed and configured. See <xref><xrefnodename>Directories trunk Identity Themes Models Default Distro Gdm</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Kdm</strong></tableterm> |
| <item> |
| <para>Contains design models for KDE Display Manager, the program used to log into the manchine once installed and configured. See <xref><xrefnodename>Directories trunk Identity Themes Models Default Distro Kdm</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Grub</strong></tableterm> |
| <item> |
| <para>Contains design models for GRUB (Grand Unified Boot Loader), the program used to boot the machine into an operating system. See <xref><xrefnodename>Directories trunk Identity Themes Models Default Distro Kdm</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Gsplash</strong></tableterm> |
| <item> |
| <para>Contains design models for GNOME splash, the program used to show the progress information while user's graphical session is loading. See <xref><xrefnodename>Directories trunk Identity Themes Models Default Distro Gsplash</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Ksplash</strong></tableterm> |
| <item> |
| <para>Contains design models for KDE splash, the program used to show the progress information while user's graphical session is loading. See <xref><xrefnodename>Directories trunk Identity Themes Models Default Distro Ksplash</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>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.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>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.</para> |
| <para>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.</para> |
| <para>The procedure to follow is creatig a directory for each component using its very same name (e.g., the directory <file>Anaconda</file> 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 <command>centos-art</command> script.</para> |
| <para>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.</para> |
| <para>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.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Models Default</menunode> |
| <menutitle>Directories trunk Identity Themes Models Default</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Distro Anaconda</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Distro Firstboot</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Distro</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Distro/Anaconda</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Distro Anaconda</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Distro Firstboot</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Distro Gdm</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Distro Anaconda</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Distro/Firstboot</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Distro Firstboot</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Distro Gdm</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Distro Grub</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Distro Firstboot</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Distro/Gdm</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Distro Gdm</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Distro Grub</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Distro Gsplash</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Distro Gdm</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Distro/Grub</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Distro Grub</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Distro Gsplash</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Distro Kdm</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Distro Grub</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Distro/Gsplash</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Distro Gsplash</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Distro Kdm</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Distro Ksplash</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Distro Gsplash</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Distro/Kdm</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Distro Kdm</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Distro Ksplash</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Distro Rhgb</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Distro Kdm</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Distro/Ksplash</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Distro Ksplash</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Distro Rhgb</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Distro Syslinux</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Distro Ksplash</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Distro/Rhgb</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Distro Rhgb</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Distro Syslinux</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Promo</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Distro Rhgb</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Distro/Syslinux</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Distro Syslinux</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Promo</nodename> |
| <nodenext>Directories trunk Identity Themes Models Default Web</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Distro Syslinux</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Promo</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Promo</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>It applies to all tangible and non tangible items CentOS uses to promote its existence. Clothes, posters, installation media, stationery, release countdown images, banners, stickers, are all examples of promotion designs.</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Models Default Web</nodename> |
| <nodenext>Directories trunk Identity Themes Motifs</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Promo</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Models/Default/Web</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Models Default Web</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>It applies to all web applications CentOS uses to handle its needs (Ex. Portals, Wikis, Forums, Blogs, Bug Tracker). Anything involving HTML standards should be consider here.</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Motifs</nodename> |
| <nodenext>Directories trunk Identity Themes Motifs Flame</nodenext> |
| <nodeprev>Directories trunk Identity Themes Models Default Web</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Motifs</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Motifs</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>The <file>trunk/Identity/Themes/Motifs</file> directory exists to:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>Organize CentOS themes' artistic motifs.</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>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.</para> |
| <para>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.</para> |
| <table> |
| <tableitem> |
| <tableterm><samp>TreeFlower</samp></tableterm> |
| <item> |
| <para>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.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Modern</samp></tableterm> |
| <item> |
| <para>Modern, squares and circles flowing up.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>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 <file>Identity/Themes/Motifs/</file> 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.</para> |
| <para>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.</para> |
| <para>To add a new motif structure to CentOS Artwork Repository, you need to use the <command>centos-art</command> command line in the <file>Identity/Themes/Motifs/</file> directory as described below:</para> |
| <example xml:space="preserve">centos-art add --motif=ThemeName</example> |
| <para>The previous command will create the basic structure of themes for you. The basic structure produced by <command>centos-art</command> command is illustrated in the following figure:</para> |
| <example xml:space="preserve">trunk/Identity/Themes/Motifs/$ThemeName/ |
| |-- Backgrounds |
| | |-- Img |
| | `-- Tpl |
| |-- Info |
| | |-- Img |
| | `-- Tpl |
| |-- Palettes |
| `-- Screenshots</example> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>When designing artistic motifs for CentOS, consider the following recommendations:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>Give a unique (case-sensitive) name to your Motif. This name is used as value wherever theme variable (<b>$THEME</b>) or translation marker (<b>=THEME=</b>) is. Optionally, you can add a description about inspiration and concepts behind your work.</para> |
| </item> |
| <item> |
| <para>Use the location <file>trunk/Identity/Themes/Motifs/$THEME/</file> 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.</para> |
| </item> |
| <item> |
| <para>The CentOS Project is using the blue color (<b>#204c8d</b>) as base color for its corporate visual identity. Use such base corporate color information as much as possible in your artistic motif designs.</para> |
| </item> |
| <item> |
| <para>Try to make your design fit one of the theme models.</para> |
| </item> |
| <item> |
| <para>Feel free to make your art enterprise-level and beautiful.</para> |
| </item> |
| <item> |
| <para>Add the following information on your artwork (both in a visible design area and document metadata):</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>The name (or logo) of your artistic motif.</para> |
| </item> |
| <item> |
| <para>The copyright sentence: <b>Copyright (C) YEAR YOURNAME</b></para> |
| </item> |
| <item> |
| <para>The license under which the work is released. All CentOS Art works are released under <uref><urefurl>http://creativecommons.org/licenses/by-sa/3.0/</urefurl><urefdesc>Creative Common Share-Alike License 3.0</urefdesc></uref> (<uref><urefurl>http://creativecommons.org/licenses/by-sa/3.0/</urefurl></uref>).</para> |
| </item> |
| </itemize> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes</menunode> |
| <menutitle>Directories trunk Identity Themes</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity</menunode> |
| <menutitle>Directories trunk Identity</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk</menunode> |
| <menutitle>Directories trunk</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Motifs Flame</nodename> |
| <nodenext>Directories trunk Identity Themes Motifs Modern</nodenext> |
| <nodeprev>Directories trunk Identity Themes Motifs</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Motifs/Flame</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Motifs Flame</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This section describes the steps we followed to construct the <emph>Flame</emph> artistic motif. This section may be useful for anyone interested in reproducing the <emph>Flame</emph> artistic motif, or in creating new artistic motifs for The CentOS Project corporate visual identity (see <xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>).</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>The <emph>Flame</emph> artistic motif was built using the flame filter of Gimp 2.2 in CentOS 5.5.</para> |
| <para>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 <file>centos-art.sh</file> script (see <xref><xrefnodename>Directories trunk Scripts</xrefnodename></xref>) inside the CentOS Artwork Repository.</para> |
| <para>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.</para> |
| <para>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.</para> |
| <para>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.</para> |
| <para>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 <file>centos-art.sh</file> script.</para> |
| <para>With the combination of both CentOS Artwork Repository and <file>centos-art.sh</file> 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.</para> |
| <para>From a monolithic corporate visual identity point of view, notice that we are producing a new visual style for the same theme (i.e., <emph>Flame</emph>). 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.</para> |
| <para>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).</para> |
| <para>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.</para> |
| <para>Due to the “randomly generated” nature of Flame filter, we find that <emph>Flame</emph> pattern is not always the same when we use <emph>Flame</emph> filter interface.</para> |
| <para>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.</para> |
| <quotation> |
| <para><strong>Important</strong> 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.</para> |
| </quotation> |
| <para>In order for us to reproduce the same flame pattern always, <emph>Flame</emph> filter interface provides the <samp>Save</samp> and <samp>Open</samp> options. The <samp>Save</samp> 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 <samp>Open</samp> option brings up a file selector that allows you to open a previously saved Flame settings file.</para> |
| <para>The Flame settings we used in our example are saved in the file:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Themes/Motifs/Flame/Backgrounds/Xcf/800x600.xcf-flame.def |
| ]]></verbatim> |
| </subsection> |
| |
| <subsection> |
| <title>Construction</title> |
| <subsubsection> |
| <title>Step 1: Set image size</title> |
| <para>Create an empty image and fill the <samp>Background</samp> layer with black (<code>000000</code>) color. Image dimensions depend on the final destination you plan to use the image for. For the sake of our construction example we used an image of 640x480 pixels and 300 pixels per inch (ppi).</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Step 2: Add base color and pattern information</title> |
| <para>Create a new layer named <samp>Base</samp>, place it over <samp>Background</samp> layer and fill it with the base color (<code>7800ff</code>) you want to have your background image set in. Add a mask to <samp>Base</samp> layer using radial gradient and blur it. You may need to repeat this step more than once in order to achieve a confortable black radial degradation on the right side of your design.</para> |
| <para>Duplicate <samp>Base</samp> layer and name it <samp>Paper</samp>. Place <samp>Paper</samp> layer over <samp>Base</samp> layer. Remove content of <samp>Paper</samp> layer and fill it with <samp>Paper (100x100)</samp> pattern. Once you've done with black radial degradation, reduce the <samp>Paper</samp> layer opacity to 20%.</para> |
| <para>Notice that when we duplicate one layer, the mask information related to layer is preserved from previous to next layer. This saves us some of the time required to produce different layers with the same mask information on them.</para> |
| <para>Duplicate <samp>Paper</samp> layer and rename it <samp>Stripes</samp>. Remove paper pattern from <samp>Stripes</samp> layer. Fill <samp>Stripes</samp> layer with <samp>Stripes (48x48)</samp> pattern and reduce the <samp>Stripes</samp> layer opacity to 15%.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Step 3: Add flame motif</title> |
| <para>Create a new layer named <samp>Flame</samp>. Set the foreground (<code>003cff</code>) and background (<code>0084ff</code>) colors to the gradient you want to build the flame motif.</para> |
| <para>To build flame motif, use the flame filter (<samp>Filters > Render > Nature > Flame...</samp>) on <samp>Flame</samp> layer. We used a layer mask, with a radial gradient on it to control the boundaries of flame motif on <samp>Flame</samp> layer.</para> |
| <para>Duplicate <samp>Flame</samp> layer and rename it `Flame Blur'. Place `Flame Blur' below <samp>Flame</samp> layer. Apply Gussian blur filter (<samp>Filters > Blur > Gussian Blur...</samp>) until reaching the desiered effect.</para> |
| <para>The opacity value, in <samp>Flame</samp> layers, may vary from one image to another based on the place the image will be finally placed on. For example, images used as desktop background have the <samp>Flame</samp> layer opacity set at 100% but <samp>Flame Blur</samp> is set to 70%. However, you may find that background images used in anaconda progress slides have opacity reduced differently, in order to reduce brightness in a way that texts could look clean and readable over it.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Step 4: Add foreground color</title> |
| <para>Create a new layer named <samp>Color</samp>, place it on top of all visible layers and fill it with plain color (<code>4c005a</code>). Reduce <samp>Color</samp> layer opacity to 20%. You can use the <samp>Color</samp> layer to control the right side color information you want to produce the image for.</para> |
| <para>Duplicate <samp>Flame</samp> layer and create a new layer named <samp>Color#1</samp>. Place <samp>Color#1</samp> layer on top of layer named <samp>Color</samp>. Remove the mask information from <samp>Color#1</samp> layer and recreate a new one using an inverted alpha channel as reference. Remove <samp>Color#1</samp> layer content and fill it back with plain black (<code>000000</code>) color. Reduce <samp>Color#1</samp> opacity to 20%. In this step we created a mask to protect the flame artistic motif from black color, so when we decrement or increment the opacity of layer, the flame artistic motif wouldn't be affected, just the environment suround it.</para> |
| <para>When you set color information, remember that the same artistic motif needs to be indexed to 14 and 16 colors, in order to produce Grub and Syslinux visual manifestations respectively. Using many different colors in the artistic motif may reduce the possibility of your design to fix all different situations in. Likewise, using more colors in one design, and less colors in another design will reduce the connectivity among your designs, since color information is relevant to visual identity.</para> |
| <para>When you propagate your artistic motif visual style to different visual manifestations of CentOS Project corporate visual identity, it is up to you to find out justice and compromise among all possible variables you may face.</para> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes</menunode> |
| <menutitle>Directories trunk Identity Themes</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity</menunode> |
| <menutitle>Directories trunk Identity</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk</menunode> |
| <menutitle>Directories trunk</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Motifs Modern</nodename> |
| <nodenext>Directories trunk Identity Themes Motifs Modern Backgrounds</nodenext> |
| <nodeprev>Directories trunk Identity Themes Motifs Flame</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Motifs/Modern</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Motifs Modern</indexterm></para> |
| <subsection> |
| <title>Presentation</title> |
| </subsection> |
| |
| <subsection> |
| <title>Construction</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Motifs Modern Backgrounds</nodename> |
| <nodenext>Directories trunk Identity Themes Motifs Modern Backgrounds Img</nodenext> |
| <nodeprev>Directories trunk Identity Themes Motifs Modern</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Motifs/Modern/Backgrounds</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Motifs Modern Backgrounds</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>Organize background images for Modern theme.</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>Inside <file>Motifs</file> directory, the <file>Backgrounds/</file> directory is used to create vectorial designs using Inkscape and background images using Gimp. Later, you can export background images as <file>.png</file> and load them in your vectorial design project using the import feautre of Inkscape.</para> |
| <para>You may need to repeat this technic for different screen resoluions. In that case you need to create one file for each screen resolution and do the appropriate linking inside .svg to .png files. For example if you need to produce background images in 800x600 you need to create the following file:</para> |
| <example xml:space="preserve">xcf/800x600.xcf</example> |
| <para>to produce the background image:</para> |
| <example xml:space="preserve">img/800x600-bg.png</example> |
| <para>which is loaded in:</para> |
| <example xml:space="preserve">svg/800x600.svg</example> |
| <para>to produce the final background image:</para> |
| <example xml:space="preserve">img/800x600.png</example> |
| <para>The <file>img/800x600.png</file> background image is produced automatically by means of rendering scripts.</para> |
| <para>In other cases (e.g. Anaconda), it is possible that you need to make some variations to one background image that don't want to appear on regular background images of the same resolution. In this case you need to create a new and specific background image for that art component. For example, if you need to produce the background image used by Anconda (800x600) art works you create the file:</para> |
| <example xml:space="preserve">xcf/800x600-anaconda.xcf</example> |
| <para>to produce the background image:</para> |
| <example xml:space="preserve">img/800x600-anaconda-bg.png</example> |
| <para>which is loaded in:</para> |
| <example xml:space="preserve">svg/800x600-anaconda.svg</example> |
| <para>to produce the file:</para> |
| <example xml:space="preserve">img/800x600-anaconda.png</example> |
| <para>The 800x600-anaconda.png file is used by all Anaconda art works sharing a common 800x600 screen resolution (e.g., Header, Progress, Splash, Firstboot, etc.). The Anaconda Prompt is indexed to 16 colors and 640x480 pixels so you need to create a 640x480 background image for it, and take the color limitation into account when designing it.</para> |
| <para>Background images without artistic motif are generally used as based to build the Background images that do contain the theme artistic motif.</para> |
| <para>Background images are linked (using the <b>import</b> 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.</para> |
| <para>In this structure you design background images for different screen resolutions based on the theme artistic motif.</para> |
| <para>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.</para> |
| <para>Inside this directory artistic motifs are organized by name (e.g., TreeFlower, Modern, etc.).</para> |
| <para>Each artistic motif directory represents just one unique artistic motif.</para> |
| <para>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.</para> |
| <para>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.</para> |
| <para>Inside CentOS Artwork Repository, theme visual styles (Motifs) and theme visual structures (Models) are two different working lines. When you design an artistic motif for CentOS you concentrate on its visual style, and eventualy, use the <command>centos-art</command> 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 <file>Motifs/</file> directory using the model name, and the model directory structure as reference.</para> |
| <para>The artistic motif base structure is used by <command>centos-art</command> to produce images automatically. This section describes each directory of CentOS artistic motif base structure.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>The <file>Backgrounds/</file> directory is probably the core component, inside <file>Motifs/</file> directory structure. Inside <file>Backgrounds/</file> directory you produce background images used by almost all theme models (e.g., Distribution, Websites, Promotion, etc.). The <file>Backgrounds/</file> directory can contain subdirectories to help you organize the design process.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs Modern Backgrounds Img</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs Modern Backgrounds Img</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs Modern Backgrounds Tpl</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs Modern Backgrounds Tpl</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| <menuentry> |
| <menunode>Directories trunk Identity Themes Motifs Modern Backgrounds Xcf</menunode> |
| <menutitle>Directories trunk Identity Themes Motifs Modern Backgrounds Xcf</menutitle> |
| <menucomment> |
| </menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Motifs Modern Backgrounds Img</nodename> |
| <nodenext>Directories trunk Identity Themes Motifs Modern Backgrounds Tpl</nodenext> |
| <nodeprev>Directories trunk Identity Themes Motifs Modern Backgrounds</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Motifs Modern Backgrounds Img</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>In this directory is where you store all background images (e.g., .png, .jpg, .xpm, etc.). This directory is required by <file>centos-art</file> command line interface.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Motifs Modern Backgrounds Tpl</nodename> |
| <nodenext>Directories trunk Identity Themes Motifs Modern Backgrounds Xcf</nodenext> |
| <nodeprev>Directories trunk Identity Themes Motifs Modern Backgrounds Img</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Motifs Modern Backgrounds Tpl</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>In this directory is where you store all the scalable vector graphics (e.g., .svg) files. This directory is required by <file>centos-art</file> command line interface.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Motifs Modern Backgrounds Xcf</nodename> |
| <nodenext>Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress</nodenext> |
| <nodeprev>Directories trunk Identity Themes Motifs Modern Backgrounds Tpl</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Motifs Modern Backgrounds Xcf</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>In this directory is where you store the project files (e.g, .xcf) of Gimp. This directory is not required by <file>centos-art</file> command line interface. If you can create a beautiful background images using scalable vector graphics only, then there is no need to use the <file>Xcf/</file> directory to store background projects. Of course, you can merge both Gimp and Inkscape power to produce images based on them. In this last case you need the <file>Xcf/</file> directory.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress</nodename> |
| <nodenext>Directories trunk Identity Themes Motifs Modern Palettes</nodenext> |
| <nodeprev>Directories trunk Identity Themes Motifs Modern Backgrounds Xcf</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>To render Anaconda progress slide images using the <emph>Modern</emph> artistic motif design, the Default theme model, and available translation files (— <strong>Removed</strong>(pxref:trunk Translations Identity Themes Distro Anaconda Progress) —); use the following commands:</para> |
| <example xml:space="preserve">cd /home/centos/artwork/trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress/ |
| centos-art render --identity</example> |
| <para>The above command will create the following structure:</para> |
| <example xml:space="preserve">trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress |
| |-- 3 |
| | |-- en |
| | | |-- 01-welcome.png |
| | | |-- 02-donate.png |
| | | `-- 03-yum.png |
| | `-- es |
| | |-- 01-welcome.png |
| | |-- 02-donate.png |
| | `-- 03-yum.png |
| |-- 4 |
| | |-- en |
| | | |-- 01-welcome.png |
| | | |-- 02-donate.png |
| | | `-- 03-yum.png |
| | `-- es |
| | |-- 01-welcome.png |
| | |-- 02-donate.png |
| | `-- 03-yum.png |
| `-- 5 |
| |-- en |
| | |-- 01-welcome.png |
| | |-- 02-donate.png |
| | `-- 03-yum.png |
| `-- es |
| |-- 01-welcome.png |
| |-- 02-donate.png |
| `-- 03-yum.png</example> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Motifs Modern Palettes</nodename> |
| <nodenext>Directories trunk Identity Themes Motifs TreeFlower</nodenext> |
| <nodeprev>Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Motifs/Modern/Palettes</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Motifs Modern Palettes</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>Organize palette files for Modern theme.</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>Here is where graphic designers define theme palettes for color-limited art works. Theme palettes contain the color information that rendering functions need, in order to produce images with color limitations. Theme palettes contain the unique color information required by theme.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Motifs TreeFlower</nodename> |
| <nodenext>Directories trunk Identity Themes Motifs TreeFlower Backgrounds</nodenext> |
| <nodeprev>Directories trunk Identity Themes Motifs Modern Palettes</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Motifs/TreeFlower</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Motifs TreeFlower</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Themes Motifs TreeFlower Backgrounds</nodename> |
| <nodenext>Directories trunk Identity Widgets</nodenext> |
| <nodeprev>Directories trunk Identity Themes Motifs TreeFlower</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Themes Motifs TreeFlower Backgrounds</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This section exists to orgnize backgrounds of <emph>TreeFlower</emph> artistic motif.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <subsubsection> |
| <title>Desktop background</title> |
| <para>Once you have defined the vectorial artistic motif design, use the <command>centos-art.sh</command> script (as described in usage section below) to produce the png version of it. With the png version of your vectorial design do the following:</para> |
| <para>Open the png version with GIMP.</para> |
| <para>Save the png version as a project of GIMP inside <file>trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Xcf</file> directory, using the same name of your vectorial design but with the <samp>.xcf</samp> extension.</para> |
| <para>Now use GIMP to improve your design. Here you may add one layer for pattern, another for colors, and so on until you find yourself confortable with your artwork. For example, the following layer distribution (from bottom to top) was used to build revision 285 of file <file>1360x768.xcf</file> using <emph>TreeFlower</emph> artistic motif at revision 241.</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Layer 1: Background</strong></tableterm> |
| <item> |
| <para>The first thing we did with GIMP was to create a layer named <samp>Background</samp> to store the artistic motif (File > Open as layer). This layer is the lowest layer in the image. Later, we started to create layers one upon another to change the artistic motif visual style.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 2: Shadow#1</strong></tableterm> |
| <item> |
| <para>This layer is above <samp>Background</samp> and contains a linear gradient from left (000000) to right (transparent) covering the whole image. This layer masks the artistic motif to avoid the effect of linear gradient. This layer is 100% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 3: Shadow#2</strong></tableterm> |
| <item> |
| <para>This layer is above <samp>Shadow#1</samp> and contains a linear gradient from left (000000) to right (transparent) covering just the 70% of the whole image aproximatly. This layer doesn't mask the artistic motif which make the left part of it fall into the dark of linear gradient. This layer is 100% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 4: Pattern (Paper)</strong></tableterm> |
| <item> |
| <para>This layer is above <samp>Shadow#2</samp> an contains the paper pattern shipped with GIMP 2.2. This layer doesn't mask the artistic motif so the pattern is applied over the whole image. This layer is set to 15% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 5: Pattern (Stripes)</strong></tableterm> |
| <item> |
| <para>This layer is above <samp>Pattern (Paper)</samp> and contains the stripes used over the artistic motif. This layer do masks the artistic motif so the stripes are only applied to it. This layer is set to 10% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 6: Shadow#3</strong></tableterm> |
| <item> |
| <para>This layer is above <samp>Pattern (Stripes)</samp> and contains a linear gradient from right (6600ff) to left (transparent). This layer masks the artistic motif so the linear gradient doesn't affect it. This layer is set to 15% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 7: Shadow#4</strong></tableterm> |
| <item> |
| <para>This layer is above <samp>Shadow#3</samp> and contains a linear gradient from left (000000) to right (transparent). This layer do masks the artistic motif so the linear gradient doesn't affect it. This layer is set to 10% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 8: Color#1</strong></tableterm> |
| <item> |
| <para>This layer is above <samp>Shadow#4</samp> and is filled with orange (ffae00) color over the whole image. This layer is set to 10% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 9: Color#2</strong></tableterm> |
| <item> |
| <para>This layer is above <samp>Color#1</samp> and is filled with blue (010a88) color over the whole image. This layer is set to 10% of opacity.</para> |
| </item> |
| </tableitem> |
| </table> |
| <quotation> |
| <para><strong>Note</strong> There is no definite combination. To get the appropriate visual design is a matter of constant testing and personal taste.</para> |
| </quotation> |
| <para>Finally, use <samp>Save as copy ...</samp> option to export the final design. To export the final design use the same name of your vectorial design plus <samp>-final.png</samp> extension.</para> |
| <para>You can repeat these steps to create images for other screen resolutions.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Anaconda Prompt (syslinux) background</title> |
| <para>When building syslinux backgrounds it is needed to take into account that the final image is reduced to 16 colors. In desktop background there is no color limitation but syslinux does have. The goal of this section is achieving a final syslinux background as close as possible to desktop backgrounds using 16 colors only.</para> |
| <para>Another point to consider is the forground and background definition used by syslinux. The syslinux documentation says that the color set in position 0 is the background and color set in position 7 is the forground. The final palette of color used by our background will match that specification. For great contrast we'll use black as background and white as forground. At this poing we have black (000000) and white (ffffff) colors in our syslinux palette, which left us with 14 colors to play with.</para> |
| <para>Let's begin with <file>Xcf/640x300.xcf</file> layer distribution from bottom to top:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>Layer 1: Background</strong></tableterm> |
| <item> |
| <para>This layer is the lowest layer in the image composition and contains the artistic motif image rendered for the same resolution (i.e., <file>Img/Png/640x300.png</file>). This layer is set to 100% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 2: Pattern (Paper)</strong></tableterm> |
| <item> |
| <para>This layer is placed above <samp>Background</samp> layer and contains the paper pattern shipped with GIMP 2.2. This layer doesn't mask the artistic motif. This layer is set to 30% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 3: Pattern (Stripes)</strong></tableterm> |
| <item> |
| <para>This layer is placed above <samp>Pattern (Paper)</samp> layer and contains the stripes pattern shipped with GIMP 2.2. This layer does mask the artistic motif in order to apply the stripes over it only. The background is not affected by the stripes pattern just the artistic motif. This layer is set to 20% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 4: Shadow#1</strong></tableterm> |
| <item> |
| <para>This layer is placed above <samp>Pattern (Stripes)</samp> layer and fills the entire layer area with violet (6600ff) color. This layer do mask the artistic motif in order to applied the violet color to the background area outside the artistic motif only. This layer is set to 15% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 5: Color#1</strong></tableterm> |
| <item> |
| <para>This layer is above <samp>Shadow#1</samp> and is filled with orange (ffae00) color to cover the whole image. This layer is set to 10% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 6: Color#2</strong></tableterm> |
| <item> |
| <para>This layer is above <samp>Color#1</samp> and is filled with blue (010a88) color to cover the whole image. This layer is set to 10% of opacity.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>Layer 7: Shadow#2</strong></tableterm> |
| <item> |
| <para>This layer is above <samp>Color#1</samp> and contains a linear gradient from left (000000) to right (transparent) covering 70% of the image approximately.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>At this point we have the composition and should look like the desktop backgrounds. Compared with desktop backgrounds there are some differences in opacity. This is because in our testings the final color information found with this composition produces an acceptable 16 color image. Of course this is something we haven't seen yet.</para> |
| <para>To define the color information of our current coposition, save the syslinux background composition we've done using <samp>File > Save as Copy ...</samp> option in the following location:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/Img/Png/640x300-final.png |
| ]]></verbatim> |
| <para>Now, create the final png version of syslinux backgrounds using the following command:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art render --entry=trunk/Identity/Themes/Motifs/TreeFlower/Distro/Anaconda/Prompt |
| ]]></verbatim> |
| <para>This command will create syslinux-splash final images for all major releases of CentOS distribution the repository has been configured to. The important files here are <file>syslinux-splash.png</file>, other files may contain the wrong information because we haven't defined yet the correct color information to use.</para> |
| <para>Open one <file>syslinux-splash.png</file> file with GIMP and use the <samp>Image > Mode > Indexed</samp> to reduce image colors up to 16 colors, using the <samp>Generate optimum palette</samp> feature of GIMP. If the image looks aceptable after reducing colors, use the <samp>Palettes</samp> menu (Ctrl+P) of GIMP to import a new palette from file and name it <samp>CentOS-TreeFlower-Syslinux</samp>. Once you've saved the palette, the color information is stored at:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl |
| ]]></verbatim> |
| <para>You need to edit <file>CentOS-TreeFlower-Syslinux.gpl</file> file in order to set the appropriate order of colors. Remember black (000000) in position 0, and white (ffffff) in position 7. Other positions are irrelevant. When editing this file you may find that color reduction did not set black and white colors to their respective values exactly. Change that manually. For example, consider the following palette:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| GIMP Palette |
| Name: CentOS-TreeFlower-Syslinux |
| Columns: 16 |
| # |
| 0 0 0 Background (black) |
| 23 20 35 Untitled |
| 34 25 48 Untitled |
| 37 35 60 Untitled |
| 47 36 68 Untitled |
| 37 54 86 Untitled |
| 60 48 90 Untitled |
| 255 255 255 Foreground (white) |
| 66 54 99 Untitled |
| 74 61 98 Untitled |
| 49 78 126 Untitled |
| 43 87 151 Untitled |
| 92 89 95 Untitled |
| 54 104 183 Untitled |
| 158 153 156 Untitled |
| 201 196 195 Untitled |
| ]]></verbatim> |
| <para>Update the <samp>Palettes</samp> menu to get the new color positions from the file you just edited and open the palette with double click.</para> |
| <para>Update the <file>syslinux.gpl</file> file copying the following file:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ~/.gimp-2.2/palettes/CentOS-TreeFlower-Syslinux.gpl |
| ]]></verbatim> |
| <para>to</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.gpl |
| ]]></verbatim> |
| <para>With the <samp>CentOS-TreeFlower-Syslinux</samp> palette opened in the <samp>Palette Editor</samp>, open (Ctrl+O) the following file:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.ppm |
| ]]></verbatim> |
| <para>and replace its color information with that one in <samp>CentOS-TreeFlower-Syslinux</samp> palette. When you are replacing color information inside <file>syslilnux.ppm</file>, remember to keep the order of colors just as they are in the <samp>CentOS-TreeFlower-Palette</samp> palette.</para> |
| <para>The <file>syslinux.ppm</file> file is 16 pixels width and 1 pixel height, so you probably need to zoom it a bit to set the color information in their place when using the pen tool with the brush <samp>Circle (01) (1 x 1)</samp>.</para> |
| <para>Once you've updated the <samp>syslinux.ppm</samp> file, it is time to update the following file:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.hex |
| ]]></verbatim> |
| <para>The <file>syslinux.hex</file> file contains the color information in hexadecimal notation. The color information in hexadecimal notation is required by <command>ppmtolss16</command> command. The <command>ppmtolss16</command> command produces the final LSS16 image format that is used by syslinux program inside CentOS distribution.</para> |
| <para>The color information inside <file>syslinux.hex</file> must match the one in <file>syslinux.ppm</file> and <file>syslinux.gpl</file>. For example, based on <file>CentOS-TreeFlower-Syslinux</file> palette of colors above, consider the following <file>syslinux.hex</file> file:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| #000000=0 |
| #171423=1 |
| #221930=2 |
| #25233c=3 |
| #2f2444=4 |
| #253656=5 |
| #3c305a=6 |
| #ffffff=7 |
| #423663=8 |
| #4a3d62=9 |
| #314e7e=10 |
| #2b5797=11 |
| #5c595f=12 |
| #3668b7=13 |
| #9e999c=14 |
| #c9c4c3=15 |
| ]]></verbatim> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Grub background</title> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Identity Widgets</nodename> |
| <nodenext>Directories trunk Locales</nodenext> |
| <nodeprev>Directories trunk Identity Themes Motifs TreeFlower Backgrounds</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Identity/Widgets</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Identity Widgets</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales</nodename> |
| <nodenext>Directories trunk Locales Identity</nodenext> |
| <nodeprev>Directories trunk Identity Widgets</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales</indexterm>The <file>trunk/Locales</file> directory exists to store the translation messages used to produce content in different languages.</para> |
| <para>Translation messages are organized using the directory structure of the component being translated. For example, if we want to provide translation messages for <file>trunk/Manuals/Repository</file>, then the <file>trunk/Locales/Manuals/Repository</file> directory needs to be created.</para> |
| <para>Once the locale directory exists for the component we want to provide translation messages for, it is necessary to create the translation files where translation messages are. The translation files follows the concepts of <command>xml2po</command> and GNU <command>gettext</command> tools.</para> |
| <para>The basic translation process is as follow: first, translatable strings are extracted from files and a portable object template (.pot) is created or updated with the information. Using the portable object template, a portable object (.po) is created or updated for translator to locale the messages retrived. Finally, a machine object (.mo) is created from portable object to sotore the translated messages.</para> |
| <para>Inside the repository there are two ways to retrive translatable strings from files. The first one is through <command>xml2po</command> command and the second through <command>xgettext</command> command. The <command>xml2po</command> is used to retrive translatable strings from XML files (e.g., Scalable Vector Graphics, DocBook, etc.) and the <command>xgettext</command> command is used to retrive translatable strings from shell scripts files (e.g., the files that make the <command>centos-art.sh</command> command-line interface).</para> |
| <para>When translatable strings are retrived from XML files, using the <command>xml2po</command> command, there is no need to create the machine object as we do when translatable strings ar retrived from shell files, using the <command>xgettext</command> command. The <command>xml2po</command> produces a temporal machine object in order to create a translated XML file. Once the translated XML file has been created the machine object is no longer needed. On the other hand, the machine object produced by the <command>xgettext</command> command is required by the system in order for the show shell script localized messages.</para> |
| <para>Another difference between <command>xml2po</command> and <command>xgettext</command> we need to be aware of is the directory structure used to store machine objects. In <command>xml2po</command>, the machine object is created in the current working directory as <file>.xml2po.mo</file> and can be safetly removed once the translated XML file has been created. In the case of <command>xgettext</command>, the machine object needs to be stored in the <file>$TEXTDOMAIN/$LOCALE/LL_MESSAGES/$TEXTDOMAIN.mo</file> file in order for the system to interpret it and should not be removed since it is the file that contain the translation messages themselves.</para> |
| <para>Automation of localization tasks is achived through the <code>locale</code> functionality of command-line interface.</para> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Scripts Functions Locale</menunode> |
| <menutitle>Directories trunk Scripts Functions Locale</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales Identity</nodename> |
| <nodenext>Directories trunk Locales Identity Brands</nodenext> |
| <nodeprev>Directories trunk Locales</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales/Identity</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales Identity</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| |
| |
| |
| |
| |
| |
| <menuentry> |
| <menunode>Directories trunk Identity</menunode> |
| <menutitle>Directories trunk Identity</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales Identity Brands</nodename> |
| <nodenext>Directories trunk Locales Identity Brands Tpl</nodenext> |
| <nodeprev>Directories trunk Locales Identity</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales/Identity/Brands</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales Identity Brands</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>Organize brands' translation files.</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>Translation files, inside <file>trunk/Translations/Identity/Brands</file> translation entry, don't use default rendering translation functionality, they use the following translation pre-rendering configuration file instead:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| /home/centos/artwork/trunk/Translation/Identity/Brands/render.conf.sh |
| ]]></verbatim> |
| <para>Inside <file>trunk/Translations/Identity/Brands</file> translation entry, translation files are symbolic links pointing to the common template translation structure, inside the translation template (<samp>Tpl/</samp>) directory.</para> |
| <para>Inside <file>trunk/Translations/Identity/Brands</file> translation entry, translation files are created using identity design templates as reference. The translation pre-rendering script creates a translation structure where the translation template (<samp>Tpl/</samp>) directory structure applies to each single design template available.</para> |
| <para>For example, if the brands' translation template (<samp>Tpl/</samp>) directory has 30 translation files, and there are 20 design templates; the brands' translation pre-rendering script creates a translation structure of symbolic links where the 30 translation files apply the 20 design templates one by one, producing 600 translation symbolic links as result. At this point, when rendering identity, the <command>centos-art</command> script considers translation symbolic links as translation files.</para> |
| <para>Translation file names, inside brands' translation template (<samp>Tpl</samp>) directory have special meaning:</para> |
| |
| <subsubsection> |
| <title>Conventional file names</title> |
| <para><indexterm index="cp">Translation brands file names</indexterm> Convenctional file names look like <file>blue.sed</file>, <file>2c-a.sed</file>, etc. Replacement commands inside translation file are applied to design templates and translation file names are used as final image name. The image dimensions use the same dimensions that design template has.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Numeric file names</title> |
| <para><indexterm index="cp">Translation brands file names</indexterm> Numeric file names look like <file>300.sed</file>, <file>200.sed</file>, etc. Replacements commands inside translation files are applied to design templates, and translation file names are used as final image name. The final image is saved using an specific <samp>width</samp> defined by the number part of the translation file name. The image <samp>height</samp> is automatically scaled based on the previous <samp>width</samp> definition to maintain the designing ratio.</para> |
| <para>For example, if your design template has 400x200 pixels of dimension, and you apply a translation file named `300.sed' to it, the final image you get as result will have 300x100 pixels of dimension. The same is true if you use higher numbers like `1024.sed', `2048.sed', etc. In these cases you have bigger images proportionally.</para> |
| <para>As we are using scalable vector graphics to design identity templates, the image size you produce is not limitted in size. You can use one design template produced in 400x200 pixels to produce larger or shorter PNG images using numeric translation files as described above.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Translation markers</title> |
| <para>Inside <file>trunk/Translations/Identity/Brands/</file>, translation files combine the following translation markers:</para> |
| <table> |
| <tableitem> |
| <tableterm><samp>#000000</samp></tableterm> |
| <item> |
| <para>Specify which color to use when rendering brand images.</para> |
| <quotation> |
| <para><strong>Note</strong> As translation files inside <file>trunk/Translations/Identity/Brands</file> are symbolic links that point to template translation files, translation markers are defined inside template translation files.</para> |
| </quotation> |
| </item> |
| </tableitem> |
| </table> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para><indexterm index="cp">How to render brands' translation files</indexterm> To render brands' translation files, use the following command:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art render --translation=/home/centos/artwork/trunk/Translations/Identity/Brands |
| ]]></verbatim> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| |
| <menuentry> |
| <menunode>Directories trunk Identity Brands</menunode> |
| <menutitle>Directories trunk Identity Brands</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales Identity Brands Tpl</nodename> |
| <nodenext>Directories trunk Locales Identity Fonts</nodenext> |
| <nodeprev>Directories trunk Locales Identity Brands</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales/Identity/Brands/Tpl</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales Identity Brands Tpl</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales Identity Fonts</nodename> |
| <nodenext>Directories trunk Locales Identity Models</nodenext> |
| <nodeprev>Directories trunk Locales Identity Brands Tpl</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales/Identity/Fonts</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales Identity Fonts</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This section exists to organize fonts translation files.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>Translation files, inside <file>trunk/Translations/Fonts</file>, have the following structure:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| s!font-family:Denmark!font-family:DejaVu LGC Sans! |
| s!font-weight:normal!font-weight:bold! |
| s!font-style:normal!font-style:italic! |
| ]]></verbatim> |
| <para>Inside <file>trunk/Translations/Fonts</file>, there is one translation file for each font preview image you want to produce. This way, we create one translation file for each font-family we use somewhere inside CentOS visual identity.</para> |
| <quotation> |
| <para><strong>Important</strong> Do not create translation files for font-families not used somewhere inside CentOS visual identity. The identity of font entry (see <xref><xrefnodename>Directories trunk Identity Fonts</xrefnodename></xref>) is used as reference when someone needs to know which font-families are allowed to use inside CentOS visual identity.</para> |
| </quotation> |
| |
| <subsubsection> |
| <title>Translation Markers</title> |
| <para>Inside <file>trunk/Translations/Identity/Fonts</file>, translation files combine the following translation markers:</para> |
| <table> |
| <tableitem> |
| <tableterm><samp>font-family:Denmark</samp></tableterm> |
| <item> |
| <para>Specify which font family to use when rendering font preview images.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>font-weight:normal</samp></tableterm> |
| <item> |
| <para>Specify which font weight to use when rendering font preview images.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>font-style:normal</samp></tableterm> |
| <item> |
| <para>Specify which font style to use when rendering font preview images.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para><indexterm index="cp">How to render fonts' translation files</indexterm> Inside <file>trunk/Translations/Fonts</file> you use your favorite text editor to create translation files. Inside <file>trunk/Translations/Fonts</file> there is not translation template directory (<file>Tpl/</file>), nor translation rendering using <command>centos-art</command> script. For example, to create the <file>dejavu_lgc_sans-boldoblique.sed</file> translation file using <command>vim</command> editor, type the following command:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.sed |
| ]]></verbatim> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Identity Fonts</menunode> |
| <menutitle>Directories trunk Identity Fonts</menutitle> |
| <menucomment></menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales Identity Models</nodename> |
| <nodenext>Directories trunk Locales Identity Release</nodenext> |
| <nodeprev>Directories trunk Locales Identity Fonts</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales/Identity/Models</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales Identity Models</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales Identity Release</nodename> |
| <nodenext>Directories trunk Locales Identity Themes</nodenext> |
| <nodeprev>Directories trunk Locales Identity Models</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales/Identity/Release</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales Identity Release</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales Identity Themes</nodename> |
| <nodenext>Directories trunk Locales Identity Themes Backgrounds</nodenext> |
| <nodeprev>Directories trunk Locales Identity Release</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales/Identity/Themes</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales Identity Themes</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales Identity Themes Backgrounds</nodename> |
| <nodenext>Directories trunk Locales Identity Themes Distro Anaconda Progress</nodenext> |
| <nodeprev>Directories trunk Locales Identity Themes</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales/Identity/Themes/Backgrounds</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales Identity Themes Backgrounds</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales Identity Themes Distro Anaconda Progress</nodename> |
| <nodenext>Directories trunk Locales Identity Widgets</nodenext> |
| <nodeprev>Directories trunk Locales Identity Themes Backgrounds</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales/Identity/Themes/Distro/Anaconda/Progress</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales Identity Themes Distro Anaconda Progress</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>Organize Anaconda progress translation templates.</para> |
| </item> |
| <item> |
| <para>Organize Anaconda progress translation files in several languages and major releases of CentOS distribution.</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>Use the following command to produce translation files based:</para> |
| <example xml:space="preserve">trunk/Translations/Identity/Themes/Distro/Anaconda/Progress |
| `-- Tpl |
| |-- en |
| | |-- 01-welcome.sed |
| | |-- 02-donate.sed |
| | `-- 03-yum.sed |
| `-- es |
| |-- 01-welcome.sed |
| |-- 02-donate.sed |
| `-- 03-yum.sed</example> |
| <para>In order to produce the slide images in PNG format we need to have the translation files first. So we use the following commands to create translation files for CentOS 3, 4, and 5 major releases:</para> |
| <example xml:space="preserve">centos-art render --translation --filter='3,4,5'</example> |
| <para>The above commands will produce the following translation structure:</para> |
| <example xml:space="preserve">trunk/Translations/Identity/Themes/Distro/Anaconda/Progress |
| |-- 3 |
| | |-- en |
| | | |-- 01-welcome.sed |
| | | |-- 02-donate.sed |
| | | `-- 03-yum.sed |
| | `-- es |
| | |-- 01-welcome.sed |
| | |-- 02-donate.sed |
| | `-- 03-yum.sed |
| |-- 4 |
| | |-- en |
| | | |-- 01-welcome.sed |
| | | |-- 02-donate.sed |
| | | `-- 03-yum.sed |
| | `-- es |
| | |-- 01-welcome.sed |
| | |-- 02-donate.sed |
| | `-- 03-yum.sed |
| |-- 5 |
| | |-- en |
| | | |-- 01-welcome.sed |
| | | |-- 02-donate.sed |
| | | `-- 03-yum.sed |
| | `-- es |
| | |-- 01-welcome.sed |
| | |-- 02-donate.sed |
| | `-- 03-yum.sed |
| `-- Tpl |
| |-- en |
| | |-- 01-welcome.sed |
| | |-- 02-donate.sed |
| | `-- 03-yum.sed |
| `-- es |
| |-- 01-welcome.sed |
| |-- 02-donate.sed |
| `-- 03-yum.sed</example> |
| <para>At this point we have all the translation files we need to produce Anaconda progress welcome, donate and yum slides images; in English and Spanish languages; for CentOS 3, CentOS 4, and CentOS 5. That is, a sum of 18 images around.</para> |
| <para>Now, with translation files in place, let's move to <file>trunk/Identity</file> structure and render them.</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>See <xref><xrefnodename>Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress</xrefnodename></xref>.</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>Translation rendering is described in <samp>trunk/Translations</samp> documentation entry (— <strong>Removed</strong>(pxref:trunk Translations) —).</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Locales Identity Widgets</nodename> |
| <nodenext>Directories trunk Manual</nodenext> |
| <nodeprev>Directories trunk Locales Identity Themes Distro Anaconda Progress</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Locales/Identity/Widgets</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Locales Identity Widgets</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Manual</nodename> |
| <nodenext>Directories trunk Scripts</nodenext> |
| <nodeprev>Directories trunk Locales Identity Widgets</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Manual</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Manual</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts</nodename> |
| <nodenext>Directories trunk Scripts Functions</nodenext> |
| <nodeprev>Directories trunk Manual</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>The <file>trunk/Scripts</file> directory exists to organize the trunk development line of <file>centos-art.sh</file> automation script. The <file>centos-art.sh</file> script standardizes tasks you need to do frequently inside CentOS Artwork Repository.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>The best way to understand <file>centos-art.sh</file> 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.</para> |
| <para>The <file>centos-art.sh</file> script is written in Bash. Most tasks, inside <file>centos-art.sh</file> script, have been organized in many specific functionalities that you can invoke from the <command>centos-art</command> command-line interface.</para> |
| <para>When you type the <command>centos-art</command> 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 <var>PATH</var> environment variable to look for that command location. If your system was prepared to use CentOS Artwork Repository correctly (— <strong>Removed</strong>(pxref:trunk Scripts Bash Functions Verify) —), you should have a symbolic link inside <file>~/bin/</file> directory that points to the <file>centos-art.sh</file> script file. As <file>~/bin/</file> directory is, by default, inside <var>PATH</var> environment variable, the execution of <command>centos-art</command> command runs the <file>centos-art.sh</file> script.</para> |
| <para>When <file>centos-art.sh</file> script is executed, the first it does is executing the <file>trunk/Scripts/Bash/initEnvironment.sh</file> script to initialize global variables (e.g., <command>gettext</command> variables) and global function scripts. Global function scripts are located inside <file>trunk/Scripts/Bash/Functions</file> directory and their file names begin with <samp>cli</samp>. Global function scripts provide common functionalities that can be used anywhere inside <file>centos-art.sh</file> script execution environment.</para> |
| <para>Once global variables and function scripts have been loaded, <file>centos-art.sh</file> script executes the <command>cli</command> global function from <file>cli.sh</file> function script to retrive command-line arguments and define some default values that may be used later by specific function scripts (— <strong>Removed</strong>(pxref:trunk Scripts Bash Functions) —).</para> |
| <para>As convenction, the <file>centos-art.sh</file> command-line arguments have the following format:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art function path/to/dir --options |
| ]]></verbatim> |
| <para>In the above example, <samp>centos-art</samp> is the command you use to invoke <file>centos-art.sh</file> script. The <samp>arg1</samp> is required and represents the functionality you want to perform (e.g., <option>verify</option>, <option>render</option>, <option>locale</option>, <option>manual</option>, etc.). The remaining arguments are modifiers to <option>arg1</option>. The <option>--arg2</option> definition is required and represets, specifically, the action inside the functionality you want to perform. The <option>--arg3</option> and on, are optional.</para> |
| <para>Once command-line arguments have been retrived, the <file>centos-art.sh</file> script loads specific functionalities using the <file>cli_getFunctions.sh</file> function script. Only one specific functionality can be loaded at one script execution I.e., you run <command>centos-art.sh</command> script to run just one functionality.</para> |
| <float name="fig:trunk/Scripts/Bash:Initialization"> |
| <floattype>Figure</floattype> |
| <floatpos></floatpos> |
| <verbatim xml:space="preserve"><![CDATA[ |
| +----------------------------------------------------------------------+ |
| | [centos@host]$ centos-art function --action='value' --option='value' | |
| +----------------------------------------------------------------------+ |
| | ~/bin/centos-art --> ~/artwork/trunk/Scripts/centos-art.sh | |
| +---v-----------------------------------------v------------------------+ |
| | centos-art.sh | |
| +---v---------------------------------v---+ |
| . | initEnvironment.sh | . |
| . +---------------------------------+ . |
| . | cli $@ | . |
| . +---v-------------------------v---+ . |
| . . | cli_getFunctions | . . |
| . . +---v-----------------v---+ . . |
| . . . | function1 | . . . |
| . . . | function2 | . . . |
| . . . | function3 | . . . |
| . . . +-----------------+ . . . |
| . . ........................... . . |
| . ................................... . |
| ........................................... |
| ]]></verbatim> |
| <caption>The functionalities initialization environment.</caption> |
| </float> |
| <para>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.</para> |
| <float name="fig:trunk/Scripts/Bash/Functions:Initialization"> |
| <floattype>Figure</floattype> |
| <floatpos></floatpos> |
| <verbatim xml:space="preserve"><![CDATA[ |
| +--------------------------------------+ |
| | cli_getFunctions | |
| +---v------------------------------v---+ |
| . | function1 | . |
| . +---v------------------------v-+ . |
| . . | function1_getArguments | . . |
| . . +---v--------------v-----+ . . |
| . . . | action 1 | . . . |
| . . . | action 2 | . . . |
| . . . | action n | . . . |
| . . . +--------------+ . . . |
| . . .......................... . . |
| . ................................ . |
| . +------------------------------+ . |
| . | function2 | . |
| . +---v------------------------v-+ . |
| . . | function2_getArguments | . . |
| . . +---v--------------v-----+ . . |
| . . . | action 1 | . . . |
| . . . | action 2 | . . . |
| . . . | action n | . . . |
| . . . +--------------+ . . . |
| . . .......................... . . |
| . ................................ . |
| . +------------------------------+ . |
| . | function3 | . |
| . +---v------------------------v-+ . |
| . . | function3_getArguments | . . |
| . . +---v--------------v-----+ . . |
| . . . | action 1 | . . . |
| . . . | action 2 | . . . |
| . . . | action n | . . . |
| . . . +--------------+ . . . |
| . . .......................... . . |
| . ................................ . |
| ........................................ |
| ]]></verbatim> |
| <caption>The actions initialization environment.</caption> |
| </float> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>The <file>centos-art.sh</file> script usage information is described inside each specific function documentation (— <strong>Removed</strong>(pxref:trunk Scripts Bash Functions) —).</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Scripts</menunode> |
| <menutitle>Directories trunk Scripts</menutitle> |
| <menucomment> |
| |
| </menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions</nodename> |
| <nodenext>Directories trunk Scripts Functions Help</nodenext> |
| <nodeprev>Directories trunk Scripts</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>The <file>trunk/Scripts/Bash/Functions</file> directory exists to organize <file>centos-art.sh</file> specific functionalities.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>The specific functions of <file>centos-art.sh</file> script are designed with “Software Toolbox” philosophy (see <xref><xrefnodename>Toolbox introduction</xrefnodename><xrefinfofile>coreutils.info</xrefinfofile></xref>) in mind: each program “should do one thing well”. Inside <file>centos-art.sh</file> 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.</para> |
| <para>The specific functions of <file>centos-art.sh</file> script are organized inside specific directories under <file>trunk/Scripts/Bash/Functions</file> 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 <code>render</code>, the specific function directory for it would be <samp>trunk/Scripts/Bash/Functions/Render</samp>.</para> |
| <para>To better understand how specific functions of <file>centos-art.sh</file> script are designed, lets create one function which only goal is to output different kind of greetings to your screen.</para> |
| <para>When we create specific functions for <file>centos-art.sh</file> 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.</para> |
| <quotation> |
| <para><strong>Tip</strong> Join CentOS developers mailing list <email><emailaddress>centos-art@centos.org</emailaddress></email> to share your ideas.</para> |
| </quotation> |
| <para>It is also worth to know what global functions and variables do we have available inside <file>centos-art.sh</file> script, so advantage can be taken from them. Global variables are defined inside global function scripts. Global functions scripts are stored immediatly under <file>trunk/Scripts/Bash/Functions</file> directory, in files begining with <samp>cli</samp> prefix.</para> |
| <para>OK, let's begin with our functionality example.</para> |
| <para>What function name do we use? Well, lets use <code>greet</code>. Note that <samp>hello</samp> word is not a verb; but an expression, a kind of greeting, an interjection specifically. In contrast, <samp>greet</samp> is a verb and describes what we do when we say <samp>Hello!</samp>, <samp>Hi!</samp>, and similar expressions.</para> |
| <para>So far, we've gathered the following function information:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Name: greet |
| Path: trunk/Scripts/Bash/Functions/Greet |
| File: trunk/Scripts/Bash/Functions/Greet/greet.sh |
| ]]></verbatim> |
| <para>The <file>greet.sh</file> function script is the first file <file>centos-art.sh</file> script loads when the <samp>greet</samp> functionality is called using commands like <samp>centos-art greet --hello='World'</samp>. The <file>greet.sh</file> function script contains the <code>greet</code> function definition.</para> |
| <para>Inside <file>centos-art.sh</file> script, as convenction, each function script has one top commentary, followed by one blank line, and then one function defintion below it only.</para> |
| <para>Inside <file>centos-art.sh</file> 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 <file>centos-art.sh</file> script is released as GPL, so do all its functions—, the <code>$Id$</code> keyword of Subversion is later expanded by <command>svn propset</command> command.</para> |
| <para>In our <code>greet</code> function example, top commentary for <file>greet.sh</file> function script would look like the following:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| #!/bin/bash |
| # |
| # greet.sh -- This function outputs different kind of greetings to |
| # your screen. Use this function to understand how centos-art.sh |
| # script specific functionalities work. |
| # |
| # Copyright (C) YEAR YOURFULLNAME |
| # |
| # This program is free software; you can redistribute it and/or modify |
| # it under the terms of the GNU General Public License as published by |
| # the Free Software Foundation; either version 2 of the License, or |
| # (at your option) any later version. |
| # |
| # This program is distributed in the hope that it will be useful, but |
| # WITHOUT ANY WARRANTY; without even the implied warranty of |
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
| # General Public License for more details. |
| # |
| # You should have received a copy of the GNU General Public License |
| # along with this program; if not, write to the Free Software |
| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 |
| # USA. |
| # |
| # ---------------------------------------------------------------------- |
| # $Id$ |
| # ---------------------------------------------------------------------- |
| ]]></verbatim> |
| <para>After top commentary, separated by one blank line, the <code>greet</code> function definition would look like the following:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function greet { |
| |
| # Define global variables. |
| |
| # Define command-line interface. |
| greet_getActions |
| |
| } |
| ]]></verbatim> |
| <para>The first definition inside <code>greet</code> function, are global variables that will be available along <code>greet</code> function execution environment. This time we didn't use global variable definitions for <code>greet</code> function execution environment, so we left that section empty.</para> |
| <para>Later, we call <code>greet_getActions</code> function to define the command-line interface of <code>greet</code> functionality. The command-line interface of <code>greet</code> functionality defines what and how actions are performed, based on arguments combination passed to <file>centos-art.sh</file> script.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function greet_getActions { |
| |
| case "$ACTIONNAM" in |
| |
| --hello ) |
| greet_doHello |
| ;; |
| |
| --bye ) |
| greet_doBye |
| ;; |
| |
| * ) |
| cli_printMessage "`gettext "The option provided is not valid."`" |
| cli_printMessage "$(caller)" 'AsToKnowMoreLine' |
| |
| esac |
| |
| } |
| ]]></verbatim> |
| <para>The <var>ACTIONNAM</var> global variable is defined in <file>cli.sh</file> function script and contains the value passed before the equal sign (i.e., <samp>=</samp>) in the second command-line argument of <file>centos-art.sh</file> script. For example, if the second command-line argument is <option>--hello='World'</option>, the value of <var>ACTIONNAM</var> variable would be <samp>--hello</samp>. Using this configuration let us deside which action to perform based on the action name passed to <file>centos-art.sh</file> script as second argument.</para> |
| <para>The <code>greet</code> function definition makes available two valid greetings through <option>--hello</option> and <option>--bye</option> options. If no one of them is provided as second command-line argument, the <samp>*</samp> case is evaluated instead.</para> |
| <para>The <samp>*</samp> case and its two lines further on should always be present in <file>_getActions.sh</file> 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.</para> |
| <para>The <code>greet_doHello</code> and <code>greet_doBye</code> function definitions are the core of <code>greet</code> specific functionality. In such function definitions we set what our <code>greet</code> function really does: to output different kinds of greetings.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function greet_doHello { |
| |
| cli_printMessage "`gettext "Hello"` $ACTIONVAL" |
| |
| } |
| ]]></verbatim> |
| <para>The <code>greet_doHello</code> function definition is stored in <file>greet_doHello.sh</file> function script.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function greet_doBye { |
| |
| cli_printMessage "`gettext "Goodbye"` $ACTIONVAL" |
| |
| } |
| ]]></verbatim> |
| <para>The <code>greet_doBye</code> function definition is stored in the <file>greet_doBye.sh</file> function script.</para> |
| <para>Both <file>greet_doHello.sh</file> and <file>greet_doBye.sh</file> function scripts are stored inside <code>greet</code> function directory path (i.e. <file>trunk/Scripts/Bash/Functions/Greet</file>).</para> |
| <para>The <var>ACTIONVAL</var> global variable is defined in <file>cli.sh</file> function script and contains the value passed after the equal sign (i.e., <samp>=</samp>) in the second command-line argument of <file>centos-art.sh</file> script. For example, if the second command-line argument is <option>--hello='World'</option>, the value of <var>ACTIONVAL</var> variable would be <samp>World</samp> without quotes.</para> |
| <para>Let's see how <code>greet</code> specific functionality files are organzied under <code>greet</code> function directory. To see file organization we use the <command>tree</command> command:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Scripts/Bash/Functions/Greet |
| |-- greet_doBye.sh |
| |-- greet_doHello.sh |
| |-- greet_getActions.sh |
| `-- greet.sh |
| ]]></verbatim> |
| <para>To try the <code>greet</code> specific functionality we've just created, pass the function name (i.e., <samp>greet</samp>) as first argument to <file>centos-art.sh</file> script, and any of the valid options as second argument. Some examples are illustrated below:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| [centos@projects ~]$ centos-art greet --hello='World' |
| Hello World |
| [centos@projects ~]$ centos-art greet --bye='World' |
| Goodbye World |
| [centos@projects ~]$ |
| ]]></verbatim> |
| <para>The word <samp>World</samp> in the examples above can be anything. In fact, change it to have a little fun.</para> |
| <para>Now that we have a specific function that works as we expect, it is time to document it. To document <code>greet</code> specific functionality, we use its directory path and the <code>manual</code> functionality (— <strong>Removed</strong>(pxref:trunk Scripts Bash Functions Manual) —) of <file>centos-art.sh</file> script, just as the following command illustrates:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art manual --edit=trunk/Scripts/Bash/Functions/Greet |
| ]]></verbatim> |
| <para>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 <file>centos-art.sh</file> script uses the function documentation entry as vehicle to communicate which the valid functions are. When no documentation entry exists for a function, the <file>centos-art.sh</file> script informs that no documentation entry exists for such function and requests user to create it right at that time.</para> |
| <para>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 <code>locale</code> functionality (— <strong>Removed</strong>(pxref:trunk Scripts Bash Functions Locale) —) of <file>centos-art.sh</file> script, just as the following command illustrates:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art locale --edit |
| ]]></verbatim> |
| <quotation> |
| <para><strong>Warning</strong> To translate output messages in different languages, your system locale information —as in <env>LANG</env> 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 <samp>es_ES.UTF-8</samp>, or similar, first.</para> |
| </quotation> |
| <para>Well, it seems that our example is rather complete by now.</para> |
| <para>In <code>greet</code> function example we've described so far, we only use <command>cli_printMessage</command> 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 <option>--filter='regex'</option> and reduce the amount of files to process using a regular expression pattern.</para> |
| <para>The <code>greet</code> function described in this section may serve you as an introduction to understand how specific functionalities work inside <file>centos-art.sh</file> script. With some of luck this introduction will also serve you as motivation to create your own <file>centos-art.sh</file> script specific functionalities.</para> |
| <para>By the way, the <code>greet</code> functionality doesn't exist inside <file>centos-art.sh</file> script yet. Would you like to create it?</para> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <subsubsection> |
| <title>Global variables</title> |
| <para>The following global variables of <file>centos-art.sh</file> script, are available for you to use inside specific functions:</para> |
| <definition> |
| <definitionterm><indexterm index="vr">TEXTDOMAIN</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>TEXTDOMAIN</defvariable> |
| </definitionterm> |
| <definitionitem> |
| <para>Default domain used to retrieve translated messages. This value is set in <file>initFunctions.sh</file> and shouldn't be changed.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="vr">TEXTDOMAINDIR</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>TEXTDOMAINDIR</defvariable> |
| </definitionterm> |
| <definitionitem> |
| <para>Default directory used to retrieve translated messages. This value is set in <file>initFunctions.sh</file> and shouldn't be changed.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="vr">FUNCNAM</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>FUNCNAM</defvariable> |
| </definitionterm> |
| <definitionitem> |
| <para>Define function name.</para> |
| <para>Function names associate sets of actions. There is one set of actions for each unique function name inside <file>centos-art.sh</file> script.</para> |
| <para>Dunction names are passed as first argument in <file>centos-art.sh</file> command-line interface. For example, in the command <samp>centos-art render --entry=path/to/dir --filter=regex</samp>, the <var>ACTION</var> passed to <file>centos-art.sh</file> script is <option>render</option>.</para> |
| <para>When first argument is not provided, the <file>centos-art.sh</file> script immediatly ends its execution.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="vr">FUNCDIR</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>FUNCDIR</defvariable> |
| </definitionterm> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="vr">FUNCDIRNAME</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>FUNCDIRNAME</defvariable> |
| </definitionterm> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="vr">FUNCSCRIPT</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>FUNCSCRIPT</defvariable> |
| </definitionterm> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="vr">FUNCCONFIG</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>FUNCCONFIG</defvariable> |
| </definitionterm> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="vr">ACTIONNAM</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>ACTIONNAM</defvariable> |
| </definitionterm> |
| <definitionitem> |
| <para>Define action name.</para> |
| <para>Each action name identifies an specific action to perform, inside an specific function.</para> |
| <para>Action name names aare passed as second argument in <file>centos-art.sh</file> command-line interface. For example, in the command <samp>centos-art render --entry=path/to/dir --filter=regex</samp>, the <var>ACTIONNAM</var> passed to <file>centos-art.sh</file> script is <option>--entry</option>.</para> |
| <para>When second argument is not provided, the <file>centos-art.sh</file> script immediatly ends its execution.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="vr">ACTIONVAL</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>ACTIONVAL</defvariable> |
| </definitionterm> |
| <definitionitem> |
| <para>Define action value.</para> |
| <para>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.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="vr">REGEX</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>REGEX</defvariable> |
| </definitionterm> |
| <definitionitem> |
| <para>Define regular expression used as pattern to build the list of files to process.</para> |
| <para>By default, <var>REGEX</var> variable is set to <code>.+</code> to match all files.</para> |
| <para>Functions that need to build a list of files to process use the option <option>--filter</option> to redefine <var>REGEX</var> variable default value, and so, control the amount of files to process.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="vr">ARGUMENTS</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>ARGUMENTS</defvariable> |
| </definitionterm> |
| <definitionitem> |
| <para>Define optional arguments.</para> |
| <para>Optional arguments, inside <file>centos-art.sh</file> script, are considered as all command-line arguments passed to <file>centos-art.sh</file> script, from third argument position on. For example, in the command <samp>centos-art render --entry=path/to/dir --filter=regex</samp> , the optional arguments are from <samp>--filter=regex</samp> argument on.</para> |
| <para>Optional arguments are parsed using <command>getopt</command> command through the following base construction:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| # Define short options we want to support. |
| local ARGSS="" |
| |
| # Define long options we want to support. |
| local ARGSL="filter:,to:" |
| |
| # Parse arguments using getopt(1) command parser. |
| cli_doParseArguments |
| |
| # Reset positional parameters using output from (getopt) argument |
| # parser. |
| eval set -- "$ARGUMENTS" |
| |
| # Define action to take for each option passed. |
| while true; do |
| case "$1" in |
| --filter ) |
| REGEX="$2" |
| shift 2 |
| ;; |
| --to ) |
| TARGET="$2" |
| shift 2 |
| ;; |
| * ) |
| break |
| esac |
| done |
| ]]></verbatim> |
| <para>Optional arguments provide support to command options inside <file>centos-art.sh</file> script. For instance, consider the Subversion (<command>svn</command>) command, where there are many options (e.g., <option>copy</option>, <option>delete</option>, <option>move</option>, etc), and inside each option there are several modifiers (e.g., <samp>--revision</samp>, <samp>--message</samp>, <samp>--username</samp>, etc.) that can be combined one another in their short or long variants.</para> |
| <para>The <var>ARGUMENTS</var> variable is used to store arguments passed from command-line for later use inside <file>centos-art.sh</file> script. Storing arguments is specially useful when we want to run a command with some specific options from them. Consider the following command:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art path --copy=SOURCE --to=TARGET --message="The commit message goes here." --username='johndoe' |
| ]]></verbatim> |
| <para>In the above command, the <option>--message</option>, and <option>--username</option> options are specific to <command>svn copy</command> command. In such cases, options are not interpreted by <file>centos-art.sh</file> script itself. Instead, the <file>centos-art.sh</file> script uses <command>getopt</command> to retrive them and store them in the <var>ARGUMENTS</var> variable for later use, as described in the following command:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| # Build subversion command to duplicate locations inside the |
| # workstation. |
| eval svn copy $SOURCE $TARGET --quiet $ARGUMENTS |
| ]]></verbatim> |
| <para>When <command>getopt</command> parses <var>ARGUMENTS</var>, we may use short options (e.g., <option>-m</option>) or long options (e.g., <option>--message</option>). When we use short options, arguments are separated by one space from the option (e.g., <option>-m 'This is a commit message.'</option>). When we use long options arguments are separated by an equal sign (<samp>=</samp>) (e.g., <option>--message='This is a commit message'</option>).</para> |
| <para>In order for <command>getopt</command> to parse <var>ARGUMENTS</var> 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.</para> |
| <para>As convenction, inside <file>centos-art.sh</file> script, short option definitions are set in the <var>ARGSS</var> variable; and long option definitions are set in the <var>ARGSL</var> variable.</para> |
| <para>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 <samp>:</samp> after the option definition (e.g., <option>-o m: -l message:</option>). On the other hand, to define an option argument as not required, you need to set two colons <samp>::</samp> after the option definition (e.g., <option>-o m:: -l message::</option>).</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="vr">EDITOR</indexterm> |
| <defcategory>Variable</defcategory> |
| <defvariable>EDITOR</defvariable> |
| </definitionterm> |
| <definitionitem> |
| <para>Default text editor.</para> |
| <para>The <file>centos-art.sh</file> script uses default text <env>EDITOR</env> to edit pre-commit subversion messages, translation files, configuration files, script files, and similar text-based files.</para> |
| <para>If <env>EDITOR</env> environment variable is not set, <file>centos-art.sh</file> script uses <file>/usr/bin/vim</file> as default text editor. Otherwise, the following values are recognized by <file>centos-art.sh</file> script:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><file>/usr/bin/vim</file></para> |
| </item> |
| <item> |
| <para><file>/usr/bin/emacs</file></para> |
| </item> |
| <item> |
| <para><file>/usr/bin/nano</file></para> |
| </item> |
| </itemize> |
| <para>If no one of these values is set in <env>EDITOR</env> environment variable, <file>centos-art.sh</file> uses <file>/usr/bin/vim</file> text editor by default.</para> |
| </definitionitem> |
| </definition> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Global functions</title> |
| <para>Function scripts stored directly under <file>trunk/Scripts/Bash/Functions/</file> 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 <file>centos-art.sh</file> script.</para> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_checkActionArguments</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_checkActionArguments</deffunction> |
| </definitionterm> |
| <definitionitem> |
| <para>Validate action value (<var>ACTIONVAL</var>) variable.</para> |
| <para>The action value variable can take one of the following values:</para> |
| <enumerate first="1"> |
| <item> |
| <para>Path to one directory inside the local working copy,</para> |
| </item> |
| <item> |
| <para>Path to one file inside the local working copy,</para> |
| </item> |
| </enumerate> |
| <para>If another value different from that specified above is passed to action value variable, the <file>centos-art.sh</file> script prints an error message and ends script execution.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_checkFiles</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_checkFiles</deffunction> |
| <defparam>FILE</defparam> |
| <defdelimiter>[</defdelimiter> |
| <defparam>TYPE</defparam> |
| <defdelimiter>]</defdelimiter> |
| </definitionterm> |
| <definitionitem> |
| <para>Verify file existence.</para> |
| <para><code>cli_checkFiles</code> receives a <var>FILE</var> absolute path and performs file verification as specified in <var>TYPE</var>. When <var>TYPE</var> is not specified, <code>cli_checkFiles</code> verifies <var>FILE</var> existence, no matter what kind of file it be. If <var>TYPE</var> is specified, use one of the following values:</para> |
| <table> |
| <tableitem> |
| <tableterm><option>d</option></tableterm> |
| <tableterm><option>directory</option></tableterm> |
| <item> |
| <para>Ends script execution if <var>FILE</var> is not a directory.</para> |
| <para>When you verify directories with cli_checkFiles, if directory doesn't exist, <file>centos-art.sh</file> script asks you for confirmation in order to create that directory. If you answer positively, <file>centos-art.sh</file> script creates that directory and continues script flows normally. Otherwise, if you answer negatively, <file>centos-art.sh</file> ends script execution with an error and documentation message.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>f</option></tableterm> |
| <tableterm><option>regular-file</option></tableterm> |
| <item> |
| <para>Ends script execution if <var>FILE</var> is not a regular file.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>h</option></tableterm> |
| <tableterm><option>symbolic-link</option></tableterm> |
| <item> |
| <para>Ends script execution if <var>FILE</var> is not a symbolic link.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>x</option></tableterm> |
| <tableterm><option>execution</option></tableterm> |
| <item> |
| <para>Ends script execution if <var>FILE</var> is not executable.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>fh</option></tableterm> |
| <item> |
| <para>Ends script execution if <var>FILE</var> is neither a regular file nor a symbolic link.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>fd</option></tableterm> |
| <item> |
| <para>Ends script execution if <var>FILE</var> is neither a regular file nor a directory.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>isInWorkingCopy</option></tableterm> |
| <item> |
| <para>Ends script execution if <var>FILE</var> is not inside the working copy.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>As default behaviour, if <var>FILE</var> passes all verifications, <file>centos-art.sh</file> script continues with its normal flow.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_commitRepoChanges</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_commitRepoChanges</deffunction> |
| <defdelimiter>[</defdelimiter> |
| <defparam>LOCATION</defparam> |
| <defdelimiter>]</defdelimiter> |
| </definitionterm> |
| <definitionitem> |
| <para>Syncronize changes between repository and working copy.</para> |
| <para>The <code>cli_commitRepoChanges</code> function brings changes from the central repository down to the working copy—using <command>svn update</command>—, checks the working copy changes—using <command>svn status</command> command—, prints status report—using both <command>svn update</command> and <command>svn status</command> commands output, and finally, commits recent changes from the working copy up to the repository—using <command>svn commit</command> command—.</para> |
| <para>Previous to commit the working copy changes up to the central repository, the <code>cli_commitRepoChanges</code> function asks you to verify changes—using <command>svn diff</command> command—, and later, another confirmation question is shown to be sure you really want to commit changes up to central repository.</para> |
| <para>If <var>LOCATION</var> argument is not specified, the value of <var>ACTIONVAL</var> variable is used as reference instead.</para> |
| <float name="trunk/Scripts/Bash/Functions/cli_commitRepoChanges"> |
| <floattype>Figure</floattype> |
| <floatpos></floatpos> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ---------------------------------------------------------------------- |
| --> Bringing changes from the repository into the working copy |
| --> Checking changes in the working copy |
| ---------------------------------------------------------------------- |
| Added 0 file from the repository. |
| Deleted 0 file from the repository. |
| Updated 0 file from the repository. |
| Conflicted 0 file from the repository. |
| Merged 0 file from the repository. |
| Modified 4 files from the working copy. |
| Unversioned 0 file from the working copy. |
| Deleted 0 file from the working copy. |
| Added 0 file from the working copy. |
| ---------------------------------------------------------------------- |
| ]]></verbatim> |
| <caption>The <code>cli_commitRepoChanges</code> function output.</caption> |
| </float> |
| <para>Call the <code>cli_commitRepoChanges</code> function before or/and after calling functions that modify files or directories inside the working copy as you may need to.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_doParseArguments</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_doParseArguments</deffunction> |
| </definitionterm> |
| <definitionitem> |
| <para>Redefine arguments (<var>ARGUMENTS</var>) global variable using <command>getopt</command> command output. For more information about how to use <code>cli_doParseArguments</code> function, see <var>ARGUMENTS</var> variable description above.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_doParseArgumentsReDef</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_doParseArgumentsReDef</deffunction> |
| <defparam>$</defparam> |
| <defparam>@</defparam> |
| </definitionterm> |
| <definitionitem> |
| <para>Initialize/reset arguments (<var>ARGUMENTS</var>) global variable using positional parameters variable (<var>$@</var>) as reference.</para> |
| <para>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 <code>cli_doParseArgumentsReDef</code> with the positional parameters variable (<var>$@</var>), set as first argument, to that specific function you want to redefine positional parameters at.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getArguments</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getArguments</deffunction> |
| </definitionterm> |
| <definitionitem> |
| <para>Initialize function name (<var>FUNCNAM</var>), action name (<var>ACTIONNAM</var>), and action value (<var>ACTIONVAL</var>) global variables, using positional parameters passed in <var>$@</var> variable.</para> |
| <para>The <code>cli_getArguments</code> function is called from <code>cli.sh</code> function script, using <code>cli</code> function positional parameters (i.e., the positional parameters passed as arguments in the command-line) as first function argument.</para> |
| <para>Once command-line positional parameters are accesible to <file>centos-art.sh</file> script execution evironment, <code>cli_getArguments</code> uses regular expression to retrive action variables from first and second argument. The first argument defines the value used as function name (<var>FUNCNAM</var>), and the second argument defines both values used as action name (<var>ACTIONNAM</var>) and action value (<var>ACTIONVAL</var>), respectively.</para> |
| <para>The first argument is a word in lower case. This word specifies the name of the functionality you want to use (e.g., <samp>render</samp> to render images, <samp>manual</samp> to work on documentation, and so on.)</para> |
| <para>The second argument has a long option style (e.g., <samp>--option=value</samp>). The <samp>--option</samp> represents the action name (<var>ACTIONNAM</var>), and the characters inbetween the equal sign (<samp>=</samp>) and the first space character, are considered as the action value (<var>ACTIONVAL</var>). In order to provide action values with space characters inbetween you need to enclose action value with quotes like in <samp>--option='This is long value with spaces inbetween'</samp>. Generally, action values are used to specify paths over which the action name acts on.</para> |
| <para>Once action related variables (i.e., <var>FUNCNAM</var>, <var>ACTIONNAM</var>, and <var>ACTIONVAL</var>) are defined and validated, <code>cli_getArguments</code> shifts the positional arguments to remove the first two arguments passed (i.e., those used to retrive action related variables) and redefine the arguments (<var>ARGUMENTS</var>) global variable with the new positional parameters information.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getFunctions</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getFunctions</deffunction> |
| </definitionterm> |
| <definitionitem> |
| <para>Initialize funtionalities supported by <file>centos-art.sh</file> script.</para> |
| <para>Functionalities supported by <file>centos-art.sh</file> script are organized in functionality directories under <file>trunk/Scripts/Bash/Functions/</file> 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).</para> |
| <para>In order for <file>centos-art.sh</file> script to recognize a functionality, such functionality needs to be stored under <file>trunk/Scripts/Bash/Functions/</file> 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 <samp>functionality directory</samp>.</para> |
| <para>Inside each functionality directory, the functionalty itself is implemented through function scripts. Function scripts are organized in files independently one another and written in <samp>camelCase</samp> format with the function name as prefix. Separation between prefix and description is done using underscore (<samp>_</samp>) character.</para> |
| <para>In order for <file>centos-art.sh</file> script to load functionalities correctly, function definition inside function scripts should be set using the <samp>function</samp> reserved word, just as in the following example:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function prefix_doSomething { |
| |
| # Do something here... |
| |
| } |
| ]]></verbatim> |
| <para>The above function definition is just a convenction we use, in order to make identification of function names easier read and automate by <file>centos-art.sh</file> script initialization commands, once <file>centos-art.sh</file> script determines which functionality directory to use. Specifically, in order to initialize and export functions, <file>centos-art.sh</file> script executes all function scripts inside the functionality directory, and later <command>grep</command> on them using a regular expression pattern, where the <samp>function</samp> reserved word is used as reference to retrive the function names and export them to <file>centos-art.sh</file> script execution environment, and so, make function definitions —from function scripts inside the functionality directory— available for further calls.</para> |
| <para>If the functionality specified in the command-line first argument doesn't have a functionality directory, <file>centos-art.sh</file> script considers the functionality provided in the command-line as invalid functionality and immediatly stops script execution with an error message.</para> |
| <para>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:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| #!/bin/bash |
| # |
| # prefix_doSomething.sh -- This function illustrates function scripts |
| # design model you can use to create your own function scripts inside |
| # centos-art.sh script. |
| # |
| # Copyright (C) YEAR YOURFULLNAME |
| # |
| # This program is free software; you can redistribute it and/or modify |
| # it under the terms of the GNU General Public License as published by |
| # the Free Software Foundation; either version 2 of the License, or |
| # (at your option) any later version. |
| # |
| # This program is distributed in the hope that it will be useful, but |
| # WITHOUT ANY WARRANTY; without even the implied warranty of |
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
| # General Public License for more details. |
| # |
| # You should have received a copy of the GNU General Public License |
| # along with this program; if not, write to the Free Software |
| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 |
| # USA. |
| # |
| # ---------------------------------------------------------------------- |
| # $Id$ |
| # ---------------------------------------------------------------------- |
| |
| function prefix_doSomething { |
| |
| # Do something here... |
| |
| } |
| ]]></verbatim> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getCountryCodes</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getCountryCodes</deffunction> |
| <defdelimiter>[</defdelimiter> |
| <defparam>FILTER</defparam> |
| <defdelimiter>]</defdelimiter> |
| </definitionterm> |
| <definitionitem> |
| <para>Output country codes supported by <file>centos-art.sh</file> script.</para> |
| <para>The <code>cli_getCountryCodes</code> function outputs a list with country codes as defined in ISO3166 standard. When <var>FILTER</var> is provided, <code>cli_getCountryCodes</code> outputs country codes that match <var>FILTER</var> regular expression pattern.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getCountryName</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getCountryName</deffunction> |
| <defdelimiter>[</defdelimiter> |
| <defparam>FILTER</defparam> |
| <defdelimiter>]</defdelimiter> |
| </definitionterm> |
| <definitionitem> |
| <para>Outputs country name supported by <file>centos-art.sh</file> script.</para> |
| <para>The <code>cli_getCountryName</code> 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, <code>cli_getCountryName</code> returns the country name that matches the locale code specified in <var>FILTER</var>, exactly.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getCurrentLocale</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getCurrentLocale</deffunction> |
| </definitionterm> |
| <definitionitem> |
| <para>Output current locale used by <file>centos-art.sh</file> script.</para> |
| <para>The <code>cli_getCurrentLocale</code> function uses <env>LANG</env> environment variable to build a locale pattern that is later applied to <code>cli_getLocales</code> function output in order to return the current locale that <file>centos-art.sh</file> script works with.</para> |
| <para>The current locale information, returned by <code>cli_getCurrentLocale</code>, is output from more specific to less specific. For example, if <samp>en_GB</samp> locale exists in <code>cli_getLocales</code> function output, the <samp>en_GB</samp> locale would take precedence before <samp>en</samp> locale.</para> |
| <para>Locale precedence selection is quite important in order to define the locale type we use for message translations. For example, if <samp>en_GB</samp> is used, we are also saying that the common language specification for English language (i.e., <samp>en</samp>) is no longer used. Instead, we are using English non-common country-specific language specifications like <samp>en_AU</samp>, <samp>en_BW</samp>, <samp>en_GB</samp>, <samp>en_US</samp>, etc., for message translations.</para> |
| <para>Use <code>cli_getCurrentLocale</code> function to know what current locale information to use inside <file>centos-art.sh</file> script.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getFilesList</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getFilesList</deffunction> |
| <defdelimiter>[</defdelimiter> |
| <defparam>LOCATION</defparam> |
| <defdelimiter>]</defdelimiter> |
| </definitionterm> |
| <definitionitem> |
| <para>Output list of files to process.</para> |
| <para>The <code>cli_getFilesList</code> function uses <var>LOCATION</var> variable as source location to build a list of files just as specified by regular expression (<var>REGEX</var>) global variable. Essentially, what the <code>cli_getFilesList</code> function does is using <command>find</command> command to look for files in the location (<var>LOCATION</var>) just as posix-egrep regular expression (<var>REGEX</var>) specifies.</para> |
| <para>If <var>LOCATION</var> is not specified when <code>cli_getFilesList</code> function is called, the action value (<var>ACTIONVAL</var>) global variable is used as location value instead.</para> |
| <para>By default, if the regular expression (<var>REGEX</var>) global variable is not redefined after its first definition in the <code>cli</code> function, all files that match default regular expression value (i.e., <samp>.+</samp>) 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 <code>cli</code> function and before calling <code>cli_getFilesList</code> function, the last value you specifed is used instead.</para> |
| <para>When you need to customize the regular expression (<var>REGEX</var>) 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 <samp>local</samp> 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.</para> |
| <para>As result, the <code>cli_getFilesList</code> re-defines the value of <var>FILES</var> variable with the list of files the <command>find</command> command returned. As example, consider the following construction:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function prefix_doSomething { |
| |
| # Initialize the list of files to process. |
| local FILES='' |
| |
| # Initialize location. |
| local LOCATION=/home/centos/artwork/trunk/Identity/Themes/Models/Default |
| |
| # Re-define regular expression to match scalable vector graphic |
| # files only. Note how we use the global value of REGEX to build a |
| # new local REGEX value here. |
| local REGEX="${REGEX}.*\.(svgz|svg)" |
| |
| # Redefine list of files to process. |
| cli_getFilesList $LOCATION |
| |
| # Process list of files. |
| for FILE in $FILES;do |
| cli_printMessages "$FILE" 'AsResponseLine' |
| # Do something else here on... |
| done |
| |
| } |
| ]]></verbatim> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getLangCodes</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getLangCodes</deffunction> |
| <defdelimiter>[</defdelimiter> |
| <defparam>FILTER</defparam> |
| <defdelimiter>]</defdelimiter> |
| </definitionterm> |
| <definitionitem> |
| <para>Outputs language codes supported by <file>centos-art.sh</file> script.</para> |
| <para><code>cli_getLangCodes</code> function outputs a list of language codes as defined in ISO639 standard. When <var>FILTER</var> is provided, <code>cli_getLangCodes</code> outputs language codes that match <var>FILTER</var> regular expression pattern.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getLangName</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getLangName</deffunction> |
| <defdelimiter>[</defdelimiter> |
| <defparam>FILTER</defparam> |
| <defdelimiter>]</defdelimiter> |
| </definitionterm> |
| <definitionitem> |
| <para>Outputs language names supported by <file>centos-art.sh</file> script.</para> |
| <para><code>cli_getLangName</code> function reads one language locale code in the format LL_CC and outputs the language related name as in ISO639. If filter is specified, <code>cli_getLangName</code> returns the language name that matches the locale code specified in <var>FILTER</var>, exactly.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getLocales</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getLocales</deffunction> |
| </definitionterm> |
| <definitionitem> |
| <para>Output locale codes supported by <file>centos-art.sh</file> script.</para> |
| <para>Occasionally, you use <code>cli_getLocales</code> function to add locale information in non-common country-specific language (<samp>LL_CC</samp>) format for those languages (e.g., <samp>bn_IN</samp>, <samp>pt_BR</samp>, etc.) which locale differences cannot be solved using common language specifications (<samp>LL</samp>) into one unique common locale specification (e.g., <samp>bn</samp>, <samp>pt</samp>, etc.).</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getRepoName</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getRepoName</deffunction> |
| <defparam>NAME</defparam> |
| <defparam>TYPE</defparam> |
| </definitionterm> |
| <definitionitem> |
| <para>Sanitate file names.</para> |
| <para>Inside <file>centos-art.sh</file> script, specific functionalities rely both in <code>cli_getRepoName</code> and repository file system organization to achieve their goals. Consider <code>cli_getRepoName</code> function as central place to manage file name convenctions for other functions inside <file>centos-art.sh</file> script.</para> |
| <quotation> |
| <para><strong>Important</strong> <code>cli_getRepoName</code> function doesn't verify file or directory existence, for that purpose use <code>cli_checkFiles</code> function instead.</para> |
| </quotation> |
| <para>The <var>NAME</var> variable contains the file name or directory name you want to sanitate.</para> |
| <para>The <var>TYPE</var> variable specifies what type of sanitation you want to perform on <var>NAME</var>. The <var>TYPE</var> can be one of the following values:</para> |
| <table> |
| <tableitem> |
| <tableterm><option>d</option></tableterm> |
| <tableterm><option>directory</option></tableterm> |
| <item> |
| <para>Sanitate directory <var>NAME</var>s.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>f</option></tableterm> |
| <tableterm><option>regular-file</option></tableterm> |
| <item> |
| <para>Sanitate regular file <var>NAME</var>s.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>Use <code>cli_getRepoName</code> function to sanitate file names and directory names before their utilization.</para> |
| <para>Use <code>cli_getRepoName</code> when you need to change file name convenctions inside <file>centos-art.sh</file> script.</para> |
| <para>When we change file name convenctions inside <code>cli_getRepoName</code> 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 (— <strong>Removed</strong>(pxref:trunk Scripts Bash Functions Path) —, for more information).</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getRepoStatus</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getRepoStatus</deffunction> |
| <defdelimiter>[</defdelimiter> |
| <defparam>LOCATION</defparam> |
| <defdelimiter>]</defdelimiter> |
| </definitionterm> |
| <definitionitem> |
| <para>Request repository status.</para> |
| <para>This function requests the status of a <var>LOCATION</var> inside the working copy using the <command>svn status</command> command and returns the first character in the output line, just as described in <command>svn help status</command>. If <var>LOCATION</var> is not a regular file or a directory, inside the working copy, the <file>centos-art.sh</file> script prints a message and ends its execution.</para> |
| <para>Use this function to perform verifications based a repository <var>LOCATION</var> status.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getTemporalFile</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getTemporalFile</deffunction> |
| <defparam><var>NAME</var></defparam> |
| </definitionterm> |
| <definitionitem> |
| <para>Output absolute path to temporal file <var>NAME</var>.</para> |
| <para>The <code>cli_getTemporalFile</code> function uses <file>/tmp</file> directory as source location to store temporal files, the <file>centos-art.sh</file> script name, and a random identification string to let you run more than one <file>centos-art.sh</file> script simultaneously on the same user session. For example, due the following temporal file defintion:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| cli_getTemporalFile $FILE |
| ]]></verbatim> |
| <para>If <var>FILE</var> name is <file>instance.svg</file> and the unique random string is <samp>f16f7b51-ac12-4b7f-9e66-72df847f12de</samp>, the final temporal file, built from previous temporal file definition, would be:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| /tmp/centos-art.sh-f16f7b51-ac12-4b7f-9e66-72df847f12de-instance.svg |
| ]]></verbatim> |
| <para>When you use the <code>cli_getTemporalFile</code> 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:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| for FILE in $FILES;do |
| |
| # Initialize temporal instance of file. |
| INSTANCE=$(cli_getTemporalFile $FILE) |
| |
| # Do something ... |
| |
| # Remove temporal instance of file. |
| if [[ -f $INSTANCE ]];then |
| rm $INSTANCE |
| fi |
| |
| done |
| ]]></verbatim> |
| <para>Use the <code>cli_getTemporalFile</code> function whenever you need to create temporal files inside <file>centos-art.sh</file> script.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_getThemeName</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_getThemeName</deffunction> |
| </definitionterm> |
| <definitionitem> |
| <para>Output theme name.</para> |
| <para>In order for <code>cli_getThemeName</code> function to extract theme name correctly, the <var>ACTIONVAL</var> variable must contain a directory path under <file>trunk/Identity/Themes/Motifs/</file> directory structure. Otherwise, <code>cli_getThemeName</code> returns an empty string.</para> |
| </definitionitem> |
| </definition> |
| <definition> |
| <definitionterm><indexterm index="fn">cli_printMessage</indexterm> |
| <defcategory>Function</defcategory> |
| <deffunction>cli_printMessage</deffunction> |
| <defparam>MESSAGE</defparam> |
| <defdelimiter>[</defdelimiter> |
| <defparam>FORMAT</defparam> |
| <defdelimiter>]</defdelimiter> |
| </definitionterm> |
| <definitionitem> |
| <para>Define standard output message definition supported by <file>centos-art.sh</file> script.</para> |
| <para>When <var>FORMAT</var> is not specified, <code>cli_printMessage</code> outputs information just as it was passed in <var>MESSAGE</var> variable. Otherwise, <var>FORMAT</var> can take one of the following values:</para> |
| <table> |
| <tableitem> |
| <tableterm><option>AsHeadingLine</option></tableterm> |
| <item> |
| <para>To print heading messages.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ---------------------------------------------------------------------- |
| $MESSAGE |
| ---------------------------------------------------------------------- |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsWarningLine</option></tableterm> |
| <item> |
| <para>To print warning messages.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ---------------------------------------------------------------------- |
| WARNING: $MESSAGE |
| ---------------------------------------------------------------------- |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsNoteLine</option></tableterm> |
| <item> |
| <para>To print note messages.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ---------------------------------------------------------------------- |
| NOTE: $MESSAGE |
| ---------------------------------------------------------------------- |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsUpdatingLine</option></tableterm> |
| <item> |
| <para>To print <samp>Updating</samp> messages on two-columns format.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Updating $MESSAGE |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsRemovingLine</option></tableterm> |
| <item> |
| <para>To print <samp>Removing</samp> messages on two-columns format.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Removing $MESSAGE |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsCheckingLine</option></tableterm> |
| <item> |
| <para>To print <samp>Checking</samp> messages on two-columns format.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Checking $MESSAGE |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsCreatingLine</option></tableterm> |
| <item> |
| <para>To print <samp>Creating</samp> messages on two-columns format.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Creating $MESSAGE |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsSavedAsLine</option></tableterm> |
| <item> |
| <para>To print <samp>Saved as</samp> messages on two-columns format.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Saved as $MESSAGE |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsLinkToLine</option></tableterm> |
| <item> |
| <para>To print <samp>Linked to</samp> messages on two-columns format.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Linked to $MESSAGE |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsMovedToLine</option></tableterm> |
| <item> |
| <para>To print <samp>Moved to</samp> messages on two-columns format.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Moved to $MESSAGE |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsTranslationLine</option></tableterm> |
| <item> |
| <para>To print <samp>Translation</samp> messages on two-columns format.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Translation $MESSAGE |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsConfigurationLine</option></tableterm> |
| <item> |
| <para>To print <samp>Configuration</samp> messages on two-columns format.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Configuration $MESSAGE |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsResponseLine</option></tableterm> |
| <item> |
| <para>To print response messages on one-column format.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| --> $MESSAGE |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsRequestLine</option></tableterm> |
| <item> |
| <para>To print request messages on one-column format. Request messages output messages with one colon (<samp>:</samp>) and without trailing newline (<samp>\n</samp>) at message end.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| $MESSAGE: |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsYesOrNoRequestLine</option></tableterm> |
| <item> |
| <para>To print <samp>yes or no</samp> request messages on one-column format. If something different from <samp>y</samp> is answered (when using <code>en_US.UTF-8</code> locale), script execution ends immediatly.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| $MESSAGE [y/N]: |
| ]]></verbatim> |
| <para>When we use <file>centos-art.sh</file> script in a locale different from <code>en_US.UTF-8</code>, confirmation answer may be different from <samp>y</samp>. For example, if you use <code>es_ES.UTF-8</code> locale, the confirmation question would look like:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| $MESSAGE [s/N]: |
| ]]></verbatim> |
| <para>and the confirmation answer would be <samp>s</samp>, as it is on Spanish <samp>sÃ</samp> word.</para> |
| <para>Definition of which confirmation word to use is set on translation messages for your specific locale information. — <strong>Removed</strong>(xref:trunk Scripts Bash Functions Locale) —, for more information about locale-specific translation messages.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsToKnowMoreLine</option></tableterm> |
| <item> |
| <para>To standardize <samp>to know more, run the following command:</samp> messages. When the <option>AsToKnowMoreLine</option> option is used, the <var>MESSAGE</var> value should be set to <code>"$(caller)"</code>. <code>caller</code> is a Bash builtin that returns the context of the current subroutine call. <option>AsToKnowMoreLine</option> option uses <code>caller</code> builtin output to build documentation entries dynamically.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ---------------------------------------------------------------------- |
| To know more, run the following command: |
| centos-art manual --read='path/to/dir' |
| ---------------------------------------------------------------------- |
| ]]></verbatim> |
| <para>Use <option>AsToKnowMoreLine</option> option after errors and for intentional script termination.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><option>AsRegularLine</option></tableterm> |
| <item> |
| <para>To standardize regular messages on one-column format.</para> |
| <para>When <var>MESSAGE</var> contains a colon inside (e.g., <samp>description: message</samp>), the <code>cli_printMessage</code> function outputs <var>MESSAGE</var> on two-columns format.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>Use <code>cli_printMessage</code> function whenever you need to output information from <file>centos-art.sh</file> script.</para> |
| <quotation> |
| <para><strong>Tip</strong> To improve two-columns format, change the following file:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Scripts/Bash/Styles/output_forTwoColumns.awk |
| ]]></verbatim> |
| </quotation> |
| </definitionitem> |
| </definition> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Specific functions</title> |
| <para>The following specific functions of <file>centos-art.sh</file> script, are available for you to use:</para> |
| <menu> |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| </menu> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Scripts</menunode> |
| <menutitle>Directories trunk Scripts</menutitle> |
| <menucomment> |
| </menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Help</nodename> |
| <nodenext>Directories trunk Scripts Functions Html</nodenext> |
| <nodeprev>Directories trunk Scripts Functions</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Help</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Help</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Html</nodename> |
| <nodenext>Directories trunk Scripts Functions Identity</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Help</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Html</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Html</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Identity</nodename> |
| <nodenext>Directories trunk Scripts Functions Locale</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Html</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Identity</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Identity</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Locale</nodename> |
| <nodenext>Directories trunk Scripts Functions Manual</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Identity</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Locale</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Locale</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>This command looks for <samp>.sh</samp> files inside Bash directory and extracts translatable strings from files, using <command>xgettext</command> command, in order to create a portable object template (<file>centos-art.sh.pot</file>) file for them.</para> |
| <para>With the <file>centos-art.sh.pot</file> file up to date, the <command>centos-art</command> command removes the temporal list of files sotred inside <file>/tmp</file> directory and checks the current language of your user's session to create a portable object file for it, in the location <file>$CLI_LANG/$CLI_LANG.po</file>.</para> |
| <para>The <var>CLI_LANG</var> variable discribes the locale language used to output messages inside <command>centos-art</command> command. The locale language used inside <command>centos-art</command> command is taken from the <env>LANG</env> environment variable. The <var>CLI_LANG</var> variable has the <samp>LL_CC</samp> format, where <samp>LL</samp> is a language code from the ISO-639 standard, and <samp>CC</samp> a country code from the ISO-3166 standard.</para> |
| <para>The <env>LANG</env> 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 <env>LANG</env> environment variable to the correct value. On the other side, if you are using a text session edit your <file>~/.bash_profile</file> file to set and export the <env>LANG</env> environment variable to your native locale as defines the <command>locale -a</command> command output; do logout, and do login again.</para> |
| <para>At this point, the <env>LANG</env> environment variable has the appropriate value you need, in order to translate <command>centos-art.sh</command> messages to your native language (the one set in <env>LANG</env> environment variable).</para> |
| <para>With the <file>$CLI_LANG/$CLI_LANG.po</file> file up to date, the <command>centos-art</command> opens it for you to update translation strings. The <command>centos-art</command> command uses the value of <var>EDITOR</var> environment variable to determine your favorite text editor. If no value is defined on <var>EDITOR</var>, the <file>/usr/bin/vim</file> text editor is used as default.</para> |
| <para>When you finishd PO file edition and quit text editor, the <command>centos-art</command> command creates the related machine object in the location <file>$CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo</file>.</para> |
| <para>At this point, all translations you made in the PO file should be available to your language when runing <command>centos-art.sh</command> script.</para> |
| <para>In order to make the <command>centos-art.sh</command> internationalization, the <command>centos-art.sh</command> script was modified as described in the <command>gettext</command> info documentation (<command>info gettext</command>). You can find such modifications in the following files:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><file>trunk/Scripts/Bash/initFunctions.sh</file></para> |
| </item> |
| <item> |
| <para><file>trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh</file></para> |
| </item> |
| <item> |
| <para><file>trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh</file></para> |
| </item> |
| </itemize> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <table> |
| <tableitem> |
| <tableterm><samp>centos-art locale --edit</samp></tableterm> |
| <item> |
| <para>Use this command to translate command-line interface output messages in the current system locale you are using (as specified in <env>LANG</env> environment variable).</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>centos-art locale --list</samp></tableterm> |
| <item> |
| <para>Use this command to see the command-line interface locale report.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Manual</nodename> |
| <nodenext>Directories trunk Scripts Functions Path</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Locale</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Manual</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Manual</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Path</nodename> |
| <nodenext>Directories trunk Scripts Functions Render</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Manual</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Path</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Path</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This section exists to organize files related to <code>path</code> functiontionality. The <code>path</code> functionality standardizes movement, syncronization, branching, tagging, and general file maintainance inside the repository.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para><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.”</emph></para> |
| |
| <subsubsection> |
| <title>Repository layout</title> |
| <para>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.</para> |
| <para>As convenction, inside CentOS Artwork Repository, we organize files and directories related to CentOS corporate visual identity under three top level directories named: <file>trunk/</file>, <file>branches/</file>, and <file>tags/</file>.</para> |
| <para>The <file>trunk/</file> directory (see <xref><xrefnodename>Directories trunk</xrefnodename></xref>) organizes the main development line of CentOS corporate visual identity. Inside <file>trunk/</file> 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 <file>trunk/</file> directory structure is mainly used to perform development tasks related to CentOS corporate visual identity.</para> |
| <para>The <file>branches/</file> directory () oranizes parallel development lines to <file>trunk/</file> directory. The <file>branches/</file> 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 <file>branches/</file> directory is mainly used to perform quality assurance tasks related to CentOS corporate visual identity.</para> |
| <para>The <file>tags/</file> directory (see <xref><xrefnodename>Directories tags</xrefnodename></xref>) organizes parallel frozen lines to <file>branches/</file> directory. The parallel frozen lines are immutable, nothing change inside them once they has been created. The <file>tags/</file> directory is mainly used to publish final releases of CentOS corporate visual identity.</para> |
| <para>The CentOS Artwork Repository layout is firmly grounded on a Subversion base. Subversion (<uref><urefurl>http://subversion.tigris.org</urefurl></uref>) 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.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Repository name convenctions</title> |
| <para>Repository name convenctions help us to maintain consistency of names inside the repository.</para> |
| <para>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 (<samp>01-welcome.png</samp>, <samp>splash.png</samp>, <samp>anaconda_header.png</samp>, etc.) and directory names are all written capitalized (e.g., <samp>Identity</samp>, <samp>Themes</samp>, <samp>Motifs</samp>, <samp>TreeFlower</samp>, etc.).</para> |
| <para>Repository name convenctions are implemented inside the <code>cli_getRepoName</code> function of <file>centos-art.sh</file> script. With <code>cli_getRepoName</code> function we reduce the amount of commands and convenctions to remember, concentrating them in just one single place to look for fixes and improvements.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Repository work flow</title> |
| <para>Repository work flow describes the steps and time intervals used to produce CentOS corporate visual identity inside CentOS Artwork Repository.</para> |
| <para>To illustrate repository work flow let's consider themes' development cycle.</para> |
| <para>Initially, we start working themes on their trunk development line (e.g., <file>trunk/Identity/Themes/Motifs/TreeFlower/</file>), here we organize information that cannot be produced automatically (i.e., background images, concepts, color information, screenshots, etc.).</para> |
| <para>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., <file>branches/Identity/Themes/Motifs/TreeFlower/1/</file>). 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.</para> |
| <para>Once the branch has been tunned up, and considered “ready” for release, it is freezed under <file>tags/</file> directory (e.g., <file>tags/Identity/Themes/Motifs/TreeFower/1.0/</file>) for packagers, webmasters, promoters, and anyone who needs images from that CentOS theme the tag was created for.</para> |
| <para>Both branches and tags, inside CentOS Artwork Repository, use numerical values to identify themselves under the same location. Branches start at one (i.e., <samp>1</samp>) and increment one unit for each branch created from the same trunk development line. Tags start at zero (i.e., <samp>0</samp>) and increment one unit for each tag created from the same branch development line.</para> |
| <quotation> |
| <para><strong>Convenction</strong> 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.</para> |
| </quotation> |
| <para>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.</para> |
| <para>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.</para> |
| <para>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.</para> |
| <para>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 <file>tags/</file> 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.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Parallel directories</title> |
| <para>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.</para> |
| <para>Parallel directories take their structure from one unique parent directory. Inside CentOS Artwork Repository, this unique parent directory is under <file>trunk/Identity</file> location. The <file>trunk/Identity</file> location must be considered the reference for whatever information you plan to create inside the repository.</para> |
| <para>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 <file>trunk/Identity/Themes/Motifs/TreeFlower/Distro</file> directory structure, the <file>centos-art.sh</file> script removes the <file>Motifs/TreeFlower/</file> directory levels from path, in order to build the parallel directory used to retrived translations, and pre-rendering configuration scripts required by <code>render</code> functionality.</para> |
| <para>Another example of parallel directory is the documentation structure created by <code>manual</code> functionality. This time, <file>centos-art.sh</file> script uses parallel directory information with uncommon directory levels to build the documentation entry required by Texinfo documentation system, inside the repository.</para> |
| <para>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.</para> |
| <para>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.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Syncronizing path information</title> |
| <para>Parallel directories are very useful to keep repository organized but introduce some complications. For instance, consider what would happen to functionalities like <code>manual</code> (<samp>trunk Scripts Bash Functions Manual</samp>) 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?</para> |
| <para>In such cases, functionalities like <code>manual</code> 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.</para> |
| <para>In the specific case of documentation (the <code>manual</code> 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 (<file>trunk/Manuals</file>) and change what must be changed to match the new parent directory structure.</para> |
| <para>There is no immediate way for <code>manual</code>, 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.</para> |
| <quotation> |
| <para><strong>Warning</strong> There is not support for URL reference inside <file>centos-art.sh</file> script. The <file>centos-art.sh</file> script is designed to work with local files inside the working copy only.</para> |
| </quotation> |
| <para>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.</para> |
| <para>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 <file>centos-art.sh</file> script needs to know when such changes happen, in a way they could be noted and handled without producing errors.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>What is the right place to store it?</title> |
| <para>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?</para> |
| <para>The CentOS Community different free support vains (see: <uref><urefurl>http://wiki.centos.org/GettingHelp</urefurl></uref>) 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.</para> |
| <para>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 <xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>) 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 <file>trunk/Identity/Themes/Motifs/TreeFlower</file> directory as example. It is the trunk development line of <emph>TreeFlower</emph> artistic motif. Artistic motifs are considered part of themes, which in turn are considered part of CentOS corporate visual identity.</para> |
| <para>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.</para> |
| <para>For example, the <file>trunk/Identity/Themes/Motifs/TreeFlower</file> 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 <file>trunk/Identity/Themes/Distro/Motifs/TreeFlower</file> location are described in the following commands, respectively:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art manual --read=turnk/ |
| centos-art manual --read=turnk/Identity/ |
| centos-art manual --read=turnk/Identity/Themes/ |
| centos-art manual --read=turnk/Identity/Themes/Motifs/ |
| centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/ |
| ]]></verbatim> |
| <para>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.</para> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <table> |
| <tableitem> |
| <tableterm><command>centos-art path --copy='SRC' --to='DST'</command></tableterm> |
| <item> |
| <para>Copy <option>SRC</option> to <option>DST</option> and schedule <option>DST</option> for addition (with history). In this command, <file>SRC</file> and <file>DST</file> are both working copy (WC) entries.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><command>centos-art path --delete='SRC'</command></tableterm> |
| <item> |
| <para>Delete <option>DST</option>. In order for this command to work the file or directory you intend to delete should be under version control first. In this command, <file>SRC</file> is a working copy (WC) entry.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Scripts</menunode> |
| <menutitle>Directories trunk Scripts</menutitle> |
| <menucomment> |
| </menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Render</nodename> |
| <nodenext>Directories trunk Scripts Functions Render Config</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Path</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Render</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Render</indexterm>The <code>render</code> functionality exists to produce both identity and translation files on different levels of information (i.e., different languages, release numbers, architectures, etc.).</para> |
| <para>The <code>render</code> functionality relies on “renderable directory structures” to produce files. Renderable directory structures can be either “identity directory structures” or “translation directory structures” with special directories inside.</para> |
| |
| <subsection> |
| <title>Renderable identity directory structures</title> |
| <para>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 <file>centos-art.sh</file> to a renderable identity directory structure. If such renderable identity directory structure doesn't exist, then it is good time to create it.</para> |
| <para>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.</para> |
| <para>Inside renderable identity directory structures, <file>centos-art.sh</file> 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.</para> |
| <para>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).</para> |
| |
| <subsubsection> |
| <title>Design template without translation</title> |
| <para>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.</para> |
| <para>For example, to produce images without translations (there is no much use in producing text-based files without translations), consider the following configuration:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>One renderable identity directory structure:</strong></tableterm> |
| <item> |
| <para>In this example we used <file>Identity/Path/To/Dir</file> as the identity component we want to produce untranslated images for. Identity components can be either under <file>trunk/</file> or <file>branches/</file> directory structure.</para> |
| <para>The identity component (i.e., <file>Identity/Path/To/Dir</file>, 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 <file>centos-art.sh</file> uses to know where to look for related translations, configuration scripts and whatever auxiliar thing a renderable directory structure may need to have.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| | The bond component |
| |----------------->| |
| trunk/Identity/Path/To/Dir <-- Renderable identity directory structure. |
| |-- Tpl <-- Design template directory. |
| | `-- file.svg <-- Design template file. |
| `-- Img <-- Directory used to store final files. |
| `-- file.png <-- Final image-based file produced from |
| design template file. |
| ]]></verbatim> |
| <para>Inside design template directory, design template files are based on <acronym><acronymword>SVG</acronymword><acronymdesc>Scalable Vector Graphics</acronymdesc></acronym> and use the extension <code>.svg</code>. Design template files can be organized using several directory levels to create a simple but extensible configuration, specially if translated images are not required.</para> |
| <para>In order for <acronym><acronymword>SVG</acronymword><acronymdesc>Scalable Vector Graphics</acronymdesc></acronym> files to be considered “design template” files, they should be placed under the design template directory and to have set a <code>CENTOSARTWORK</code> object id inside.</para> |
| <para>The <code>CENTOSARTWORK</code> word itself is a convenction name we use to define which object/design area, inside a design template, the <file>centos-art.sh</file> script will use to export as <acronym><acronymword>PNG</acronymword><acronymdesc>Portable Network Graphic</acronymdesc></acronym> image at rendition time. Whithout such object id specification, the <file>centos-art.sh</file> script cannot know what object/design area you (as designer) want to export as <acronym><acronymword>PNG</acronymword><acronymdesc>Portable Network Graphic</acronymdesc></acronym> image file.</para> |
| <quotation> |
| <para><strong>Note</strong> At rendition time, the content of <file>Img/</file> directory structure is produced by <file>centos-art.sh</file> automatically.</para> |
| </quotation> |
| <para>When a renderable identity directory structure is configured to produce image-based content, <file>centos-art.sh</file> produces <acronym><acronymword>PNG</acronymword><acronymdesc>Portable Network Graphics</acronymdesc></acronym> files with the <code>.png</code> extension. Once the base image format has been produced, it is possible for <file>centos-art.sh</file> to use it in order to automatically create other image formats that may be needed (— <strong>Removed</strong>(pxref:trunk Scripts Bash Functions Render Config) —).</para> |
| <para>Inside the working copy, you can find an example of “design template without translation” configuration at <file>trunk/Identity/Models/</file>.</para> |
| <para>See <xref><xrefnodename>Directories trunk Identity</xrefnodename></xref>, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>One translation directory structure:</strong></tableterm> |
| <item> |
| <para>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.</para> |
| <para>If the translation entry is empty (i.e., there is no file inside it), <file>centos-art.sh</file> interprets the identity renderable directory structure as a “design templates without translation” configuration.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| | The bond component |
| |----------------->| |
| trunk/Translations/Identity/Path/To/Dir |
| `-- (empty) |
| ]]></verbatim> |
| <para>If the translation entry is not empty, <file>centos-art.sh</file> 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 (<var>MATCHINGLIST</var>) variable in the pre-rendition configuration script of the renderable identity directory structure we are producing images for.</para> |
| <para>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, <emph>one</emph> translation files is applied to <emph>one</emph> design template, to produce <emph>one</emph> translated image.</para> |
| <para>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.</para> |
| <para>— <strong>Removed</strong>(xref:trunk Translations) —, for more information.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>One pre-rendition configuration script:</strong></tableterm> |
| <item> |
| <para>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 <file>centos-art.sh</file> will perform over the identity directory structure and how does it do that.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| | The bond component |
| |----------------->| |
| trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir |
| `-- render.conf.sh |
| ]]></verbatim> |
| <para>In this configuration the pre-rendition configuration script (<file>render.conf.sh</file>) would look like the following:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function render_loadConfig { |
| |
| # Define rendition actions. |
| ACTIONS[0]='BASE:renderImage' |
| |
| } |
| ]]></verbatim> |
| <para>Since translation directory structure is empty, <file>centos-art.sh</file> assumes a “design template without translation” configuration to produce untranslated images.</para> |
| <para>To produce untranslated images, <file>centos-art.sh</file> takes one design template and creates one temporal instance from it. Later, <file>centos-art.sh</file> uses the temporal design template instance as source file to export the final untranslated image. The action of exporting images from <acronym><acronymword>SVG</acronymword><acronymdesc>Scalable Vector Graphics</acronymdesc></acronym> to <acronym><acronymword>PNG</acronymword><acronymdesc>Portable Network Graphics</acronymdesc></acronym> is possible thanks to Inkscape's command-line interface and the <code>CENTOSARTWORK</code> object id we previously set inside design templates.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art.sh render --identity=trunk/Identity/Path/To/Dir |
| ------------------------------------------------- |
| 0 | Execute centos-art.sh on renderable identity directory structure. |
| --v---------------------------------------------- |
| trunk/Identity/Path/To/Dir/Tpl/file.svg |
| ------------------------------------------------- |
| 1 | Create instance from design template. |
| --v---------------------------------------------- |
| /tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg |
| ------------------------------------------------- |
| 2 | Render untranslated image from design template instance. |
| --v---------------------------------------------- |
| trunk/Identity/NewDir/Img/file.png |
| ------------------------------------------------- |
| 3 | Remove design template instance. |
| ]]></verbatim> |
| <para>Finally, when the untranslated image has been created, the temporal design template instance is removed. At this point, <file>centos-art.sh</file> takes the next design template and repeats the whole production flow once again (design template by design template), until all design templates be processed.</para> |
| <para>— <strong>Removed</strong>(xref:trunk Scripts Bash Functions Render Config) —, for more information.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Design template with translation (one-to-one)</title> |
| <para>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.</para> |
| <para>In order for <file>centos-art.sh</file> 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, <file>centos-art.sh</file> will not produce the final image related to the missing component.</para> |
| <para>In order for <file>centos-art.sh</file> to know which is the relation between translation files and design templates the translation directory structure is taken as reference. For example, the <file>trunk/Translations/Identity/Path/To/Dir/file.sed</file> translation file does match <file>trunk/Identity/Path/To/Dir/Tpl/file.svg</file> design template, but it doesn't match <file>trunk/Identity/Path/To/Dir/File.svg</file> or <file>trunk/Identity/Path/To/Dir/Tpl/File.svg</file> or <file>trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg</file> design templates.</para> |
| <para>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.</para> |
| <quotation> |
| <para><strong>Note</strong> If we use no translation file in the translation entry (i.e., an empty directory), <file>centos-art.sh</file> assumes the untranslated image production. If we fill the translation entry with translation files, <file>centos-art.sh</file> assumes the translated image production.</para> |
| </quotation> |
| <para>To produce final images, <file>centos-art.sh</file> applies one translation file to one design template and produce a translated design template instance. Later, <file>centos-art.sh</file> uses the translated template instance to produce the translated image. Finally, when the translated image has been produced, <file>centos-art.sh</file> removes the translated design template instance. This production flow is repeated for each translation file available in the translatio entry.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| centos-art.sh render --identity=trunk/Identity/Path/To/Dir |
| ------------------------------------------------- |
| 0 | Execute centos-art.sh on directory structure. |
| --v---------------------------------------------- |
| trunk/Translations/Identity/Path/To/Dir/file.sed |
| ------------------------------------------------- |
| 1 | Apply translation to design template. |
| --v---------------------------------------------- |
| trunk/Identity/Path/To/Dir/Tpl/file.svg |
| ------------------------------------------------- |
| 2 | Create design template instance. |
| --v---------------------------------------------- |
| /tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg |
| ------------------------------------------------- |
| 3 | Render PNG image from template instance. |
| --v---------------------------------------------- |
| trunk/Identity/NewDir/Img/file.png |
| ------------------------------------------------- |
| 4 | Remove design template instance. |
| ]]></verbatim> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Design template with translation (optimized)</title> |
| <para>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?</para> |
| <para>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 (<var>MATCHINGLIST</var>) 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.</para> |
| <para>The <var>MATCHINGLIST</var> variable is set in the pre-rendition configuration script of the component we want to produce images for. By default, the <var>MATCHINGLIST</var> variable is empty which means no matching list is used. Otherwise, if <var>MATCHINGLIST</var> variable has a value different to empty value then, <file>centos-art.sh</file> interprets the matching list in order to know how translation files are applied to design templates.</para> |
| <para>For example, consider the following configuration:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>One entry under <file>trunk/Identity/</file>:</strong></tableterm> |
| <item> |
| <para>In this configuration we want to produce three images using a paragraph-based style, controlled by <file>paragraph.svg</file> design template; and one image using a list-based style, controlled by <file>list.svg</file> design template.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Identity/Path/To/Dir |
| |-- Tpl |
| | |-- paragraph.svg |
| | `-- list.svg |
| `-- Img |
| |-- 01-welcome.png |
| |-- 02-donate.png |
| |-- 03-docs.png |
| `-- 04-support.png |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>One entry under <file>trunk/Translations/</file>:</strong></tableterm> |
| <item> |
| <para>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.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Translations/Identity/Path/To/Dir |
| |-- 01-welcome.sed |
| |-- 02-donate.sed |
| |-- 03-docs.sed |
| `-- 04-support.sed |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>One entry under <file>trunk/trunk/Scripts/Bash/Functions/Render/Config/</file>:</strong></tableterm> |
| <item> |
| <para>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 <file>centos-art.sh</file> 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 <var>MATCHINGLIST</var> variable inside the pre-rendition configuration script of the component we want to produce images for.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir |
| `-- render.conf.sh |
| ]]></verbatim> |
| <para>In this configuration the pre-rendition configuration script (<file>render.conf.sh</file>) would look like the following:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function render_loadConfig { |
| |
| # Define rendition actions. |
| ACTIONS[0]='BASE:renderImage' |
| |
| # Define matching list. |
| MATCHINGLIST="\ |
| paragraph.svg:\ |
| 01-welcome.sed\ |
| 02-donate.sed\ |
| 04-support.sed |
| list.svg:\ |
| 03-docs.sed |
| " |
| |
| } |
| ]]></verbatim> |
| <para>As result, <file>centos-art.sh</file> will produce <file>01-welcome.png</file>, <file>02-donate.png</file> and <file>04-support.png</file> using the paragraph-based design template, but <file>03-docs.png</file> using the list-based design template.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Design template with translation (optimized+flexibility)</title> |
| <para>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 <emph>almost</emph> does.</para> |
| <para>Generally, we use design templates to define how final images will look like. Generally, each renderable directory structure has one <file>Tpl/</file> 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.</para> |
| <para>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.</para> |
| <para>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.</para> |
| <para>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 <file>centos-art.sh</file>.</para> |
| <para>For example, consider the following configuration:</para> |
| <table> |
| <tableitem> |
| <tableterm><strong>One entry under <file>trunk/Identity/Themes/Models/</file>:</strong></tableterm> |
| <item> |
| <para>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 <code>CENTOSARTWORK</code> export id present to identify the exportation area, translation marks, etc. However, design models do use dynamic backgrounds inclusion while design templates don't.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| THEMEMODEL | | The bond component |
| |<----| |--------------------->| |
| trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/ |
| |-- paragraph.svg |
| `-- list.svg |
| ]]></verbatim> |
| <para>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.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>One entry under <file>trunk/Identity/Themes/Motifs/</file>:</strong></tableterm> |
| <item> |
| <para>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 <file>centos-art.sh</file> (e.g., Backgrounds, Color information, Screenshots, etc.).</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| Artistic motif name | | Artistic motif backgrounds |
| |<-------| |-------->| |
| trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/ |
| |-- Img |
| | |-- Png |
| | | |-- 510x300.png |
| | | `-- 510x300-final.png |
| | `-- Jpg |
| | |-- 510x300.jpg |
| | `-- 510x300-final.jpg |
| |-- Tpl |
| | `-- 510x300.svg |
| `-- Xcf |
| `-- 510x300.xcf |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>One entry under <file>trunk/Translations/</file>:</strong></tableterm> |
| <item> |
| <para>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.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| | The bond component |
| |--------------------->| |
| trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/ |
| `-- 5 |
| |-- en |
| | |-- 01-welcome.sed |
| | |-- 02-donate.sed |
| | `-- 03-docs.sed |
| `-- es |
| |-- 01-welcome.sed |
| |-- 02-donate.sed |
| `-- 03-docs.sed |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><strong>One entry under <file>trunk/Scripts/Bash/Functions/Render/Config/</file>:</strong></tableterm> |
| <item> |
| <para>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 <file>centos-art.sh</file> how to render the component.</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/ |
| `-- render.conf.sh |
| ]]></verbatim> |
| <para>In this configuration the pre-rendition configuration script (<file>render.conf.sh</file>) would look like the following:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| function render_loadConfig { |
| |
| # Define rendition actions. |
| ACTIONS[0]='BASE:renderImage' |
| |
| # Define matching list. |
| MATCHINGLIST="\ |
| paragraph.svg:\ |
| 01-welcome.sed\ |
| 02-donate.sed |
| list.svg:\ |
| 03-docs.sed |
| " |
| |
| # Deifne theme model. |
| THEMEMODEL='Default' |
| |
| } |
| ]]></verbatim> |
| </item> |
| </tableitem> |
| </table> |
| <para>The production flow of “optimize+flexibility” configuration&dots;</para> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>Renderable translation directory structures</title> |
| <para>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.</para> |
| <para>In order to aliviate production of translation file, we made translation directory structures renderable adding a template (<file>Tpl/</file>) directory structure to handle common content inside translation files. This way, we work on translation templates and later use <file>centos-art.sh</file> to produce specific translation files (based on translation templates) for different information (e.g., languages, release numbers, architectures, etc.).</para> |
| <para>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 <file>centos-art.sh</file> is executed to produce translation files from translation templates.</para> |
| <para>Inside renderable translation directory structures, <file>centos-art.sh</file> can produce text-based files only.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Copying renderable directory structures</title> |
| <para>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).</para> |
| <para>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).</para> |
| <para>In order for a renderable directory structure to be valid, the new directory structure copied should match the following conditions:</para> |
| <enumerate first="1"> |
| <item> |
| <para>To have a unique directory structure under <file>trunk/Identity</file>, organized by any one of the above organizational designs above.</para> |
| </item> |
| <item> |
| <para>To have a unique directory structure under <file>trunk/Translations</file> to store translation files.</para> |
| </item> |
| <item> |
| <para>To have a unique directory structure under <file>trunk/Scripts/Bash/Functions/Render/Config</file> to set pre-rendition configuration script.</para> |
| </item> |
| </enumerate> |
| <para>As convenction, the <code>render_doCopy</code> function uses <file>trunk/Identity</file> directory structure as source location. Once the <file>trunk/Identity</file> directory structure has been specified and verified, the related path information is built from it and copied automatically to the new location specified by <var>FLAG_TO</var> variable.</para> |
| <para>Design templates + No translation:</para> |
| <para>Command: - centos-art render –copy=trunk/Identity/Path/To/Dir –to=trunk/Identity/NewPath/To/Dir</para> |
| <para>Sources: - trunk/Identity/Path/To/Dir - trunk/Translations/Identity/Path/To/Dir - trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir</para> |
| <para>Targets: - trunk/Identity/NewPath/To/Dir - trunk/Translations/Identity/NewPath/To/Dir - trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir</para> |
| <para>Renderable layout 2:</para> |
| <para>Command: - centos-art render –copy=trunk/Identity/Themes/Motifs/TreeFlower \ –to=trunk/Identity/Themes/Motifs/NewPath/To/Dir</para> |
| <para>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</para> |
| <para>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</para> |
| <para>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.</para> |
| <para>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).</para> |
| <para>- The common directory structures are not copied or deleted. We cannot copy a directory structure to itself.</para> |
| <para>- 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.</para> |
| <para>- 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).</para> |
| <para>- 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.</para> |
| <para>- The specific auxiliar directories are optional.</para> |
| <para>- 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).</para> |
| <para>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.</para> |
| <para>The `render_doCopy' functionality does duplicate directory structures directly involved in rendition process only. Once such directories have been duplicated, the functionality stops thereat.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para>...</para> |
| </item> |
| </itemize> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Render Config</nodename> |
| <nodenext>Directories trunk Scripts Functions Shell</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Render</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Render/Config</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Render Config</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>The <file>trunk/Scripts/Bash/Config</file> directory exists to oraganize pre-rendering configuration scripts.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>Pre-rendering configuration scripts let you customize the way <command>centos-art.sh</command> script renders identity and translation repository entries. Pre-rendering configuration scripts are <file>render.conf.sh</file> files with <command>render_loadConfig</command> function definition inside.</para> |
| <para>There is one <file>render.conf.sh</file> 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.</para> |
| |
| <subsubsection> |
| <title>The <file>render.conf.sh</file> identity model</title> |
| <para>Inside CentOS Artwork Repository, we consider identity entries to all directories under <file>trunk/Identity</file> 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.</para> |
| <para>Inside identity pre-rendering configuration scripts, image-based pre-rendering configuration scripts look like the following:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| #!/bin/bash |
| |
| function render_loadConfig { |
| |
| # Define rendering actions. |
| ACTIONS[0]='BASE:renderImage' |
| ACTIONS[1]='POST:renderFormats: tif xpm pdf ppm' |
| |
| } |
| ]]></verbatim> |
| <para>Inside identity pre-rendering configuration scripts, text-based pre-rendering configuration scripts look like the following:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| #!/bin/bash |
| |
| function render_loadConfig { |
| |
| # Define rendering actions. |
| ACTIONS[0]='BASE:renderText' |
| ACTIONS[1]='POST:formatText: --width=70 --uniform-spacing' |
| |
| } |
| ]]></verbatim> |
| <para>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.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>The <file>render.conf.sh</file> translation model</title> |
| <para>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.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>The <file>render.conf.sh</file> rendering actions</title> |
| <para>Inside both image-based and text-based identity pre-rendering configuration scripts, we use the <samp>ACTIONS</samp> array variable to define the way <command>centos-art.sh</command> script performs identity rendering. Identity rendering is organized by one <samp>BASE</samp> action, and optional <samp>POST</samp> and <samp>LAST</samp> rendering actions.</para> |
| <para>The <samp>BASE</samp> action specifies what kind of rendering does the <command>centos-art.sh</command> script will perform with the files related to the pre-rendering configuration script. The <samp>BASE</samp> action is required. Possible values to <samp>BASE</samp> action are either <samp>renderImage</samp> or <samp>renderText</samp> only.</para> |
| <para>To specify the <samp>BASE</samp> action you need to set the <samp>BASE:</samp> string followed by one of the possible values. For example, if you want to render images, consider the following definition of <samp>BASE</samp> action:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ACTIONS[0]='BASE:renderImage' |
| ]]></verbatim> |
| <para>Only one <samp>BASE</samp> action must be specified. If more than one <samp>BASE</samp> action is specified, the last one is used. If no <samp>BASE</samp> action is specified at all, an error is triggered and the <command>centos-art.sh</command> script ends its execution.</para> |
| <para>The <samp>POST</samp> action specifies which action to apply for each file rendered (at the rendering time). This action is optional. You can set many different <samp>POST</samp> actions to apply many different actions over the same already rendered file. Possible values to <samp>POST</samp> action are <samp>renderFormats</samp>, <samp>renderSyslinux</samp>, <samp>renderGrub</samp>, etc.</para> |
| <para>To specify the <samp>POST</samp> action, you need to use set the <samp>POST:</samp> 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 <samp>xpm</samp>, <samp>jpg</samp>, and <samp>tif</samp> images, based on already rendered <samp>png</samp> image, and also organize the produced files in directories named as their own extensions:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ACTIONS[0]='BASE:renderImage' |
| ACTIONS[1]='POST:renderFormats: xpm jpg tif' |
| ACTIONS[2]='POST:groupByFormat: png xpm jpg tif' |
| ]]></verbatim> |
| <para>In the previous example, file organization takes place at the moment of rendering, just after producing the <samp>png</samp> 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 <samp>POST:groupByFormat</samp> action line:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ACTIONS[0]='BASE:renderImage' |
| ACTIONS[1]='POST:renderFormats: xpm jpg tif' |
| ]]></verbatim> |
| <para>The <samp>LAST</samp> action specifies which actions to apply once the last file in the list of files to process has been rendered. The <samp>LAST</samp> action is optional. Possible values for <samp>LAST</samp> actions may be <samp>groupByFormat</samp>, <samp>renderGdmTgz</samp>, etc.</para> |
| <quotation> |
| <para><strong>Note</strong> — <strong>Removed</strong>(xref:trunk Scripts Bash Functions Render) —, to know more about possible values for <samp>BASE</samp>, <samp>POST</samp> and <samp>LAST</samp> action definitions.</para> |
| </quotation> |
| <para>To specify the <samp>LAST</samp> action, you need to set the <samp>LAST:</samp> 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:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| ACTIONS[0]='BASE:renderImage' |
| ACTIONS[1]='POST:renderFormats: xpm jpg tif' |
| ACTIONS[2]='LAST:groupByformat: png xpm jpg tif' |
| ]]></verbatim> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <para>Use the following commands to administer both identity and translation pre-rendering configuration scripts:</para> |
| <table> |
| <tableitem> |
| <tableterm><samp>centos-art config --create='path/to/dir/'</samp></tableterm> |
| <item> |
| <para>Use this command to create <samp>path/to/dir</samp> related pre-rendering configuration script.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>centos-art config --edit='path/to/dir/'</samp></tableterm> |
| <item> |
| <para>Use this command to edit <samp>path/to/dir</samp> related pre-rendering configuration script.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>centos-art config --read='path/to/dir/'</samp></tableterm> |
| <item> |
| <para>Use this command to read <samp>path/to/dir</samp> related pre-rendering configuration script.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>centos-art config --remove='path/to/dir/'</samp></tableterm> |
| <item> |
| <para>Use this command to remove <samp>path/to/dir</samp> related pre-rendering configuration script.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>In the commands above, <samp>path/to/dir</samp> refers to one renderable directory path under <file>trunk/Identity</file> or <file>trunk/Translations</file> structures only.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Scripts</menunode> |
| <menutitle>Directories trunk Scripts</menutitle> |
| <menucomment> |
| |
| </menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Shell</nodename> |
| <nodenext>Directories trunk Scripts Functions Svg</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Render Config</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Shell</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Shell</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This section exists to organize files related to <code>shell</code> functionality of <file>centos-art.sh</file> script.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>The <code>shell</code> functionality of <file>centos-art.sh</file> script helps you to maintain bash scripts inside repository. For example, suppose you've created many functionalities for <file>centos-art.sh</file> 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 <code>shell</code> functionality exists to solve maintainance tasks just as the one previously mentioned.</para> |
| <para>When you use <code>shell</code> functionality to update copyright inside script files, it is required that your script files contain (at least) the following top commentary structure:</para> |
| <float name="fig:trunk/Scripts/Bash/Functions/Shell:1"> |
| <floattype>Figure</floattype> |
| <floatpos></floatpos> |
| <verbatim xml:space="preserve"><![CDATA[ |
| 1| #!/bin/bash |
| 2| # |
| 3| # doSomething.sh -- The function description goes here. |
| 4| # |
| 5| # Copyright |
| 6| # |
| 7| # ... |
| 8| # |
| 9| # ---------------------------------------------------------------------- |
| 10| # $Id$ |
| 11| # ---------------------------------------------------------------------- |
| 12| |
| 13| function doSomething { |
| 14| |
| 15| } |
| ]]></verbatim> |
| <caption>The functions script base comment structure</caption> |
| </float> |
| <para>Relevant lines in the above structure are lines from 5 to 9. Everything else in the file is left immutable.</para> |
| <para>When you are updating copyright through <code>shell</code> functionality, the <file>centos-art.sh</file> script replaces everything in-between line 5 —the first one matching <samp>^# Copyright .+$</samp> string— and line 9—the first long dash separator matching <samp>^# -+$</samp>— with the content of copyright template instance.</para> |
| <quotation> |
| <para><strong>Caution</strong> Be sure to add the long dash separator that matches <samp>^# -+$</samp> regular expression <emph>before</emph> the function definition. Otherwise, if the <samp>Copyright</samp> line is present but no long dash separator exists, <file>centos-art.sh</file> will remove anything in-between the <samp>Copyright</samp> line and the end of file. This way you may lost your function definitions entirely.</para> |
| </quotation> |
| <para>The copyright template instance is created from one copyright template stored in the <file>Config/tpl_forCopyright.sed</file> file. The template instance is created once, and later removed when no longer needed. At this moment, when template instance is created, the <file>centos-art.sh</file> script takes advantage of automation in order to set copyright full name and date dynamically.</para> |
| <para>When you use <code>shell</code> functionality to update copyright, the first thing <file>shell</file> functionality does is requesting copyright information to user, and later, if values were left empty (i.e., no value was typed before pressing <key>RET</key> key), the <file>shell</file> functionality uses its own default values.</para> |
| <para>When <code>shell</code> functionality uses its own default values, the final copyright note looks like the following:</para> |
| <float name="fig:trunk/Scripts/Bash/Functions/Shell:2"> |
| <floattype>Figure</floattype> |
| <floatpos></floatpos> |
| <verbatim xml:space="preserve"><![CDATA[ |
| 1| #!/bin/bash |
| 2| # |
| 3| # doSomthing.sh -- The function description goes here. |
| 4| # |
| 5| # Copyright (C) 2003, 2010 The CentOS Project |
| 6| # |
| 7| # This program is free software; you can redistribute it and/or modify |
| 8| # it under the terms of the GNU General Public License as published by |
| 9| # the Free Software Foundation; either version 2 of the License, or |
| 10| # (at your option) any later version. |
| 11| # |
| 12| # This program is distributed in the hope that it will be useful, but |
| 13| # WITHOUT ANY WARRANTY; without even the implied warranty of |
| 14| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
| 15| # General Public License for more details. |
| 16| # |
| 17| # You should have received a copy of the GNU General Public License |
| 18| # along with this program; if not, write to the Free Software |
| 19| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 |
| 20| # USA. |
| 21| # |
| 22| # ---------------------------------------------------------------------- |
| 23| # $Id$ |
| 24| # ---------------------------------------------------------------------- |
| 25| |
| 26| function doSomething { |
| 27| |
| 28| } |
| ]]></verbatim> |
| <caption>The function script comment example</caption> |
| </float> |
| <para>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.</para> |
| <para>To change copyright information (i.e., full name or year information), run the <code>shell</code> 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 <code>shell</code> functionality as many times as you need to.</para> |
| <para>To change copyright license (i.e., the text in-between lines 7 and 20), you need to edit the <file>Config/tpl_forCopyright.sed</file> file, set the appropriate information, and run the <code>shell</code> functionality once again for changes to take effect over the files you specify.</para> |
| <quotation> |
| <para><strong>Important</strong> The <file>centos-art.sh</file> script is released as:</para> |
| <verbatim xml:space="preserve"><![CDATA[ |
| GNU GENERAL PUBLIC LICENSE |
| Version 2, June 1991 |
| |
| Copyright (C) 1989, 1991 Free Software Foundation, Inc. |
| 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. |
| ]]></verbatim> |
| <para>Do not change the license information under which <file>centos-art.sh</file> script is released. Instead, if you think a different license must be used, please share your reasons at <email><emailaddress>centos-devel@centos-art.sh</emailaddress><emailname>CentOS Developers mailing list</emailname></email>.</para> |
| </quotation> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <table> |
| <tableitem> |
| <tableterm><command>centos-art sh --update-copyright='path/to/dir'</command></tableterm> |
| <tableterm><command>centos-art sh --update-copyright='path/to/dir' --filter='regex'</command></tableterm> |
| <item> |
| <para>Use these commands to update copyright information in <samp>.sh</samp> files under <samp>path/to/dir</samp> directory.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>When you provide <option>--filter='regex'</option> argument, the list of files to process is reduced as specified in <samp>regex</samp> regular expression. Inside <file>centos-art.sh</file> script, the <samp>regex</samp> regular expression is used in combination with <command>find</command> command to look for files matching the regular expression path pattern.</para> |
| <quotation> |
| <para><strong>Warning</strong> In order for <samp>regex</samp> regular expression to match a file, the <samp>regex</samp> regular expresion must match the whole file path not just the file name.</para> |
| </quotation> |
| <para>For example, if you want to match all <file>render.conf.sh</file> files inside <file>path/to/dir</file>, use the <code>.+/render.conf</code> regular expression. Later, <file>centos-art.sh</file> script uses this value inside <code>^$REGEX\.sh$</code> expression in order to build the final regular expression (i.e., <code>^.+/render.conf\.sh$</code>) that is evaluated against available file paths inside the list of files to process.</para> |
| <para>Exceptionally, when you provide <option>--filter='regex'</option> in the way that <samp>regex</samp>, appended to <samp>path/to/dir/</samp> (i.e. <samp>path/to/dir/regex</samp>), matches a regular file; the <file>centos-art.sh</file> script uses the file matching as only file in the list of files to process.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Scripts</menunode> |
| <menutitle>Directories trunk Scripts</menutitle> |
| <menucomment> |
| </menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Svg</nodename> |
| <nodenext>Directories trunk Scripts Functions Verify</nodenext> |
| <nodeprev>Directories trunk Scripts Functions Shell</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Svg</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Svg</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This section exists to organize files related to <code>svg</code> functionality of <file>centos-art.sh</file> script.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>The <code>svg</code> functionality of <file>centos-art.sh</file> script helps you to maintain scalable vector graphics (SVG) inside repository. For example, suppose you've been working in CentOS default design models under <file>trunk/Identity/Themes/Models/</file>, and you want to set common metadata to all of them, and later remove all unused SVG defintions from <samp>*.svg</samp> files. Doing so file by file may be a tedious task, so the <file>centos-art.sh</file> script provides the <code>svg</code> functionality to aid you maintain such actions.</para> |
| <para><indexterm index="cp">Metadata maintainance</indexterm></para> |
| <subsubsection> |
| <title>Metadata maintainance</title> |
| <para>The metadata used is defined by Inkscape 0.46 using the SVG standard markup. The <file>centos-art.sh</file> script replaces everything in-between <code><metadata</code> and <code></metadata></code> tags with a predefined metadata template we've set for this purpose.</para> |
| <para>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 <samp>=SOMETEXT=</samp>, where <code>SOMETEXT</code> 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.</para> |
| <para>With metadata template in place, the <file>centos-art.sh</file> 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 <file>centos-art.sh</file> script is currently creating metadata information for.</para> |
| <para>With metadata template instance in place, the <file>centos-art.sh</file> script uses it to replace real values inside all <samp>.svg</samp> files under the current location you're running the <file>centos-art.sh</file> script on. Default behaviour is to ask user to enter each metadatum required, one by one. If user leaves metadatum empty, by pressing <key>RET</key> key, <file>centos-art.sh</file> uses its default value.</para> |
| <para>The <file>centos-art.sh</file> script modifies the following metadata:</para> |
| <table> |
| <tableitem> |
| <tableterm><samp>Title</samp></tableterm> |
| <item> |
| <para>Name by which this document is formally known. If no value is set here, <file>centos-art.sh</file> script uses the file name as title.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Date</samp></tableterm> |
| <item> |
| <para>Date associated with the creation of this document (YYYY-MM-DD). If no value is set here, <file>centos-art.sh</file> script uses the current date information as in <command>date +%Y-%m-%d</command>.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Creator</samp></tableterm> |
| <item> |
| <para>Name of entity primarily responsible for making the content of this document. If no value is set here, <file>centos-art.sh</file> script uses the string <samp>The CentOS Project</samp>.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Rights</samp></tableterm> |
| <item> |
| <para>Name of entity with rights to the intellectual Property of this document. If no value is set here, <file>centos-art.sh</file> script uses the string <samp>The CentOS Project</samp>.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Publisher</samp></tableterm> |
| <item> |
| <para>Name of entity responsible for making this document available. If no value is set here, <file>centos-art.sh</file> script uses the string <samp>The CentOS Project</samp>.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Identifier</samp></tableterm> |
| <item> |
| <para>Unique URI to reference this document. If no value is set here, <file>centos-art.sh</file> script uses the current file path to build the related url that points to current file location inside repository central server.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Source</samp></tableterm> |
| <item> |
| <para>Unique URI to reference the source of this document. If no value is set here, <file>centos-art.sh</file> script uses current file path to build the related url that points to current file location inside repository central server.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Relation</samp></tableterm> |
| <item> |
| <para>Unique URI to a related document. If no value is set here, <file>centos-art.sh</file> script uses current file path to build the related url that points to current file location inside repository central server.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Language</samp></tableterm> |
| <item> |
| <para>Two-letter language tag with optional subtags for the language of this document. (e.g. <samp>en-GB</samp>). If no value is set here, <file>centos-art.sh</file> script uses the current locale information as in <code>cli_getCurrentLocale</code> function.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Keywords</samp></tableterm> |
| <item> |
| <para>The topic of this document as comma-separated key words, prhases, or classifications. If no value is set here, <file>centos-art.sh</file> script uses file path to build</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Coverage</samp></tableterm> |
| <item> |
| <para>Extent or scope of this document. If no value is set here, <file>centos-art.sh</file> script uses the string <samp>The CentOS Project</samp>.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Description</samp></tableterm> |
| <item> |
| <para>Description about the document. If no value is set here, <file>centos-art.sh</file> script uses uses empty value as default.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><samp>Contributors</samp></tableterm> |
| <item> |
| <para>People that contributes in the creation/maintainance of the document. If no value is set here, <file>centos-art.sh</file> script uses uses empty value as default.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>The <samp>License</samp> metadatum is not set as a choise, by now. It is fixed <uref><urefurl>http://creativecommons.org/licenses/by-sa/3.0/</urefurl><urefdesc>Creative Common Attribution Share-Alike 3.0 License</urefdesc></uref>. This is done in order to grant license consistency among all SVG files we manage inside CentOS Artwork Repository.</para> |
| <para><indexterm index="cp">Unused definitions</indexterm></para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Unused definitions</title> |
| <para>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 <samp>Vacuum Defs</samp> command in <samp>File</samp> menu. It will remove any gradients, patterns, or markers which are not used by anything in the document, making the file smaller.</para> |
| <para>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.</para> |
| <para>To remove unused definitions from several scalable vector graphics files, the <file>centos-art.sh</file> script uses Inkscape command-line interface, specifically with the <option>--vaccum-defs</option> option.</para> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <table> |
| <tableitem> |
| <tableterm><command>centos-art svg --update-metadata='path/to/dir'</command></tableterm> |
| <tableterm><command>centos-art svg --update-metadata='path/to/dir' --filter='regex'</command></tableterm> |
| <item> |
| <para>Use these commands to update metadata information to <samp>.svg</samp> files under <samp>path/to/dir</samp> directory.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><command>centos-art svg --vacuum-defs='path/to/dir'</command></tableterm> |
| <tableterm><command>centos-art svg --vacuum-defs='path/to/dir' --filter='regex'</command></tableterm> |
| <item> |
| <para>Use these commands to remove unused definitions inside <samp>.svg</samp> files under <samp>path/to/dir</samp> directory.</para> |
| </item> |
| </tableitem> |
| </table> |
| <para>When you provide <option>--filter='regex'</option> argument, the list of files to process is reduced as specified in <samp>regex</samp> regular expression. Inside <file>centos-art.sh</file> script, the <samp>regex</samp> regular expression is used in combination with <command>find</command> command to look for files matching the regular expression path pattern.</para> |
| <quotation> |
| <para><strong>Warning</strong> In order for <samp>regex</samp> regular expression to match a file, the <samp>regex</samp> regular expresion must match the whole file path not just the file name.</para> |
| </quotation> |
| <para>For example, if you want to match all <file>summary.svg</file> files inside <file>path/to/dir</file>, use the <code>.+/summary</code> regular expression. Later, <file>centos-art.sh</file> script uses this value inside <code>^$REGEX\.svg$</code> expression in order to build the final regular expression (i.e., <code>^.+/summary\.svg$</code>) that is evaluated against available file paths inside the list of files to process.</para> |
| <para>Exceptionally, when you provide <option>--filter='regex'</option> in the way that <samp>regex</samp>, appended to <samp>path/to/dir/</samp> (i.e. <samp>path/to/dir/regex</samp>), matches a regular file; the <file>centos-art.sh</file> script uses the file matching as only file in the list of files to process.</para> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Scripts</menunode> |
| <menutitle>Directories trunk Scripts</menutitle> |
| <menucomment> |
| </menucomment> |
| </menuentry> |
| </menu> |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Directories trunk Scripts Functions Verify</nodename> |
| <nodeprev>Directories trunk Scripts Functions Svg</nodeprev> |
| <nodeup>Directories</nodeup> |
| <section> |
| <title>The <file>trunk/Scripts/Functions/Verify</file> Directory</title> |
| <para><indexterm index="cp">Directories trunk Scripts Functions Verify</indexterm></para> |
| <subsection> |
| <title>Goals</title> |
| <para>This section exists to organize files related to <file>centos-art.sh</file> script <samp>verify</samp> functionality. The <samp>verify</samp> functionality of <file>centos-art.sh</file> script helps you to verify the workstation configuration you are planning to use as host for your working copy of CentOS Artwork Repository.</para> |
| </subsection> |
| |
| <subsection> |
| <title>Description</title> |
| <para>The first time you download CentOS Artwork Repository you need to configure your workstation in order to use <file>centos-art.sh</file> script. These preliminar configurations are based mainly on auxiliar RPM packages installation, symbolic links creations, and environment variables definitions. The <samp>verify</samp> functionality of <file>centos-art.sh</file> script guides you through this preliminar configuration process.</para> |
| <para>If this is the first time you run <file>centos-art.sh</file> script, the appropriate way to use its <samp>verify</samp> functionality is not using the <file>centos-art.sh</file> script directly, but the absolute path to <command>centos-art.sh</command> script instead (i.e., <file>~/artwork/trunk/Scripts/Bash/centos-art.sh</file>). This is necessary because <file>centos-art</file> symbolic link, under <file>~/bin/</file> directory, has not been created yet.</para> |
| |
| <subsubsection> |
| <title>Packages</title> |
| <para>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 <command>centos-art.sh</command> script uses are shipped with CentOS distribution, and can be installed from CentOS base repository. The only exception is <samp>inkscape</samp>, the package we use to manipulate SVG files. The <samp>inkscape</samp> package is not inside CentOS distribution so it needs to be installed from third party repositories.</para> |
| <quotation> |
| <para><strong>Note</strong> Configuration of third party repositories inside CentOS distribution is described in CentOS wiki, specifically in the following URL: <uref><urefurl>http://wiki.centos.org/AdditionalResources/Repositories</urefurl></uref></para> |
| </quotation> |
| <para>Before installing packages, the <file>centos-art.sh</file> script uses <command>sudo</command> to request root privileges to execute <command>yum</command> installation functionality. If your user isn't defined as a privileged user—at least to run <command>yum</command> commands— inside <file>/etc/sudoers</file> configuration file, you will not be able to perform package installation tasks as set in <file>centos-art.sh</file> script <samp>verify</samp> functionality.</para> |
| <para>Setting sudo privileges to users is an administrative task you have to do by yourself. If you don't have experience with <command>sudo</command> command, please read its man page running the command: <command>man sudo</command>. This reading will be very useful, and with some practice, you will be able to configure your users to have <command>sudo</command> privileges.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Links</title> |
| <para>Creation of symbolic links helps us to alternate between different implementations of <file>centos-art.sh</file> script-line (e.g., <file>centos-art.sh</file>, for Bash implementation; <file>centos-art.py</file>, for Python implementation; <file>centos-art.pl</file>, for Perl implementation; and so on for other implementations). The <file>centos-art.sh</file> script-line definition takes place inside your personal binary (<file>~/bin/</file>) directory in order to make the script implementation —the one that <file>centos-art</file> links to— available to <var>PATH</var> environment variable.</para> |
| <para>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—.</para> |
| <para>Creation of symbolic links helps us to make <file>centos-art.sh</file> script functionalities available outside <file>trunk/</file> repository directory structure, but at its same level in repository tree. This is useful if you need to use the “render” functionality of <command>centos-art.sh</command> under <file>branches/</file> repository directory structure as you usually do inside <file>trunk/</file> repository directory structure. As consequence of this configuration, automation scripts cannot be branched under <file>branches/Scripts</file> directory structure.</para> |
| </subsubsection> |
| |
| <subsubsection> |
| <title>Environment variables</title> |
| <para>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 <file>~/.bash_profile</file> file. The <samp>verify</samp> functionality of <file>centos-art.sh</file> script doesn't modify your <file>~/.bash_profile</file> file.</para> |
| <para>The <samp>verify</samp> functionality of <file>centos-art.sh</file> script evaluates the following environment variables:</para> |
| <table> |
| <tableitem> |
| <tableterm><env>EDITOR</env></tableterm> |
| <item> |
| <para>Default text editor.</para> |
| <para>The <file>centos-art.sh</file> script uses default text <env>EDITOR</env> to edit pre-commit subversion messages, translation files, configuration files, script files, and similar text-based files.</para> |
| <para>If <env>EDITOR</env> environment variable is not set, <file>centos-art.sh</file> script uses <file>/usr/bin/vim</file> as default text editor. Otherwise, the following values are recognized by <file>centos-art.sh</file> script:</para> |
| <itemize> |
| <itemfunction>•</itemfunction> |
| <item> |
| <para><file>/usr/bin/vim</file></para> |
| </item> |
| <item> |
| <para><file>/usr/bin/emacs</file></para> |
| </item> |
| <item> |
| <para><file>/usr/bin/nano</file></para> |
| </item> |
| </itemize> |
| <para>If no one of these values is set in <env>EDITOR</env> environment variable, <file>centos-art.sh</file> uses <file>/usr/bin/vim</file> text editor by default.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><env>TEXTDOMAIN</env></tableterm> |
| <item> |
| <para>Default domain used to retrieve translated messages. This variable is set in <file>initFunctions.sh</file> and shouldn't be changed.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><env>TEXTDOMAINDIR</env></tableterm> |
| <item> |
| <para>Default directory used to retrieve translated messages. This variable is set in <file>initFunctions.sh</file> and shouldn't be changed.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><env>LANG</env></tableterm> |
| <item> |
| <para>Default locale information.</para> |
| <para>This variable is initially set in the configuration process of CentOS distribution installer (i.e., Anaconda), specifically in the <samp>Language</samp> step; or once installed using the <command>system-config-language</command> tool.</para> |
| <para>The <file>centos-art.sh</file> script uses the <var>LANG</var> environment variable to know in which language the script messages are printed out.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><env>TZ</env></tableterm> |
| <item> |
| <para>Default time zone representation.</para> |
| <para>This variable is initially set in the configuration process of CentOS distribution installer (i.e., Anaconda), specifically in the <samp>Date and time</samp> step; or once installed using the <command>system-config-date</command> tool.</para> |
| <para>The <file>centos-art.sh</file> script doesn't use the <var>TZ</var> 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.</para> |
| <para>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 <var>TZ</var> variable may be necessary.</para> |
| <quotation> |
| <para><strong>Convenction</strong> 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.</para> |
| </quotation> |
| <para>The format of <var>TZ</var> environment variable is described in <file>tzset(3)</file> manual page.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsubsection> |
| </subsection> |
| |
| <subsection> |
| <title>Usage</title> |
| <table> |
| <tableitem> |
| <tableterm><command>centos-art verify --packages</command></tableterm> |
| <item> |
| <para>Verify required packages your workstation needs in order to run the <file>centos-art.sh</file> script correctly. If there are missing packages, the <file>centos-art.sh</file> script asks you to confirm their installation. When installing packages, the <file>centos-art.sh</file> script uses the <command>yum</command> application in order to achieve the task.</para> |
| <para>In case all packages required by <file>centos-art.sh</file> script are already installed in your workstation, the message <samp>The required packages are already installed.</samp> is output for you to know.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><command>centos-art verify --links</command></tableterm> |
| <item> |
| <para>Verify required links your workstation needs in order to run the centos-art command correctly. If any required link is missing, the <command>centos-art.sh</command> script asks you to confirm their installation. To install required links, the <command>centos-art.sh</command> script uses the <command>ln</command> command.</para> |
| <para>In case all links required by <file>centos-art.sh</file> script are already created in your workstation, the message <samp>The required links are already installed.</samp> is output for you to know.</para> |
| <para>In case a regular file exists with the same name of a required link, the <file>centos-art.sh</file> script outputs the <samp>Already exists as regular file.</samp> 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 <file>centos-art.sh</file> script will fall into a continue installation request for that missing link. To end this continue request you can answer <samp>No</samp>, or remove the existent regular file to let <file>centos-art.sh</file> script install the link on its place.</para> |
| </item> |
| </tableitem> |
| <tableitem> |
| <tableterm><command>centos-art verify --environment</command></tableterm> |
| <tableterm><command>centos-art verify --environment --filter='regex'</command></tableterm> |
| <item> |
| <para>Output a brief description of environment variables used by <file>centos-art.sh</file> script.</para> |
| <para>If <samp>--filter</samp> option is provided, output is reduced as defined in the <samp>regex</samp> regular expression value. If <samp>--filter</samp> option is specified but <samp>regex</samp> value is not, the <file>centos-art.sh</file> script outputs information as if <samp>--filter</samp> option had not been provided at all.</para> |
| </item> |
| </tableitem> |
| </table> |
| </subsection> |
| |
| <subsection> |
| <title>See also</title> |
| <menu> |
| <menuentry> |
| <menunode>Directories trunk Scripts</menunode> |
| <menutitle>Directories trunk Scripts</menutitle> |
| <menucomment> |
| </menucomment> |
| </menuentry> |
| </menu> |
| |
| </subsection> |
| </section> |
| </node> |
| <node> |
| <nodename>Index</nodename> |
| <nodenext>List of Figures</nodenext> |
| <nodeprev>Directories</nodeprev> |
| <nodeup>Top</nodeup> |
| <unnumbered> |
| <title>Index</title> |
| <printindex>cp</printindex> |
| </unnumbered> |
| </node> |
| <node> |
| <nodename>List of Figures</nodename> |
| <nodeprev>Index</nodeprev> |
| <nodeup>Top</nodeup> |
| <unnumbered> |
| <title>List of Figures</title> |
| <listoffloats type="Figure"></listoffloats> |
| </unnumbered> |
| </node> |
| </texinfo> |
| |
| |
| |
| |
| |
| |
| |