Some of the underlying work to prepare for emblems on the icons.

	* style-guide.html: Some minor updates to the style guide,
	including rules about headers.

	* libnautilus/nautilus-icon-factory.h,
	libnautilus/nautilus-icon-factory.c:
	(nautilus_icon_factory_get_emblem_icons_for_file),
	(nautilus_scalable_icon_get), (nautilus_icon_factor_clear),
	(nautilus_icon_factory_load_file),
	(nautilus_gdk_pixbuf_composite_corner),
	(nautilus_icon_factor_load_icon), (nautilus_scalable_icon_hash),
	(nautilus_scalable_icon_equal),
	(nautilus_icon_factory_get_icon_for_file), (load_specific_image):
	Added interface for getting emblem icons for a file, and got rid
	of the symbolic-link overlay that was previously built into the
	icon.

	* libnautilus/gnome-icon-container.c (update_icon):
	Get pixbufs for all emblems and pass into the icon object.

	* libnautilus/nautilus-icons-controller.c
	(nautius_icons_controller_get_icon_image):
	src/file-manager/fm-icons-controller.h,
	src/file-manager/fm-icons-controller.c
	(fm_icons_controller_get_icon_image): Return a list of emblem
	images along with the main image.

	* libnautilus/nautilus-icons-view-icon-item.h,
	libnautilus/nautilus-icons-view-icon-item.c
	(nautilus_icons_view_icon_item_set_emblems),
	(nautilus_icons_view_icon_item_destroy): Keep a list of emblem
	pixbufs in each icon. We don't draw them quite yet.

	* libnautilus/gdk-extensions.h, libnautilus/gdk-extensions.c:
	(nautilus_gdk_pixbuf_list_ref), (nautilus_gdk_pixbuf_list_unref),
	(nautilus_gdk_pixbuf_list_free): Convenience functions for
	manipulating lists of GdkPixbuf objects.

	* libnautilus/nautilus-directory.h,
	libnautilus/nautilus-directory.c: (nautilus_file_list_ref),
	(nautilus_file_list_unref), (nautilus_file_list_free): Convenience
	functions for manipulating lists of NautilusFile objects. Also got
	rid of NautilusFileList typedef.

	* libnautilus/nautilus-icon-factory.h,
	libnautilus/nautilus-icon-factory.h:
	(nautilus_scalable_icon_list_free): Convenience function for
	manipulating lists of NautilusScalableIcon objects.

	* libnautilus/nautilus-glib-extensions.h,
	libnautilus/nautilus-glib-extensions.c: (nautilus_g_list_equal):
	Function to compare two GLists to see if they are
	identical. Particularly useful with lists of reference-counted
	objects.

	* src/file-manager/fm-directory-view-icons.c
	(fm_directory_view_icons_destroy),
	(add_icon_if_already_positioned),
	(fm_directory_view_icons_append_selection_context_menu_items),
	(display_icons_not_already_positioned),
	(fm_direectory_view_icons_get_selection):
	src/file-manager/fm-directory-view-list.c
	(fm_directory_view_list_get_selection):
	src/file-manager/fm-directory-view.c (display_selection_info),
	(display_pending_files), (add_files_cb), (open_in_new_window_cb),
	(fm_directory_view_real_append_selection_context_menu_items): Got
	rid of use of NautilusFileList typedef, corrected ref. counting of
	files in the lists by using new calls.

	* src/nautilus-bookmarklist.c, src/nautilus-bookmarks-menu.c,
	src/nautilus-index-tabs.c,
	src/file-manager/fm-directory-view-icons.c,
	src/file-manager/fm-directory-view.c,
	src/file-manager/fm-icons-controller.c: A bit of reformatting.

1 files changed, 45 insertions, 13 deletions

diff --git a/docs/style-guide.html b/docs/style-guide.html
index 6ed2a57c7..3b63c9d21 100644
--- a/docs/style-guide.html
+++ b/docs/style-guide.html
@@ -9,26 +9,24 @@
 <p>To make code written for Nautilus look and act in a predictable way,
 we follow a set of guidelines that specify some details of how we write code.
 To start, we follow all the guidelines outlined in the
