Re: Content of GNOME Developer's Guide

[John R Sheets <dusk smsi-roman com>]

Todd Graham Lewis wrote:

> On Mon, 16 Nov 1998, John R Sheets wrote:
>
> When you look at the FAQ, you'll see that it's still an open issue for
> me as well.  Right now the FAQ has a very conservative license which I
> hope to open up.  Stallman has some sort of free literature offshoot
> movement/license thing going on that Alan Cox has spoken highly of.
> I've been meaning to chase it down, but have not done so yet.

Anyone else have thoughts on the licensing issues?  Errr, is anyone else even
_here_?

> > Applets are kind of an odd man out with this book structure.  The appendix is
> > mostly reserved for non-GNOME topics (that's why Glib/GTK are there).  But
> > applets are definitely GNOME.  However, they are more of a specific
> > implementation than a core feature.  I dunno.  Just have to see.
>
> I agree on the odd-man-out count.  Rather than appendices, why not have an
> odds'n'ends section with stuff like the panel, etc.?  Appendices should
> really only be used for peripheral material, not for stuff that's merely
> hard to classify.

Hummm, that's a good point.  We should hash this out some more.  I don't really like
the idea of having an entire Part being "Miscellaneous stuff we couldn't figure out
where else to put".  (Not that that's what you were suggesting.)  Smells of a hack.
I'd rather find some way to integrate it into the base structure of the book.  Maybe
we just need to tweak the Part/Chapter flow a little more.

> > > >   - 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.
> >
> > That would most likely fit in the Appendix (it's looking to be a rather long
> > appendix).
>
> I respectfully disagree.  Understanding what Microsoft did right with OLE
> is essential to groking Baboon.  Baboon is an OLE clone, and explaining
> it without explaining OLE is a mistake IMO.

Oh, you're right.  The OLE blurb should be a preface to the Baboon chapter.

> > > I think that i18n and sound should go in Part 3.
> >
> > Sound, yes; i18n, not sure.  Internationalization is more of a universal
> > feature.
>
> But it is a fundamental GNOME requirement.  I would think that all
> fundamental aspects of the GNOME system should be brought to the
> developer's attention in the document proper, rather than in the
> appendices.  Again, appendices are for supplemental material, not
> for core aspects which are merely hard to fit in.

Agreed.  We should come up with a better content flow that will cover this, too.
Maybe all we need is to alter the title (and thus scope) of the Parts.

> > > 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.
> >
> > Agreed, it's very important, but not really GNOME.  Thus, the appendix.
>
> My point was that it is really GNOME.  GNOME apps should use glib rather
> than their libc counterparts.  If they do so, then they are portable to
> win32 and to God-knows what else.  If they do not do so, then they are
> not portable.  This, like i18n, is a fundamental requirement of GNOME
> apps, at least so far as I understand the requirements.

Yes, we need to discuss this more, as well.  Seems I was a little hasty.  (c:

> > >         - OpenGL programming, important for games
> >
> > Way off topic for GNOME, I think.
>
> I was thinking more of the GtkGlArea stuff which allows one to use
> OpenGL within one's GTK+/GNOME app.  This is an important feature which
> a certain class of developers would be interested in.  It fits in with
> the caanvas as a neat feature available for developers to use.

True, it would fit in with GnomeCanvas.  Maybe we should switch from a
component-based Chaptering system to more of an application-type system....Instead
of GnomeApp, and Menus, and GnomeCanvas, we'd have GNOME Games, GNOME Productivity,
etc.

Actually, no, I don't like that either.  Perhaps a compromise somewhere inbetween?

John