From: Brian S. Julin <bri@tull.umassp.edu>
  To  : Marcus Sundberg , ggi-develop@eskimo.com
  Date: Sat, 3 Jul 1999 15:44:55 -0400 (EDT)

Re: Palette proposal

On Sat, 3 Jul 1999, Marcus Sundberg wrote:
> > As long as this behavior is documented I'm happy.
> 
> Sure, the above is perfectly valid code.

What's the proper procedure for updating the docs -- are the CVS copies
the master copies (just edit the SGML?) or does Steve keep his own
stash?

> > How about having both ggiGetPalette and ggiSetPalette do that on
> > GT_PALETTE visuals,
> 
> Well, if you think it's necessary and are willing to change all
> setpalette functions accordingly I won't mind. ;)

Will do.

> > The documented return code for ggiSetPalette
> > (the first index set) would remain the same when GGI_PALETTE_DONTCARE
> > is used.
> 
> This is documented somewhere? I can not recalled something like
> that being even discussed.

The docs on the WWW site say:

] Return value
]
]   ggiSetPalette returns the number of the first entry changed. Negative
]   values indicate error (codes).
]
]   ggiGetPalette returns 0 for OK, otherwise an error code. When called
]   with len=0 this function will not automatically succeed, but the
]   return code will indicate whether there is a readable CLUT.

> Note that GGI_PALETTE_DONTCARE is free to re-order color entries
> as it likes, so the first index set is about as useful information
> as (random() % palsize)...

I can take this behavior out if it's useless.

> In any case something as major as adding a new graphtype should not
> be done until there is something that can and dose actually use it.

Well, until there is, I can't very well test it anyway, no? :-)

--
Brian