2005-06-04 Benedikt Meurer <benny@xfce.org>

	* COPYING.LIB: Add license text for the thunar-vfs library (which is
	  licensed under the LGPL).
	* HACKING: Add information for people that plan to hack on Thunar.
	* AUTHORS: Add Jeff Franks.
	* THANKS: Import the THANKS template.
	* README: Add some basic information about Thunar. Needs more details.
	* docs/design/overview.xmi: Import the current overview diagram for
	  Thunar.
	* Makefile.am, configure.in.in, docs/Makefile.am,
	  docs/design/Makefile.am: Include the docs/ tree with the build
	  framework.
	* configure.in.in, thunar/Makefile.am, thunar-vfs/Makefile.am: Link
	  against GThread (not yet required from what is coded so far).
	* configure.in.in: Check for several required header files.
	* thunar-vfs/Makefile.am, thunar-vfs/thunar-vfs-info.{c,h},
	  thunar-vfs/thunar-vfs-monitor.{c,h},
	  thunar-vfs/thunar-vfs-uri.{c,h}, thunar-vfs/thunar-vfs-util.{c,h},
	  thunar-vfs/thunar-vfs.h: Add some experimental source code to
	  implement parts of the VFS module.
	* thunar/fallback-icon.h, thunar/fallback-icon.png: Import the
	  fallback icon.
	* thunar/thunar-application.{c,h}: Import Jeff's ThunarApplication
	  boilerplate (adjusting style as required).
	* thunar/thunar-desktop-view.{c,h}: Boilerplate for the
	  ThunarDesktopView class with the very basic requirements.
	* thunar/thunar-file.{c,h}, thunar/thunar-folder.{c,h}: Experimental
	  implementation of ThunarFile and ThunarFolder based on the
	  experimental source for the VFS module.
	* thunar/thunar-list-model.{c,h}: Sample implementation of the
	  ThunarListModel class, based on an earlier implementation found in
	  Filer.
	* thunar/thunar-preferences.{c,h}: Template for the ThunarPreferences
	  class.
	* thunar/thunar-window.{c,h}: Quick-and-dirty ThunarWindow
	  implementation to be able to roughly test the ThunarListModel class.
	* thunar/main.c: Add code to start a single ThunarWindow.
	* autogen.sh: Copyright fixes. Substitute date to make it easier to
	  identify snapshots during the early development stages.




(Old svn revision: 16314)

1 files changed, 70 insertions, 0 deletions

diff --git a/HACKING b/HACKING
new file mode 100644
index 00000000..1add425b
--- /dev/null
+++ b/HACKING
@@ -0,0 +1,70 @@
+Bug tracking system
+===================
+
+Thunar uses the Xfce bug tracking system at http://bugzilla.xfce.org/,
+hosted and maintained by the Xfce project.
+
+
+Patches
+=======
+
+Please submit patches to the Xfce bug tracking system or to the thunar-dev
+mailinglist. Your patch should be in unified diff format (the -u option
+to GNU diff) and it must comply with the coding style described below.
+
+Please send a patch against a recent version of this package. Patches
+against the Subversion trunk branch are most preferable. You can always
+access the trunk branch from
+
+  http://svn.foo-projects.org/svn/xfce/thunar/trunk
+
+or using an installed Subversion client
+
+  svn co http://svn.foo-projects.org/svn/xfce/thunar/trunk thunar
+
+
+Feature requests
+================
+
+Please file feature requests to the Xfce bug tracking system
+(http://buzilla.xfce.org, product Thunar) with a Severity of
+enhancement. Make sure that your feature request wasn't reported
+already before; requesting a feature several times won't increase
+the changed that it gets added!
+
+
+Coding Style
+============
+
+ - GNU coding conventions, with GLib-like extensions, mostly the same
+   as GTK+.
+ - Always expand tabs. This differs from the GNU suggestion, but it is
+   necessary to be independent from a given tab setting.
+ - Do NOT ever misuse debugging macros like g_return_val_if_fail() or
+   g_return_if_fail() to control program flow. They are solely useful
+   to discover bugs, the final binary won't include code for these
+   statements, and so any use of these macros to control program
+   flow presents a bug!
+ - Do NOT follow the philosophy "If it works, it's right" that most
+   other open source projects follow, instead Thunar's philosophy is
+   "It doesn't work unless it's right". Think carefully of what you want
+   to do, don't just fire up your favourite editor and start hacking
+   in the hope that it will evolve into something useful one day.
+ - Maintainability goes over performance. If you have to choose between
+   a maintainable and a fast solution, always prefer the former, as it's
+   quite easy to optimize well-designed modules, but very hard and costly
+   to make spaghetti-code readable.
+ - Write ChangeLog entries. Whenever you commit a change or send a patch,
+   write a good entry per change to the ChangeLog file, see the libexo
+   ChangeLog for the exact format; it's very important to be descriptive
+   and correct here, else you'll loose your commit bits or your patches
+   won't be considered for inclusion.
+ - Use GObject whenever possible. Object-oriented design and programming
+   makes it easier to separate functionality and also aids in verification
+   and testing, and GObject provides a very solid base.
+
+
+Release process
+===============
+
+Yet to be defined!