-<a href="http://developer.gnome.org/doc/guides/programming-guidelines/">GNOME Programming Guidelines</a>.</p>
-
-<p>This document covers things that are not mentioned in the GNOME
+<a href="http://developer.gnome.org/doc/guides/programming-guidelines/">GNOME Programming Guidelines</a>.
+This document covers things that are not mentioned in the GNOME
 Programming Guidelines, and things that are mentioned there, but need
 to be re-emphasized, because people don't follow them often enough.</p>
 
 <p>I'm just getting started on this document. Feedback is welcome.
 Eventually I'd like better organization and tons of examples.</p>
 
-<p>At some point, this will probably be converted to DocBook format
-instead of HTML.</p>
-
 <blockquote>
-<p>-<a href="mailto:darin@eazel.com">Darin</a></p>
+<p>- <a href="mailto:darin@eazel.com">Darin</a></p>
 </blockquote>
 
-<p><b>We use the most-recommended coding style from GNOME Programming
+<p><b>We use the most-recommended coding style from the GNOME Programming
 Guidelines.</b> This means that we use the Linux kernel brace style with
-8-character tabs (not the GNU brace style), and we put spaces before
-the parentheses that introduce function argument lists.</p>
+8-character tabs (not the GNU brace style), we put spaces before
+the parentheses that introduce function argument lists, we put the
+braces that open the block for an if statement on the same line as the
+if statement (part of Linux kernel brace style).</p>
 
 <p><b>We prefer to use words rather than acronyms or abbreviations.</b> This means that
 we name classes with a prefix like Nautilus, not Ntl, for example.</p>
@@ -46,7 +44,7 @@ pointer casts.</p>
 <p><b>We use typedefs from &lt;glib.h&gt; for things like guint and gpointer,
 but not gint, gchar, or gdouble.</b> Using these gives a false sense
 of portability. In all three cases, using system calls like printf requires
-knowing that these are the "real" int, char, and double, so there's not reason
+knowing that these are the "real" int, char, and double, so there's no reason
 to use a typedef that's non-standard.</p>
 
 <p><b>We avoid in-band signaling.</b> This means that we avoid using special
@@ -54,11 +52,45 @@ values to indicate errors, for example. This can lead to subtle bugs when a vali
 result is misinterpreted as an error, and can make it hard to tell if the code
 handles errors or not.</p>
 
-<p><b>We code for clarity first.</b></p>
+<p><b>We code for clarity first.</b> Other concerns like efficiency are secondary.
+Sometimes they become more important than clarity, but only once they are proven
+to be a problem.</p>
 
-<p><b>We use for loops when they make the code easier to read.</b> It's true that
+<p><b>We use for loops when they make the code easier to read.</b> While loops
+can be used for other cases. It's true that
 "easy to read" is a subjective thing.</p>
 
+<p><b>We make each header "stand alone".</b> Our concept with C header files is
+that each one must be written so it can be included without including another file
+first. To test that the header files we develop have this property, we always
+include the corresponding header file first in each C source file. The only exception
+is the include of &lt;config.h>, which goes first. Here's an example:</p>
+
+<blockquote>
+<pre>
+/* -*- Mode: C; indent-tabs-mode: t; c-basic-offset: 8; tab-width: 8 -*-
+ *
+ * nautilus-icon-factory.c: Class for obtaining icons for files and other objects.
+ *
+ * Copyright (C) 1999, 2000 Red Hat Inc.
+ * Copyright (C) 1999, 2000 Eazel, Inc.
+ *
+ * <i>License agreement goes here.</i>
+ *
+ * Author: John Sullivan &lt;sullivan@eazel.com>
+ */
+
+#include &lt;config.h>
+#include "nautilus-icon-factory.h"
+
+#include &lt;string.h>
+#include &lt;stdio.h>
+<i>Include statements for other header files go here.</i>
+
+<i>Other declarations and code go here.</i>
+</pre>
+</blockquote>
+
 </body>
 
 </html>