Re: Content of GNOME Developer's Guide

[Todd Graham Lewis <tlewis mindspring net>]

On Mon, 16 Nov 1998, John R Sheets wrote:

> - Intro - What is GNOME & what does it offer; quick run-through
> of terms & what the various software packages (e.g. auto*, CVS,
> GTK+) do.

Feel free to take this from the FAQ; Section 1 thereof has a pretty
good introduction.  BTW, what will the license be on the docs?
Verbatim-only redistribution?  Unlimited, but with control over the
title, ala the Artistic license?

> - Part One - Building GNOME Apps
>      (The everpresent Hello World program, hopefully with a
> twist)
>   - Chapter 1: GnomeApp
>   - Chapter 2: Menus
>   - Chapter 3: Toolbars
>   - Chapter 4: Controls (worthy of its own section???)

Do initialization, popt, and the rest merit a separate section?

> - Part Two - GNOME Components
>      (Tools/components unique to GNOME)
>   - Chapter 5: Common Dialogs
>   - Chapter 6: Dialogs
>   - Chapter 7: GnomeCanvas
>   - Chapter 8: Applets (for Panel -- maybe in Appendix??)

Sure.

> - Part Three - The GNOME Framework
>      (The backend glue that holds everything together; only
> needed
>       for advanced GNOME programming)
>   - Chapter 9: Data Storage (XML, config, session mgt.)

Whoa!  SM should get its own section.

>   - Chapter 10: Communication (libGnorba)
>   - Chapter 11: Baboon (reusable components)

Somewhere in here should be a general architectural overview of the
component approach to programming, examples from the COM/OLE world, etc.

> - Appendix
>   - Installation (CVS, Autoconf/make)
>   - Glib Primer (data structures, portability, modules)
>   - GTK+ Primer
>   - Internationalization
>   - Sound

I think that i18n and sound should go in Part 3.  Also, I think that
GLIB should be moved to the front, as programmers _have_ to understand
it and its primacy in order to write good GNOME apps.

Some big components that I don't see mention of are:

	- DnD
	- multiple languages (will the manual be C-only?)
	- OpenGL programming, important for games
	- imlib, which programmers most definitely should know about

This outline looks great!  Please don't take my suggestions to imply that
you haven't done good work here, because you have.  What's the next step?
I'm a big fan of lengthy outlines preceding the actual writing.  Would
people prefer to:

	1) flesh out the outline communally and then divy up the
	implementation, or

	2) divy up the manual and let people outline the sections
	which they own?

I know that the tendency is to do #2, but I think that #1 would result
in a more cohesive and logical manual.  I'm game either way.

Who is actually going to put in work on this project?  I am.  We should
take a tally of who we are so we know when everyone has had his say
on stuff like this.  Or John, would you prefer to be the benevolent
dictator?  I am fine with that, too; it means less work for the rest
of us.  8^)

This should be fun!

--
Todd Graham Lewis            32°49'N,83°36'W          (800) 719-4664, x2804
******Linux******         MindSpring Enterprises      tlewis@mindspring.net