From 50021cba20a09b1ed685db5466f940b17d4880ac Mon Sep 17 00:00:00 2001 From: Richard Purdie Date: Wed, 20 Apr 2011 14:20:19 +0100 Subject: Drop documentation directory, this is replaced by the new yocto-docs repository --- documentation/bsp-guide/Makefile | 35 - .../bsp-guide/bsp-guide-customization.xsl | 6 - documentation/bsp-guide/bsp-guide.xml | 68 -- documentation/bsp-guide/bsp.xml | 654 -------------- documentation/bsp-guide/figures/bsp-title.png | Bin 14940 -> 0 bytes .../bsp-guide/figures/poky-ref-manual.png | Bin 17829 -> 0 bytes documentation/bsp-guide/style.css | 958 --------------------- 7 files changed, 1721 deletions(-) delete mode 100644 documentation/bsp-guide/Makefile delete mode 100644 documentation/bsp-guide/bsp-guide-customization.xsl delete mode 100644 documentation/bsp-guide/bsp-guide.xml delete mode 100644 documentation/bsp-guide/bsp.xml delete mode 100644 documentation/bsp-guide/figures/bsp-title.png delete mode 100644 documentation/bsp-guide/figures/poky-ref-manual.png delete mode 100644 documentation/bsp-guide/style.css (limited to 'documentation/bsp-guide') diff --git a/documentation/bsp-guide/Makefile b/documentation/bsp-guide/Makefile deleted file mode 100644 index fdb45ecd1..000000000 --- a/documentation/bsp-guide/Makefile +++ /dev/null @@ -1,35 +0,0 @@ -XSLTOPTS = --stringparam html.stylesheet style.css \ - --stringparam chapter.autolabel 1 \ - --stringparam section.autolabel 1 \ - --stringparam section.label.includes.component.label 1 \ - --xinclude - -## -# These URI should be rewritten by your distribution's xml catalog to -# match your localy installed XSL stylesheets. -XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/current -XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl - -all: html pdf tarball - -pdf: - ../tools/poky-docbook-to-pdf bsp-guide.xml ../template - -html: -# See http://www.sagehill.net/docbookxsl/HtmlOutput.html - xsltproc $(XSLTOPTS) -o bsp-guide.html bsp-guide-customization.xsl bsp-guide.xml - -tarball: html - tar -cvzf bsp-guide.tgz style.css bsp-guide.html bsp-guide.pdf figures/bsp-title.png - -validate: - xmllint --postvalid --xinclude --noout bsp-guide.xml - -OUTPUTS = bsp-guide.pdf bsp-guide.html -SOURCES = *.png *.xml *.css *.svg - -publish: - scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/ - -clean: - rm -f $(OUTPUTS) diff --git a/documentation/bsp-guide/bsp-guide-customization.xsl b/documentation/bsp-guide/bsp-guide-customization.xsl deleted file mode 100644 index 362ebed13..000000000 --- a/documentation/bsp-guide/bsp-guide-customization.xsl +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - diff --git a/documentation/bsp-guide/bsp-guide.xml b/documentation/bsp-guide/bsp-guide.xml deleted file mode 100644 index fd409bc74..000000000 --- a/documentation/bsp-guide/bsp-guide.xml +++ /dev/null @@ -1,68 +0,0 @@ - - - - - - - - - - - - - - - - Richard Purdie - - Intel Corporation - - richard.purdie@linuxfoundation.org - - - - - - 0.9 - 27 October 2010 - This manual revision is the initial manual and corresponds to the - Yocto Project 0.9 Release. - - - 1.0 - 6 April 2011 - This manual revision corresponds to the Yocto Project 1.0 Release. - - - - - 2010-2011 - Linux Foundation - - - - - Permission is granted to copy, distribute and/or modify this document under - the terms of the Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England & Wales as published by Creative Commons. - - - - - - - - - - - diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml deleted file mode 100644 index 36715f33b..000000000 --- a/documentation/bsp-guide/bsp.xml +++ /dev/null @@ -1,654 +0,0 @@ - - - - - Board Support Packages (BSP) - Developers Guide - - - A Board Support Package (BSP) is a collection of information that - defines how to support a particular hardware device, set of devices, or - hardware platform. - The BSP includes information about the hardware features - present on the device and kernel configuration information along with any - additional hardware drivers required. - The BSP also lists any additional software - components required in addition to a generic Linux software stack for both - essential and optional platform features. - - - - This section (or document if you are reading the BSP Developer's Guide) defines - a structure for these components - so that BSPs follow a commonly understood layout. - Providing a common form allows end-users to understand and become familiar - with the layout. - A common form also encourages standardization - of software support of hardware. - - - - The proposed format does have elements that are specific to the Poky and - OpenEmbedded build systems. - It is intended that this information can be - used by other systems besides Poky and OpenEmbedded and that it will be simple - to extract information and convert it to other formats if required. - Poky, through its standard layers mechanism, can directly accept the format - described as a layer. - The BSP captures all - the hardware-specific details in one place in a standard format, which is - useful for any person wishing to use the hardware platform regardless of - the build system they are using. - - - - The BSP specification does not include a build system or other tools - - it is concerned with the hardware-specific components only. - At the end - distribution point you can ship the BSP combined with a build system - and other tools. - However, it is important to maintain the distinction that these - are separate components that happen to be combined in certain end products. - - -
- Example Filesystem Layout - - - The BSP consists of a file structure inside a base directory, which uses the following - naming convention: - - meta-<bsp_name> - - "bsp_name" is a placeholder for the machine or platform name. - Here are some example base directory names: - - meta-emenlow - meta-intel_n450 - meta-beagleboard - - - - - Below is the common form for the file structure inside a base directory. - While you can use this basic form for the standard, realize that the actual structures - for specific BSPs could differ. - - -meta-<bsp_name>/ -meta-<bsp_name>/<bsp_license_file> -meta-<bsp_name>/README -meta-<bsp_name>/binary/<bootable_images> -meta-<bsp_name>/conf/layer.conf -meta-<bsp_name>/conf/machine/*.conf -meta-<bsp_name>/recipes-bsp/* -meta-<bsp_name>/recipes-graphics/* -meta-<bsp_name>/recipes-kernel/linux/linux-yocto_git.bbappend - - - - - Below is an example of the crownbay BSP: - - -meta-crownbay/COPYING.MIT -meta-crownbay/README -meta-crownbay/binary/.gitignore -meta-crownbay/conf/layer.conf -meta-crownbay/conf/machine/crownbay.conf -meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig -meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xcorg.conf -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd-bin/.gitignore -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd-bin_1.7.99.2.bb -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/crosscompile.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/fix_open_max_preprocessor_error.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/macro_tweak.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/nodolt.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd_1.7.99.2.bb -meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend - - - - - The following sections describe each part of the proposed BSP format. - - -
- License Files - -meta-<bsp_name>/<bsp_license_file> - - - - These optional files satisfy licensing requirements for the BSP. - The type or types of files here can vary depending on the licensing requirements. - For example, in the crownbay BSP all licensing requirements are handled with the - COPYING.MIT file. - - - - Licensing files can be MIT, BSD, GPLv*, and so forth. - These files are recommended for the BSP but are optional and totally up to the BSP developer. - -
- -
- README File - -meta-<bsp_name>/README - - - - This file provides information on how to boot the live images that are optionally - included in the /binary directory. - The README file also provides special information needed for - building the image. - - - - Technically speaking a README is optional but it is highly - recommended that every BSP has one. - -
- -
- Pre-built User Binaries - -meta-<bsp_name>/binary/<bootable_images> - - - - This optional area contains useful pre-built kernels and user-space filesystem - images appropriate to the target system. - This directory contains the Application Development Toolkit (ADT) and minimal - live images when the BSP is has been "tar-balled" and placed on the Yocto Project website. - You can use these kernels and images to get a system running and quickly get started - on development tasks. - - - - The exact types of binaries present are highly hardware-dependent. - However, a README file should be present in the BSP file structure that explains how to use - the kernels and images with the target hardware. - If pre-built binaries are present, source code to meet licensing requirements must also - be provided in some form. - -
- -
- Layer Configuration File - -meta-<bsp_name>/conf/layer.conf - - - - This file identifies the structure as a Poky layer, identifies the - contents of the layer, and contains information about how Poky should use it. - Generally, a standard boilerplate file such as the following works. - In the following example you would replace "bsp" and "_bsp" with the actual name - of the BSP (i.e. <bsp_name> from the example template). - - - - -# We have a conf directory, add to BBPATH -BBPATH := "${BBPATH}:${LAYERDIR}" - -# We have a recipes directory containing .bb and .bbappend files, add to BBFILES -BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ ${LAYERDIR}/recipes/*/*.bbappend" - -BBFILE_COLLECTIONS += "bsp" -BBFILE_PATTERN_bsp := "^${LAYERDIR}/" -BBFILE_PRIORITY_bsp = "5" - - - - - This file simply makes BitBake aware of the recipes and configuration directories. - This file must exist so that Poky can recognize the BSP. - -
- -
- Hardware Configuration Options - -meta-<bsp_name>/conf/machine/*.conf - - - - The machine files bind together all the information contained elsewhere - in the BSP into a format that Poky can understand. - If the BSP supports multiple machines, multiple machine configuration files - can be present. - These filenames correspond to the values to which users have set the MACHINE variable. - - - - These files define things such as the kernel package to use - (PREFERRED_PROVIDER of virtual/kernel), the hardware drivers to - include in different types of images, any special software components - that are needed, any bootloader information, and also any special image - format requirements. - - - - At least one machine file is required for a BSP layer. - However, you can supply more than one file. - - - - This directory could also contain shared hardware "tuning" definitions that are commonly used to - pass specific optimization flags to the compiler. - An example is tune-atom.inc: - - - -BASE_PACKAGE_ARCH = "core2" -TARGET_CC_ARCH = "-m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse" - - - - This example defines a new package architecture called "core2" and uses the - specified optimization flags, which are carefully chosen to give best - performance on atom processors. - - - The tune file would be included by the machine definition and can be - contained in the BSP or referenced from one of the standard core set of - files included with Poky itself. - - - Both the base package architecture file and the tune file are optional for a Poky BSP layer. - -
- -
- Miscellaneous Recipe Files - -meta-<bsp_name>/recipes-bsp/* - - - - This optional directory contains miscellaneous recipe files for the BSP. - Most notably would be the formfactor files. - For example, in the crownbay BSP there is a machconfig file and a - formfactor_0.0.bbappend file: - -meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig -meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend - - - - - If a BSP does not have a formfactor entry, defaults are established according to - the configuration script. - -
- -
- Display Support Files - -meta-<bsp_name>/recipes-graphics/* - - - - This optional directory contains recipes for the BSP if it has - special requirements for graphics support. - All files that are needed for the BSP to support a display are kept here. - For example, in the crownbay BSP several display support files exist: - -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xcorg.conf -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd-bin/.gitignore -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd-bin_1.7.99.2.bb -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/crosscompile.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/fix_open_max_preprocessor_error.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/macro_tweak.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/nodolt.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd_1.7.99.2.bb - - -
- -
- Linux Kernel Configuration - -meta-<bsp_name>/recipes-kernel/linux/linux-yocto_git.bbappend - - - - This file appends your specific changes to the kernel you are using. - - - For your BSP you typically want to use an existing Poky kernel found in the - Poky repository at meta/recipes-kernel/kernel. - You can append your specific changes to the kernel recipe by using an append file, - which is located in the - meta-<bsp_name>/recipes-kernel/linux - directory. - - - Suppose you use a BSP that uses the linux-yocto_git.bb kernel, - which is the preferred kernel to use for developing a new BSP using the Yocto Project. - In other words, you have selected the kernel in your - <bsp_name>.conf file by adding the following statement: - -PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" - - You would use the linux-yocto_git.bbappend file to append - specific BSP settings to the kernel, thus configuring the kernel for your particular BSP. - - - Now take a look at the existing "crownbay" BSP. - The append file used is: - -meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend - - The file contains the following: - -FILESEXTRAPATHS := "${THISDIR}/${PN}" -COMPATIBLE_MACHINE_crownbay = "crownbay" -KMACHINE_crownbay = "yocto/standard/crownbay" - - This append file adds "crownbay" as a compatible machine, - and additionally sets a Yocto Kernel-specific variable that identifies the name of the - BSP branch to use in the GIT repository to find configuration information. - - - One thing missing in this particular BSP, which you will typically need when - developing a BSP, is the kernel configuration (.config) for your BSP. - When developing a BSP, you probably have a kernel configuration file or a set of kernel - configuration files that, when taken together, define the kernel configuration for your BSP. - You can accomplish this definition by putting the configurations in a file or a set of files - inside a directory located at the same level as your append file and having the same name - as the kernel. - With all these conditions met simply reference those files in a SRC_URI statement in the append - file. - - - For example, suppose you had a set of configuration options in a file called - defconfig. - If you put that file inside a directory named - /linux-yocto and then added - a SRC_URI statement such as the following to the append file, those configuration - options will be picked up and applied when the kernel is built. - -SRC_URI += "file://defconfig" - - - - As mentioned earlier, you can group related configurations into multiple files and - name them all in the SRC_URI statement as well. - For example, you could group separate configurations specifically for Ethernet and graphics - into their own files and add those by using a SRC_URI statement like the - following in your append file: - -SRC_URI += "file://defconfig \ - file://eth.cfg \ - file://gfx.cfg" - - - - The FILESEXTRAPATHS variable is in boilerplate form here in order to make it easy - to do that. - It basically allows those configuration files to be found by the build process. - - - Other methods exist to accomplish grouping and defining configuration options. - For example, you could directly add configuration options to the Yocto kernel - meta branch for your BSP. - The configuration options will likely end up in that location anyway if the BSP gets - added to the Yocto Project. - For information on how to add these configurations directly, see the - "Yocto Project Kernel Architecture and Use Manual" on the - Yocto Project website - Documentation Page - - - In general, however, the Yocto Project maintainers take care of moving the SRC_URI-specified - configuration options to the meta branch. - Not only is it easier for BSP developers to not have to worry about putting those - configurations in the branch, but having the maintainers do it allows them to apply - 'global' knowledge about the kinds of common configuration options multiple BSPs in - the tree are typically using. - This allows for promotion of common configurations into common features. - -
- - -
- -
- BSP 'Click-Through' Licensing Procedure - - This section describes how - click-through licensing is expected to work. - Currently, this functionality is not yet implemented. - - - - In some cases, a BSP contains separately licensed IP - (Intellectual Property) for a component that imposes - upon the user a requirement to accept the terms of a - 'click-through' license. - Once the license is accepted the - Poky build system can then build and include the - corresponding component in the final BSP image. - Some affected components might be essential to the normal - functioning of the system and have no 'free' replacement - (i.e. the resulting system would be non-functional - without them). - On the other hand, other components might be simply - 'good-to-have' or purely elective, or if essential - nonetheless have a 'free' (possibly less-capable) - version that could be used as a in the BSP recipe. - - - - For cases where you can substitute something and still maintain functionality, - the Yocto Project website at - - will make available a 'de-featured' BSP completely free of the encumbered IP. - In that case you can use the substitution directly and without any further licensing - requirements. - If present, this fully 'de-featured' BSP will be named appropriately different - than the normal encumbered BSP. - If available, this substitution is the simplest and most preferred option. - This, of course, assumes the resulting functionality meets requirements. - - - - If however, a non-encumbered version is unavailable or the 'free' version - would provide unsuitable functionality or quality, you can use - an encumbered version. - - - - Several methods exist within the Poky build system to satisfy the licensing - requirements for an encumbered BSP. - The following list describes them in preferential order: - - - - - - - Get a license key (or keys) for the encumbered BSP by visiting - a website and providing the name of the BSP and your email address - through a web form. - - - - - - After agreeing to any applicable license terms, the - BSP key(s) will be immediately sent to the address - you gave and you can use them by specifying BSPKEY_<keydomain> - environment variables when building the image: - - - - $ BSPKEY_<keydomain>=<key> bitbake poky-image-sato - - - - These steps allow the encumbered image to be built - with no change at all to the normal build process. - - - - Equivalently and probably more conveniently, a line - for each key can instead be put into the user's - local.conf file. - - - - The <keydomain> component of the - BSPKEY_<keydomain> is required because there - might be multiple licenses in effect for a given BSP. - In such cases, a given <keydomain> corresponds to - a particular license. In order for an encumbered - BSP that encompasses multiple key domains to be built - successfully, a <keydomain> entry for each - applicable license must be present in local.conf or - supplied on the command-line. - - - - - Do nothing - build as you normally would. - When a license is needed the build will stop and prompt you with instructions. - Follow the license prompts that originate from the - encumbered BSP. - These prompts usually take the form of instructions - needed to manually fetch the encumbered package(s) - and md5 sums into the required directory - (e.g. the poky/build/downloads). - Once the manual package fetch has been - completed, restart the build to continue where - it left off. - During the build the prompt will not appear again since you have satisfied the - requirement. - - - - - Get a full-featured BSP recipe rather than a key. - You can do this by visiting the applicable BSP download page from the Yocto - Project website at - . - BSP tarballs that have proprietary information can be downloaded after agreeing - to licensing requirements as part of the download process. - Obtaining the code this way allows you to build an encumbered image with - no changes at all as compared to the normal build. - - - - - Note that the third method is also the only option available - when downloading pre-compiled images generated from non-free BSPs. - Those images are likewise available at from the Yocto Project website. - -
- - diff --git a/documentation/bsp-guide/figures/bsp-title.png b/documentation/bsp-guide/figures/bsp-title.png deleted file mode 100644 index ee383141f..000000000 Binary files a/documentation/bsp-guide/figures/bsp-title.png and /dev/null differ diff --git a/documentation/bsp-guide/figures/poky-ref-manual.png b/documentation/bsp-guide/figures/poky-ref-manual.png deleted file mode 100644 index 333442e0d..000000000 Binary files a/documentation/bsp-guide/figures/poky-ref-manual.png and /dev/null differ diff --git a/documentation/bsp-guide/style.css b/documentation/bsp-guide/style.css deleted file mode 100644 index 9d068a0f5..000000000 --- a/documentation/bsp-guide/style.css +++ /dev/null @@ -1,958 +0,0 @@ -/* - Generic XHTML / DocBook XHTML CSS Stylesheet. - - Browser wrangling and typographic design by - Oyvind Kolas / pippin@gimp.org - - Customised for Poky by - Matthew Allum / mallum@o-hand.com - - Thanks to: - Liam R. E. Quin - William Skaggs - Jakub Steiner - - Structure - --------- - - The stylesheet is divided into the following sections: - - Positioning - Margins, paddings, width, font-size, clearing. - Decorations - Borders, style - Colors - Colors - Graphics - Graphical backgrounds - Nasty IE tweaks - Workarounds needed to make it work in internet explorer, - currently makes the stylesheet non validating, but up until - this point it is validating. - Mozilla extensions - Transparency for footer - Rounded corners on boxes - -*/ - - - /*************** / - / Positioning / -/ ***************/ - -body { - font-family: Verdana, Sans, sans-serif; - - min-width: 640px; - width: 80%; - margin: 0em auto; - padding: 2em 5em 5em 5em; - color: #333; -} - -.reviewer { - color: red; -} - -h1,h2,h3,h4,h5,h6,h7 { - font-family: Arial, Sans; - color: #00557D; - clear: both; -} - -h1 { - font-size: 2em; - text-align: left; - padding: 0em 0em 0em 0em; - margin: 2em 0em 0em 0em; -} - -h2.subtitle { - margin: 0.10em 0em 3.0em 0em; - padding: 0em 0em 0em 0em; - font-size: 1.8em; - padding-left: 20%; - font-weight: normal; - font-style: italic; -} - -h2 { - margin: 2em 0em 0.66em 0em; - padding: 0.5em 0em 0em 0em; - font-size: 1.5em; - font-weight: bold; -} - -h3.subtitle { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; - font-size: 142.14%; - text-align: right; -} - -h3 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 140%; - font-weight: bold; -} - -h4 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 120%; - font-weight: bold; -} - -h5 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 110%; - font-weight: bold; -} - -h6 { - margin: 1em 0em 0em 0em; - padding: 1em 0em 0em 0em; - font-size: 80%; - font-weight: bold; -} - -.authorgroup { - background-color: transparent; - background-repeat: no-repeat; - padding-top: 256px; - background-image: url("figures/bsp-title.png"); - background-position: left top; - margin-top: -256px; - padding-right: 50px; - margin-left: 0px; - text-align: right; - width: 740px; -} - -h3.author { - margin: 0em 0me 0em 0em; - padding: 0em 0em 0em 0em; - font-weight: normal; - font-size: 100%; - color: #333; - clear: both; -} - -.author tt.email { - font-size: 66%; -} - -.titlepage hr { - width: 0em; - clear: both; -} - -.revhistory { - padding-top: 2em; - clear: both; -} - -.toc, -.list-of-tables, -.list-of-examples, -.list-of-figures { - padding: 1.33em 0em 2.5em 0em; - color: #00557D; -} - -.toc p, -.list-of-tables p, -.list-of-figures p, -.list-of-examples p { - padding: 0em 0em 0em 0em; - padding: 0em 0em 0.3em; - margin: 1.5em 0em 0em 0em; -} - -.toc p b, -.list-of-tables p b, -.list-of-figures p b, -.list-of-examples p b{ - font-size: 100.0%; - font-weight: bold; -} - -.toc dl, -.list-of-tables dl, -.list-of-figures dl, -.list-of-examples dl { - margin: 0em 0em 0.5em 0em; - padding: 0em 0em 0em 0em; -} - -.toc dt { - margin: 0em 0em 0em 0em; - padding: 0em 0em 0em 0em; -} - -.toc dd { - margin: 0em 0em 0em 2.6em; - padding: 0em 0em 0em 0em; -} - -div.glossary dl, -div.variablelist dl { -} - -.glossary dl dt, -.variablelist dl dt, -.variablelist dl dt span.term { - font-weight: normal; - width: 20em; - text-align: right; -} - -.variablelist dl dt { - margin-top: 0.5em; -} - -.glossary dl dd, -.variablelist dl dd { - margin-top: -1em; - margin-left: 25.5em; -} - -.glossary dd p, -.variablelist dd p { - margin-top: 0em; - margin-bottom: 1em; -} - - -div.calloutlist table td { - padding: 0em 0em 0em 0em; - margin: 0em 0em 0em 0em; -} - -div.calloutlist table td p { - margin-top: 0em; - margin-bottom: 1em; -} - -div p.copyright { - text-align: left; -} - -div.legalnotice p.legalnotice-title { - margin-bottom: 0em; -} - -p { - line-height: 1.5em; - margin-top: 0em; - -} - -dl { - padding-top: 0em; -} - -hr { - border: solid 1px; -} - - -.mediaobject, -.mediaobjectco { - text-align: center; -} - -img { - border: none; -} - -ul { - padding: 0em 0em 0em 1.5em; -} - -ul li { - padding: 0em 0em 0em 0em; -} - -ul li p { - text-align: left; -} - -table { - width :100%; -} - -th { - padding: 0.25em; - text-align: left; - font-weight: normal; - vertical-align: top; -} - -td { - padding: 0.25em; - vertical-align: top; -} - -p a[id] { - margin: 0px; - padding: 0px; - display: inline; - background-image: none; -} - -a { - text-decoration: underline; - color: #444; -} - -pre { - overflow: auto; -} - -a:hover { - text-decoration: underline; - /*font-weight: bold;*/ -} - - -div.informalfigure, -div.informalexample, -div.informaltable, -div.figure, -div.table, -div.example { - margin: 1em 0em; - padding: 1em; - page-break-inside: avoid; -} - - -div.informalfigure p.title b, -div.informalexample p.title b, -div.informaltable p.title b, -div.figure p.title b, -div.example p.title b, -div.table p.title b{ - padding-top: 0em; - margin-top: 0em; - font-size: 100%; - font-weight: normal; -} - -.mediaobject .caption, -.mediaobject .caption p { - text-align: center; - font-size: 80%; - padding-top: 0.5em; - padding-bottom: 0.5em; -} - -.epigraph { - padding-left: 55%; - margin-bottom: 1em; -} - -.epigraph p { - text-align: left; -} - -.epigraph .quote { - font-style: italic; -} -.epigraph .attribution { - font-style: normal; - text-align: right; -} - -span.application { - font-style: italic; -} - -.programlisting { - font-family: monospace; - font-size: 80%; - white-space: pre; - margin: 1.33em 0em; - padding: 1.33em; -} - -.tip, -.warning, -.caution, -.note { - margin-top: 1em; - margin-bottom: 1em; - -} - -/* force full width of table within div */ -.tip table, -.warning table, -.caution table, -.note table { - border: none; - width: 100%; -} - - -.tip table th, -.warning table th, -.caution table th, -.note table th { - padding: 0.8em 0.0em 0.0em 0.0em; - margin : 0em 0em 0em 0em; -} - -.tip p, -.warning p, -.caution p, -.note p { - margin-top: 0.5em; - margin-bottom: 0.5em; - padding-right: 1em; - text-align: left; -} - -.acronym { - text-transform: uppercase; -} - -b.keycap, -.keycap { - padding: 0.09em 0.3em; - margin: 0em; -} - -.itemizedlist li { - clear: none; -} - -.filename { - font-size: medium; - font-family: Courier, monospace; -} - - -div.navheader, div.heading{ - position: absolute; - left: 0em; - top: 0em; - width: 100%; - background-color: #cdf; - width: 100%; -} - -div.navfooter, div.footing{ - position: fixed; - left: 0em; - bottom: 0em; - background-color: #eee; - width: 100%; -} - - -div.navheader td, -div.navfooter td { - font-size: 66%; -} - -div.navheader table th { - /*font-family: Georgia, Times, serif;*/ - /*font-size: x-large;*/ - font-size: 80%; -} - -div.navheader table { - border-left: 0em; - border-right: 0em; - border-top: 0em; - width: 100%; -} - -div.navfooter table { - border-left: 0em; - border-right: 0em; - border-bottom: 0em; - width: 100%; -} - -div.navheader table td a, -div.navfooter table td a { - color: #777; - text-decoration: none; -} - -/* normal text in the footer */ -div.navfooter table td { - color: black; -} - -div.navheader table td a:visited, -div.navfooter table td a:visited { - color: #444; -} - - -/* links in header and footer */ -div.navheader table td a:hover, -div.navfooter table td a:hover { - text-decoration: underline; - background-color: transparent; - color: #33a; -} - -div.navheader hr, -div.navfooter hr { - display: none; -} - - -.qandaset tr.question td p { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; -} - -.qandaset tr.answer td p { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; -} -.answer td { - padding-bottom: 1.5em; -} - -.emphasis { - font-weight: bold; -} - - - /************* / - / decorations / -/ *************/ - -.titlepage { -} - -.part .title { -} - -.subtitle { - border: none; -} - -/* -h1 { - border: none; -} - -h2 { - border-top: solid 0.2em; - border-bottom: solid 0.06em; -} - -h3 { - border-top: 0em; - border-bottom: solid 0.06em; -} - -h4 { - border: 0em; - border-bottom: solid 0.06em; -} - -h5 { - border: 0em; -} -*/ - -.programlisting { - border: solid 1px; -} - -div.figure, -div.table, -div.informalfigure, -div.informaltable, -div.informalexample, -div.example { - border: 1px solid; -} - - - -.tip, -.warning, -.caution, -.note { - border: 1px solid; -} - -.tip table th, -.warning table th, -.caution table th, -.note table th { - border-bottom: 1px solid; -} - -.question td { - border-top: 1px solid black; -} - -.answer { -} - - -b.keycap, -.keycap { - border: 1px solid; -} - - -div.navheader, div.heading{ - border-bottom: 1px solid; -} - - -div.navfooter, div.footing{ - border-top: 1px solid; -} - - /********* / - / colors / -/ *********/ - -body { - color: #333; - background: white; -} - -a { - background: transparent; -} - -a:hover { - background-color: #dedede; -} - - -h1, -h2, -h3, -h4, -h5, -h6, -h7, -h8 { - background-color: transparent; -} - -hr { - border-color: #aaa; -} - - -.tip, .warning, .caution, .note { - border-color: #aaa; -} - - -.tip table th, -.warning table th, -.caution table th, -.note table th { - border-bottom-color: #aaa; -} - - -.warning { - background-color: #fea; -} - -.caution { - background-color: #fea; -} - -.tip { - background-color: #eff; -} - -.note { - background-color: #dfc; -} - -.glossary dl dt, -.variablelist dl dt, -.variablelist dl dt span.term { - color: #044; -} - -div.figure, -div.table, -div.example, -div.informalfigure, -div.informaltable, -div.informalexample { - border-color: #aaa; -} - -pre.programlisting { - color: black; - background-color: #fff; - border-color: #aaa; - border-width: 2px; -} - -.guimenu, -.guilabel, -.guimenuitem { - background-color: #eee; -} - - -b.keycap, -.keycap { - background-color: #eee; - border-color: #999; -} - - -div.navheader { - border-color: black; -} - - -div.navfooter { - border-color: black; -} - - - /*********** / - / graphics / -/ ***********/ - -/* -body { - background-image: url("images/body_bg.jpg"); - background-attachment: fixed; -} - -.navheader, -.note, -.tip { - background-image: url("images/note_bg.jpg"); - background-attachment: fixed; -} - -.warning, -.caution { - background-image: url("images/warning_bg.jpg"); - background-attachment: fixed; -} - -.figure, -.informalfigure, -.example, -.informalexample, -.table, -.informaltable { - background-image: url("images/figure_bg.jpg"); - background-attachment: fixed; -} - -*/ -h1, -h2, -h3, -h4, -h5, -h6, -h7{ -} - -div.preface .titlepage .title, -div.colophon .title, -div.chapter .titlepage .title { - background-image: url("images/title-bg.png"); - background-position: bottom; - background-repeat: repeat-x; -} - -div.section div.section .titlepage .title, -div.sect2 .titlepage .title { - background: none; -} - - -h1.title { - background-color: transparent; - background-image: url("poky-ref-manual.png"); - background-repeat: no-repeat; - height: 256px; - text-indent: -9000px; - overflow:hidden; -} - -h2.subtitle { - background-color: transparent; - text-indent: -9000px; - overflow:hidden; - width: 0px; - display: none; -} - - /*************************************** / - / pippin.gimp.org specific alterations / -/ ***************************************/ - -/* -div.heading, div.navheader { - color: #777; - font-size: 80%; - padding: 0; - margin: 0; - text-align: left; - position: absolute; - top: 0px; - left: 0px; - width: 100%; - height: 50px; - background: url('/gfx/heading_bg.png') transparent; - background-repeat: repeat-x; - background-attachment: fixed; - border: none; -} - -div.heading a { - color: #444; -} - -div.footing, div.navfooter { - border: none; - color: #ddd; - font-size: 80%; - text-align:right; - - width: 100%; - padding-top: 10px; - position: absolute; - bottom: 0px; - left: 0px; - - background: url('/gfx/footing_bg.png') transparent; -} -*/ - - - - /****************** / - / nasty ie tweaks / -/ ******************/ - -/* -div.heading, div.navheader { - width:expression(document.body.clientWidth + "px"); -} - -div.footing, div.navfooter { - width:expression(document.body.clientWidth + "px"); - margin-left:expression("-5em"); -} -body { - padding:expression("4em 5em 0em 5em"); -} -*/ - - /**************************************** / - / mozilla vendor specific css extensions / -/ ****************************************/ -/* -div.navfooter, div.footing{ - -moz-opacity: 0.8em; -} - -div.figure, -div.table, -div.informalfigure, -div.informaltable, -div.informalexample, -div.example, -.tip, -.warning, -.caution, -.note { - -moz-border-radius: 0.5em; -} - -b.keycap, -.keycap { - -moz-border-radius: 0.3em; -} -*/ - -table tr td table tr td { - display: none; -} - - -hr { - display: none; -} - -table { - border: 0em; -} - - .photo { - float: right; - margin-left: 1.5em; - margin-bottom: 1.5em; - margin-top: 0em; - max-width: 17em; - border: 1px solid gray; - padding: 3px; - background: white; -} - .seperator { - padding-top: 2em; - clear: both; - } - - #validators { - margin-top: 5em; - text-align: right; - color: #777; - } - @media print { - body { - font-size: 8pt; - } - .noprint { - display: none; - } - } - - -.tip, -.note { - background: #666666; - color: #fff; - padding: 20px; - margin: 20px; -} - -.tip h3, -.note h3 { - padding: 0em; - margin: 0em; - font-size: 2em; - font-weight: bold; - color: #fff; -} - -.tip a, -.note a { - color: #fff; - text-decoration: underline; -} -- cgit v1.2.3