From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Sat, 12 Sep 1998 16:58:17 +0000

Re: Time for a stable version release ?

Andrew Apted wrote:
> 
> Marcus writes:
> >  For libggi Andrew and I had about the same idea of a release plan:
> >
> >  Resolve all remaining API issues by mid-september (hmm, we're
> >  already there ;) maybe a week more) Those are  AFAIK:
> >  * The SYNC issue, which I conider it agreed that ASYNC should be
> >    default.
> 
> Yup.
> 
> >  As for what to to with SYNC mode I suggest we just keep the
> >    mansync code as it is, but the library only get's loaded when you do
> >    ggiAddFlags(SYNC). Then we state in the docs that sync mode is not
> >    threadsafe or signalsafe and generally bad.
> 
> I'm tending to agree with what Andy seems to be saying: either we have
> a SYNC mode that is fully "official" and allowed to be used (and with
> reasonable performance), or have none at all.

The mansync code is "official" and allowed, it's just that it's not
very good, just like now.

> I like Steve's proposal of a "ggiEnableSync()" function that is allowed
> to _fail_ if the target doesn't have SYNC mode behaviour.  Bad programs
> that require it (and die if it isn't available) will be in the same boat
> as bad programs that require DirectBuffer and die if it isn't available.

Yes, I like that too.

> >  * To lock or not to lock... ggiLock/ggiUnlock would greatly increase
> >    the performance of libggi and ease implementation of many things,
> >    and I think it's a piece of cake for users to learn it. Many, if not
> >    most, modern gfx API's that provide both acceleration and direct FB
> >    access have lock/unlock calls anyway.
> 
> I like it, but IMO the function names should be more explicit, such as
> ggiLockFramebuffer() and ggiUnlockFramebuffer() which show just what is
> being locked/unlocked.

Sure. Actually ggiDBLock() and ggiDBUnlock() would be most consistent,
as it is a DirectBuffer you will have direct access too. 

> >  * Andrew, do you have time to implement the nice keyboard-event
> >    scheme we talked about a few weeks ago?
> 
> Yep.  Also I'd like to straighten up the namespace a bit, the
> GGI_KV_xyzzy stuff is inconsistent with the GGI_KEY_XYZZY stuff.
> What is the most agreeable one ?  I think I'd prefer GGI_KEY_Enter,
> GGI_KEY_Escape, GGI_KEY_PageDown, etc...

I'd prefer GGI_Escape, GGI_PageDown (or possibly GGIK_Escape, etc)
An eight character prefix is a little bit overkill to me, and I don't
think users will try to use GGI_PageDown as a graphtype anyway. ;)

> As for ASCII keys, I'd rather we remove the GGI_KV_A (etc) and use 'A'
> and so on, and just keep the non-ascii Latin-1 ones, such as
> GGI_KEY_NoBreakSpace, GGI_KEY_Aacute, GGI_KEY_Ntilde, etc...  The
> rationale is that 'A' is so much easier to write & understand than
> its GGI_* counterpart.

Well, as I said before, I'm probably not the only one that doesn't
know how to type an "asciicircum" or "adiearesis". IMO we should
keep the defines as a convenient service to users, but ofcourse
they can still use the asciivalues if they like, which we should
also state in the docs.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se