web/html/participate/developers-guide sn-cvs-config.php, NONE, 1.1 sn-cvs-cvscommands.php, NONE, 1.1 sn-cvs-preparation.php, NONE, 1.1 ch-console-access.php, 1.1.1.1, 1.2 ch-cvs.php, 1.1.1.1, 1.2 ch-guidelines.php, 1.1.1.1, 1.2 ch-menus.php, 1.1.1.1, 1.2 ch-package-versions.php, 1.1.1.1, 1.2 ch-rpm-building.php, 1.1.1.1, 1.2 ch-ui-guidelines.php, 1.1.1.1, 1.2 index.php, 1.1.1.1, 1.2 ln-legalnotice.php, 1.1.1.1, 1.2 s1-rpm-guidelines.php, 1.1.1.1, 1.2 s1-rpm-more-guidelines.php, 1.1.1.1, 1.2 s1-ui-get-details.php, 1.1.1.1, 1.2 s1-ui-get-religion.php, 1.1.1.1, 1.2 s1-ui-gnome-guidelines.php, 1.1.1.1, 1.2 s1-ui-more-suggestions.php, 1.1.1.1, 1.2 s1-ui-scaling.php, 1.1.1.1, 1.2
Paul W. Frields (pfrields)
fedora-extras-commits at redhat.com
Thu Sep 29 17:08:36 UTC 2005
Author: pfrields
Update of /cvs/fedora/web/html/participate/developers-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv16475
Modified Files:
ch-console-access.php ch-cvs.php ch-guidelines.php
ch-menus.php ch-package-versions.php ch-rpm-building.php
ch-ui-guidelines.php index.php ln-legalnotice.php
s1-rpm-guidelines.php s1-rpm-more-guidelines.php
s1-ui-get-details.php s1-ui-get-religion.php
s1-ui-gnome-guidelines.php s1-ui-more-suggestions.php
s1-ui-scaling.php
Added Files:
sn-cvs-config.php sn-cvs-cvscommands.php
sn-cvs-preparation.php
Log Message:
Update to UTF-8, adding new CVS sections
***** Error reading new file: [Errno 2] No such file or directory: 'sn-cvs-config.php'
***** Error reading new file: [Errno 2] No such file or directory: 'sn-cvs-cvscommands.php'
***** Error reading new file: [Errno 2] No such file or directory: 'sn-cvs-preparation.php'
Index: ch-console-access.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/ch-console-access.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- ch-console-access.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ ch-console-access.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,29 +7,29 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 6. Enabling Console Access</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-ui-scaling.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch-menus.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-console-access"></a>Chapter 6. Enabling Console Access</h2></div></div><div></div></div><p>
- Some applications, such as <b class="application">Log Viewer</b> and other
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 6. Enabling Console Access</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-ui-scaling.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch-menus.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-console-access"></a>Chapter 6. Enabling Console Access</h2></div></div></div><p>
+ Some applications, such as <span><strong class="application">Log Viewer</strong></span> and other
applications in the Configuration Tools Project need root privileges to
run. To prompt the user for the root password, configure the correct PAM
- files to use <tt class="command">consolehelper</tt>. This example uses the
- program <tt class="command">redhat-logviewer</tt> as an example. Replace it with
+ files to use <code class="command">consolehelper</code>. This example uses the
+ program <code class="command">redhat-logviewer</code> as an example. Replace it with
the name of your program.
- </p><div class="orderedlist"><ol type="1"><li><p>At a shell prompt, change to the <tt class="filename">/usr/bin/</tt>
+ </p><div class="orderedlist"><ol type="1"><li><p>At a shell prompt, change to the <code class="filename">/usr/bin/</code>
directory, and make a symbolic link from the name of the application
- to <tt class="command">/usr/bin/consolehelper</tt>. For example:</p><pre class="screen">
-<tt class="command">ln -s consolehelper redhat-logviewer</tt>
+ to <code class="command">/usr/bin/consolehelper</code>. For example:</p><pre class="screen">
+<code class="command">ln -s consolehelper redhat-logviewer</code>
</pre></li><li><p>As root, create the file
- <tt class="filename">/etc/security/console.apps/<i class="replaceable"><tt>app-name</tt></i></tt>,
+ <code class="filename">/etc/security/console.apps/<em class="replaceable"><code>app-name</code></em></code>,
such as
- <tt class="filename">/etc/security/console.apps/<i class="replaceable"><tt>redhat-logviewer</tt></i></tt>,
+ <code class="filename">/etc/security/console.apps/<em class="replaceable"><code>redhat-logviewer</code></em></code>,
with the following lines:</p><pre class="screen">
-<tt class="computeroutput">USER=root
+<code class="computeroutput">USER=root
PROGRAM=/usr/share/redhat-logviewer/redhat-logviewer.py
-SESSION=true</tt>
+SESSION=true</code>
</pre></li><li><p>Create the PAM configuration file
- <tt class="filename">/etc/pam.d/redhat-logviewer</tt> with the following
+ <code class="filename">/etc/pam.d/redhat-logviewer</code> with the following
lines:</p><pre class="screen">
-<tt class="computeroutput">#%PAM-1.0
+<code class="computeroutput">#%PAM-1.0
auth sufficient /lib/security/pam_rootok.so
auth sufficient /lib/security/pam_timestamp.so
auth required /lib/security/pam_stack.so service=system-auth
@@ -37,40 +37,40 @@
session optional /lib/security/pam_xauth.so
session optional /lib/security/pam_timestamp.so
account required /lib/security/pam_permit.so
-</tt></pre></li></ol></div><p>
- When a user executes the command <tt class="filename">redhat-logviewer</tt>, it
- calls <tt class="command">consolehelper</tt>, which in turn calls
- <tt class="command">userhelper</tt> to authenticate the user with PAM. If the
+</code></pre></li></ol></div><p>
+ When a user executes the command <code class="filename">redhat-logviewer</code>, it
+ calls <code class="command">consolehelper</code>, which in turn calls
+ <code class="command">userhelper</code> to authenticate the user with PAM. If the
user enters the correct root password, the user is authenticated, and
authentication is remember for the user on the same tty for five minutes.
</p><p>
When using Make to install the package and when configuring the files to
build the RPM package, to make sure these files are installed in the
correct location, create the
- <tt class="filename">/etc/security/console.apps/redhat-logviewer</tt> file as
- <tt class="filename">redhat-logviewer.console</tt> and the
- <tt class="filename">/etc/pam.d/redhat-logviewer</tt> file as
- <tt class="filename">redhat-logviewer.pam</tt>. In the
- <tt class="filename">Makefile</tt>, add the following variables declarations:
+ <code class="filename">/etc/security/console.apps/redhat-logviewer</code> file as
+ <code class="filename">redhat-logviewer.console</code> and the
+ <code class="filename">/etc/pam.d/redhat-logviewer</code> file as
+ <code class="filename">redhat-logviewer.pam</code>. In the
+ <code class="filename">Makefile</code>, add the following variables declarations:
</p><pre class="screen">
-<tt class="computeroutput">PAMD_DIR = /etc/pam.d
+<code class="computeroutput">PAMD_DIR = /etc/pam.d
SECURITY_DIR = /etc/security/console.apps
-PKGNAME = redhat-logviewer</tt>
+PKGNAME = redhat-logviewer</code>
</pre><p>
- In the <tt class="computeroutput">install</tt> section of the
- <tt class="filename">Makefile</tt>, add the following lines:
+ In the <code class="computeroutput">install</code> section of the
+ <code class="filename">Makefile</code>, add the following lines:
</p><pre class="screen">
-<tt class="computeroutput">install ${PKGNAME}.pam $(INSTROOT)$(PAMD_DIR)/${PKGNAME}
-install ${PKGNAME}.console $(INSTROOT)$(SECURITY_DIR)/${PKGNAME}</tt>
+<code class="computeroutput">install ${PKGNAME}.pam $(INSTROOT)$(PAMD_DIR)/${PKGNAME}
+install ${PKGNAME}.console $(INSTROOT)$(SECURITY_DIR)/${PKGNAME}</code>
</pre><p>
- Finally, in the <tt class="filename">redhat-logviewer.spec</tt> file, add the
- following lines under the <tt class="computeroutput">%files</tt> section
+ Finally, in the <code class="filename">redhat-logviewer.spec</code> file, add the
+ following lines under the <code class="computeroutput">%files</code> section
so that the files are installed with the RPM and are in the file list for
the package:
</p><pre class="screen">
-<tt class="computeroutput">%attr(0644,root,root) %config(noreplace) /etc/security/console.apps/%{name}
-%attr(0644,root,root) %config(noreplace) /etc/pam.d/%{name}</tt>
-</pre></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-ui-scaling.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="index.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch-menus.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.6. Scaling It Down </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> Chapter 7. Adding Applications to the Menus</td></tr></table></div>
+<code class="computeroutput">%attr(0644,root,root) %config(noreplace) /etc/security/console.apps/%{name}
+%attr(0644,root,root) %config(noreplace) /etc/pam.d/%{name}</code>
+</pre></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-ui-scaling.php">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch-menus.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.6. Scaling It Down </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> Chapter 7. Adding Applications to the Menus</td></tr></table></div>
<?
Index: ch-cvs.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/ch-cvs.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- ch-cvs.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ ch-cvs.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,47 +7,64 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 3. CVS</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch-package-versions.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="s1-cvs-configure.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-cvs"></a>Chapter 3. CVS</h2></div></div><div></div></div><p>
- CVS, or Concurrent Versions System, provides a framework for multiple
- users to edit the same files. As you can imagine, if a group of users
- edits the files in a single directory, chaos would reign. Using CVS,
- however, a group of people can safely work on the same set of files. CVS
- keeps the master copy of the files, and it records who changed what and
- when in a central repository. If conflicts arise, CVS lets you know. CVS
- is usually used so that programmers can share code, but it also works well
- for documentation.
- </p><a class="indexterm" name="id2819681"></a><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-cvs-overview"></a>3.1. How CVS Works</h2></div></div><div></div></div><a class="indexterm" name="id2819704"></a><a class="indexterm" name="id2819718"></a><p>
- In most cases, each set of files that make up a package or project is
- stored as a <i class="firstterm">module</i> on the CVS server.
- </p><p>
- When working with files from CVS, you <i class="firstterm">checkout</i> a
- copy of the module on your local file system. After modifying one or
- more files, you <i class="firstterm">commit</i> them back to the central
- CVS repository server.
- </p><p>
- When you commit changes, only changes to files the server knows about
- are committed. In other words, if you created a file in your local
- checkout of a module, the new file is not automatically uploaded to the
- server. You must <i class="firstterm">add</i> the file to the repository
- and then commit it. If you remove a file from your local checkout of a
- module, you must specify that you want to remove it from the repository
- on the CVS server and then commit the removal of the file.
- </p><p>
- The specific commands to perform these actions are discussed in <a href="s1-cvs-cvscommands.php" title="3.3. Basic CVS Commands">Section 3.3, “Basic CVS Commands”</a>.
- </p><p>
- If someone has modified the file between the last time you grabbed the
- file from CVS and when you try to commit a change, it tried to merge the
- changes into the master copy of the CVS server. If the content you
- changed is in a different location in the file than the content changed
- by someone else, chances are, the commit action will go through without
- a <i class="firstterm">conflict</i>. If someone modified the same content
- as the content you just changed and tried to commit, you will see a
- message that a file conflict has occurred. Thus, you need to
- <i class="firstterm">update</i> your files frequently. It is a good
- practice to update them right before you start modifying a file. Refer
- to <a href="s1-cvs-cvscommands.php#s2-cvs-cvscommands-conflicts" title="3.3.7. Resolving Conflicts">Section 3.3.7, “Resolving Conflicts”</a> for instructions
- on resolving conflicts.
- </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch-package-versions.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="index.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-cvs-configure.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 2. Package Versions </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 3.2. Configuring CVS on Your System</td></tr></table></div>
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 3. CVS</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch-package-versions.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="sn-cvs-preparation.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-cvs"></a>Chapter 3. CVS</h2></div></div></div><p>
+ The Concurrent Versions System (<span><strong class="application">CVS</strong></span>)
+ provides a framework where multiple users can edit the same files.
+ As you can imagine, if a group of users edits the files in a single
+ directory, chaos would reign. Using <span><strong class="application">CVS</strong></span>,
+ however, a group of people can safely work on the same set of files.
+ <span><strong class="application">CVS</strong></span> keeps the master copy of the files,
+ and it records who changed what and when in a central repository. If
+ conflicts arise, <span><strong class="application">CVS</strong></span> lets you know.
+ <span><strong class="application">CVS</strong></span> is often used so that programmers can
+ share code, but it also works well for documentation.
+ </p><a class="indexterm" name="id2831081"></a><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sn-cvs-overview"></a>3.1. How CVS Works</h2></div></div></div><a class="indexterm" name="id2831099"></a><a class="indexterm" name="id2832576"></a><p>
+ In most cases, each set of files that make up a package or project
+ is stored as a <em class="firstterm">module</em> on the CVS server.
+ </p><p>
+ When working with files from <span><strong class="application">CVS</strong></span>, you
+ <em class="firstterm">checkout</em> a copy of the module on your local
+ file system. After modifying one or more files, you
+ <em class="firstterm">commit</em> them back to the central
+ <span><strong class="application">CVS</strong></span> repository server.
+ </p><p>
+ With <span><strong class="application">CVS</strong></span> you may edit a file without
+ first getting permission or locking the file. The
+ <em class="wordasword">concurrent</em> part of the
+ <span><strong class="application">CVS</strong></span> name comes from its ability to
+ allow several different people to edit different parts of the same
+ file. As long as none of the changes overlap,
+ <span><strong class="application">CVS</strong></span> can correctly record their changes.
+ In case of duplicate changes, they are clearly marked in the files
+ and the authors must resolve the issue among themselves.
+ </p><p>
+ When you commit changes, only changes to files the server knows
+ about are committed. In other words, if you created a file in your
+ local checkout of a module, the new file is not automatically
+ uploaded to the server. You must <em class="firstterm">add</em> the
+ file to the repository and then commit it. If you remove a file
+ from your local checkout of a module, you must specify that you
+ want to remove it from the repository on the CVS server and then
+ commit the removal of the file.
+ </p><p>
+ The specific commands to perform these actions are discussed in
+ <a href="sn-cvs-cvscommands.php" title="3.4. Basic CVS Commands">Section 3.4, “Basic CVS Commands”</a>.
+ </p><p>
+ If someone has modified the file between the last time you grabbed
+ the file from CVS and when you try to commit a change,
+ <span><strong class="application">CVS</strong></span> will try to merge the changes into
+ the master copy of the <span><strong class="application">CVS</strong></span> server. If
+ the content you changed is in a different location in the file
+ than the content changed by someone else, chances are, the commit
+ action will go through without a <em class="firstterm">conflict</em>.
+ If someone modified the same content as the content you just
+ changed and tried to commit, you will see a message that a file
+ conflict has occurred. Thus, you need to
+ <em class="firstterm">update</em> your files frequently. It is a good
+ practice to update them right before you start modifying a file.
+ Refer to <a href="sn-cvs-cvscommands.php#sn-cvs-cvscommands-conflicts" title="3.4.8. Resolving Conflicts">Section 3.4.8, “Resolving Conflicts”</a> for
+ instructions on resolving conflicts.
+ </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch-package-versions.php">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="sn-cvs-preparation.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 2. Package Versions </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 3.2. Preparing For CVS Use</td></tr></table></div>
<?
Index: ch-guidelines.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/ch-guidelines.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- ch-guidelines.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ ch-guidelines.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,12 +7,12 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 1. General Guidelines</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="index.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch-package-versions.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-guidelines"></a>Chapter 1. General Guidelines</h2></div></div><div></div></div><p>
- Developers for the Fedora project must adhere to the following rules:
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 1. General Guidelines</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="index.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch-package-versions.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-guidelines"></a>Chapter 1. General Guidelines</h2></div></div></div><p>
+ Developers for the Fedora Project must adhere to the following rules:
</p><div class="orderedlist"><ol type="1"><li><p>If you are not the owner of a package, email the owner before
making any changes.</p></li><li><p>Never rebuild a package with the exact same
name-epoch-version-release number. Mnemonic: <span class="emphasis"><em>Never say
- n-e-v-r again</em></span>. </p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="index.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="index.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch-package-versions.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Fedora Project Developer's Guide </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> Chapter 2. Package Versions</td></tr></table></div>
+ n-e-v-r again</em></span>. </p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="index.php">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch-package-versions.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Fedora Core Developer's Guide </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> Chapter 2. Package Versions</td></tr></table></div>
<?
Index: ch-menus.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/ch-menus.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- ch-menus.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ ch-menus.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,16 +7,16 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 7. Adding Applications to the Menus</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch-console-access.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> </td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-menus"></a>Chapter 7. Adding Applications to the Menus</h2></div></div><div></div></div><p>
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 7. Adding Applications to the Menus</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch-console-access.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> </td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-menus"></a>Chapter 7. Adding Applications to the Menus</h2></div></div></div><p>
If you want users to be able to find your application, you need to add it
- to the <b class="guimenu">Main Menu</b>. The <b class="guimenu">Main Menu</b> in
+ to the <span><strong class="guimenu">Main Menu</strong></span>. The <span><strong class="guimenu">Main Menu</strong></span> in
GNOME and KDE are generated from the same desktop files so that they have
the same menus. This feature is useful because only one desktop file needs
to be installed. The desktop file must be installed in the
- <tt class="filename">/usr/share/applications/</tt> directory, must have a
+ <code class="filename">/usr/share/applications/</code> directory, must have a
specific format, and must be in UTF-8 format. For example:
</p><pre class="screen">
-<tt class="computeroutput">[Desktop Entry]
+<code class="computeroutput">[Desktop Entry]
Name=System Logs
Name[it]=Log di sistema
Comment=Examine system log files
@@ -27,100 +27,100 @@
Type=Application
Terminal=false
Encoding=UTF-8
-</tt>
+</code>
</pre><p>
This example does not show all translations of the name and comment, but
you can see the format of the file and translations from it. The
- <tt class="computeroutput">Categories</tt> field specifies which menu
+ <code class="computeroutput">Categories</code> field specifies which menu
group the application should appear under. In this example, the entry is
- under <b class="guilabel">System Tools</b>.
+ under <span><strong class="guilabel">System Tools</strong></span>.
</p><p>
The file should follow the specification outlined at <a href="http://www.freedesktop.org/standards/desktop-entry-spec/" target="_top">http://www.freedesktop.org/standards/desktop-entry-spec/</a>. The
- <tt class="computeroutput">Categories</tt> field is used as described
+ <code class="computeroutput">Categories</code> field is used as described
in the specification at <a href="http://www.freedesktop.org/standards/menu-spec/" target="_top">http://www.freedesktop.org/standards/menu-spec/</a>,
though Fedora Core doesn't yet use the XML format described in that spec.
</p><p>
If you are not sure your desktop file is written correctly,
- install the <tt class="filename">desktop-file-utils</tt> package. This
+ install the <code class="filename">desktop-file-utils</code> package. This
package contains the command
- <tt class="command">desktop-file-validate</tt>. To use it, execute the command
+ <code class="command">desktop-file-validate</code>. To use it, execute the command
followed by the location of your desktop file. If the file contains all
the required fields, the command will return nothing; otherwise, it will
return an error message. For example, the following error message is
displayed if the Encoding field is missing:
</p><pre class="screen">
-<tt class="computeroutput">Error, file /tmp/redhat-logviewer.desktop does not contain the "Encoding"
+<code class="computeroutput">Error, file /tmp/redhat-logviewer.desktop does not contain the "Encoding"
key. This is a required field for all desktop files.
-</tt></pre><p>
+</code></pre><p>
Save the file as
- <tt class="filename"><i class="replaceable"><tt>application-name</tt></i>.desktop</tt>,
- such as <tt class="filename">redhat-logviewer.desktop</tt>, and the following
- to the spec file under the <tt class="computeroutput">%files</tt>
+ <code class="filename"><em class="replaceable"><code>application-name</code></em>.desktop</code>,
+ such as <code class="filename">redhat-logviewer.desktop</code>, and the following
+ to the spec file under the <code class="computeroutput">%files</code>
section:
</p><pre class="screen">
-<tt class="computeroutput">%attr(0644,root,root) %{_datadir}/applications/%{name}.desktop</tt>
+<code class="computeroutput">%attr(0644,root,root) %{_datadir}/applications/%{name}.desktop</code>
</pre><p>
Also add the following line to the install section of the
- <tt class="filename">Makefile</tt> to to make sure it is installed in the
+ <code class="filename">Makefile</code> to to make sure it is installed in the
correct place:
</p><pre class="screen">
-<tt class="computeroutput">install ${PKGNAME}.desktop $(INSTROOT)/usr/share/applications/${PKGNAME}.desktop</tt>
+<code class="computeroutput">install ${PKGNAME}.desktop $(INSTROOT)/usr/share/applications/${PKGNAME}.desktop</code>
</pre><p>
- If an upstream package already comes with a <tt class="filename">.desktop</tt>
- file that installs to <tt class="filename">/usr/share/applications/</tt>, you
+ If an upstream package already comes with a <code class="filename">.desktop</code>
+ file that installs to <code class="filename">/usr/share/applications/</code>, you
may not need to do anything (especially because Fedora Core uses mostly the
same menu layout as upstream GNOME). However, if you need to modify the
- upstream <tt class="filename">.desktop</tt> file, the
- <tt class="filename">desktop-file-utils</tt> package contains a tool called
- <tt class="command">desktop-file-install</tt>. This tool can be used in the
- <tt class="computeroutput">%install</tt> section of an RPM to munge the
- upstream <tt class="filename">.desktop</tt> file in various ways. Here is an example from
- <tt class="filename">gnome-system-monitor</tt>:
+ upstream <code class="filename">.desktop</code> file, the
+ <code class="filename">desktop-file-utils</code> package contains a tool called
+ <code class="command">desktop-file-install</code>. This tool can be used in the
+ <code class="computeroutput">%install</code> section of an RPM to munge the
+ upstream <code class="filename">.desktop</code> file in various ways. Here is an example from
+ <code class="filename">gnome-system-monitor</code>:
</p><pre class="screen">
- <tt class="computeroutput">
+ <code class="computeroutput">
desktop-file-install --vendor gnome --delete-original \
--dir $RPM_BUILD_ROOT%{_datadir}/applications \
--add-category X-Red-Hat-Base \
$RPM_BUILD_ROOT%{_datadir}/applications/*
- </tt>
+ </code>
</pre><p>
In the above example, the following changes are made:
</p><div class="itemizedlist"><ul type="disc"><li><p>
- The <tt class="filename">.desktop</tt> file is renamed to have the vendor "gnome" prefixed
- to its filename. <tt class="filename">.desktop</tt> files should have a namespace prefix
+ The <code class="filename">.desktop</code> file is renamed to have the vendor "gnome" prefixed
+ to its filename. <code class="filename">.desktop</code> files should have a namespace prefix
to avoid collisions.
</p></li><li><p>
- The <tt class="command">--delete-original</tt> option
- means that in addition to creating a new <tt class="filename">.desktop</tt> file,
+ The <code class="command">--delete-original</code> option
+ means that in addition to creating a new <code class="filename">.desktop</code> file,
the original file is removed.
</p></li><li><p>
- The category <tt class="computeroutput">X-Red-Hat-Base</tt> is
- added to the <tt class="computeroutput">Categories</tt> field.
+ The category <code class="computeroutput">X-Red-Hat-Base</code> is
+ added to the <code class="computeroutput">Categories</code> field.
</p></li></ul></div><p>
In addition to letting you add/remove categories and so forth,
- <tt class="command">desktop-file-install</tt> will automatically validate the
- <tt class="filename">.desktop</tt> file.
- </p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-categories"></a>7.1. Red Hat Categories</h2></div></div><div></div></div><p>
+ <code class="command">desktop-file-install</code> will automatically validate the
+ <code class="filename">.desktop</code> file.
+ </p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-categories"></a>7.1. Red Hat Categories</h2></div></div></div><p>
There are two special categories,
- <tt class="computeroutput">X-Red-Hat-Base</tt> and
- <tt class="computeroutput">X-Red-Hat-Extra</tt>. These distinguish
+ <code class="computeroutput">X-Red-Hat-Base</code> and
+ <code class="computeroutput">X-Red-Hat-Extra</code>. These distinguish
between menu items that appear in the base menus, and those that appear
- in the "More Foo" menus. For example, the "Internet" and "More Internet
- Applications" menus. The rule is that only one application of a given
+ in the "More Foo" menus. For example, the "Internet" and "More Internet
+ Applications" menus. The rule is that only one application of a given
class of application may have the
- <tt class="computeroutput">X-Red-Hat-Base</tt> category. For example,
- <span class="emphasis"><em>one</em></span> and only one web browser may be in "Internet",
- other web browsers must be in "More Internet Applications." As a
- secondary rule, "geeky" or obscure applications may always be in the
- <tt class="computeroutput">X-Red-Hat-Extra</tt> category. Essentially,
- the <tt class="computeroutput">X-Red-Hat-Base</tt> should be reserved
+ <code class="computeroutput">X-Red-Hat-Base</code> category. For example,
+ <span class="emphasis"><em>one</em></span> and only one web browser may be in "Internet",
+ other web browsers must be in "More Internet Applications." As a
+ secondary rule, "geeky" or obscure applications may always be in the
+ <code class="computeroutput">X-Red-Hat-Extra</code> category. Essentially,
+ the <code class="computeroutput">X-Red-Hat-Base</code> should be reserved
for a nice set of default applications for nontechnical end users.
</p><p>
- The best guideline: use <tt class="computeroutput">X-Red-Hat-Extra</tt>
+ The best guideline: use <code class="computeroutput">X-Red-Hat-Extra</code>
by default, and if you want to use
- <tt class="computeroutput">X-Red-Hat-Base</tt>, make your case on
- <tt class="email"><<a href="mailto:fedora-devel-list">fedora-devel-list</a>></tt>.
- </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch-console-access.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="index.php">Up</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">Chapter 6. Enabling Console Access </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div>
+ <code class="computeroutput">X-Red-Hat-Base</code>, make your case on
+ <code class="email"><<a href="mailto:fedora-devel-list">fedora-devel-list</a>></code>.
+ </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch-console-access.php">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">Chapter 6. Enabling Console Access </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div>
<?
Index: ch-package-versions.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/ch-package-versions.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- ch-package-versions.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ ch-package-versions.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,18 +7,18 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 2. Package Versions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch-guidelines.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch-cvs.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-package-versions"></a>Chapter 2. Package Versions</h2></div></div><div></div></div><p>
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 2. Package Versions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch-guidelines.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch-cvs.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-package-versions"></a>Chapter 2. Package Versions</h2></div></div></div><p>
The following rules apply:
</p><div class="orderedlist"><ol type="1"><li><p>Stable releases are allowed until the feature freeze date.</p></li><li><p>Stable snapshots are generally OK, but there has to be a good
reason why you want to use the stable snapshot instead of the stable
release plus patches. This is generally more acceptable for larger,
- well-maintained projects such as <tt class="filename">gcc</tt>,
- <tt class="filename">gdb</tt>).</p></li><li><p>Alpha releases are usually not OK. Obviously, there are some
+ well-maintained projects such as <code class="filename">gcc</code>,
+ <code class="filename">gdb</code>).</p></li><li><p>Alpha releases are usually not OK. Obviously, there are some
packages whose upstream maintainers have never changed their
- versions from <tt class="computeroutput">-alpha</tt>. Basically,
+ versions from <code class="computeroutput">-alpha</code>. Basically,
this guideline applies when there is a previous stable version
available.
- </p></li><li><p>Beta releases are generally not OK. Refer to <a href="ch-package-versions.php#s1-beta-exceptions" title="2.1. Beta Exceptions">Section 2.1, “Beta Exceptions”</a>.</p></li><li><p>Development/beta snapshots are generally not OK.</p></li></ol></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-beta-exceptions"></a>2.1. Beta Exceptions</h2></div></div><div></div></div><p>
+ </p></li><li><p>Beta releases are generally not OK. Refer to <a href="ch-package-versions.php#s1-beta-exceptions" title="2.1. Beta Exceptions">Section 2.1, “Beta Exceptions”</a>.</p></li><li><p>Development/beta snapshots are generally not OK.</p></li></ol></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-beta-exceptions"></a>2.1. Beta Exceptions</h2></div></div></div><p>
For large important packages with a maintained developer base, shipping
beta/pre-release versions is OK during a development cycle, provided all
of the following are met:
@@ -39,7 +39,7 @@
new things to our users not just because they are newer, but because
they provide either feature enhancements or better stability (bug
fixes).
- </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch-guidelines.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="index.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch-cvs.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 1. General Guidelines </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> Chapter 3. CVS</td></tr></table></div>
+ </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch-guidelines.php">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch-cvs.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 1. General Guidelines </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> Chapter 3. CVS</td></tr></table></div>
<?
Index: ch-rpm-building.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/ch-rpm-building.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- ch-rpm-building.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ ch-rpm-building.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,17 +7,17 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 4. Building RPM Packages</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-cvs-cvscommands.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="s1-rpm-guidelines.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-rpm-building"></a>Chapter 4. Building RPM Packages</h2></div></div><div></div></div><p>
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 4. Building RPM Packages</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="sn-cvs-cvscommands.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="s1-rpm-guidelines.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-rpm-building"></a>Chapter 4. Building RPM Packages</h2></div></div></div><p>
This chapter attempts to discuss how to build RPMs so that the package
- conforms to Fedora project standards. It does not attempt to explain everything
+ conforms to Fedora Project standards. It does not attempt to explain everything
there is to know about RPM or building RPMs.
</p><p>
- A good source for learning more about RPM is the <i class="citetitle">Red Hat RPM
- Guide</i> by Eric Foster-Johnson; Red Hat Press.
- </p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-rpm-spec-file"></a>4.1. Spec File</h2></div></div><div></div></div><p>
+ A good source for learning more about RPM is the <em class="citetitle">Red Hat RPM
+ Guide</em> by Eric Foster-Johnson; Red Hat Press.
+ </p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-rpm-spec-file"></a>4.1. Spec File</h2></div></div></div><p>
This section describes how the spec file should be written.
</p><pre class="screen">
-<tt class="computeroutput">Name: foo
+<code class="computeroutput">Name: foo
Summary: The foo package does foo
Version: 1.0
Release: 1
@@ -54,13 +54,13 @@
/sbin/ldconfig
%preun
-if [ "$1" = 0 ]; then
+if [ "$1" = 0 ]; then
/sbin/service foo stop > /dev/null 2>&1
/sbin/chkconfig --del foo
fi
%postun
-if [ "$1" -ge "1" ]; then
+if [ "$1" -ge "1" ]; then
/sbin/service foo condrestart > /dev/null 2>&1
/sbin/ldconfig
fi
@@ -75,42 +75,42 @@
%changelog
* Mon Jun 16 2003 Some One <one at example.com>
-— fixed the broken frobber (#86434)</tt>
-</pre><div class="variablelist"><dl><dt><span class="term"><tt class="computeroutput">Name</tt></span></dt><dd><p>The name of the package.</p></dd><dt><span class="term"><tt class="computeroutput">Summary</tt></span></dt><dd><p>A short summary of the purpose of the package, should not
+— fixed the broken frobber (#86434)</code>
+</pre><div class="variablelist"><dl><dt><span class="term"><code class="computeroutput">Name</code></span></dt><dd><p>The name of the package.</p></dd><dt><span class="term"><code class="computeroutput">Summary</code></span></dt><dd><p>A short summary of the purpose of the package, should not
include the name of the package in the summary as this is
- redundant information.</p></dd><dt><span class="term"><tt class="computeroutput">Version</tt></span></dt><dd><p>The version of the package. Should match the version of the
- (main) tarball of the source. If the "real" version has dashes in
- it, replace them with underscores.</p></dd><dt><span class="term"><tt class="computeroutput">Release</tt></span></dt><dd><p>This is the Fedora project release count for the package. Each time it
- is modified for the Fedora project (sent through the build system) this number
+ redundant information.</p></dd><dt><span class="term"><code class="computeroutput">Version</code></span></dt><dd><p>The version of the package. Should match the version of the
+ (main) tarball of the source. If the "real" version has dashes in
+ it, replace them with underscores.</p></dd><dt><span class="term"><code class="computeroutput">Release</code></span></dt><dd><p>This is the Fedora Project release count for the package. Each time it
+ is modified for the Fedora Project (sent through the build system) this number
must be incremented. <span class="emphasis"><em>NEVER</em></span> rebuild a package
without incrementing this number, as this gives a totally false
impression to the user — that the package has not changed at
all. Whenever a package is rebuilt, it changes, even if the source
- code was not updated.</p></dd><dt><span class="term"><tt class="computeroutput">License</tt></span></dt><dd><p>One of GPL, LGPL, BSD(-like), Artistic, etc. Most old packages
- erroneously call this the "Copyright" field. This is incorrect but
+ code was not updated.</p></dd><dt><span class="term"><code class="computeroutput">License</code></span></dt><dd><p>One of GPL, LGPL, BSD(-like), Artistic, etc. Most old packages
+ erroneously call this the "Copyright" field. This is incorrect but
the two are synonyms for each other. Fix old packages to have the
- correct tag if found.</p></dd><dt><span class="term"><tt class="computeroutput">Group</tt></span></dt><dd><p>This must be one of the canonical groups from the
- <tt class="filename">/usr/share/doc/rpm-<i class="replaceable"><tt><version></tt></i>/GROUPS</tt>
- file. Do <span class="emphasis"><em>not</em></span> make up group names.</p></dd><dt><span class="term"><tt class="computeroutput">URL</tt></span></dt><dd><p>The Web address for the package, if one exists.</p></dd><dt><span class="term"><tt class="computeroutput">Source</tt></span></dt><dd><p>Start numbering the sources at 0
- (<tt class="computeroutput">Source0</tt> ,
- <tt class="computeroutput">Source1</tt>, etc.). A tag of
- <tt class="computeroutput">Source</tt> is implicitly source
+ correct tag if found.</p></dd><dt><span class="term"><code class="computeroutput">Group</code></span></dt><dd><p>This must be one of the canonical groups from the
+ <code class="filename">/usr/share/doc/rpm-<em class="replaceable"><code><version></code></em>/GROUPS</code>
+ file. Do <span class="emphasis"><em>not</em></span> make up group names.</p></dd><dt><span class="term"><code class="computeroutput">URL</code></span></dt><dd><p>The Web address for the package, if one exists.</p></dd><dt><span class="term"><code class="computeroutput">Source</code></span></dt><dd><p>Start numbering the sources at 0
+ (<code class="computeroutput">Source0</code> ,
+ <code class="computeroutput">Source1</code>, etc.). A tag of
+ <code class="computeroutput">Source</code> is implicitly source
0. Include the full URL or path to the source package if
necessary. If a filename without a URL or path is given as the
- source, the file should be in the <tt class="filename">SOURCES</tt>
+ source, the file should be in the <code class="filename">SOURCES</code>
directory under your top level directory —
- <tt class="filename">/usr/src/redhat/SOURCES/</tt> by default or define
- the top level directory in your <tt class="filename">~/.rpmmacros</tt>
- file.</p><p>Use the special macros <tt class="computeroutput">%name</tt>
- and <tt class="computeroutput">%version</tt> where possible so
+ <code class="filename">/usr/src/redhat/SOURCES/</code> by default or define
+ the top level directory in your <code class="filename">~/.rpmmacros</code>
+ file.</p><p>Use the special macros <code class="computeroutput">%name</code>
+ and <code class="computeroutput">%version</code> where possible so
that updating these particular fields automatically update the
- source field.</p></dd><dt><span class="term"><tt class="computeroutput">Patch</tt></span></dt><dd><p>Start numbering patch files with 0
- (<tt class="computeroutput">Patch0</tt>,
- <tt class="computeroutput">Patch1</tt>, etc.). To make patches,
+ source field.</p></dd><dt><span class="term"><code class="computeroutput">Patch</code></span></dt><dd><p>Start numbering patch files with 0
+ (<code class="computeroutput">Patch0</code>,
+ <code class="computeroutput">Patch1</code>, etc.). To make patches,
name them in the format
- <i class="replaceable"><tt><name></tt></i>-<i class="replaceable"><tt><version></tt></i>-<i class="replaceable"><tt><whatisfixed></tt></i>.patch.
- Do not use the <tt class="computeroutput">%name</tt> and
- <tt class="computeroutput">%version</tt> macros here; chances are
+ <em class="replaceable"><code><name></code></em>-<em class="replaceable"><code><version></code></em>-<em class="replaceable"><code><whatisfixed></code></em>.patch.
+ Do not use the <code class="computeroutput">%name</code> and
+ <code class="computeroutput">%version</code> macros here; chances are
these patches may be needed even when you upgrade the package
source code after generating the initial patch, and it will
probably apply without modifications. If you use the macros, you
@@ -122,100 +122,100 @@
this will the tons of little changes we have to make in our own
packages be integrated upstream over time.</p><p>To create a patch, follow this process:</p><div class="orderedlist"><ol type="1"><li><p>Enter the directory where the source code for the package
is, and copy the original file to the same name as the file
- with the <i class="replaceable"><tt><whatisfixed></tt></i> string
+ with the <em class="replaceable"><code><whatisfixed></code></em> string
appended to it. For example, if the the old file was called
- <tt class="filename">sourcecode.c</tt>, copy it to
- <tt class="filename">sourcecode.c.iconfix</tt>.</p></li><li><p>Then, make your edits/changes/fixes to the file
- <tt class="filename">sourcecode.c</tt>.</p></li><li><p>Go into the directory one level above the sourcecode,
- usually the directory <tt class="filename">../BUILD</tt>. Use the
- <tt class="command">gendiff</tt> command from the
- <tt class="filename">rpm</tt> package to generate the patch
+ <code class="filename">sourcecode.c</code>, copy it to
+ <code class="filename">sourcecode.c.iconfix</code>.</p></li><li><p>Then, make your edits/changes/fixes to the file
+ <code class="filename">sourcecode.c</code>.</p></li><li><p>Go into the directory one level above the sourcecode,
+ usually the directory <code class="filename">../BUILD</code>. Use the
+ <code class="command">gendiff</code> command from the
+ <code class="filename">rpm</code> package to generate the patch
file:</p><pre class="screen">
-<tt class="command">gendiff <i class="replaceable"><tt><source-dir></tt></i> <i class="replaceable"><tt><fixed-extension></tt></i> > ../SOURCES/<i class="replaceable"><tt><source-dir></tt></i>-<i class="replaceable"><tt><fixed-extension></tt></i>.patch</tt>
+<code class="command">gendiff <em class="replaceable"><code><source-dir></code></em> <em class="replaceable"><code><fixed-extension></code></em> > ../SOURCES/<em class="replaceable"><code><source-dir></code></em>-<em class="replaceable"><code><fixed-extension></code></em>.patch</code>
</pre><p>For example, if the source code is in the directory
- <tt class="filename">program-1.0/</tt>, and the backup file was
- appended with the string <tt class="filename">iconfix</tt>, the
+ <code class="filename">program-1.0/</code>, and the backup file was
+ appended with the string <code class="filename">iconfix</code>, the
command would be as follows:
</p><pre class="screen">
-<tt class="command">gendiff sourcecode-1.0 .iconfix > ../SOURCES/sourcecode-1.0-iconfix.patch</tt>
-</pre></li></ol></div></dd><dt><span class="term"><tt class="computeroutput">Buildroot</tt></span></dt><dd><p>Make sure you use the special
- <tt class="computeroutput">%{_tmppath}</tt> macro. Do not
- hard code <tt class="filename">/tmp/</tt> or
- <tt class="filename">/var/tmp/</tt> because users or the build system
+<code class="command">gendiff sourcecode-1.0 .iconfix > ../SOURCES/sourcecode-1.0-iconfix.patch</code>
+</pre></li></ol></div></dd><dt><span class="term"><code class="computeroutput">Buildroot</code></span></dt><dd><p>Make sure you use the special
+ <code class="computeroutput">%{_tmppath}</code> macro. Do not
+ hard code <code class="filename">/tmp/</code> or
+ <code class="filename">/var/tmp/</code> because users or the build system
may have configured RPM to put temporary files elsewhere or may
declared a different location for temporary files. Use the name
and version macros so that two different versions of the package
- can be built at the same time without collisions.</p></dd><dt><span class="term"><tt class="computeroutput">Requires</tt></span></dt><dd><p>If your package requires other packages to be on the system at
+ can be built at the same time without collisions.</p></dd><dt><span class="term"><code class="computeroutput">Requires</code></span></dt><dd><p>If your package requires other packages to be on the system at
the time of installation, list them here. Include versions if
necessary (for example, somepackage >= 2.0). Multiple entries must
be separated by a space or a comma. Explicit file dependencies may
be listed rather than package dependencies by giving the full path
- (for example, <tt class="filename">/sbin/chkconfig</tt>).</p></dd><dt><span class="term"><tt class="computeroutput">Prereq</tt></span></dt><dd><p>Similar to <tt class="computeroutput">Requires</tt>, except
+ (for example, <code class="filename">/sbin/chkconfig</code>).</p></dd><dt><span class="term"><code class="computeroutput">Prereq</code></span></dt><dd><p>Similar to <code class="computeroutput">Requires</code>, except
that this tag lists packages or files that are required to be
present before the package is actually installed. Very important
if you are packaging something that needs to make use of other
- programs in <tt class="computeroutput">%pre</tt> or
- <tt class="computeroutput">%post</tt> sections.</p></dd><dt><span class="term"><tt class="computeroutput">BuildPrereq</tt></span></dt><dd><p>If your package needs other packages installed to build, list
+ programs in <code class="computeroutput">%pre</code> or
+ <code class="computeroutput">%post</code> sections.</p></dd><dt><span class="term"><code class="computeroutput">BuildPrereq</code></span></dt><dd><p>If your package needs other packages installed to build, list
them after this tag. Examples include
- <tt class="filename">gtk2-devel</tt> and
- <tt class="filename">db3-devel</tt>.</p></dd><dt><span class="term"><tt class="computeroutput">%description</tt></span></dt><dd><p>Make your description as complete as possible, but not more
+ <code class="filename">gtk2-devel</code> and
+ <code class="filename">db3-devel</code>.</p></dd><dt><span class="term"><code class="computeroutput">%description</code></span></dt><dd><p>Make your description as complete as possible, but not more
than 10-15 lines of text. If other packages are necessary, or this
package works with others, it is probably wise to describe the
- specifics of that operation here.</p></dd><dt><span class="term"><tt class="computeroutput">%prep</tt></span></dt><dd><p>This phase should unpack the source code and apply any patches
+ specifics of that operation here.</p></dd><dt><span class="term"><code class="computeroutput">%prep</code></span></dt><dd><p>This phase should unpack the source code and apply any patches
necessary for the build. Additionally, if autoconf and/or automake
needs to be rerun, do so here. You usually unpack source code with
- the <tt class="computeroutput">%setup</tt> macro, and usually
- provide the <tt class="option">-q</tt> flag so that it is quiet while
+ the <code class="computeroutput">%setup</code> macro, and usually
+ provide the <code class="option">-q</code> flag so that it is quiet while
unpacking:
</p><pre class="screen">
-<tt class="computeroutput">%setup -q</tt>
-</pre><p>Other options to <tt class="computeroutput">%setup</tt>
- include:</p><div class="itemizedlist"><ul type="disc"><li><p><tt class="computeroutput">-a
- <i class="replaceable"><tt><num></tt></i></tt>,
- where <i class="replaceable"><tt><num></tt></i> is the number
+<code class="computeroutput">%setup -q</code>
+</pre><p>Other options to <code class="computeroutput">%setup</code>
+ include:</p><div class="itemizedlist"><ul type="disc"><li><p><code class="computeroutput">-a
+ <em class="replaceable"><code><num></code></em></code>,
+ where <em class="replaceable"><code><num></code></em> is the number
given the source file such as 0 for source0, means that only
the source files specifies should be unpacked. The files are
unpacked <span class="emphasis"><em>after</em></span> changing to the
- directory.</p></li><li><p><tt class="computeroutput">-b
- <i class="replaceable"><tt><num></tt></i></tt>,
- where <i class="replaceable"><tt><num></tt></i> is the number
+ directory.</p></li><li><p><code class="computeroutput">-b
+ <em class="replaceable"><code><num></code></em></code>,
+ where <em class="replaceable"><code><num></code></em> is the number
given the source file such as 0 for source0, means that only
the source files specifies should be unpacked. The files are
unpacked <span class="emphasis"><em>before</em></span> changing to the
- directory.</p></li><li><p><tt class="computeroutput">-c</tt> is used to create the
- directory before unpacking the sources.</p></li><li><p><tt class="computeroutput">-n
- <i class="replaceable"><tt><name></tt></i></tt> can be
- used to specify the directory name</p></li><li><p><tt class="computeroutput">-D</tt> specifies that the
+ directory.</p></li><li><p><code class="computeroutput">-c</code> is used to create the
+ directory before unpacking the sources.</p></li><li><p><code class="computeroutput">-n
+ <em class="replaceable"><code><name></code></em></code> can be
+ used to specify the directory name</p></li><li><p><code class="computeroutput">-D</code> specifies that the
directory should not be deleted before unpacking.</p></li></ul></div><p>While applying patches, be sure to provide the
- <tt class="option">-b</tt> argument followed by the string you used in
+ <code class="option">-b</code> argument followed by the string you used in
the name of the patch file:
</p><pre class="screen">
-<tt class="computeroutput">%patch0 -p1 -b .<i class="replaceable"><tt><fixupstring></tt></i></tt>
-</pre></dd><dt><span class="term"><tt class="computeroutput">%build</tt></span></dt><dd><p>Include the command necessary to build the program in this
- section (for example, <tt class="command">make</tt>).
- </p><p>Always use the <tt class="computeroutput">%configure</tt>
+<code class="computeroutput">%patch0 -p1 -b .<em class="replaceable"><code><fixupstring></code></em></code>
+</pre></dd><dt><span class="term"><code class="computeroutput">%build</code></span></dt><dd><p>Include the command necessary to build the program in this
+ section (for example, <code class="command">make</code>).
+ </p><p>Always use the <code class="computeroutput">%configure</code>
macro where possible. This macro expands to automatically
configure properly packaged programs that use autoconf and
automake. It sets up all the paths and optimized CFLAGS correctly
for whatever version of Fedora Core you are building on. If you need to
provide extra flags, do so after the
- <tt class="computeroutput">%configure</tt> entry. Example:
+ <code class="computeroutput">%configure</code> entry. Example:
</p><pre class="screen">
-<tt class="computeroutput">%configure --extra-flag=yes</tt>
-</pre></dd><dt><span class="term"><tt class="computeroutput">%install</tt></span></dt><dd><p>Include all the command needed to install the package.</p><p>Usually you want to clean out any old buildroots that might be
+<code class="computeroutput">%configure --extra-flag=yes</code>
+</pre></dd><dt><span class="term"><code class="computeroutput">%install</code></span></dt><dd><p>Include all the command needed to install the package.</p><p>Usually you want to clean out any old buildroots that might be
lying around before actually installing files into it:</p><pre class="screen">
-<tt class="computeroutput">rm -fr %{buildroot}</tt>
-</pre></dd><dt><span class="term"><tt class="computeroutput">%makeinstall</tt></span></dt><dd><p>Like the <tt class="computeroutput">%configure</tt> macro,
- the <tt class="computeroutput">%makeinstall</tt> macro correctly
+<code class="computeroutput">rm -fr %{buildroot}</code>
+</pre></dd><dt><span class="term"><code class="computeroutput">%makeinstall</code></span></dt><dd><p>Like the <code class="computeroutput">%configure</code> macro,
+ the <code class="computeroutput">%makeinstall</code> macro correctly
installs a autoconf/automake style package into your
- buildroot. Use it where possible.</p></dd><dt><span class="term"><tt class="computeroutput">%clean</tt></span></dt><dd><p>Supply a command to clean up your buildroot. Usually the
- command <tt class="computeroutput">rm -fr %{buildroot}</tt>
- suffices.</p></dd><dt><span class="term"><tt class="computeroutput">%post</tt></span></dt><dd><p>Include anything that needs to happen immediately after
+ buildroot. Use it where possible.</p></dd><dt><span class="term"><code class="computeroutput">%clean</code></span></dt><dd><p>Supply a command to clean up your buildroot. Usually the
+ command <code class="computeroutput">rm -fr %{buildroot}</code>
+ suffices.</p></dd><dt><span class="term"><code class="computeroutput">%post</code></span></dt><dd><p>Include anything that needs to happen immediately after
package installation. For example, if the package includes an
initscript that needs to be run to start the service. Another
- example is if the <tt class="command">ldconfig</tt> command needs to be
+ example is if the <code class="command">ldconfig</code> command needs to be
run after installing or upgrading any system libraries. Provide
- the full path to the commands.</p></dd><dt><span class="term"><tt class="computeroutput">%preun</tt></span></dt><dd><p>Similar to the <tt class="computeroutput">%post</tt> section,
+ the full path to the commands.</p></dd><dt><span class="term"><code class="computeroutput">%preun</code></span></dt><dd><p>Similar to the <code class="computeroutput">%post</code> section,
but run right before a package is removed. For example, it can
check what the package reference count is. This is important to
know whether you are upgrading a package (which involves
@@ -225,22 +225,22 @@
to the number of packages with that name still installed). When
it is being uninstalled, it will return 0.</p><p>If you are going to stop a service and remove it from use in
your %preun section, you want to make sure you are really removing
- the package, and not just upgrading.</p></dd><dt><span class="term"><tt class="computeroutput">%postun</tt></span></dt><dd><p>Similar to the <tt class="computeroutput">%preun</tt>
+ the package, and not just upgrading.</p></dd><dt><span class="term"><code class="computeroutput">%postun</code></span></dt><dd><p>Similar to the <code class="computeroutput">%preun</code>
section, but run after a package is removed. In this example, the
service is restarted if and only if it remains on the system. We
- do this in the postuninstall phase of the "old" package. If the
+ do this in the postuninstall phase of the "old" package. If the
reference count on the package name is greater than or equal to
one, we know the package is still on the system (for example, it
was upgraded, not removed), and the service is restarted if it was
- already running with the <tt class="command">condrestart</tt>
- directive.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Warning: Warning"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Warning]" src="./stylesheet-images/warning.png"></td><th align="left">Warning</th></tr><tr><td colspan="2" align="left" valign="top"><p>
+ already running with the <code class="command">condrestart</code>
+ directive.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Warning: Warning"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Warning]" src="./stylesheet-images/warning.png"></td><th align="left">Warning</th></tr><tr><td align="left" valign="top"><p>
All script sections of an RPM, including
- <tt class="computeroutput">%pre</tt>,
- <tt class="computeroutput">%preun</tt>,
- <tt class="computeroutput">%post</tt>,
- <tt class="computeroutput">%postun</tt> should
+ <code class="computeroutput">%pre</code>,
+ <code class="computeroutput">%preun</code>,
+ <code class="computeroutput">%post</code>,
+ <code class="computeroutput">%postun</code> should
<span class="emphasis"><em>never</em></span> output to standard error or standard
- out. Redirect those messages to <tt class="filename">/dev/null</tt>
+ out. Redirect those messages to <code class="filename">/dev/null</code>
if they can not be avoided. If the package is installed in a
batch fashion, via a graphical RPM tool, or via an automated
system, the user never sees those messages. <span class="emphasis"><em>Do
@@ -248,80 +248,80 @@
one of these sections for giving the user additional
instructions after an RPM has been installed. For the same
reasons, scripts should <span class="emphasis"><em>never</em></span> be
- interactive.</p></td></tr></table></div></dd><dt><span class="term"><tt class="computeroutput">%files</tt></span></dt><dd><p>List the files that should be included in the package. The
- files listed here are displayed when the <tt class="command">rpm
- -ql</tt> command is issued for the package.</p><p>A package should not put a file in a directory that it does
+ interactive.</p></td></tr></table></div></dd><dt><span class="term"><code class="computeroutput">%files</code></span></dt><dd><p>List the files that should be included in the package. The
+ files listed here are displayed when the <code class="command">rpm
+ -ql</code> command is issued for the package.</p><p>A package should not put a file in a directory that it does
not own and that none of its dependencies own. If this happens,
the file is removed when the package is removed, but the directory
is not.</p><p>Another common mistake is to put a file in a directory that
another package owns without adding a dependency on that
- package. For example, assume <tt class="filename">mypkg</tt> owns the
- <tt class="filename">/foo/</tt> directory and
- <tt class="filename">yourpkg</tt> owns the
- <tt class="filename">/foo/bar</tt> file. If both packages are installed
- and then <tt class="filename">mypkg</tt> is removed, the
- <tt class="filename">/foo</tt> directory is not removed because it is
- not empty. And when <tt class="filename">yourpkg</tt> is removed, the
+ package. For example, assume <code class="filename">mypkg</code> owns the
+ <code class="filename">/foo/</code> directory and
+ <code class="filename">yourpkg</code> owns the
+ <code class="filename">/foo/bar</code> file. If both packages are installed
+ and then <code class="filename">mypkg</code> is removed, the
+ <code class="filename">/foo</code> directory is not removed because it is
+ not empty. And when <code class="filename">yourpkg</code> is removed, the
file is removed, but the directory is not.</p><p>In summary, make sure the package owns all the directories it
uses or you depend on packages that do.</p><p>Use the FHS transparent macros that are defined on a
per-platform basis so the package is portable back to older
versions of Fedora Core if the locations for these special
directories change.</p><p>Other macros for directories include:
- </p><div class="itemizedlist"><ul type="disc"><li><p><tt class="computeroutput">%{_bindir}</tt> —
- <tt class="filename">bin</tt> directory for the system</p></li><li><p><tt class="computeroutput">%{_mandir}</tt> —
- the default directory for manual pages</p></li><li><p><tt class="computeroutput">%{_datadir}</tt> —
- the default <tt class="filename">share</tt> directory location</p></li><li><p><tt class="computeroutput">%{_defaultdocdir}</tt> —
- the default directory for documentation</p></li></ul></div><p>The <tt class="computeroutput">%defattr</tt> macro
+ </p><div class="itemizedlist"><ul type="disc"><li><p><code class="computeroutput">%{_bindir}</code> —
+ <code class="filename">bin</code> directory for the system</p></li><li><p><code class="computeroutput">%{_mandir}</code> —
+ the default directory for manual pages</p></li><li><p><code class="computeroutput">%{_datadir}</code> —
+ the default <code class="filename">share</code> directory location</p></li><li><p><code class="computeroutput">%{_defaultdocdir}</code> —
+ the default directory for documentation</p></li></ul></div><p>The <code class="computeroutput">%defattr</code> macro
specifies what the default permissions, user, and group are for files
- found in the <tt class="computeroutput">%files</tt> section. In
+ found in the <code class="computeroutput">%files</code> section. In
almost every case specify the following:</p><pre class="screen">
-<tt class="computeroutput">%defattr(-,root,root,-)</tt>
-</pre><p>It is is in the form <tt class="computeroutput">(<i class="replaceable"><tt>file
- permissions</tt></i>, <i class="replaceable"><tt>owner</tt></i>,
- <i class="replaceable"><tt>group</tt></i>, <i class="replaceable"><tt>directory
- permissions</tt></i>)</tt>. If a dash (-) is
+<code class="computeroutput">%defattr(-,root,root,-)</code>
+</pre><p>It is is in the form <code class="computeroutput">(<em class="replaceable"><code>file
+ permissions</code></em>, <em class="replaceable"><code>owner</code></em>,
+ <em class="replaceable"><code>group</code></em>, <em class="replaceable"><code>directory
+ permissions</code></em>)</code>. If a dash (-) is
specified for any field, whatever the actual
permissions/ownership of the file in the buildroot are at
packaging time are used instead.</p><p>If necessary, specify attributes on a particular file can also
be specified to make sure they are correct. For instance, to make
sure a file has the mode
- <tt class="computeroutput">0400</tt>:</p><pre class="screen">
-<tt class="computeroutput">%attr(0400,root,root) /etc/readonlyrootfile</tt>
+ <code class="computeroutput">0400</code>:</p><pre class="screen">
+<code class="computeroutput">%attr(0400,root,root) /etc/readonlyrootfile</code>
</pre><p>If the file is a directory, it can be marked as a directory
- with the <tt class="computeroutput">%dir</tt> prefix.
- <tt class="computeroutput">%dir</tt> is only required if the
+ with the <code class="computeroutput">%dir</code> prefix.
+ <code class="computeroutput">%dir</code> is only required if the
directory only (and not the files under it) should be packaged
(or package the files under it with different flags).
Listing a directory only includes the directory, not the file in
it and not any of its subdirectories.
</p><pre class="screen">
-<tt class="computeroutput">%dir %{_datadir}/%{name}</tt>
+<code class="computeroutput">%dir %{_datadir}/%{name}</code>
</pre><p>If the file is a documentation file, mark it with the
- <tt class="computeroutput">%doc</tt> prefix. The paths are
+ <code class="computeroutput">%doc</code> prefix. The paths are
relative to the RPM build directory. For example:
</p><pre class="screen">
-<tt class="computeroutput">%doc doc/*</tt>
+<code class="computeroutput">%doc doc/*</code>
</pre><p>If it is a configuration file it should be marked as
follows:</p><pre class="screen">
-<tt class="computeroutput">%config <i class="replaceable"><tt><filename></tt></i></tt>
+<code class="computeroutput">%config <em class="replaceable"><code><filename></code></em></code>
</pre><p>
If the configuration file should not be replaced when the RPM is
upgraded, mark it as follows:
</p><pre class="screen">
-<tt class="computeroutput">%config(noreplace) <i class="replaceable"><tt><filename></tt></i></tt>
+<code class="computeroutput">%config(noreplace) <em class="replaceable"><code><filename></code></em></code>
</pre><p>
For files that should be included in the list of files so that
they are uninstalled when the package is removed but may not exist
until they are created during post-install should be marked as
follows:
</p><pre class="screen">
-<tt class="computeroutput">%config(missingok) <i class="replaceable"><tt><filename></tt></i></tt>
-</pre></dd><dt><span class="term"><tt class="computeroutput">%changelog</tt></span></dt><dd><p>Supply a changelog entry whenever a change to a package is
+<code class="computeroutput">%config(missingok) <em class="replaceable"><code><filename></code></em></code>
+</pre></dd><dt><span class="term"><code class="computeroutput">%changelog</code></span></dt><dd><p>Supply a changelog entry whenever a change to a package is
made. It must be in proper format as shown in the example. Be as
- descriptive as possible; sentences such as <b class="userinput"><tt>fixed
- bug</tt></b> does not example what has been fixed. If the
+ descriptive as possible; sentences such as <strong class="userinput"><code>fixed
+ bug</code></strong> does not example what has been fixed. If the
changes include a fix for a bug filed in Bugzilla, include the
- Bugzilla number in the changelog entry.</p></dd></dl></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-cvs-cvscommands.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="index.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-rpm-guidelines.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">3.3. Basic CVS Commands </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 4.2. Guidelines</td></tr></table></div>
+ Bugzilla number in the changelog entry.</p></dd></dl></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="sn-cvs-cvscommands.php">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="s1-rpm-guidelines.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">3.4. Basic CVS Commands </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 4.2. Guidelines</td></tr></table></div>
<?
Index: ch-ui-guidelines.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/ch-ui-guidelines.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- ch-ui-guidelines.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ ch-ui-guidelines.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,7 +7,7 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 5. User Interface Guidelines</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-rpm-more-guidelines.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="s1-ui-gnome-guidelines.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-ui-guidelines"></a>Chapter 5. User Interface Guidelines</h2></div></div><div></div></div><p>
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 5. User Interface Guidelines</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-rpm-more-guidelines.php">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="s1-ui-gnome-guidelines.php">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="ch-ui-guidelines"></a>Chapter 5. User Interface Guidelines</h2></div></div></div><p>
If you just start reading the reference manual for a GUI toolkit and
typing in code, the result will be pretty sad. Imagine implementing a
compiler without reading any papers or textbooks on the subject. UI design
@@ -19,22 +19,22 @@
more thought up front about who's going to use it, for what tasks, and how
the software could make their day more pleasant and efficient. There's no
reason command line applications have to be cryptic and annoying; compare
- "classic ftp" to lftp.
+ "classic ftp" to lftp.
</p><p>
- Caring about good design isn't just for people who write the "pixels on
- the screen" part of the software, either. The backend should be designed
+ Caring about good design isn't just for people who write the "pixels on
+ the screen" part of the software, either. The backend should be designed
to support the frontend, rather than being designed in isolation.
</p><p>
Finally, caring about good design isn't just for programmers. The whole
development process should take it into account.
- </p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-cliff-notes"></a>5.1. Read the <span class="trademark">CliffNotes</span>®</h2></div></div><div></div></div><p>
+ </p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-cliff-notes"></a>5.1. Read the <span class="trademark">CliffNotes</span>®</h2></div></div></div><p>
Start with User Interface Design for Programmers, by Joel Spolsky. This
book is short, entertaining, and covers the main points. There's a sort
of rough draft or abridged version <a href="http://www.joelonsoftware.com/navLinks/fog0000000247.html" target="_top">online</a>
or you can buy it from your favorite bookstore. The printed book is
worth it for the extra material, and just for ease of reading, but the
online version is fine too.
- </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-rpm-more-guidelines.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="index.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-ui-gnome-guidelines.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">4.3. More RPM Building Hints </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 5.2. The GNOME Guidelines</td></tr></table></div>
+ </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-rpm-more-guidelines.php">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="s1-ui-gnome-guidelines.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">4.3. More RPM Building Hints </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 5.2. The GNOME Guidelines</td></tr></table></div>
<?
Index: index.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/index.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- index.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ index.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,7 +7,7 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Fedora Project Developer's Guide</th></tr><tr><td width="20%" align="left"> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch-guidelines.php">Next</a></td></tr></table><hr></div><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="developers-guide"></a>Fedora Project Developer's Guide</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tammy</span> <span class="surname">Fox</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Havoc</span> <span class="surname">Pennington</span></h3></div></div></div><div><p class="copyright">Copyright © 2003 Red Hat, Inc., Tammy Fox, Havoc Pennington</p></div><div><a href="ln-legalnotice.php">Legal Notice</a></div></div><div></div><hr></div><div class="toc"><p><b>Table of Conte!
nts</b></p><dl><dt>1. <a href="ch-guidelines.php">General Guidelines</a></dt><dt>2. <a href="ch-package-versions.php">Package Versions</a></dt><dd><dl><dt>2.1. <a href="ch-package-versions.php#s1-beta-exceptions">Beta Exceptions</a></dt></dl></dd><dt>3. <a href="ch-cvs.php">CVS</a></dt><dd><dl><dt>3.1. <a href="ch-cvs.php#s1-cvs-overview">How CVS Works</a></dt><dt>3.2. <a href="s1-cvs-configure.php">Configuring CVS on Your System</a></dt><dt>3.3. <a href="s1-cvs-cvscommands.php">Basic CVS Commands</a></dt><dd><dl><dt>3.3.1. <a href="s1-cvs-cvscommands.php#s2-cvs-cvscommands-co">Checking Out Modules</a></dt><dd><dl><dt>3.3.1.1. <a href="s1-cvs-cvscommands.php#s3-cvs-cvscommands-co-branch">Checking Out Branches of Modules</a></dt></dl></dd><dt>3.3.2. <a href="s1-cvs-cvscommands.php#s2-cvs-cvscommands-up">Updating Files</a></dt><dt>3.3.3. <a href="s1-cvs-cvscommands.php#s2-cvs-cvscommands-commit">Committing Files</a></dt><dt>3.3.4. <a href="s1-cvs-cvscommands.php#s2-cvs-cvscom!
mands-add">Adding Files</a></dt><dt>3.3.5. <a href="s1-cvs-cvs!
comman
php#s2-cvs-cvscommands-rm">Removing Files</a></dt><dt>3.3.6. <a href="s1-cvs-cvscommands.php#s2-cvs-cvscommands-status">Status of Files</a></dt><dt>3.3.7. <a href="s1-cvs-cvscommands.php#s2-cvs-cvscommands-conflicts">Resolving Conflicts</a></dt><dt>3.3.8. <a href="s1-cvs-cvscommands.php#s2-cvs-cvscommands-summary">Summary</a></dt></dl></dd></dl></dd><dt>4. <a href="ch-rpm-building.php">Building RPM Packages</a></dt><dd><dl><dt>4.1. <a href="ch-rpm-building.php#s1-rpm-spec-file">Spec File</a></dt><dt>4.2. <a href="s1-rpm-guidelines.php">Guidelines</a></dt><dt>4.3. <a href="s1-rpm-more-guidelines.php">More RPM Building Hints</a></dt></dl></dd><dt>5. <a href="ch-ui-guidelines.php">User Interface Guidelines</a></dt><dd><dl><dt>5.1. <a href="ch-ui-guidelines.php#s1-ui-cliff-notes">Read the <span class="trademark">CliffNotes</span>®</a></dt><dt>5.2. <a href="s1-ui-gnome-guidelines.php">The GNOME Guidelines</a></dt><dt>5.3. <a href="s1-ui-get-religion.php">Get Religion</a></dt><dt>!
5.4. <a href="s1-ui-get-details.php">Get Details</a></dt><dt>5.5. <a href="s1-ui-more-suggestions.php">More Suggestions</a></dt><dt>5.6. <a href="s1-ui-scaling.php">Scaling It Down</a></dt></dl></dd><dt>6. <a href="ch-console-access.php">Enabling Console Access</a></dt><dt>7. <a href="ch-menus.php">Adding Applications to the Menus</a></dt><dd><dl><dt>7.1. <a href="ch-menus.php#s1-categories">Red Hat Categories</a></dt></dl></dd></dl></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch-guidelines.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"> </td><td width="40%" align="right" valign="top"> Chapter 1. General Guidelines</td></tr></table></div>
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Fedora Core Developer's Guide</th></tr><tr><td width="20%" align="left"> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch-guidelines.php">Next</a></td></tr></table><hr></div><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="developers-guide"></a>Fedora Core Developer's Guide</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tammy</span> <span class="surname">Fox</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Havoc</span> <span class="surname">Pennington</span></h3></div></div></div><div><p class="copyright">Copyright © 2003 Red Hat, Inc., Tammy Fox, Havoc Pennington</p></div><div><a href="ln-legalnotice.php">Legal Notice</a></div></div><hr></div><div class="toc"><p><b>Table of Co!
ntents</b></p><dl><dt><span class="chapter"><a href="ch-guidelines.php">1. General Guidelines</a></span></dt><dt><span class="chapter"><a href="ch-package-versions.php">2. Package Versions</a></span></dt><dd><dl><dt><span class="sect1"><a href="ch-package-versions.php#s1-beta-exceptions">2.1. Beta Exceptions</a></span></dt></dl></dd><dt><span class="chapter"><a href="ch-cvs.php">3. CVS</a></span></dt><dd><dl><dt><span class="section"><a href="ch-cvs.php#sn-cvs-overview">3.1. How CVS Works</a></span></dt><dt><span class="section"><a href="sn-cvs-preparation.php">3.2. Preparing For CVS Use</a></span></dt><dd><dl><dt><span class="section"><a href="sn-cvs-preparation.php#sn-cvs-rpm-check">3.2.1. Is CVS Installed On Your System</a></span></dt><dt><span class="section"><a href="sn-cvs-preparation.php#sn-cvs-generate-keys">3.2.2. Generating SSH Keys</a></span></dt></dl></dd><dt><span class="section"><a href="sn-cvs-config.php">3.3. Configuring For CVS Access</a></span></dt><dd><dl!
><dt><span class="section"><a href="sn-cvs-config.php#sn-cvs-c!
onfig-
rc">3.3.1. Avoiding Repetitive Typing</a></span></dt><dt><span class="section"><a href="sn-cvs-config.php#sn-cvs-config-anon">3.3.2. Configuring for Read-Only CVS Access</a></span></dt><dt><span class="section"><a href="sn-cvs-config.php#sn-cvs-config-author">3.3.3. Configuring Read/Write CVS Access</a></span></dt></dl></dd><dt><span class="section"><a href="sn-cvs-cvscommands.php">3.4. Basic CVS Commands</a></span></dt><dd><dl><dt><span class="section"><a href="sn-cvs-cvscommands.php#sn-cvs-cvscommands-co">3.4.1. Checking Out Modules</a></span></dt><dd><dl><dt><span class="section"><a href="sn-cvs-cvscommands.php#sn-cvs-cvscommands-co-branch">3.4.1.1. Checking Out Branches of Modules</a></span></dt></dl></dd><dt><span class="section"><a href="sn-cvs-cvscommands.php#sn-cvs-cvscommands-up">3.4.2. Updating Files</a></span></dt><dt><span class="section"><a href="sn-cvs-cvscommands.php#sn-cvs-cvscommands-commit">3.4.3. Committing Files</a></span></dt><dt><span class="section"><a!
href="sn-cvs-cvscommands.php#sn-cvs-cvscommands-add">3.4.4. Adding Files</a></span></dt><dt><span class="section"><a href="sn-cvs-cvscommands.php#sn-cvs-cvscommands-admin">3.4.5. Managing Binary Files</a></span></dt><dt><span class="section"><a href="sn-cvs-cvscommands.php#sn-cvs-cvscommands-rm">3.4.6. Removing Files</a></span></dt><dt><span class="section"><a href="sn-cvs-cvscommands.php#sn-cvs-cvscommands-status">3.4.7. Status of Files</a></span></dt><dt><span class="section"><a href="sn-cvs-cvscommands.php#sn-cvs-cvscommands-conflicts">3.4.8. Resolving Conflicts</a></span></dt><dt><span class="section"><a href="sn-cvs-cvscommands.php#sn-cvs-cvscommands-summary">3.4.9. Summary</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="ch-rpm-building.php">4. Building RPM Packages</a></span></dt><dd><dl><dt><span class="sect1"><a href="ch-rpm-building.php#s1-rpm-spec-file">4.1. Spec File</a></span></dt><dt><span class="sect1"><a href="s1-rpm-guidelines.php">4.2!
. Guidelines</a></span></dt><dt><span class="sect1"><a href="s!
1-rpm-
e-guidelines.php">4.3. More RPM Building Hints</a></span></dt></dl></dd><dt><span class="chapter"><a href="ch-ui-guidelines.php">5. User Interface Guidelines</a></span></dt><dd><dl><dt><span class="sect1"><a href="ch-ui-guidelines.php#s1-ui-cliff-notes">5.1. Read the <span class="trademark">CliffNotes</span>®</a></span></dt><dt><span class="sect1"><a href="s1-ui-gnome-guidelines.php">5.2. The GNOME Guidelines</a></span></dt><dt><span class="sect1"><a href="s1-ui-get-religion.php">5.3. Get Religion</a></span></dt><dt><span class="sect1"><a href="s1-ui-get-details.php">5.4. Get Details</a></span></dt><dt><span class="sect1"><a href="s1-ui-more-suggestions.php">5.5. More Suggestions</a></span></dt><dt><span class="sect1"><a href="s1-ui-scaling.php">5.6. Scaling It Down</a></span></dt></dl></dd><dt><span class="chapter"><a href="ch-console-access.php">6. Enabling Console Access</a></span></dt><dt><span class="chapter"><a href="ch-menus.php">7. Adding Applications to the Men!
us</a></span></dt><dd><dl><dt><span class="sect1"><a href="ch-menus.php#s1-categories">7.1. Red Hat Categories</a></span></dt></dl></dd></dl></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch-guidelines.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"> </td><td width="40%" align="right" valign="top"> Chapter 1. General Guidelines</td></tr></table></div>
<?
Index: ln-legalnotice.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/ln-legalnotice.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- ln-legalnotice.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ ln-legalnotice.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -18,15 +18,17 @@
commercially or noncommercially, provided that the GNU Free Documentation
License (FDL), the copyright notices, and the license notice saying the GNU
FDL applies to the document are reproduced in all copies, and that you add
- no other conditions whatsoever to those of th GNU FDL.
+ no other conditions whatsoever to those of the GNU FDL.
</p><p>
Garrett LeSage created the admonition graphics (note, tip, important,
- caution, and warning). They may be freely redistributed with documentation
- produced for the Fedora project.
+ caution, and warning).
+ Tommy Reynolds <code class="email"><<a href="mailto:Tommy.Reynolds at MegaCoder.com">Tommy.Reynolds at MegaCoder.com</a>></code> created the callout graphics.
+ They all may be freely redistributed with documentation
+ produced for the Fedora Project.
</p><p>
developers-guide-0.1.2 (2003-10-02)
</p><p>
- Red Hat, Red Hat Network, the Red Hat "Shadow Man" logo, RPM, Maximum RPM, the RPM logo, Linux
+ Red Hat, Red Hat Network, the Red Hat "Shadow Man" logo, RPM, Maximum RPM, the RPM logo, Linux
Library, PowerTools, Linux Undercover, RHmember, RHmember More, Rough Cuts,
Rawhide and all Red Hat-based trademarks and logos are trademarks or registered
trademarks of Red Hat, Inc. in the United States and other countries.
@@ -35,7 +37,7 @@
</p><p>
Motif and UNIX are registered trademarks of The Open Group.
</p><p>
- Intel and Pentium are a registered trademarks of Intel Corporation. Itanium
+ Intel and Pentium are registered trademarks of Intel Corporation. Itanium
and Celeron are trademarks of Intel Corporation.
</p><p>
AMD, AMD Athlon, AMD Duron, and AMD K6 are trademarks of Advanced Micro
Index: s1-rpm-guidelines.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/s1-rpm-guidelines.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- s1-rpm-guidelines.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ s1-rpm-guidelines.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,21 +7,21 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.2. Guidelines</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch-rpm-building.php">Prev</a> </td><th width="60%" align="center">Chapter 4. Building RPM Packages</th><td width="20%" align="right"> <a accesskey="n" href="s1-rpm-more-guidelines.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-rpm-guidelines"></a>4.2. Guidelines</h2></div></div><div></div></div><p>
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.2. Guidelines</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch-rpm-building.php">Prev</a> </td><th width="60%" align="center">Chapter 4. Building RPM Packages</th><td width="20%" align="right"> <a accesskey="n" href="s1-rpm-more-guidelines.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-rpm-guidelines"></a>4.2. Guidelines</h2></div></div></div><p>
Adhere to the follow rules to make sure the package is packaged
properly. This should be used as a checklist:
</p><div class="orderedlist"><ol type="1"><li><p>Every package must have a unique version number (per
epoch)</p></li><li><p>The RPM package filename must be in the n-v-r (name, version,
release) format and must contain the architecture for the package. The
proper format is
- <i class="replaceable"><tt><name></tt></i>-<i class="replaceable"><tt><version></tt></i>-<i class="replaceable"><tt><release></tt></i>.<i class="replaceable"><tt><arch></tt></i>.rpm.
- For example, <tt class="filename">pkgname-1.24-2.i386.rpm</tt> is a proper
+ <em class="replaceable"><code><name></code></em>-<em class="replaceable"><code><version></code></em>-<em class="replaceable"><code><release></code></em>.<em class="replaceable"><code><arch></code></em>.rpm.
+ For example, <code class="filename">pkgname-1.24-2.i386.rpm</code> is a proper
RPM filename.</p></li><li><p>The n-v-r in the filename must be the same as the n-v-r in the
spec file.</p></li><li><p>If the package is changed in <span class="emphasis"><em>any</em></span> way,
including changing the signature or recompiling, the version or
release must be incremented.</p></li><li><p>The package may obsolete itself.</p></li><li><p>If a file from the package conflicts with a file from another
- package in the Fedora project, the package must use
- <tt class="computeroutput">Conflicts:</tt> to specify it in the spec
+ package in the Fedora Project, the package must use
+ <code class="computeroutput">Conflicts:</code> to specify it in the spec
file.</p></li><li><p>The file list for the package must contain all the files in the
package so that all files are removed when the package is
removed.</p></li><li><p>The package may not use interactive pre-install, post-install,
@@ -29,18 +29,18 @@
prompted at anytime during the install, upgrade, or removal —
Everything must be completely automated.</p></li><li><p>The package must not write anything to standard error or
standard out. Redirect any messages to
- <tt class="filename">/dev/null</tt> if they are not necessary, or write
+ <code class="filename">/dev/null</code> if they are not necessary, or write
them to a log file.</p></li><li><p>When specifying a group in the spec file, it must be one from
- <tt class="filename">/usr/share/doc/rpm-<i class="replaceable"><tt><version></tt></i>/GROUPS</tt>. It
+ <code class="filename">/usr/share/doc/rpm-<em class="replaceable"><code><version></code></em>/GROUPS</code>. It
there is not an exact match, use the closest match. Do not invent a
new group name.</p></li><li><p>The package can not just unarchive the files in the post-install
script. This defeats the purpose of using RPM.</p></li><li><p>If a file is moved from one binary package to another, the new
package with the file <span class="emphasis"><em>must</em></span> specified the old
package in the spec file with the
- <tt class="computeroutput">Conflicts:</tt> option.</p></li><li><p>If a newer RPM does not have a binary package that the older
+ <code class="computeroutput">Conflicts:</code> option.</p></li><li><p>If a newer RPM does not have a binary package that the older
SRPMS produced, the binary package not produced anymore must be
- specified with the <tt class="computeroutput">Obsoletes:</tt>
- option in the new spec file.</p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch-rpm-building.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-rpm-building.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-rpm-more-guidelines.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 4. Building RPM Packages </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 4.3. More RPM Building Hints</td></tr></table></div>
+ specified with the <code class="computeroutput">Obsoletes:</code>
+ option in the new spec file.</p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch-rpm-building.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-rpm-building.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-rpm-more-guidelines.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 4. Building RPM Packages </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 4.3. More RPM Building Hints</td></tr></table></div>
<?
Index: s1-rpm-more-guidelines.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/s1-rpm-more-guidelines.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- s1-rpm-more-guidelines.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ s1-rpm-more-guidelines.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,28 +7,28 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.3. More RPM Building Hints</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-rpm-guidelines.php">Prev</a> </td><th width="60%" align="center">Chapter 4. Building RPM Packages</th><td width="20%" align="right"> <a accesskey="n" href="ch-ui-guidelines.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-rpm-more-guidelines"></a>4.3. More RPM Building Hints</h2></div></div><div></div></div><p>
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.3. More RPM Building Hints</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-rpm-guidelines.php">Prev</a> </td><th width="60%" align="center">Chapter 4. Building RPM Packages</th><td width="20%" align="right"> <a accesskey="n" href="ch-ui-guidelines.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-rpm-more-guidelines"></a>4.3. More RPM Building Hints</h2></div></div></div><p>
This section contains some additional troubleshooting tips:
</p><div class="orderedlist"><ol type="1"><li><p>%{_libdir} is tricky.</p><p>Use %{_prefix}/lib for data files, and %{_libdir} for libraries.
There is a slew of non-trivial FHS issues here as well.</p></li><li><p>Building as nobody with %files -f file.list</p><p>Make sure you have a %defattr(-,root,root) in place, or
- user/group will not be correct.</p><p>A <tt class="computeroutput">%defattr(-,root,root)</tt> will be
- honored anywhere in a <tt class="computeroutput">%files</tt>
+ user/group will not be correct.</p><p>A <code class="computeroutput">%defattr(-,root,root)</code> will be
+ honored anywhere in a <code class="computeroutput">%files</code>
list.</p><p>The Principle of Least Surprise sez' put it at the beginning of
file.list.</p></li><li><p>* %{prefix} is not %{_prefix}</p><p>The macro %{prefix} is a side effect macro, silently added when
Prefix: whatever is parsed, while the macro %{_prefix} is what is
used in configure prefix=%{_prefix} There's also extensive and
conventional use of %prefix in Gnome and other packaging.</p></li><li><p>Fix/mangle the file manifest in %install, not %files. Fixing the
file manifest in %install will (eventually) permit constructs like:</p><pre class="screen">
-<tt class="computeroutput">%files
+<code class="computeroutput">%files
%{_bindir}/*
-...</tt>
+...</code>
</pre><p>and eventually:</p><pre class="screen">
-<tt class="computeroutput">%files
-/</tt>
+<code class="computeroutput">%files
+/</code>
</pre><p>The risk, of course, is that packages will be polluted by
unknown files which cause file conflicts down the road. I believe
(but other opinions and traditional wisdom differ) that %files
- should be made as compact as possible.</p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-rpm-guidelines.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-rpm-building.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch-ui-guidelines.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">4.2. Guidelines </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> Chapter 5. User Interface Guidelines</td></tr></table></div>
+ should be made as compact as possible.</p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-rpm-guidelines.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-rpm-building.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch-ui-guidelines.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">4.2. Guidelines </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> Chapter 5. User Interface Guidelines</td></tr></table></div>
<?
Index: s1-ui-get-details.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/s1-ui-get-details.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- s1-ui-get-details.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ s1-ui-get-details.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,9 +7,9 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.4. Get Details</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-ui-get-religion.php">Prev</a> </td><th width="60%" align="center">Chapter 5. User Interface Guidelines</th><td width="20%" align="right"> <a accesskey="n" href="s1-ui-more-suggestions.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-get-details"></a>5.4. Get Details</h2></div></div><div></div></div><p>
- <i class="citetitle">Designing from Both Sides of the Screen</i> by Ellen
- Isaacs and Alan Walendowski is a very practical "How To" book, similar
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.4. Get Details</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-ui-get-religion.php">Prev</a> </td><th width="60%" align="center">Chapter 5. User Interface Guidelines</th><td width="20%" align="right"> <a accesskey="n" href="s1-ui-more-suggestions.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-get-details"></a>5.4. Get Details</h2></div></div></div><p>
+ <em class="citetitle">Designing from Both Sides of the Screen</em> by Ellen
+ Isaacs and Alan Walendowski is a very practical "How To" book, similar
in spirit to Joel's book but more detailed and not aimed exclusively at
programmers.
</p><p>
@@ -28,11 +28,11 @@
between the designer and programmer, and how to balance UI goals with
time, resource, and engineering constraints.
</p><p>
- Alan Cooper's <i class="citetitle">About Face 2.0</i> is comparable to
- <i class="citetitle">Designing from Both Sides of the Screen</i> in that
- it's a practical "How To" and reference manual, so if you want more
+ Alan Cooper's <em class="citetitle">About Face 2.0</em> is comparable to
+ <em class="citetitle">Designing from Both Sides of the Screen</em> in that
+ it's a practical "How To" and reference manual, so if you want more
advice on concrete methodologies, have a look.
- </p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-ui-get-religion.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-ui-guidelines.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-ui-more-suggestions.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.3. Get Religion </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 5.5. More Suggestions</td></tr></table></div>
+ </p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-ui-get-religion.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-ui-guidelines.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-ui-more-suggestions.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.3. Get Religion </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 5.5. More Suggestions</td></tr></table></div>
<?
Index: s1-ui-get-religion.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/s1-ui-get-religion.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- s1-ui-get-religion.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ s1-ui-get-religion.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,9 +7,9 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.3. Get Religion</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-ui-gnome-guidelines.php">Prev</a> </td><th width="60%" align="center">Chapter 5. User Interface Guidelines</th><td width="20%" align="right"> <a accesskey="n" href="s1-ui-get-details.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-get-religion"></a>5.3. Get Religion</h2></div></div><div></div></div><p>
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.3. Get Religion</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-ui-gnome-guidelines.php">Prev</a> </td><th width="60%" align="center">Chapter 5. User Interface Guidelines</th><td width="20%" align="right"> <a accesskey="n" href="s1-ui-get-details.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-get-religion"></a>5.3. Get Religion</h2></div></div></div><p>
For a less applied, more big-picture book, you might be interested in
- Alan Cooper's <i class="citetitle">The Inmates are Running the Asylum</i>,
+ Alan Cooper's <em class="citetitle">The Inmates are Running the Asylum</em>,
which is in part an extended (and fun to read) rant, but also contains
some interesting case studies, examples, and practical suggestions.
</p><p>
@@ -17,14 +17,14 @@
about development team organization, project management, etc. as well as
technical suggestions.
</p><p>
- Alan Cooper has a more practical, "how-to" style book as well, called
- <i class="citetitle">About Face 2.0</i> - be sure to get the brand-new 2.0
+ Alan Cooper has a more practical, "how-to" style book as well, called
+ <em class="citetitle">About Face 2.0</em> - be sure to get the brand-new 2.0
edition, rather than the now-somewhat-dated original.
</p><p>
- Everyone on earth recommends <i class="citetitle">The Design of Everyday
- Things</i>, by Donald Norman. This is another good book
+ Everyone on earth recommends <em class="citetitle">The Design of Everyday
+ Things</em>, by Donald Norman. This is another good book
to check out.
- </p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-ui-gnome-guidelines.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-ui-guidelines.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-ui-get-details.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.2. The GNOME Guidelines </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 5.4. Get Details</td></tr></table></div>
+ </p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-ui-gnome-guidelines.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-ui-guidelines.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-ui-get-details.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.2. The GNOME Guidelines </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 5.4. Get Details</td></tr></table></div>
<?
Index: s1-ui-gnome-guidelines.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/s1-ui-gnome-guidelines.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- s1-ui-gnome-guidelines.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ s1-ui-gnome-guidelines.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,11 +7,11 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.2. The GNOME Guidelines</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch-ui-guidelines.php">Prev</a> </td><th width="60%" align="center">Chapter 5. User Interface Guidelines</th><td width="20%" align="right"> <a accesskey="n" href="s1-ui-get-religion.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-gnome-guidelines"></a>5.2. The GNOME Guidelines</h2></div></div><div></div></div><p>
- Read the <i class="citetitle">GNOME Human Interface Guidelines</i>. These
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.2. The GNOME Guidelines</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch-ui-guidelines.php">Prev</a> </td><th width="60%" align="center">Chapter 5. User Interface Guidelines</th><td width="20%" align="right"> <a accesskey="n" href="s1-ui-get-religion.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-gnome-guidelines"></a>5.2. The GNOME Guidelines</h2></div></div></div><p>
+ Read the <em class="citetitle">GNOME Human Interface Guidelines</em>. These
are pretty good guidelines developed by some interaction design
professionals, and are the best guidelines to come from the open source
- community so far. Until we have official Fedora project guidelines,
+ community so far. Until we have official Fedora Project guidelines,
following the GNOME guidelines will probably result in a substantially
better UI than making up your own. And our tools will be consistent with
each other and at least one desktop environment.
@@ -29,7 +29,7 @@
widgets properly, and such. Don't get too bogged down in this and
neglect the big picture. You can be fully guideline-compliant and
still have an application that doesn't make any sense.
- </p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch-ui-guidelines.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-ui-guidelines.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-ui-get-religion.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 5. User Interface Guidelines </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 5.3. Get Religion</td></tr></table></div>
+ </p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch-ui-guidelines.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-ui-guidelines.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-ui-get-religion.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 5. User Interface Guidelines </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 5.3. Get Religion</td></tr></table></div>
<?
Index: s1-ui-more-suggestions.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/s1-ui-more-suggestions.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- s1-ui-more-suggestions.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ s1-ui-more-suggestions.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,13 +7,13 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.5. More Suggestions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-ui-get-details.php">Prev</a> </td><th width="60%" align="center">Chapter 5. User Interface Guidelines</th><td width="20%" align="right"> <a accesskey="n" href="s1-ui-scaling.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-more-suggestions"></a>5.5. More Suggestions</h2></div></div><div></div></div><p>
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.5. More Suggestions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-ui-get-details.php">Prev</a> </td><th width="60%" align="center">Chapter 5. User Interface Guidelines</th><td width="20%" align="right"> <a accesskey="n" href="s1-ui-scaling.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-more-suggestions"></a>5.5. More Suggestions</h2></div></div></div><p>
Some places to start:
</p><div class="orderedlist"><ol type="1"><li><p><a href="http://developer.gnome.org/projects/gup/references.html" target="_top">GNOME
Usability Project</a></p></li><li><p><a href="http://www.uidesigns.com/index.php?section=6&subsection=0" target="_top">Suggested
readings</a> from the Isaacs and Walendowski book</p></li><li><p><a href="http://www.asktog.com/basics/firstPrinciples.html" target="_top">Tog's
- <i class="citetitle">First Principles</i></a></p></li><li><p><a href="http://www.asktog.com/basics/03Performance.html" target="_top"><i class="citetitle">Maximizing
- Human Performance</i></a></p></li><li><p><a href="http://www.stcsig.org/usability/topics/personas.html" target="_top"><i class="citetitle">Personas</i></a></p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-ui-get-details.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-ui-guidelines.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-ui-scaling.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.4. Get Details </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 5.6. Scaling It Down</td></tr></table></div>
+ <em class="citetitle">First Principles</em></a></p></li><li><p><a href="http://www.asktog.com/basics/03Performance.html" target="_top"><em class="citetitle">Maximizing
+ Human Performance</em></a></p></li><li><p><a href="http://www.stcsig.org/usability/topics/personas.html" target="_top"><em class="citetitle">Personas</em></a></p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-ui-get-details.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-ui-guidelines.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s1-ui-scaling.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.4. Get Details </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> 5.6. Scaling It Down</td></tr></table></div>
<?
Index: s1-ui-scaling.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/developers-guide/s1-ui-scaling.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- s1-ui-scaling.php 30 Mar 2005 17:47:23 -0000 1.1.1.1
+++ s1-ui-scaling.php 29 Sep 2005 17:08:19 -0000 1.2
@@ -7,24 +7,24 @@
?>
-<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.6. Scaling It Down</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-ui-more-suggestions.php">Prev</a> </td><th width="60%" align="center">Chapter 5. User Interface Guidelines</th><td width="20%" align="right"> <a accesskey="n" href="ch-console-access.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-scaling"></a>5.6. Scaling It Down</h2></div></div><div></div></div><p>
- These books talk about things like your <i class="firstterm">development
- team</i>, your <i class="firstterm">dedicated graphic
- artist</i>, and your <i class="firstterm">professional interaction
- designer</i>. Since you may or may not have all of these available,
+<div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.6. Scaling It Down</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s1-ui-more-suggestions.php">Prev</a> </td><th width="60%" align="center">Chapter 5. User Interface Guidelines</th><td width="20%" align="right"> <a accesskey="n" href="ch-console-access.php">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s1-ui-scaling"></a>5.6. Scaling It Down</h2></div></div></div><p>
+ These books talk about things like your <em class="firstterm">development
+ team</em>, your <em class="firstterm">dedicated graphic
+ artist</em>, and your <em class="firstterm">professional interaction
+ designer</em>. Since you may or may not have all of these available,
here are some simple tasks you can do on your own:
- </p><div class="itemizedlist"><ul type="disc"><li><p>Come up with what Joel calls "imaginary users"/"scenarios" and
- Alan Cooper calls "personas" - describe the prototypical person who
+ </p><div class="itemizedlist"><ul type="disc"><li><p>Come up with what Joel calls "imaginary users"/"scenarios" and
+ Alan Cooper calls "personas" - describe the prototypical person who
will use the software. Or if there are several very different
possible users, write that down too. Maybe you need to have two
paths through the UI for different audiences.</p></li><li><p>Write down the goals of your target users; what are they trying
to get done? Set some clear direction for your software. Create a
- list of tasks the software will support.</p></li><li><p>Don't assume a priori that if you're writing the "XYZ tool" that
+ list of tasks the software will support.</p></li><li><p>Don't assume a priori that if you're writing the "XYZ tool" that
the tool must be one window opened from one menu entry. Maybe
supporting your list of tasks should involve file manager
extensions, applets, web frontend, wizards, etc. Your goal should be
- to support all the tasks appropriately somewhere in Fedora project,
- not to "write an XYZ tool." </p></li><li><p> Do at least a quick and easy UI specification before you write
+ to support all the tasks appropriately somewhere in Fedora Project,
+ not to "write an XYZ tool." </p></li><li><p> Do at least a quick and easy UI specification before you write
code. Joel's book, and the Isaacs and Walendowski, discuss how to
write such a spec. It doesn't need to be lengthy. Refer to the
following examples: </p><div class="itemizedlist"><ul type="circle"><li><p><a href="http://www.joelonsoftware.com/articles/WhatTimeIsIt.html" target="_top">http://www.joelonsoftware.com/articles/WhatTimeIsIt.html</a></p></li><li><p><a href="http://www.uidesigns.com/spec/" target="_top">http://www.uidesigns.com/spec/</a></p></li></ul></div></li><li><p>Post any or all of the above to the website and/or development mailing lists.
@@ -32,18 +32,18 @@
you do or don't have a particular UI feature.</p></li><li><p>As you write code, try to stick to the guidelines that are just
as easy to follow as not follow; get the pixel spacing right, use
clear plain language in messages, and that sort of thing.</p></li><li><p>Be sure to use libraries when appropriate, such as GTK+ and Qt. Avoid
- toolkits that don't properly fit in to Fedora project (such as Motif, Tk, or
+ toolkits that don't properly fit in to Fedora Project (such as Motif, Tk, or
Swing). Libraries will handle some important details for you.</p></li><li><p>If you use a GUI builder to create resource files, tweaking UI
details will be a whole lot less annoying. (With GTK+2 for example,
load dialogs from .glade files at runtime, using libglade.) This way
- you can rearrange the UI without changing all the code.</p></li><li><p>Don't be afraid to do some quick "user testing" on non-technical
+ you can rearrange the UI without changing all the code.</p></li><li><p>Don't be afraid to do some quick "user testing" on non-technical
people. You can get useful information quickly, this need not be a
high-overhead undertaking.</p></li><li><p>Categorizing your tasks using the 2x2 matrix in Chapter 6 of the
Isaacs and Walendowski book is quick to do and very valuable; you
- might think of this as the old API design rule, "make easy things
- easy and hard things possible," applied to the user interface
- instead of the application interface.</p></li><li><p>Feel free to email <tt class="email"><<a href="mailto:fedora-devel-list at redhat.com">fedora-devel-list at redhat.com</a>></tt> with
- comments, questions, or proposals.</p></li></ul></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-ui-more-suggestions.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-ui-guidelines.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch-console-access.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.5. More Suggestions </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> Chapter 6. Enabling Console Access</td></tr></table></div>
+ might think of this as the old API design rule, "make easy things
+ easy and hard things possible," applied to the user interface
+ instead of the application interface.</p></li><li><p>Feel free to email <code class="email"><<a href="mailto:fedora-devel-list at redhat.com">fedora-devel-list at redhat.com</a>></code> with
+ comments, questions, or proposals.</p></li></ul></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s1-ui-more-suggestions.php">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-ui-guidelines.php">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch-console-access.php">Next</a></td></tr><tr><td width="40%" align="left" valign="top">5.5. More Suggestions </td><td width="20%" align="center"><a accesskey="h" href="index.php">Home</a></td><td width="40%" align="right" valign="top"> Chapter 6. Enabling Console Access</td></tr></table></div>
<?
More information about the fedora-extras-commits
mailing list